Sentinel (and rEvo)

Sat Jan 9 15:39:41 PST 2016

> 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'm not sure if this is relevant, but I've noticed that many dive
> computers need some time between setting up the serial line, and
> starting the communication by sending bytes. If you'll look at the other
> backends, you'll notice many sleep calls with a delay of several hundred
> milliseconds. So that's certainly worth trying.

Ok, I'll try with putting in some sleeps between the initialization of the
serial connection, and requesting a dump.

>> FWIW is it meaningful that the portmon log seems to indicate single byte
>> read most of the time, or is it just an artifact of how portmon logs the
>> communication?
> Portmon has nothing to do with this. It's the application that is
> reading single bytes.

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.

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

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.

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.

Poltsi

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

     Science, it reduces the stupid