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>
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.
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.
The number of tank pressure sensors is not necessary equal to the number
of gas mixes. Take for example a dive with two gas mixes, but only a
single tank pressure sensor attached to one of the two tanks. Because
the tank index is shared with the gas mix index, it will refer to a
non-existing sensor when switching to a tank without a pressure sensor
attached.
The invalid tank index should not be considered a fatal error. The tank
pressure values should be ignored instead. The device appears to record
zero values anyway, except for the first value immediately after the gas
switch. I suspect that's caused by the fact that the pressure is only
recorded every 4 samples, and therefore the last pressure value is
reported with a small delay.
The Uwatec Aladin Tec 2G doesn't support freedive mode. This appears to
be a bug in SmartTrak and LogTrak. They both report gauge and air/nitrox
dives as apnea dives.
The current algorithm always downloads a full memory dump, and extracts
the dives afterwards. For the typical scenario where only a few dives
are being downloaded, this is inefficient because most of the data isn't
needed. This can easily be avoided by downloading the data on the fly.
Reading a ringbuffer backwards in order to process the most recent data
first, is a very common operation. Nearly every dive computer backend
has its own implementation. Thus with a common implementation, the
amount of code duplication and complexity in the dive computer backends
can be greatly reduced.
The common algorithm is implemented as a simple ringbuffer stream, which
takes care of all the technical details like the ringbuffer boundaries,
alignment to the page size, using the optimal packet size and caching
the remaining data.
The select system call modifies the file descriptor set, and depending
on the underlying implementation also the timeout. Therefore these
parameters should be re-initialized before every call.
The existing code also didn't handle EINTR and EAGAIN correct.
With a time based sample interval, the number of samples for a single
timestamp should be constant. However in practice some devices
occasionally store fewer samples. Since our sample time is based purely
on the sample interval, it goes completely out of sync with the sample
timestamp. To avoid this problem, the sample timestamp is used as the
base value.
For the Oceanic Pro Plus 2, this problem is very noticable. After about
115 minutes into a dive, the sample interval appears to increase to 60
seconds. Thus, without this fix, the resulting dive time for long dives
is suddenly much shorter than it should be.
The Aqualung i450T appears to ignore the fixed sample rate and instead
store a timestamp in each sample.
The presence of the surface samples in combination with this timestamp
based format is odd. Even the official Diverlog software is confused:
the Windows versions seems to ignore them, but the Mac version takes
them into account.
After the previous commit, the raw data is now reported with one large
vendor sample. Because that makes the data more difficult to interpret
(for example during debugging), a small helper function is added to
split the data again in multiple vendor samples.
Originally, the time and vendor sample values are emitted immediately
after the previous sample is complete. This is now postponed until all
raw samples are available.
This will be required for the Aqualung i450t. That model appears to
ignore the fixed sample rate and instead store a timestamp in each
sample. That means the timestamp is only available once the last raw
sample data has been reached.
Skipping the extra samples by increasing the length is not always
reliable. If there are empty samples present, they will get skipped
instead of the real samples. And if the number of samples isn't an exact
multiple of the samplerate, we're accessing data beyond the end of the
dive profile.
