Unable to connect Eon Core

[divegoa]

• Version I am using is 4.7.7
• OS running is Linux Mint 18.2 64 bit.
• Dive Computer is Eon Core

Subsurface gives error: unable to open /dev/ttyS30 Suunto (Eon Core)

I have added user to dialout group

 

Does Subsurface not support the Eon Core? Eon Core is in the import dropdown list, But Eon Core is not on the list of supported dive computers on the documentation page. 

What can I do?

[divegoa]

lsusb -v  gives me this:

Bus 001 Device 005: ID 1493:0033 Suunto 

Couldn't open device, some information will be missing

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               2.00

  bDeviceClass            0 (Defined at Interface level)

  bDeviceSubClass         0 

  bDeviceProtocol         0 

  bMaxPacketSize0        64

  idVendor           0x1493 Suunto

  idProduct          0x0033 

  bcdDevice            0.00

  iManufacturer           1 

  iProduct                2 

  iSerial                 3 

  bNumConfigurations      1

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           48

    bNumInterfaces          1

    bConfigurationValue     1

    iConfiguration          0 

    bmAttributes         0x80

      (Bus Powered)

    MaxPower              100mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           3

      bInterfaceClass         3 Human Interface Device

      bInterfaceSubClass      0 No Subclass

      bInterfaceProtocol      0 None

      iInterface              0 

        HID Device Descriptor:

          bLength                 9

          bDescriptorType        33

          bcdHID               1.01

          bCountryCode            0 Not supported

          bNumDescriptors         1

          bDescriptorType        34 Report

          wDescriptorLength      36

         Report Descriptors: 

           ** UNAVAILABLE **

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x02  EP 2 OUT

        bmAttributes            3

          Transfer Type            Interrupt

          Synch Type               None

          Usage Type               Data

        wMaxPacketSize     0x0040  1x 64 bytes

        bInterval               1

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x82  EP 2 IN

        bmAttributes            3

          Transfer Type            Interrupt

          Synch Type               None

          Usage Type               Data

        wMaxPacketSize     0x0040  1x 64 bytes

        bInterval               1

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x83  EP 3 IN

        bmAttributes            3

          Transfer Type            Interrupt

          Synch Type               None

          Usage Type               Data

        wMaxPacketSize     0x0040  1x 64 bytes

        bInterval               1

[Miika Turkia]

if you run command "id" on a terminal, does it show that you belong to the dialout group? It might take a relogin for the new group to become effective. IIRC EON CORE should work, documentation might need an update..

[Linus Torvalds]

On Thu, Mar 29, 2018 at 6:47 PM, divegoa <div...@gmail.com> wrote:
>
> Does Subsurface not support the Eon Core? Eon Core is in the import dropdown
> list, But Eon Core is not on the list of supported dive computers on the
> documentation page.

The EON Core is indeed supported, and it should just work. I wonder if
it's the "oops, we disabled USB HID by mistake" problem, but I don't
think that affected the released 4.7.7. Dirk?

One thing to look out for is to make sure you have the right
permissions. By default, most distros seem to disallow access to USB
HID devices (like the EON Steel), and you may need something like
this:

SUBSYSTEM=="usb", ATTRS{idVendor}=="1493",
ATTRS{idProduct}=="0033", MODE="0666"

in a udev rules file.

So you can do something like

echo 'SUBSYSTEM=="usb", ATTRS{idVendor}=="1493",
ATTRS{idProduct}=="0033", MODE="0666"' >
/usr/lib/udev/rules.d/91-suunto-eonsteel.rules

or similar.

Linus

[divegoa]

I've added the udev rules,( not thru terminal ) but by copying the files.

The udev rules were in the /etc/udev/ directory. I've copied them to the usr/lib/ directory and rebooted. 

This hasn't helped. It still gives unable to open /dev/ttyS30 Suunto (Eon Core)

What else can I try?

[Linus Torvalds]

On Thu, Mar 29, 2018 at 9:26 PM, divegoa <div...@gmail.com> wrote:
> This hasn't helped. It still gives unable to open /dev/ttyS30 Suunto (Eon
> Core)
>
> What else can I try?

I'm traveling, but I'll be back home this weekend and will take a look.

We do have a few unfortunate special cases that trigger only for the
EON Steel and might leave the EON Core broken. But they are
elsewhere than your thing (like bluetooth discovery and some cylinder
size fixups). It all *should* just work, but we haven't had an EON
Core to test with.

