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