No, you only replied to me, and not the mailinglist :-)

Ah, drat! Sorry for that.

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?

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.

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

Poltsi

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

No worries, my rebreather unit is in Britain to be serviced, so I haven't had time to test against that.

In the meantime though, I've been busy trying to relearn C.

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

It would make sense to at least support 2 simultaneous gas pressure-readings, since you are consuming both the diluent and the O2 at the same time. Is this possible?

The tempsticks are an array of temperature sensors which are located within the scrubber. The scrubber is the part of a rebreather where the exhaled gas is 'scrubbed' of its CO2 by having the gas pass through a chemical compound called sofnolime which binds by the means of a chemical reaction the CO2. The reaction is exothermic, so you can in principle measure how much of the scrubber is left since the reaction should move as a front through the scrubber.

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.

Yes, the OPOS does start connecting immediately, so I have started the portmon before starting OPOS.

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.

I attached the scripts to this email.

Ok, thanks. OTOH I did have some spare time on me so I also wrote my own :-)

And since I did not have the actual hardware I also looked into writing a simulator (in Perl) for the hardware, this I did in order to understand what the universal does.

Currently I have essentially copied the galileo-files, calling the new dc 'vms-sentinel', I've also added all the enumerators and whatnot, and got the whole code to compile. The universal now understands when I give it the 'sentinel' as the backend and sends the correct character for generic info request (testing against my simulator which is bound by a virtual null modem created by socat).

So, I think I got this insofar, and once I get the unit back, can make more advances.

Poltsi

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