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>
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>
The serial ops used a legacy calling convention that passed in just the
pointer to the userdata pointer (ie the first argument to the functions
was "void **userdata").
That's actually very inconvenient, because the custom IO data can not
only contain other interesting information that was filled in by the
custom IO provider, it also made it harder to chain these things
together, as exemplified by the core to emulate serial over the packet
interface in the subsurface bluetooth code.
This also adds the 'dc_context_t' field that is passed to the packet
routine open. That can allow the open routine to override the
'custom_io' details of the context at open time (to allow nested
custom_io operation).
Note that callers of the open function need to be aware that the
'custom_io' can be changed by the act of opening a custom_io, and the
value shouldn't be cached in some local variable.
Finally, this adds a new user-supplied opaque pointer
dc_user_device_t *user_device;
to the custom_io descriptor.
The 'user_device' data is filled in when registering the custom_io with
data that the custom IO open() routines can use. This is different from
the existing 'userdata' in that the 'user_device' is filled in before
dc_open_device() is called (and "open" can then use it to limit what
kinds of devices it looks for, for example).
In contrast, the existing 'userdata' field is filled in by the
"xyz_open()" routines, and contains the data necessary for the IO
itself.
The SSRF_CUSTOM_IO define is updated to v2 to indicate the new
interfaces.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This merges the Suunto EON Steel and Scubapro G2 BLE downloading updates
into the main Subsurface branch.
The basic infrastructure had been done earlier, this is just the tweaks
to actually take advantage of the BLE GATT back-end in Subsurface for
those two dive computers.
The actual subsurface code that exposes BLE GATT interfaces has not been
made public yet, it's too ugly, and will probably make small children go
blind. But I'll try to clean it up a bit and get it out for wider
testing asap.
* BLE-downloaders:
Scubapro G2: update for BLE downloading
Complete the EON Steel HDLC encoding/decoding work
Teach the EON Steel about HDLC encoding of the command packets
The code actually almost worked as-is, but for a tiny detail: the USBHID
packet reception code always receives a full 64-byte packet, while BLE
GATT will return how much it actually received.
The other difference is that USB HID is so fast that it didn't make any
difference where the progress was updated, it took about a second to
download everything.
BLE GATT is not fast to begin with, and the G2 may be particularly slow.
So with the BLE backend, you really do want progress updates for each
packet received, because the dump is going to take a while...
But with the trivial packet verification change, and with the progress
report updates, everything "JustWorks(tm)" over BLE.
Of course, I haven't committed the actual Subsurface BLE transfer parts
yet, because they are some incredibly ugly stuff with fragile bits and
pieces. But the fact that I can now download from two different dive
computers does mean that I think it's getting to the point where I will
just submit even my ugly code to Dirk.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The previous patch did the HDLC encoding on packet send, this does the
HDLC decoding on the receive side.
In order to properly check the data integrity, the HDLC-encoded packet
needs to be fully received before it can be processed. So while the HID
downloading continues to work packet-by-packet, the HDLC encoded BLE
GATT stream needs a temporary buffer for the data that gets filled as we
ask for the reply header.
Right now only the old USB HID path is actually tested, because I
haven't flushed out the packet receiving side in subsurface yet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The BLE GATT transport ends up using HDLC for the stream encoding,
unlike the USB HID side. The EON Steel BLE GATT protocol actually does
that for both the commands and for the replies, but this converts only
the command side, because that's the simpler one.
The reply side code will need to be re-architected a bit, because right
now it is very much oriented towards beign able to do everything one
single packet at a time (which is true for USB HID) rather than treating
the packets as a stream of data (as is necessary for the CRC32
verification and to handle the escaping of the 0x7e/0x7d bytes in the
stream).
So with this change, you can't actually do a download over BLE, but I
was able to verify that the first command transfers correctly, and the
EON Steel replies to it over Bluetooth LE GATT.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This means that they still default to their respective USB devices, but
you can now set custom IO structure to pass in your own data.
Not only will we hopefully have some kind of BLE support, you could also
use this to simply emulate packets from a log-file by having a packet
replay (or by actually emulating a device). Of course, you can already
do this by actually emulating the device in a virtual environment, but
it might be useful for some kind of libdivecomputer testing environment.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Basically, this alows us to hide the usbhid code behind the custom_io
abstraction, so that a dive computer could either be given a supplied
custom_io structure, of if none is given, would create one for a USBHID
device.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The custom IO handlers will be extended to not just do serial line
emulation (generally over Bluetooth rfcomm), but do BLE too.
BLE does not look like a serial protocol at all, it's packet-based, and
we may have to add specific routines to indicate which GATT endpoints to
use etc. But like the traditional custom serial code, we want to do the
actual IO not from within libdivecomputer, but from the user of the
library (because the BLE support will require things like the Qt
Connectivity layer - and we do not want libdivecomputer to have to link
against something like Qt).
So this renames 'custom_serial' to 'custom_io', and instead names the
individual member function pointers 'serial_*' to make it clear that
those members are for serial communication.
It also adds new placeholders for packet_open/close/read/write. Note
that while these may look similar to the serial counter-parts, they are
not the same or even necessarily mutually exclusive. It is possible the
the caller fills in one or the other (or both), and they would be used
independently.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Not that anybody should ever use that old-style family/model thing
anyway, so I considered just removing the g2 entry instead. But dctool
still uses this deprecated interfsce to pick a dive computer.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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.
Of course, it turns out that a bug in subsurface means that the logging
never gets enabled anyway even when you ask for it, so right now this
particular misfeature didn't matter. I'm hoping Tomaz/Dirk can fix the
UI widget problem.
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>
The back-end parser seems to be the same as for the Uwatec Smart (aka
Galileo Sol). At least that's the assumption right now.
The downloader just uses USB HID (very similar to EON Steel) rather than
the horrible IrDA thing.
There's also eventually a BLE thing, but that's for the future.
This is an unholy mixture of the Uwatec Smart downloader logic and the
EON Steel usbhid transfer code. The back-end is pure Uwatec Smart
(model 0x11, same as Galileo Sol).
I'm not at all sure this gets everything right, but it downloads
*something*.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge upstream libdivecomputer changes as requested by Jan Mulder.
"DiveSystem iX3M:
- Add support for new iX3M models
- Add support for new iX3M APOS4 firmware
- Add iX3M firmware version to the devinfo event (ix3m)
Shearwater:
- Report the ppO2 in external O2 sensor mode only (Shearwater)
- Replace the constant offset with a scaling factor (Shearwater)
- Apply the calibration correction only for the Predator
- Report individual sensor values
- Predator: don't report PPO2 unless in CC mode
Misc:
- Fix Sherwood Wisdom 3 memory layout
- Implement read and write functions for OSTC3
- Add support for Mares Quad
- Fix uwatec handshaking error handling"
* 'master' of git://git.libdivecomputer.org/libdivecomputer:
Add support for the new models
Add support for the new iX3M APOS4 firmware
Add the firmware version to the devinfo event
Report the ppO2 in external O2 sensor mode only
Replace the constant offset with a scaling factor
Apply the calibration correction only for the Predator
shearwater: Report individual sensor values
Predator: don't report PPO2 unless in CC mode
Fix the Sherwood Wisdom 3 memory layout
Implement the read and write functions for the OSTC3
Don't ignore handshaking errors
Add support for the Mares Quad
The new APOS4 firmware changed the data format and communication
protocol. The size of the samples changed from 54 to 64 bytes, and in
order to speedup the download, a single data packet contains 3 samples
at once. If the number of samples is not an exact multiple of three, the
last packet appears to contain garbage data.
For parsing, the firmware version is available in the dive header.
Unfortunately it can't be used for dives that are downloaded from a
device with the new firmware, but which have been recorded with an older
firmware. Such dives store the old firmware version in the dive header,
but they also use the new sample format. As a workaround, we inspect the
size of the dive.
The O2 sensor millivolt values are only valid if external O2 sensor
monitoring is enabled.
Note that the interpretation of the PPO2 status bit appears to be
reversed (0=external and 1=internal).
Reviewed-by: Anton Lundin <glance@acc.umu.se>
Correcting the Predator calibration value with a scaling factor produces
even more reasonable ppO2 values compared to using a constant offset.
The scaling factor of 2.2 is based on a linear regression between the
average ppO2 reported by the dive computer, and the average ppO2
calculated over all (calibrated) sensors using the raw calibration
value.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
The calibration values for the Petrel are typically in the range 1600 to
2400, while for Predator they are much smaller, with values in the range
800 to 1400. The consequence is that the calculated ppO2 values are too
low for the Predator. Adding a constant offset of about 1000 changes the
calibration value to be in approximately the same range as the Petrel,
and hence more reasonable ppO2 values. But this correction should only
be applied for the Predator, and not the Petrel.
Reviewed-by: Anton Lundin <glance@acc.umu.se>
This reads the reported mV values from the sensors, and based on the
calibration values converts it into a ppo2 value to report.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Sending this in OC mode is redundant and might confuse applications that
assume they only get PPO2 data in CC mode.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
From firmware version 2.15, the battery percentage is shown on the
unit (in the logbook that is, it was shown on the display for a very
long time). The used byte in the OSTC3 seems to be populated since
firmware version 2.10. The new percentage data is added to the
"battery at end" voltage data, and a V is added to denote the unit
of the voltage.
In addition, reordered the DC_FIELD_STRINGs a little, so that the
serial is on top.
Further, changed BUFLEN to 32 (as in 84eb59c) due the the length
of the new battery notation.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Merge upstream libdivecomputer changes from Jef Driesen.
The most noticeable part is Jen Mulder's OSTC3 initial setpoint
addition, which fixes the OSTC3 data in CCR3 mode.
But also various cleanups and fixups from Jef.
* 'master' of git://git.libdivecomputer.org/libdivecomputer:
OSTC3: set initial setpoint in profile data
Remove unused parameters
Cleanup the extract dives functions
Remove unnecessary helper functions
Remove deprecated functions from the public api
Remove unnecessary include statements
Fix the firmware version and serial number
Add support for the Uwatec Aladin Tec 3G
In CCR fixed setpoint mode of the OSTC3, the initial setpoint at the start
of the dive was not set. This fix adds the initial setpoint based on
the data in the fixed setpoint table (ie, the first fixed setpoint is
the initial one).
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
After being removed from the public api, these functions can be changed
into local, static functions. And in a few cases, they are no longer
necessary and can be removed completely.
The second variant of the open or create functions were introduced to
maintain backwards compatibility. But after being removed from the
public api, these functions serve no purpose anymore, and can be removed
completely.
The vendor_product_parser_create() and vendor_product_device_open()
functions should be called indirectly, through the generic
dc_device_open() and dc_parser_new() functions. And the
vendor_product_extract_dives() functions are internal functions that
should never have been part of the public api in the first place.
Merge upstream libdivecomputer changes from Jef Driesen.
No major changes and no conflicts except for a trivial one where Jef had
marked a couple of private functions 'static' and our versions had
extended the argument lists of those functions.
This just updates to the current upstream state of libdivecomputer,
where the bulk of the changes come mainly from the new ringbuffer helper
code, but there are various other small misc fixes and cleanups.
* git://git.libdivecomputer.org/libdivecomputer:
Disable the deco events
Replace the deco events with a deco sample
Report errors from the close function
Mark the private function as static
Fix a bug in the tank pressure samples
Disable freedive mode for the Uwatec Aladin Tec 2G
Mark the private function as static
Fix some compiler warnings
Fix some more null pointer dereferences
Use a more efficient download algorithm
Use the new ringbuffer stream
Add a common ringbuffer reading algorithm
Improve the robustness of the IrDA I/O code
Fix a few null pointer dereferences
Fix the number of gas mixes
Always use the sample timestamp as the base value
When compiled with older Microsoft libraries, the unsafe implemention of
snprintf results in non-null terminated strings, causing numerous subsequent
issues. This fix just enlarges the used buffer to accommdate longer strings.
A more complete solution would include the use more recent Microsoft libraries in
the build process. The larger buffer is still need then, to prevent trucated
(but proper null terminated) strings.
ref: https://github.com/Subsurface-divelog/subsurface/issues/301
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
When downloading a Shearwater Petrel using the predator backend, the
firmware version and serial number are different compared to those
reported by the petrel backend.
This is caused by a difference in the encoding of the data. In the
predator data format, the firmware version appears to be BCD encoded,
and the serial number is stored as a big endian integer.
