Sentinel (and rEvo)

[Jef Driesen]

On 2016-01-10 00:39, Paul-Erik Törrönen wrote:
>> A very important question is: how do you know the response has been
>> received completely? Some communication protocols use fixed size
>> packets, so you know the length in advance. If the length is variable,
>> then very often it's communicated somewhere in the first bytes of the
>> response. And if that's not the case, then you have to rely on a
>> timeouts (e.g. you assume the response is complete if no byte arrives
>> within a certain time). That's also the most error-prone method 
>> because
>> you can't distinguish from a timeout due to some error.
> 
> Looking at the portmon dumps, there are no explicit values passed which
> would tell the length of the requested data. There are two lines in the
> header, Mem and Memi which both carry multiple numerical values, but I
> have not comprehended their function yet.
> 
> My suspicion is that for the header part it is 'known' in the sense 
> that
> it has certain lines.
> 
> As for the dive telemetry, it begins with a 'Profile'-line, and ends 
> with
> a 'End'-line followed by '@@'-line. The lines are dos-terminated, ie.
> \r\n.
> 
> As you say, this is quite inaccurate, and I don't think even the 
> original
> software always manage to handle this correctly.

I suspect that their software is reading the response line by line, 
using the \r\n sequence as the end-of-line marker. And then that 'End' 
followed by '@@' as the end-of-message marker. That probably also 
explains why they are reading single bytes: they have to inspect every 
byte to find for those markers.

> What I meant was that I can presume that I should be reading just one 
> byte
> at a time in the dump-function, instead of trying to use dynamic 
> buffers
> as I do now in the function.

Reading one byte at a time isn't the most efficient, but if it's 
necessary then fine. You'll still need a dynamic buffer, because you 
don't know how many bytes you'll receive. Just append each byte, and the 
buffer will grow automatically.

>>> So this equals to:
>>> read: PPP
>>> read: P
>>> read: P
>>> read: P
>>> send: M
>>> read: d
>>> read: \r
>>> read: \n
>>> read: v
>>> ...
> 
>> This is right after opening the serial port, so it could be that the
>> dive computer is telling you "I'm ready to receive commands". Maybe it
>> keeps sending this byte until it receives a command?
> 
> 'this byte' would be P. And once I reply with the M-byte, I start
> receiving the header data. The response should start with a 'd\r\n' 
> when
> the header part is returned, so the above would look like:
> 
> d
> ver=V009B
> Recint=5
> SN=4AAD12245D5B7038
> V009B
> Mem 0, 4000, 1192
> ...
> 
>> This might also be
>> the reason why the communication is unstable: If you are trying to 
>> send
>> too fast, the dive computer isn't ready yet, and your command might 
>> got
>> lost.
> 
> I don't think so. I do receive the 'wait' byte (ie. 'P'), and my 
> response
> is a single byte ('M').

How does the response looks like when it fails? Do you still get the P 
bytes?

> I've uploaded the Portmon logs as well as the actual downloaded data 
> here:
> 
> http://poltsi.fi/Sukeltaminen/Sentinel/portmon-logs.tar.bz2
> 
> The portmon logs are in the main directory and are named as 
> <device>-<unit
> number>-<date>-<purpose>-<attempt>.log
> 
> My unit# is 328, but I also borrowed the #007 from my friend,
> unfortunately his unit did not have the PC link PIN, so I was unable to
> download actual dive data from that unit. Also to note is that the
> electronics was switched on my unit, so between November and December 
> the
> firmware version (ver=) as well as serial number (SN=) changed. The
> purpose is loosely at what point of actions the recording is. Connect 
> is
> when I start the Prolink software and it connects to the rebreather,
> download is when I explicitly select to download either a single dive, 
> or
> all new dives. The attempt is a running number, as I noticed only later
> that I need to restart portmon in order to properly get separate logs 
> for
> different actions.
> 
> There are 3 sub-directories:
> 
> dump-parsed
> pm-parsed
> prolink-parsed
> 
> Dump-parsed is the output from my script (dump_parser.sh) of each
> portmon-log, and contains the WRITE/READ data.
> pm-parsed is the output from your parser, the directory contains 
> separate
> read and write-files for each portmon-log.
> prolink-parsed contains the downloaded data stored by ProLink, which is
> the original software. Since my portmon-logs may contain the download 
> of
> several dives, I have named them as <portmon filename>-n.log.
> 
> Amd of course the parsing scripts themselves.
> 
> I noticed that the last portmon-log did not put the actual read data on
> the same line as the IRP_MJ_READ, instead it looked like this:
> 
> 68  0.00000000  ProLink2010oct.  IRP_MJ_READ  Silabser0  Length 1
> 68  0.00000559  SUCCESS  Length 1: 50
> 
> Even if I had not touched the settings of portmon between this and the
> previous logging.

I've never noticed this before. Strange. Still will certainly causes 
issues for my scripts.

> There is also something odd going on with the pm-based parser, for 
> example
> the Sentinel-328-20160104-Download-001.log-read is only 14k, while the
> actual data is almost 10x that, both in the prolink-parsed as well as
> dump-parsed.

It's caused by another "error" in the portmon file. Normally read 
operations contain "Length n: XX YY ZZ" in the 7th column. But in your 
files there are a few with just "Length 1". My sed regex doesn't 
recognizes that pattern and leaves it in, and that causes trouble when 
xxd tries to convert the data back to binary.

Modify the sed line in the pm-simplify-rw script as follows:

sed -e 's/IRP_MJ_//' -e 's/IOCTL_SERIAL_//' -e 's/Length [0-9]*//' -e 
's/: //' | \

Jef