Sentinel (and rEvo)

[Jef Driesen]

Sorry, I just noticed I forgot to answer your email.

On 15-11-15 12:12, "Paul-Erik Törrönen" wrote:
>> You can look at one of the simpler backends, like the cressi leonardo.
>> But the first step will be to figure out how the protocol works, and how
>> to interpret the data. Since it seems to be ascii based, you won't need
>> much coding there.
>
> Well the interpretation is done, largely because the OPOS stored the
> received ASCII as a txt-file :-)
>
> Therefrom it was quite easy to map the columns to various datasets. I have
> insofar recognized the following data-sets:
>
> Time step (the step size is given previously)
> Depth
> pO2
> Temp
> Filter (%)
> Battery 1
> Battery 2
> Dil (bar)
> O2 (bar)
> O2 Cell 1
> O2 Cell 2
> O2 Cell 3
> Setpoint
> Ceiling (m)
> Tempstick 1
> Tempstick 2
> Tempstick 3
> Tempstick 4
> Tempstick 5
> Tempstick 6
> Tempstick 7
> Tempstick 8
> CO2 (mbar)
>
> The values are given as non-padded whole numbers up to 3 chars and most of
> them are prefixed with a unique alphabet character.
>
> There are also two optional fields (in the middle) which contain any
> events such as setpoint increase or low pO2.
>
> A question: Can libdivecomputer currently store all these different sensor
> datas?

No, libdivecomputer's api doesn't support all those fields. Depth, pO2, 
temperature, gasmix, setpoint and deco/ndl info are supported. The others not. I 
don't even know what they are (e.g. tempstick).

>> Maybe you only captured part of the download? I suggest you keep
>> capturing with portmon for as long as the sentinel application is
>> running.
>
> I thought I did this since I could in the end only see what I presumed was
> the idle-polling status when I hit the save to log. It may be that I
> haven't fully understood how to use the portmon. IMO it is not the most
> intuitive software.

Maybe you missed the part at the beginning? Some applications immediately start 
to communicate with a device as soon as it gets connected. So that happens 
without any action from the user. In such case it's best to connect the device, 
start capturing with portmon, and only then start the application.

> Which reminds me, do you have the parser-scripts you mentioned available
> anywhere?

I attached the scripts to this email. The three pm-simplify scripts will remove 
the useless info from the portmon file. If you have an applications that 
continuesly polls the serial port, then the mini variant will remove that as 
well. And the "rw" variant only keeps the I/O operations. Pipe the output of the 
rw variant to the pm-merge script, to join consecutive read/writes and make the 
result even more human readable.

And since you are dealing with ascii data, you can easily filter out the 
received data, and then convert the hexadecimal data back into ascii:

./pm-simplify-rw portmon.log | ./pm-merge | \
grep READ | sed 's/READ\t//' | xxd -p -r

That's how I extracted the data last time.

Jef
-------------- next part --------------
#!/usr/bin/perl

my $previous;

while (my $line = <STDIN>) {
	if ($line =~ /^(.*)\t(.*)$/) {
		if ($previous eq $1) {
			print "$2";
		} else {
			if (defined $previous) {
				print "\n"
			}
			print "$1\t$2";
		}
		$previous = $1;
	}
}

print "\n";
-------------- next part --------------
#!/bin/sh

cat "$@" | \
	awk -F '\t' '{OFS="\t"} {print $4,$7}' | \
	sed -e 's/IRP_MJ_//' -e 's/IOCTL_SERIAL_//' -e 's/Length .*: //'
-------------- next part --------------
#!/bin/sh

cat "$@" | \
	awk -F '\t' '{OFS="\t"} {print $4,$7}' | \
	sed -e 's/IRP_MJ_//' -e 's/IOCTL_SERIAL_//' -e 's/Length .*: //' | \
	grep -v -e 'GET_COMMSTATUS' -e 'WAIT_ON_MASK' -e 'SET_WAIT_MASK'
-------------- next part --------------
#!/bin/sh

cat "$@" | \
	awk -F '\t' '{OFS="\t"} {print $4,$7}' | \
	sed -e 's/IRP_MJ_//' -e 's/IOCTL_SERIAL_//' -e 's/Length .*: //' | \
	grep -e 'WRITE' -e 'READ'