That actually is changing - I was on a boat with a diver that had the
EON Core so I saw it in real life for the first time. I'll be
replacing my EON Steel with one, it fixes the biggest gripe I had with
the EON Steel.

So remind me on Monday if I haven't already answered more fully.

I do have one question: are you able to build your own subsurface
binaries for testing? That would help enormously if I end up having a
test patch for you.

Linus

[Linus Torvalds]

On Fri, Mar 30, 2018 at 10:38 AM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> I'm traveling, but I'll be back home this weekend and will take a look.

Ok, I'm home, and as promised, took a look.

It all works for me. I had an EON Core waiting for me when I came home
(because when I decide to do something, I act on it, and Amazon loves
me). I don't have any *dives* on it, but it works fine for me.

And by "fine for me", I mean "I connected fine, and noticed that the
time and date setting code in libdivecomputer only sets the time, not
the date".

I'd never noticed on my EON Steel, because that always had the date
set on it correctly already for other reasons, but my "let's try a
brand new EON Core" case obviously showed "oops, it didn't sync the
date".

So I did actually fix a small detail in libdivecomputer, but the only
reason I even noticed that is because I have a local hack to
subsurface that just always syncs time on download. Nobody else would
ever have noticed that thing.

If your permissions are right, I suspect that it's the silly
"unintentionally disable LIBUSB" bug we had.

But check your permissions first, in case there's something wrong with
your udev rule. When you do 'lsusb', you should see something like

Bus 003 Device 007: ID 1493:0033 Suunto

(the Bus/Device numbers will obviously vary depending on where you've
plugged things in), and then you should check that the permissions on
the node (agan, the 003/007 depends on that bus/device number, change
it to match yours):

/dev/bus/usb/003/007

are right, and you can access it as a normal user. That's what the
udev rule *should* have done.

Anyway, if you see the EON Core in lsusb, and the permissions are ok,
the problem is the subsurface install.

Dirk - I pushed out my date setting fix to the libdivecomputer git
trees. And I see you fixed the LIBUSB issue. Are there new daily
builds somewhere?

Linus

[Dirk Hohndel]

> On Apr 1, 2018, at 10:10 AM, Linus Torvalds <torv...@linux-foundation.org> wrote:
> Dirk - I pushed out my date setting fix to the libdivecomputer git
> trees. And I see you fixed the LIBUSB issue. Are there new daily
> builds somewhere?

Yesterday the Linux builds on Travis kept failing in the tests and I haven't
figured out why... But that didn't prevent the builds from finishing. The latest
builds are always here:

https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous

This includes an AppImage for Linux as well as Windows installer and (usually)
an unsigned Mac DMG (but I see that right now that is missing - something else
I should look into).

I'll update the Subsurface submodule to pull in the latest libdivecomputer date setting
fix which as a side effect will also trigger new daily builds

/D

[divegoa]

UPDATE:  ITS WORKING !!

I compiled and ran subsurface but still found problems connecting to the EON Core. 

I imported the dive log file from DM5 successfully, but found that it showed the temperature data incorrectly. 

After confirming that I was a part of the dialout group, It was the udev permissions that were the problem, as Linus had pointed out.

I had manually typed them in, and had wrongly typed ATTRS{idProduct}=="0030" instead of "0033"

I corrected this in all the 99-Suunto files, and I'm able to import the dive logs from the Eon Core. I have no idea if this solved the problems, but it is working now.

Its still says there is some error, but it imports the logs.

This is what I get in terminal:

Starting download from  /dev/ttyS31

Starting the thread 0

[0.021265] ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT). [in ../../src/usbhid.c:774 (dc_usbhid_read)]

INFO: dc_deveice_open error value of 0

Finishing the thread  dives downloaded 4

Thanks for all your help, guys!

[Linus Torvalds]

On Mon, Apr 2, 2018 at 8:36 AM, divegoa <div...@gmail.com> wrote:
> UPDATE: ITS WORKING !!

Ahh, good.

> I imported the dive log file from DM5 successfully, but found that it showed
> the temperature data incorrectly.

Interesting. Some older DM5 versions used to always round to nearest
°C (which is annoying when the dive computer actually does 0.1°C
resolution, and then you round to whole degrees Celsius, and can't
show it right in the US Freedom Units).

