The correct name for the OSTC 3+ is OSTC Plus nowadays. Allthough the
exact name doesn't really matter because all OSTC3 based models are
compatible, using the correct name should reduce confusing for
end-users.
I received a bug report from a device which failed to download new dives
after a reset (probably caused by an empty battery). This reset appears
to reset the internal dive counter back to zero, and also resets the
write pointer back to the begin of the logbook ringbuffer, but leaves
the existing logbook entries in place. The result is that the logic to
find the most recent dive based on the highest internal dive counter,
will be wrong because it finds those old entries.
The discovery of the logbook (and profile) write pointers eliminates the
need to search for the most recent logbook entry.
I dived the model enough to wrap the profile buffer and I was wrong
about where the end was. Also, the buffer starts 3 bytes after where it
could. We were treating profile pointers as 4 bytes when they are two
bytes. This worked most of the time when short tissues were clear
(tissue load follows the pointer).
The Cochran Commander TM appears to be a first generation Commander with
limited storage and function compared to later models.
The main differences are:
- The TM doesn't support high-speed transfer so use the 0x05 read
command and don't change to a higher baud rate. Still reset to 9600
to wait for the heartbeat.
- The TM has a different config command (one byte).
- The TM has only one config page.
For previously supported Cochran computers high-speed read of log and
profile data started at byte 0. Older models that lack the high-speed
transfer function use the standard speed read commands and so the log
and profile data are read at higher addresses.
Since moving to per-dive download of profile data (and now rbstream
download) the data->sample_data_offset and data->sample_size variables
aren't used so calculating them doesn't make sense.
The progress bar was taking 18 seconds between updates on a Commander II
when using a 128K pagesize. Since devices differ in their baud rates, it
makes sense to use smaller pages on slower devices. This change reduces
it to 32K on a Commander II and to 64K on EMC devices.
Merge with upstream libdivecomputer from Jef:
- Jef merged my Scubapro G2 work, but renamed everything, and didn't
get the newer IO model code. Very annoying.
I went along with changing the G2 model family name to
DC_FAMILY_UWATEC_G2 just to keep some of the basic infrastructure
more easily mergeable. But his uwatec_g2 version is not usable.
- Cochran updates from John Van Ostrand
- Misc improvements from Jef:
* divesystems idive improvements
* Oceanic OCS freedive mode
* ppO2 callback cleanup
- Some transport type work:
* changes to IRDA configuration
* basic bluetooth rfcomm transport mode
* 'master' of git://git.libdivecomputer.org/libdivecomputer: (35 commits)
Removed unused code
Fixed duplicate gasmix event reports
Added decompression event handling for the Commander
Fix bad profiles when profile ringbuffer wraps around
Changed cochran_comander_profile_size function parameters
Fixed location and encoding of Commander II pointers
Use a local variable for the layout pointer
Add new EMC device model string
Add support for Pre-21000 s/n Commander dive computers
Fix problems with wrapped logbook ringbuffer
Retry read operations on failure
Change profile download to be incremental
Fix the id string offset
Fix the progress events
Use the trimix data format
Use the correct model number
Enable more fine grained progress events
Abort with an error if the buffer is too small
Use the standard libdivecomputer error codes
Scubapro G2: add missed command packet logging
...
And remove the nasty and disgusting transmitter data handling code that
Dirk added to work around his misunderstanding of the parsing code.
This code now collects the various states of the transmitter batteries
throughout a dive and reports the most meaningful summary in the end. It
also rewrites the rest of the string handling code to be architecturally
cleaner.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The syntax is trivial.
"// FTDI" for FTDI cable support
"// BT" for classic Bluetooth support
"// BLE" for Bluetooth LE support
We can then parse this information during the Subsurface build process
and create the (hopefully correct) support matrix for dive computer
download from the mobile apps.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Stop pretending that all the devices since the Petrel are the same. They
actually aren't. So let's detect them and correctly identify them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should be a STRING callback, but those come from the header and we
don't have the information until after we have parsed all the samples.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The first dive computer to support this is the Perdix AI. Interestingly,
this keeps track of two sensors at all times. I haven't seen data with
two sensors active, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The earliest document I have references log version 6. There are
apparently older versions, but I don't know what the differences
are. Before version 7, the log version wasn't always reliably
stored, so we assume 6 is the minimum and use 7 (or later) if we
find it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Newer cochran DCs record a gas change event at the begining of a
dive. The code creates a gas change before processing samples so
with newer DCs this resulted in duplicate events.
The method used to calculate the data used by dives (to determine when
we run out of ringbuffer) incorrectly didn't include surface sample
data. Ten to twenty minute of sample data is recorded at the surface in
case the diver re-descends, continuing the dive. The code then thought
that older dive profiles were not yet overwritten. The improper data was
returned to the user.
This function is much more useful if it works like a
ringbuffer_distance() function. It assumed the wrong values when
calculating profile size and it didn't have easy access to values it
needed to properly calculate profile sizes.
It makes sense to keep since it validates pointers.
Commander II pointers to profile ringbuffer data was wrong. After seeing
the Commander I encoding I realized the Commander II encoding of RB
pointers was in a flipped word big endian format. It only appeared to be
in normal big endian format because of an adjacent pointer that usually
shared the same first two bytes.
This adds support for older Cochran Commander dive computers,
specifically Commanders with serial numbers prior to 21000.
This also renames "Commander" model to "Commander II" and
adds "Commander I" to refer to pre-21000 models.
Since commit 344bfab229a17c7227b9bec02f616505a8d9e998 only a subset of
the id string is used to detect the model. But because the offset was
never updated, the model detection always fails now.
When I added support for the new Suunto EON Steel bluetooth download, I
needed crc32(), and instead of cooking my own (libdivecomputer does do
its own versions of the simpler crc functions), I made libdivecomputer
just depend on zlib instead, which provides a convenient crc32() function.
But I didn't add the new linker flag (-lz) in the right place in the
automake. It worked fine for me on Linux, but apparently not so well on
macos.
This fixes it.
Reported-and-tested-by: Benjamin <nystire@gmail.com>
Tested-by: Axel Richter <Axel.Richter@freenet.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At the moment, the progress reporting will jump straight from about 0%
at the start of the download to 100% at the end of the download, without
any updates in between. This is improved by updating after every packet.
The error code returned by the dc_usbhid_read() function should be
returned as-is, instead of being replaced with some generic error, which
gets translated again to DC_STATUS_IO in the caller.
I did the packet logging for the received data side, but forgot to do
the same thing on the command transfer side, which makes the debug logs
a bit less useful.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When doing the G2 downloader, I dropped the initial handshake as I tried
to keep the code minimal, and the handshake didn't seem to make any
difference what-so-ever to me.
And it probably doesn't matter for anybody else either. But the code
isn't working for some people, and maybe it does actually matter.
More importantly, Scubapro's own LogTRAK application does send those two
initial commands, and it's probably a good idea to minimize the
differences between the different downloaders anyway, so add the
handshake sequence back in.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Jef Driesen correctly points out that the 'address' field is just
leftover from the IrDA code, and is meaningless for the USB HID
transport version of the Scubapro G2.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
