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