But I thought Suunto got it right apart from that (and I had assumed
they'd have fixed the rounding too).

> I had manually typed them in, and had wrongly typed ATTRS{idProduct}=="0030"
> instead of "0033"

Well, 0030 isn't wrong - that's just the EON Steel (and 0031 is EON
Steel too, just in "firmware upgrade mode").

The EON Core updated it to 0033.

> I corrected this in all the 99-Suunto files, and I'm able to import the dive
> logs from the Eon Core. I have no idea if this solved the problems, but it
> is working now.

Good. Except you probably shouldn't edit the 0030 to 0033, you should
duplicate the line so that EON Steel and EON Core both work.

> Its still says there is some error, but it imports the logs.
> This is what I get in terminal:
> Starting download from /dev/ttyS31
> Starting the thread 0
> [0.021265] ERROR: Usb read interrupt transfer failed (LIBUSB_ERROR_TIMEOUT).
> [in ../../src/usbhid.c:774 (dc_usbhid_read)]

This initial error is actually expected, it's because the downloading
starts out by trying to empty any existing pending data from a
previous (failed) download. Normally no such data exists, of course,
and you get the warning about "hey, read timed out".

We used to avoid it by having a special "read to empty" function, but
that didn't work well with some libdivecomputer changes, so now we
just have that silly warning.

So all is good, as long as you get only that *one* warning at the
download start. Any further error reports after that would be signs of
communication problems.

> INFO: dc_deveice_open error value of 0

Yeah, this is a stupid mis-spelling _and_ an information that
everything was right (error = 0).

Again, it's all just information that you can ignore, all is good.

> Finishing the thread dives downloaded 4

.. and it downloaded (all?) four dives, and we're good.

NOTE! There might be some information that we are missing for unusual
cases, it's possible that the newer firmware has added fields that we
don't look at. But please go through and check everything looks ok,
including the "Extra Info" tab that should show various special Suunto
EON Core/Steel specific stuff (ie battery for both the dive computer
and any possible transmitters you had, deco algorithm, etc).

I may now have an EON Core and I've updated to the latest firmware,
but since I don't have any dives with it yet I can't check if there
are any new things it might report.

But we should import all the *basic* data just fine, I don't think any
of the core protocol has changed.

Linus

[Anton Lundin]

Random rambla about Suunto Eon Steel and udev, is to add:

SUBSYSTEM=="hidraw*", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0030", MODE="0660", GROUP="plugdev"

SUBSYSTEM=="hidraw*", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0031", MODE="0660", GROUP="plugdev"

To your udev rules.

That enables you to run dm5 via wine to firmware upgrade and customize the device. Works surprisingly well.

The winetricks applied to be able to run dm5 are: vcrun2013 remove_mono dotnet40

//Anton

[Miika Turkia]

On Monday, April 2, 2018 at 6:36:17 PM UTC+3, divegoa wrote:

UPDATE:  ITS WORKING !!

I compiled and ran subsurface but still found problems connecting to the EON Core. 

I imported the dive log file from DM5 successfully, but found that it showed the temperature data incorrectly.

Can you send me your DM5 log and describe precisely how the temperatures are incorrect? We should fix this problem for others even though you got the download working directly from EON Core.

[Dive Goa]

In case this helps: following the subsurface documentation manual, I checked that:

I am in the dialout group:

ajey@Thresher / $ id ajey

uid=1000(ajey) gid=1000(ajey) groups=1000(ajey),4(adm),20(dialout),24(cdrom),27(sudo),30(dip),46(plugdev),113(lpadmin),130(sambashare)

dmesg gives:

 usb 1-1.2: new full-speed USB device number 4 using ehci-pci

[ 2823.715961] usb 1-1.2: New USB device found, idVendor=1493, idProduct=0033

[ 2823.715971] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3

[ 2823.715976] usb 1-1.2: Product: GURU2

[ 2823.715980] usb 1-1.2: Manufacturer: Suunto

[ 2823.715984] usb 1-1.2: SerialNumber: 00000000

[ 2824.167827] hidraw: raw HID events driver (C) Jiri Kosina

[ 2824.211950] usbcore: registered new interface driver usbhid

[ 2824.211958] usbhid: USB HID core driver

[ 2824.325989] hid-generic 0003:1493:0033.0001: hiddev0,hidraw0: USB HID v1.01 Device [Suunto GURU2] on usb-0000:00:1a.0-1.2/input0

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

On 1 April 2018 at 23:55, Dive Goa <in...@divegoa.com> wrote:

Hi, 

I've never compiled anything before, but I followed these instructions and compiled the source code : 

I did this:

Package names for Ubuntu 16.10

sudo apt-get install git g++ make autoconf automake libtool cmake pkg-config \

libxml2-dev libxslt1-dev libzip-dev libsqlite3-dev \

libusb-1.0-0-dev libssl-dev \

qt5-default qt5-qmake qtchooser qttools5-dev-tools libqt5svg5-dev \

libqt5webkit5-dev libqt5qml5 libqt5quick5 qtdeclarative5-dev \

qtscript5-dev libssh2-1-dev libcurl4-openssl-dev qttools5-dev \

qtconnectivity5-dev qtlocation5-dev qtpositioning5-dev \

libcrypto++-dev libssl-dev qml-module-qtpositioning qml-module-qtlocation \

qml-module-qtquick2

and then this:

mkdir -p ~/src

cd ~/src

git clone https://github.com/Subsurface-divelog/subsurface.git

./subsurface/scripts/build.sh

Subsurface is now running, but when i connect the Eon Core and try to download the dives, Subsurface still throws up "unable to open /dev/ttyS31 Suunto Eon Core" message. 

Terminal showed:

Starting download from  /dev/ttyS31

Starting the thread 0

[0.007922] ERROR: Failed to open the usb device (LIBUSB_ERROR_ACCESS). [in ../../src/usbhid.c:666 (dc_usbhid_open)]

[0.008027] ERROR: unable to open device [in ../../src/suunto_eonsteel.c:776 (suunto_eonsteel_device_open)]

INFO: dc_deveice_open error value of -5

Finishing the thread Unable to open %s %s (%s) dives downloaded 0

lsusb gives me:

ajey@Thresher / $ lsusb

Bus 002 Device 003: ID 147e:1002 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 003: ID 04f2:b257 Chicony Electronics Co., Ltd Lenovo Integrated Camera

Bus 001 Device 004: ID 1493:0033 Suunto 

Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Followed your instructions and it looks like I don't have permissions:

ajey@Thresher / $ /dev/bus/usb/001/004

bash: /dev/bus/usb/001/004: Permission denied

Is this what is causing the issue? How do I set permissions/ udev rules??

Thanks!

Ajey

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

              Linus

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsubscribe@googlegroups.com.
To post to this group, send email to subsurface-divelog@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFzY2HDCXpM89%3Dg6p4-931YXwrkmz9gFFBQ5s%3D8w1BNGNg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Dive Goa]

              Linus

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To post to this group, send email to subsurface-divelog@googlegroups.com.

