Sentinel (and rEvo)

["Paul-Erik Törrönen"]

> No worries, my rebreather unit is in Britain to be serviced, so I haven't
> had time to test against that.

It came back, with new electronics, so all data was naturally gone. Did a
couple of dives to gather more data.

A status update:

> Anton/Glance did remind me of just using a terminal software (such as
> minicom) to see what the dive computer/rebreather sends back, this should
> be pretty straigthforward since the commands are within the ASCII code
> range.

This appears not to be the case. While I do think I get the correct serial
settings (9600,8bit...), nothing happens when I send the command
characters to the unit.

What is more confounding, though, is that I can't make sense of the
*_device_dump-function called by the universal.

I've created a branch of libdivecomputer which I have uploaded to github.com:

https://github.com/Poltsi/libdivecomputer-sentinel

It has the basic modifications that I mentioned previously, and I've also
temporarily sprinkled som printf's on the vms-sentinel.c to see what is
going on.

The thing is, that currently when I run:

$ examples/universal -b sentinel -l sentinel-002.log -d dives-002.log
/dev/ttyUSB0

I get the following output (enhanced with line numbers):

      2 DATETIME 2015-12-28T20:34:14Z (1451334854)
      3 VERSION 0.5.0-devel (842c4ca466ec56aaff70e7a774a45dde1c95e2d4)
      4 Opening the device (VMS Sentinel, /dev/ttyUSB0).
      5 Registering the event handler.
      6 Registering the cancellation handler.
      7 Downloading the dives.
      8 Event: progress 0.00% (0/128000)
      9 Foo: '0'
     10 nbytes: '0'
     11 SZ_MEMORY: '128000'
     12 Available: '0'
     13 Data n is: '953' expected: '1024'
     14 Data is: '
     15 ver=V009B
     16 Recint=5
     17 SN=4AAD12245D5B7038
     18 V009B
     19 Mem 0, 4000, 919
     20 Memi 5920, 4049, 6839
     21 Start 4001, 757074885
     22 Finish 4002, 757079479
     23 MaxD 4003, 29.64
     24 Status 4004, 0
     25 OTU 4005, 93
     26 Descend prob 4006, 0
     27 DAtmos 4008, 1067
     28 DStack 4009, 7480
     29 DUsage 4010,    9
     30 DCNS 4011, 32.712226
     31 DSafety 4012, 0.004000
     32 Dexpert, 2
     33 Dtpm, 1
     34 DDecoAlg VGM
     35 DVGMMaxDSafety 0.000000
     36 DVGMStopSafety 0.000000
     37 DVGMMidSafety 0.000000
     38 Dfiltertype, 0
     39 Dcellhealth 1, 122
     40 Dcellhealth 2, 134
     41 Dcellhealth 3, 126d
     42 ver=V009B
     43 Recint=5
     44 SN=4AAD12245D5B7038
     45 V009B
     46 Mem 0, 4000, 595
     47 Memi 5325, 4049, 5920
     48 Start 4001, 756997189
     49 Finish 4002, 757000163
     50 MaxD 4003, 43.06
     51 Status 4004, 0
     52 OTU 4005, 66
     53 Descend prob 4006, 0
     54 DAtmos 4008, 1055
     55 DStack 4009, 4655
     56 DUsage 4010,    8
     57 DCNS 4011, 495.495605
     58 DSafety 4012, 0.004000
     59 Dexpert, 2
     60 Dtpm, 1
     61 DDecoAlg VGM
     62 DVGMMaxDSafety 0.000000
     63 DVGMStopSafety 0.000000
     64 DVGMMidSafety 0.000000
     65 Dfiltertype, 0
     66 'cellhealth 1, 122
     67 ERROR: Failed to receive the answer. [in vms_sentinel.c:244
(vms_sentinel_device_dump)]
     68 universal.c:831: Error downloading the dives.
     69 Result: Timeout

What I don't understand is why is

  int available = serial_get_received (device->port);

Returning 0 (line 12), but then

  n = serial_read (device->port, data + nbytes, len);

Returns 953 (line 13).

Also there is something else strange going on as line 42 is essentially a
repeat of line 15 and line 66 is a corrupted 39.

Could it be that the serial settings are not correct?

What I see from the portmon logs is:

19  0.00000000  ProLink2010oct.  IOCTL_SERIAL_SET_LINE_CONTROL  Silabser0 
StopBits: 1 Parity: NONE WordLength: 8
20  0.00000000  ProLink2010oct.  IOCTL_SERIAL_SET_CHAR  Silabser0  EOF:1a
ERR:0 BRK:0 EVT:0 XON:11 XOFF:13

Poltsi

-- 
Paul-Erik Törrönen   poltsi at 777-team.org
+358 40 703 1231     http://poltsi.fi/

     Science, it reduces the stupid