Sentinel (and rEvo)

[Jef Driesen]

On 28-12-15 22:33, "Paul-Erik Törrönen" wrote:
>> 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.

I've never tried a terminal to communicate with a dive computer, but it could be 
that the dive computer uses some timeouts internally. Typing commands might be 
too slow.

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

What part don't you understand? This function takes a dc_buffer_t object that 
has been created by the caller. Inside the dump function, you write the data you 
download from the dive computer into this buffer. It's a dynamic buffer, so you 
can grow the size as necessary.

> 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.

It looks like you created a brand new repository instead of starting from a 
clone of the existing libdivecomputer repository. That makes it very difficult 
to see what you changed.

> 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).

The serial_get_received() function returns the number of bytes that are already 
received by the hardware and waiting in the buffer of the serial driver. So if 
this function returns 0, that means there is no data immediately available. Thus 
the serial_read() function won't return immediately, but waits until some data 
arrives (or the timeout expires).

The call to serial_get_received isn't strictly necessary here. Normally 
libdivecomputer uses fixed sized blocks (for example 1K), but if there is 
already more data immediately available, we can read all at once.

> 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?

That's not impossible, although it looks correct (based on just a quick look). 
Maybe it's just the start of the next dive?

> 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

That corresponds to 8N1. Just double check the prolink software doesn't change 
the settings later on. There are protocols that change settings after some 
initial handshaking.

Jef