[Dive Goa]

There is however:

/etc/udev/rules.d/91-suunto-eonsteel.rules

Should i copy this to /usr/lib ?

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

On 30 March 2018 at 11:37, Dive Goa <in...@divegoa.com> wrote:

Okay, looks like there is no udev directory. 

bash: /usr/lib/udev/rules.d/91-suunto-eonsteel.rules: No such file or directory

Could you please help me with how to add this ?

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsubscribe@googlegroups.com.

To post to this group, send email to subsurface-divelog@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFwKC55rOHQ040A7M_di6Cq%2BKX0NOACkO9kCbaRsoU7MWQ%40mail.gmail.com.

[Dive Goa]

Also, I just imported the DM5.db file to subsurface, and I noticed that for some reason it shows the temperature of the dive incorrectly, as a constant 45 degrees C. It shows correctly as 30 degrees C on the computer and on DM5. 

Regards,

Ajey

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

[Dive Goa]

Okay, looks like there is no udev directory. 

bash: /usr/lib/udev/rules.d/91-suunto-eonsteel.rules: No such file or directory

Could you please help me with how to add this ?

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

On 30 March 2018 at 10:47, Linus Torvalds <torv...@linux-foundation.org> wrote:

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To post to this group, send email to subsurface-divelog@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFwKC55rOHQ040A7M_di6Cq%2BKX0NOACkO9kCbaRsoU7MWQ%40mail.gmail.com.

[Linus Torvalds]

On Thu, Mar 29, 2018 at 11:32 PM, Dive Goa <in...@divegoa.com> wrote:

There is however:

/etc/udev/rules.d/91-suunto-eonsteel.rules

Should i copy this to /usr/lib ?

No, that looks like the right place for Ubuntu. Some googling gets me

   http://manpages.ubuntu.com/manpages/xenial/man7/udev.7.html

