Using the libdivecomputer simulator with an OSTC3

[Anton Lundin]

On 24 April, 2017 - Jan Mulder wrote:

> Some days ago, a remark of Dirk on github issue
> https://github.com/Subsurface-divelog/subsurface/issues/335
> triggered my curiosity. Finding issues that are close to the
> divecomputer hardware (for example during input over a Bluetooth
> connection, which will drop eventually when stopping the debugger),
> can be complex, so "the libdivecomputer simulator" comes into play
> (more info on Jef's website
> http://libdivecomputer.org/simulator.html).
> 
> The use with an OSTC3 is not straightforward, but with the
> explanation from Jef shown below, it was easy to get it to work.
> 
> best,
> 
> --jan
> 
> 
> On 24-04-17 11:23, Jef Driesen wrote:
> >On 2017-04-24 09:43, Jan Mulder wrote:
> >>Is the simulator supposed to work with a OSTC3 (BT version, not sure
> >>if this is called a 3+) dump? It says ostc3 is a supported backend,
> >>but no success on my end at this point.
> >>
> >>Agreed, the subject of the email is confusing as it references
> >>an ostc 2n
> >
> >Yes, the latest version supports the ostc3 protocol, but it works
> >a bit different.
> >
> >The ostc3 protocol is one of those modern protocols where you
> >request complete dives directly. On one hand that's great, because
> >libdivecomputer doesn't need to know how and where the dives are
> >stored in the internal memory. But on the other hand supporting
> >such a protocol in the simulator is more problematic. Since dive
> >computers in this category usually don't support memory dumps at
> >all, I needed another solution for the simulator. Instead of
> >memory dumps, it somehow needs to be able to operate one the raw
> >dive data. Since the simulator code wasn't really made to pass
> >multiple files, I did a simple workaround for now, by
> >concatenating the raw dives. This hack works for the ostc3 and
> >idive (currently the only supported protocols of this type in the
> >simulator) because their data format allows to locate the
> >individual dives again due to the presence of length fields in the
> >dive header (idive) or special markers (ostc3).
> >
> >The ostc3 is special because it does support memory dumps. But
> >that's a full memory dump, and not just the dive data that the
> >simulator needs.
> >
> >Thus in order to use the simulator, you need to dump the
> >individual dives:
> >
> >./dctool -f ostc3 download -o dive.%n.bin -f raw /dev/rfcommX
> >
> >Concatenate them:
> >
> >cat dive.%n.bin > ostc3.bin
> >
> >And use this file in the simulator:
> >
> >./simulator -p /tmp/ttySX -b ostc3 ostc3.bin
> >
> >At some point, I would like to cleanup the simulator code, and add
> >proper support for these kind of protocols, such that you can just
> >pass a set of raw dive files directly. But there's always more
> >important stuff waiting...
> >

As i wrote back in
http://libdivecomputer.org/pipermail/devel/2015-April/000714.html , when
i wrote the code for full memory dumps from the ostc3, it shouldn't be
that hard to implement a some ostc3 simulator code ontop of the full
dumps.

I wrote the "full dump" code because i did need a way to look at the raw
data, and that was before dctool existed and the capability to dump
individual dives as binary files.


Jef: I would love to see the simulator code merged with the "mainline"
libdivecomputer. Its sort of hard to track and even discover what
happens with the simulator code when it lives completely on the side as
a patch file.


//Anton


-- 
Anton Lundin	+46702-161604