2020-10-25 12:28:55 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
#ifndef DIVECOMPUTER_H
|
|
|
|
#define DIVECOMPUTER_H
|
|
|
|
|
|
|
|
#include "divemode.h"
|
|
|
|
#include "units.h"
|
2024-05-04 20:17:07 +00:00
|
|
|
#include <string>
|
2024-05-18 19:04:58 +00:00
|
|
|
#include <vector>
|
2020-10-25 12:28:55 +00:00
|
|
|
|
|
|
|
struct extra_data;
|
2024-05-25 06:16:57 +00:00
|
|
|
struct event;
|
2020-10-25 12:28:55 +00:00
|
|
|
struct sample;
|
|
|
|
|
|
|
|
/* Is this header the correct place? */
|
|
|
|
#define SURFACE_THRESHOLD 750 /* somewhat arbitrary: only below 75cm is it really diving */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE! The deviceid and diveid are model-specific *hashes* of
|
|
|
|
* whatever device identification that model may have. Different
|
|
|
|
* dive computers will have different identifying data, it could
|
|
|
|
* be a firmware number or a serial ID (in either string or in
|
|
|
|
* numeric format), and we do not care.
|
|
|
|
*
|
|
|
|
* The only thing we care about is that subsurface will hash
|
|
|
|
* that information the same way. So then you can check the ID
|
|
|
|
* of a dive computer by comparing the hashes for equality.
|
|
|
|
*
|
|
|
|
* A deviceid or diveid of zero is assumed to be "no ID".
|
|
|
|
*/
|
|
|
|
struct divecomputer {
|
2024-05-16 18:11:21 +00:00
|
|
|
timestamp_t when = 0;
|
2020-10-25 12:28:55 +00:00
|
|
|
duration_t duration, surfacetime, last_manual_time;
|
|
|
|
depth_t maxdepth, meandepth;
|
|
|
|
temperature_t airtemp, watertemp;
|
|
|
|
pressure_t surface_pressure;
|
2024-05-16 18:11:21 +00:00
|
|
|
enum divemode_t divemode = OC; // dive computer type: OC(default) or CCR
|
|
|
|
uint8_t no_o2sensors = 0; // rebreathers: number of O2 sensors used
|
|
|
|
int salinity = 0; // kg per 10000 l
|
2024-05-18 15:03:19 +00:00
|
|
|
std::string model, serial, fw_version;
|
2024-05-16 18:11:21 +00:00
|
|
|
uint32_t deviceid = 0, diveid = 0;
|
2024-05-25 06:16:57 +00:00
|
|
|
// Note: ve store samples, events and extra_data in std::vector<>s.
|
|
|
|
// This means that pointers to these items are *not* stable.
|
2024-05-19 10:38:38 +00:00
|
|
|
std::vector<struct sample> samples;
|
2024-05-25 06:16:57 +00:00
|
|
|
std::vector<struct event> events;
|
2024-05-18 19:04:58 +00:00
|
|
|
std::vector<struct extra_data> extra_data;
|
2024-05-16 18:11:21 +00:00
|
|
|
struct divecomputer *next = nullptr;
|
|
|
|
|
|
|
|
divecomputer();
|
|
|
|
~divecomputer();
|
2024-05-18 19:04:58 +00:00
|
|
|
divecomputer(divecomputer &&);
|
2024-05-19 10:38:38 +00:00
|
|
|
divecomputer &operator=(const divecomputer &);
|
2020-10-25 12:28:55 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
extern void fake_dc(struct divecomputer *dc);
|
|
|
|
extern void free_dc_contents(struct divecomputer *dc);
|
|
|
|
extern int get_depth_at_time(const struct divecomputer *dc, unsigned int time);
|
|
|
|
extern void free_dive_dcs(struct divecomputer *dc);
|
|
|
|
extern struct sample *prepare_sample(struct divecomputer *dc);
|
|
|
|
extern struct sample *add_sample(const struct sample *sample, int time, struct divecomputer *dc);
|
|
|
|
extern void fixup_dc_duration(struct divecomputer *dc);
|
|
|
|
extern unsigned int dc_airtemp(const struct divecomputer *dc);
|
|
|
|
extern unsigned int dc_watertemp(const struct divecomputer *dc);
|
2024-05-25 06:16:57 +00:00
|
|
|
extern int add_event_to_dc(struct divecomputer *dc, struct event ev); // event structure is consumed, returns index of inserted event
|
2024-05-04 20:17:07 +00:00
|
|
|
extern struct event *add_event(struct divecomputer *dc, unsigned int time, int type, int flags, int value, const std::string &name);
|
2024-05-25 06:16:57 +00:00
|
|
|
extern struct event remove_event_from_dc(struct divecomputer *dc, int idx);
|
|
|
|
struct event *get_event(struct divecomputer *dc, int idx);
|
2024-05-18 19:04:58 +00:00
|
|
|
extern void add_extra_data(struct divecomputer *dc, const std::string &key, const std::string &value);
|
Clean up divecomputer 'device' handling
We have this odd legacy notion of a divecomputer 'device', that was
originally just basically the libdivecomputer 'EVENT_DEVINFO' report
that was associated with each dive. So it had firmware version,
deviceid, and serial number.
It had also gotten extended to do 'nickname' handling, and it was all
confusing, ugly and bad. It was particularly bad because it wasn't
actually a 'per device' thing at all: due to the firmware field, a dive
computer that got a firmware update forced a new 'device'.
To make matters worse, the 'deviceid' was also almost random, because
we've calculated it a couple of different ways, and libdivecomputer
itself has changed how the legacy 32-bit 'serial number' is expressed.
Finally, because of all these issues, we didn't even try to make the
thing unique, so it really ended up being a random snapshot of the state
of the dive computer at the time of a dive, and sometimes we'd pick one,
and sometimes another, since they weren't really well-defined.
So get rid of all this confusion.
The new rules:
- the actual random dive computer state at the time of a dive is kept
in the dive data. So if you want to know the firmware version, it
should be in the 'extra data'
- the only serial number that matters is the string one in the extra
data, because that's the one that actually matches what the dive
computer reports, and isn't some random 32-bit integer with ambiguous
formatting.
- the 'device id' - the thing we match with (together with the model
name, eg "Suunto EON Steel") is purely a hash of the real serial
number.
The device ID that libdivecomputer reports in EVENT_DEVINFO is
ignored, as is the device ID we've saved in the XML or git files. If
we have a serial number, the device ID will be uniquely associated
with that serial number, and if we don't have one, the device ID will
be zero (for 'match anything').
So now 'deviceid' is literally just a shorthand for the serial number
string, and the two are joined at the hip.
- the 'device' managament is _only_ used to track devices that have
serial numbers _and_ nicknames. So no more different device
structures just because one had a nickname and the other didn't etc.
Without a serial number, the device is 'anonymous' and fundamentally
cannot be distinguished from other devices of the same model, so a
nickname is meaningless. And without a nickname, there is no point in
creating a device data structure, since all the data is in the dive
itself and the device structure wouldn't add any value..
These rules mean that we no longer have ambiguous 'device' structures,
and we can never have duplicates that can confuse us.
This does mean that you can't give a nickname to a device that cannot be
uniquely identified with a serial number, but those are happily fairly
rare (and mostly older ones). Dirk said he'd look at what it takes to
give more dive computers proper serial numbers, and I already did it for
the Garmin Descent family yesterday.
(Honesty in advertizing: right now you can't add a nickname to a dive
computer that doesn't already have one, because such a dive computer
will not have a device structure. But that's a UI issue, and I'll sort
that out separately)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-08-16 22:50:11 +00:00
|
|
|
extern uint32_t calculate_string_hash(const char *str);
|
2024-05-23 04:06:23 +00:00
|
|
|
extern bool is_dc_planner(const struct divecomputer *dc);
|
|
|
|
extern void make_planner_dc(struct divecomputer *dc);
|
|
|
|
extern const char *manual_dc_name;
|
|
|
|
extern bool is_dc_manually_added_dive(const struct divecomputer *dc);
|
|
|
|
extern void make_manually_added_dive_dc(struct divecomputer *dc);
|
2020-10-25 12:28:55 +00:00
|
|
|
|
|
|
|
/* Check if two dive computer entries are the exact same dive (-1=no/0=maybe/1=yes) */
|
|
|
|
extern int match_one_dc(const struct divecomputer *a, const struct divecomputer *b);
|
|
|
|
|
|
|
|
#endif
|