and in particular:

      "The udev rules are read from the files located in the system rules

       directory /lib/udev/rules.d, the volatile runtime directory

       /run/udev/rules.d and the local administration directory

       /etc/udev/rules.d."

so /etc/udev/rules.d is the right directory for your local admin case. 

Just make sure that file contains all three ID's (0030, 0031 and 0033) and looks something like this (sorry, this will line-wrap in the email, there should be three long lines, one for each entry):

   SUBSYSTEM=="hidraw*", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0030", MODE="0660", GROUP="plugdev"

   SUBSYSTEM=="hidraw*", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0031", MODE="0660", GROUP="plugdev"

   SUBSYSTEM=="hidraw*", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0033", MODE="0660", GROUP="plugdev"

and it should all be good. You may need to reload the rules explicitly (no need to reboot):

   sudo udevadm control --reload

and you may want to unplug and re-plug the device itself to make sure it all takes.

                  Linus

[Miika Turkia]

The DM5 sample logs I have show the temperature correctly. Could you send your DM5.db to me so I can see what is wrong with it for you? Might be that something has been changed in newer version of DM5...

[Dive Goa]

Hi Miika, 

 I'll send you the .db file, but that error happened only once, when the Eon Core wasn't connecting.  I should have taken a screenshot. It showed the temperature as a constant 45 degrees C on all the dives. 

Now it imports the logs correctly. I'll try to see if the error replicates, by clearing the logs and importing the .db file again. 

DIVE GOA Phone: +91 9325030110 Goa: SinQ Beach Club, Opp. Taj Holiday Village, Sinquerim Netrani: RNS Residency, Murudeshwar, Karnataka Website: www.divegoa.com

--

You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To post to this group, send email to subsurface-divelog@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/685fbd86-c762-40e5-ae14-1ded68bd1f59%40googlegroups.com.

[Dive Goa]

Hi, 

​Attached: DM5 database that gave the error. 

Haven't had time to import it and check if it gives the same error. 

[Linus Torvalds]

On Wed, Apr 4, 2018 at 9:09 AM, Miika Turkia <miika....@gmail.com> wrote:
>
> Thanks. The problem does reproduce with this sample. So far I have not been able to figure out what has actually changed and how the temperature should be parsed from your log. I wonder if DM5 has changed something or what. Will need to dig into this more...

Isn't the old temperature format just in whole degrees Celsius?

The newer Suunto dive computers support 0.1°C temperatures - I bet
they left the old byte alone (maybe with some insane value), and added
a new field that has temperatures in tenths of degree Celsius.

[ Hmm. Goes and looks a bit ]

The old temperature format was a single byte temperature in C, but you
have some logic for a two-byte one for dm5:

int32_t temp = (sampleBlob[i * block_size + 10] << 8) +
sampleBlob[i * block_size + 11];

and then

if (temp >= -10 && temp < 50)
cur_sample->temperature.mkelvin = C_to_mkelvin(temp);

which is odd for several reasons.

One reason is that the way you decode it, the temperature cannot be
negative. It's between 0-65535.

The other reason is that even if the sign was fixed, it would still be
insane to encode a temperature value between -10 and 50 in a 16-bit
field.

So there's something odd going on. But I've never looked at the DM5
format, so ..

Side note: the code just above this does:

float *depth = (float *)&sampleBlob[i * block_size + 3];

which will only work on little-endian machines that don't have issues
with alignment.

Thankfully, nothing else is relevant or will ever be. ARM got with the
program eventually.

Linus

[Miika Turkia]

On Friday, April 6, 2018 at 7:22:34 PM UTC+3, Linus Torvalds wrote:

On Wed, Apr 4, 2018 at 9:09 AM, Miika Turkia <miika....@gmail.com> wrote:
>
> Thanks. The problem does reproduce with this sample. So far I have not been able to figure out what has actually changed and how the temperature should be parsed from your log. I wonder if DM5 has changed something or what. Will need to dig into this more...

Isn't the old temperature format just in whole degrees Celsius?

Yep, seems to be so.
 

The newer Suunto dive computers support 0.1°C temperatures - I bet
they left the old byte alone (maybe with some insane value), and added
a new field that has temperatures in tenths of degree Celsius.

I would not be surprised. At least the old field appears to contain bogus data.
 

[ Hmm. Goes and looks a bit ]

The old temperature format was a single byte temperature in C, but you
have some logic for a two-byte one for dm5:

        int32_t temp = (sampleBlob[i * block_size + 10] << 8) +
sampleBlob[i * block_size + 11];

and then

        if (temp >= -10 && temp < 50)
                cur_sample->temperature.mkelvin = C_to_mkelvin(temp);

which is odd for several reasons.

I noticed that also when looking into this. Makes me wonder where this parsing came from. Why would I have thought the temp is larger in DM5 than what it was in DM4?
 

One reason is that the way you decode it, the temperature cannot be
negative. It's between 0-65535.

The other reason is that even if the sign was fixed, it would still be
insane to encode a temperature value between -10 and 50 in a 16-bit
field.

So there's something odd going on. But I've never looked at the DM5
format, so ..

I guess I will have to look into it again. Too bad that looking at the code does not give any hints on where from some of that parsing weirdness came from. :D
 

Side note: the code just above this does:

        float *depth = (float *)&sampleBlob[i * block_size + 3];

which will only work on little-endian machines that don't have issues
with alignment.

Thankfully, nothing else is relevant or will ever be. ARM got with the
program eventually.

IIRC there is quite a bit of little-endian only code there...

miika

[Linus Torvalds]

On Fri, Apr 6, 2018 at 12:09 PM, Miika Turkia <miika....@gmail.com> wrote:
>
> I guess I will have to look into it again. Too bad that looking at the code
> does not give any hints on where from some of that parsing weirdness came
> from. :D

Yeah, whoever did that commit 5807e4589 ("Initial support for Suunto
DM5 import") really didn't leave a lot of hints around.

> IIRC there is quite a bit of little-endian only code there...

I think it's fine. libdivecomputer tries to care about byte order
issues and unaligned accesses, but I think the days when it mattered
to normal people are largely over.

Linus

[Miika Turkia]

On Friday, April 6, 2018 at 10:34:29 PM UTC+3, Linus Torvalds wrote:

On Fri, Apr 6, 2018 at 12:09 PM, Miika Turkia <miika....@gmail.com> wrote:
>
> I guess I will have to look into it again. Too bad that looking at the code
> does not give any hints on where from some of that parsing weirdness came
> from. :D

Yeah, whoever did that commit 5807e4589 ("Initial support for Suunto
DM5 import") really didn't leave a lot of hints around.

 
Seems that the same field is still used but depending on blob version it is either decimal or float. And a nice twist was that if some samples don't record the temperature it is indicated by 0x7f in the field. Anyway, I added also some comments that might make it slightly easier for next time to understand what is going on.

https://github.com/Subsurface-divelog/subsurface/pull/1193

[Linus Torvalds]

On Fri, Apr 6, 2018, 22:29 Miika Turkia <miika....@gmail.com> wrote:

 
Seems that the same field is still used but depending on blob version it is either decimal or float. And a nice twist was that if some samples don't record the temperature it is indicated by 0x7f in the field. Anyway, I added also some comments that might make it slightly easier for next time to understand what is going on.

I'm on mobile right now, but your code looks off.

   C_to_mkelvin(lrint(temp[0] * 1.0f))

What?

Why lrint()? Why "* 1.0f"?

Why isn't this just 

    C_to_mkelvin(*temp)

Which actually uses the actual new precision of the value..

   Linus

[Miika Turkia]

On Sat, Apr 7, 2018 at 8:42 AM, Linus Torvalds <torv...@linux-foundation.org> wrote:

On Fri, Apr 6, 2018, 22:29 Miika Turkia <miika....@gmail.com> wrote:

 
Seems that the same field is still used but depending on blob version it is either decimal or float. And a nice twist was that if some samples don't record the temperature it is indicated by 0x7f in the field. Anyway, I added also some comments that might make it slightly easier for next time to understand what is going on.

I'm on mobile right now, but your code looks off.

   C_to_mkelvin(lrint(temp[0] * 1.0f))

What?

Why lrint()? Why "* 1.0f"?

Left overs from trying to figure out how this value was stored.

 

Why isn't this just 

    C_to_mkelvin(*temp)

Which actually uses the actual new precision of the value..

Much better this way.

miika

[phillefjonk]

I use the Suunto EON Core and Linux Mint 19 on a Lenovo X1 Carbon Laptop 

This is my UDEV rule, which creates a mount point /dev/suunto

$ cat /etc/udev/rules.d/91-suunto-eoncore.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="1493", ATTRS{idProduct}=="0033", GROUP="users", MODE="0666", NAME="Suunto", SYMLINK="suunto"

Works fine