devel

devel@libdivecomputer.org

3 participants
290 discussions

OSTC3 firmware upgrades
by Anton Lundin 21 Nov '14

21 Nov '14

Hi! This is is a RFC series of patches to add support for firmware upgrades on the OSTC3. The code have bin tested both against a "pcb" by HW and against my OSTC3 so it works and does the right things. JeanDo's ostc-companion[1] have bin the reference implementation I've looked at when I wrote this code. There are still a couple of pain-points that I would like some feedback on: How to start the device in service mode: To get access to the necessary commands for service mode, we can't INIT the device with INIT(0xBB), we need to INIT it with a special service mode sequence(0xAA, 0xAB, 0xCD, 0xEF). Now the INIT is sent in hw_ostc3_device_open, so how do you suggest that we refactor the code to allow another sequence after open? The current quite crude hack is to just EXIT(0xFF) the device and re-init it after a 6s sleep. This won't work against the OSTC Sport. The timing between command and data in write_block: The current hw_ostc3_device_write_block is a bit of copy-paste from hw_ostc3_transfer, to be able to send the data buffer to the device, without a additional copy. Library triggered closed state: The device reboots when it gets the FLASH_FIRM-command so how can we "not fail" when the application then tries to talk to the device afterwards, or even call hw_ostc3_device_close? There are also a couple of other FIXME's in the code, which I plan on cleaning up, but I thought that I should send out a first RFC patch series to get some additional feedback going. Any other ideas about how the code looks? //Anton 1. https://bitbucket.org/JeanDo/ostc-companion/ -- Anton Lundin +46702-161604

3 15

[PATCH 1/4] Cochran: unused variable cleanup.
by John Van Ostrand 19 Nov '14

19 Nov '14

--- src/cochran_commander.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/cochran_commander.h b/src/cochran_commander.h index 8fa6228..95d4da4 100644 --- a/src/cochran_commander.h +++ b/src/cochran_commander.h @@ -89,8 +89,6 @@ typedef struct cochran_data_t { unsigned int sample_data_offset; unsigned int sample_size; - unsigned int last_interdive_offset; - unsigned int last_entry_offset; cochran_config_t conf; } cochran_data_t; -- 1.8.3.1

1 3

[PATCH] Support for Cochran EMC and Commander Air import
by John Van Ostrand 17 Nov '14

17 Nov '14

Specifically tested with EMC-20H and Commander Air_Nitrox this commit should support the families for the most part however there are may be differences in the DC signature, memory size, and other factors that will prevent opening the device and obtaining a clean import. Try it with other EMC and Commander devices and check library ERRORs for the signature information needed to add support. Also missing is tank pressure (for Gemini) and support for logbooks that have rolled old dives off. There is support for dive samples that have rolled off. John Van Ostrand (1): Added support for Cochran EMC and Commander Air import examples/Makefile.am | 6 +- examples/cochran_download.c | 299 +++++++++++++ examples/universal.c | 8 +- include/libdivecomputer/Makefile.am | 3 +- include/libdivecomputer/cochran.h | 61 +++ include/libdivecomputer/common.h | 3 + include/libdivecomputer/parser.h | 20 +- src/Makefile.am | 7 +- src/cochran_cmdr.c | 66 +++ src/cochran_cmdr.h | 83 ++++ src/cochran_cmdr_parser.c | 202 +++++++++ src/cochran_common.c | 861 ++++++++++++++++++++++++++++++++++++ src/cochran_common.h | 109 +++++ src/cochran_common_parser.c | 157 +++++++ src/cochran_common_parser.h | 80 ++++ src/cochran_emc.c | 67 +++ src/cochran_emc.h | 180 ++++++++ src/cochran_emc_parser.c | 399 +++++++++++++++++ src/descriptor.c | 3 + src/device.c | 7 + src/libdivecomputer.symbols | 2 + src/parser.c | 7 + 22 files changed, 2617 insertions(+), 13 deletions(-) create mode 100644 examples/cochran_download.c create mode 100644 include/libdivecomputer/cochran.h create mode 100644 src/cochran_cmdr.c create mode 100644 src/cochran_cmdr.h create mode 100644 src/cochran_cmdr_parser.c create mode 100644 src/cochran_common.c create mode 100644 src/cochran_common.h create mode 100644 src/cochran_common_parser.c create mode 100644 src/cochran_common_parser.h create mode 100644 src/cochran_emc.c create mode 100644 src/cochran_emc.h create mode 100644 src/cochran_emc_parser.c -- 1.8.3.1

2 12

[PATCH] Added Cochran support for max and surface temps
by John Van Ostrand 09 Nov '14

09 Nov '14

Also fixed up off-by-one pointers into logbook data. Signed-off-by: John Van Ostrand <john(a)vanostrand.com> --- src/cochran_cmdr_parser.c | 16 ++++++++++------ src/cochran_commander.h | 10 +++++++--- src/cochran_emc_parser.c | 28 ++++++++++++++++++++-------- 3 files changed, 37 insertions(+), 17 deletions(-) diff --git a/src/cochran_cmdr_parser.c b/src/cochran_cmdr_parser.c index 7cfd650..de25912 100644 --- a/src/cochran_cmdr_parser.c +++ b/src/cochran_cmdr_parser.c @@ -50,16 +50,20 @@ cochran_cmdr_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, if (value) { switch (type) { - case DC_FIELD_TEMPERATURE: - *((unsigned int*) value) = log[CMD_START_TEMP]; + case DC_FIELD_TEMPERATURE_SURFACE: + *((unsigned int*) value) = ((float) log[CMD_START_TEMP] - 32) / 1.8; + case DC_FIELD_TEMPERATURE_MINIMUM: + *((unsigned int*) value) = ((float) log[CMD_MIN_TEMP] / 2 + 20 - 32) / 1.8; + case DC_FIELD_TEMPERATURE_MAXIMUM: + *((unsigned int*) value) = ((float) log[CMD_MAX_TEMP] / 2 + 20 - 32) / 1.8; case DC_FIELD_DIVETIME: *((unsigned int *) value) = array_uint16_le (log + EMC_BT) * 60; break; case DC_FIELD_MAXDEPTH: - *((double *) value) = array_uint16_le (log + CMD_MAX_DEPTH) / 4 * FEET; + *((double *) value) = (float) array_uint16_le (log + CMD_MAX_DEPTH) / 4 * FEET; break; case DC_FIELD_AVGDEPTH: - *((double *) value) = array_uint16_le (log + CMD_AVG_DEPTH) / 4 * FEET; + *((double *) value) = (float) array_uint16_le (log + CMD_AVG_DEPTH) / 4 * FEET; break; case DC_FIELD_GASMIX_COUNT: *((unsigned int *) value) = 2; @@ -72,9 +76,9 @@ cochran_cmdr_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, break; case DC_FIELD_SALINITY: // 0 = low conductivity, 1 = high, maybe there's a 2? - water->type = ( log[CMD_WATER_CONDUCTIVITY] == 0 ? DC_WATER_FRESH + water->type = ( (log[CMD_WATER_CONDUCTIVITY] & 0x3) == 0 ? DC_WATER_FRESH : DC_WATER_SALT ); - water->density = 1000 + 12.5 * log[CMD_WATER_CONDUCTIVITY]; + water->density = 1000 + 12.5 * (log[CMD_WATER_CONDUCTIVITY] & 0x3); break; case DC_FIELD_ATMOSPHERIC: *(double *) value = ATM / BAR * pow(1 - 0.0000225577 diff --git a/src/cochran_commander.h b/src/cochran_commander.h index d16de42..1b040de 100644 --- a/src/cochran_commander.h +++ b/src/cochran_commander.h @@ -113,11 +113,13 @@ typedef struct cochran_device_t { #define CMD_START_DEPTH 56 // 2 byte, /4=ft #define CMD_ALTITUDE 73 // 1 byte, /4=Kilofeet #define CMD_END_OFFSET 128 // 4 bytes -#define CMD_MIN_TEMP 153 // 1 byte, F +#define CMD_END_TEMP 153 // 1 byte, F #define CMD_BT 166 // 2 bytes, minutes #define CMD_MAX_DEPTH 168 // 2 bytes, /4=ft #define CMD_AVG_DEPTH 170 // 2 bytes, /4=ft #define CMD_O2_PERCENT 210 // 8 bytes, 4 x 2 byte, /256=% +#define CMD_MIN_TEMP 232 // 1 byte, /2+20=F +#define CMD_MAX_TEMP 233 // 1 byte, /2+20=F // EMC log fields #define EMC_SEC 0 @@ -127,17 +129,19 @@ typedef struct cochran_device_t { #define EMC_MON 4 #define EMC_YEAR 5 #define EMC_START_OFFSET 6 // 4 bytes -#define EMC_WATER_CONDUCTIVITY 25 // 1 byte, 0=low, 2=high +#define EMC_WATER_CONDUCTIVITY 24 // 1 byte, 0=low, 2=high #define EMC_START_DEPTH 42 // 2 byte, /256=ft #define EMC_START_TEMP 55 // 1 byte, F #define EMC_ALTITUDE 89 // 1 byte, /4=Kilofeet #define EMC_O2_PERCENT 144 // 20 bytes, 10 x 2 bytes, /256=% #define EMC_HE_PERCENT 164 // 20 bytes, 10 x 2 bytes, /256=% #define EMC_END_OFFSET 256 // 4 bytes -#define EMC_MIN_TEMP 293 // 1 byte, F +#define EMC_END_TEMP 293 // 1 byte, F #define EMC_BT 304 // 2 bytes, minutes #define EMC_MAX_DEPTH 306 // 2 bytes, /4=ft #define EMC_AVG_DEPTH 310 // 2 bytes, /4=ft +#define EMC_MIN_TEMP 403 // 1 byte, /2+20=F +#define EMC_MAX_TEMP 407 // 1 byte, /2+20=F dc_status_t cochran_packet (cochran_device_t *device, diff --git a/src/cochran_emc_parser.c b/src/cochran_emc_parser.c index 37089a7..10d87a0 100644 --- a/src/cochran_emc_parser.c +++ b/src/cochran_emc_parser.c @@ -41,6 +41,7 @@ struct dive_stats { float max_depth; float avg_depth; float min_temp; + float max_temp; }; @@ -59,29 +60,38 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, dc_salinity_t *water = (dc_salinity_t *) value; unsigned int dive_time; - float max_depth, avg_depth, min_temp; struct dive_stats stats; if (value) { switch (type) { - case DC_FIELD_TEMPERATURE: + case DC_FIELD_TEMPERATURE_SURFACE: + *((unsigned int*) value) = ((float) log[EMC_START_TEMP] - 32) / 1.8; + break; + case DC_FIELD_TEMPERATURE_MINIMUM: + if (data->corrupt_dive) { + cochran_emc_parse_dive_stats(abstract, &stats); + *((unsigned int*) value) = stats.min_temp; + } else + *((unsigned int*) value) = ((float) log[EMC_MIN_TEMP] / 2 + 20 - 32) / 1.8; + break; + case DC_FIELD_TEMPERATURE_MAXIMUM: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = min_temp; + *((unsigned int*) value) = stats.max_temp; } else - *((unsigned int*) value) = (log[EMC_START_TEMP] - 32) / 1.8; + *((unsigned int*) value) = ((float) log[EMC_MAX_TEMP] / 2 + 20 - 32) / 1.8; break; case DC_FIELD_DIVETIME: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = dive_time; + *((unsigned int*) value) = stats.dive_time; } else *((unsigned int *) value) = array_uint16_le (log + EMC_BT) * 60; break; case DC_FIELD_MAXDEPTH: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = max_depth; + *((unsigned int*) value) = stats.max_depth; } else *((double *) value) = array_uint16_le (log + EMC_MAX_DEPTH) / 4 * FEET; @@ -89,7 +99,7 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, case DC_FIELD_AVGDEPTH: if (data->corrupt_dive) { cochran_emc_parse_dive_stats(abstract, &stats); - *((unsigned int*) value) = avg_depth; + *((unsigned int*) value) = stats.avg_depth; } else *((double *) value) = array_uint16_le (log + EMC_AVG_DEPTH) / 4 * FEET; @@ -106,7 +116,7 @@ cochran_emc_parser_get_field (dc_parser_t *abstract, dc_field_type_t type, break; case DC_FIELD_SALINITY: // 0 = low conductivity, 2 = high, maybe there's a 1? - water->type = ( log[EMC_WATER_CONDUCTIVITY] == 0 ? DC_WATER_FRESH + water->type = ( (log[EMC_WATER_CONDUCTIVITY] & 0x3) == 0 ? DC_WATER_FRESH : DC_WATER_SALT ); water->density = 1000 + 12.5 * (log[EMC_WATER_CONDUCTIVITY] & 0x3); break; @@ -341,6 +351,7 @@ void cochran_emc_parse_dive_stats (dc_parser_t *abstract, stats->max_depth = 0; stats->min_temp = 999; stats->avg_depth = 0; + stats->max_temp = 0; while (offset < size) { s = sdata + offset; @@ -384,6 +395,7 @@ void cochran_emc_parse_dive_stats (dc_parser_t *abstract, temp = (temp - 32.0) / 1.8; if (temp < stats->min_temp) stats->min_temp = temp; + if (temp > stats->max_temp) stats->max_temp = temp; } time ++; -- 1.8.3.1

1 0

[PATCH] Fixed reference to DC_FAMILY_COCHRAN in universal.c
by John Van Ostrand 09 Nov '14

09 Nov '14

I'm not sure why this wasn't changed. Signed-off-by: John Van Ostrand <john(a)vanostrand.com> --- examples/universal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/universal.c b/examples/universal.c index 8672605..bb289b6 100644 --- a/examples/universal.c +++ b/examples/universal.c @@ -102,7 +102,7 @@ static const backend_table_t g_backends[] = { {"predator", DC_FAMILY_SHEARWATER_PREDATOR}, {"petrel", DC_FAMILY_SHEARWATER_PETREL}, {"nitekq", DC_FAMILY_DIVERITE_NITEKQ}, - {"cochran", DC_FAMILY_COCHRAN}, + {"cochran", DC_FAMILY_COCHRAN_COMMANDER}, }; static dc_family_t -- 1.8.3.1

1 0

small fix for Cobalt
by Dirk Hohndel 09 Nov '14

09 Nov '14

This seems like a fairly obvious fix, even though I don't have a Cobalt anymore to test it... /D

1 0

Re: Patches to add basic support for the Suunto EON Steel
by Linus Torvalds 04 Nov '14

04 Nov '14

Ok, this reply didn't go to the mailing list, because the dive log attachments made it too big. So I'm just quoting the text here for mailing list posterity, I'm assuming Jef got the actual attachments and hopefully nobody else cares (and maybe I shouldn't make my dive data that public anyway). Linus On Tue, Oct 28, 2014 at 9:51 AM, Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Tue, Oct 28, 2014 at 8:43 AM, Jef Driesen <jef(a)libdivecomputer.org> wrote: >> >> There are also some header files like unistd.h which don't exist on windows. > > Hmm. I wonder why I included them. > > Part of it is probably that the whole back-end started out as this > "suunto hacking tool" that did a lot of "print hex information of the > packets". That's also why there was no libdivecomputer infrastructure, > this thing was entirely stand-alone for just trying to gather traces > and recreate them, and figure out what the things did. > > I got no actual information from Suunto, but the fact that many things > are just text helped. Seeing filenames etc in the dumps etc.. And the > actual dive dumps have this interesting "each data has its type > associated with it, and each type has a human-readable type > descriptor". Which meant that I never needed to guess what the actual > data means - the problem was figuring out the odd marshaling of the > data, and the odd packet protocol. > > (For example, in the attached dive files, you don't see the crazy > packet protocol artifacts, because "read_file()" has cleaned it all > up. Just looking at the textual parts of the packets confused me > initially, because it turns out that the dive computer re-uses the > buffer it uses for sending the USB packets, and only fills in the > parts it needs for a possible partial packet. So the HID packets will > contain random garbage from the *previous* packet at the end etc etc. > And while the packets are 64 bytes, the two first bytes of the packet > is "packet information", so each packet contains just 62 bytes of > actual payload, yadda yadda). > >> Libdivecomputer doesn't log anything on its own. The actual logging is done >> by the application. That's on purpose. That's for example how subsurface is >> able to generate a libdivecomputer log directly from the GUI. I believe >> that's a very useful feature, which certainly doesn't sucks :-) > > So the logging I have is for protocol errors, or surprising things. > Not useful to users. It's more of a protocol verification, I would > *not* want it to show up in applications. > >> Why do you need void pointers here? You're parsing a byte array, which is by >> definition an unsigned char array. So where do you get void pointers from? > > "void *" is the "random byte area" type. It's one of the things C++ > completely screwed up. It's very useful when you use the helper > function on random data (that may be embedded in structures etc, or > give pointers to "uint32_t" etc when you convert from little-endian to > big-endian etc. > > But if there are no cases of that left over, maybe you can convert > them all to "unsigned char *" .. >> I know it doesn't support a standard memory dump. But a dump of one dive is >> fine too. I can use the parser standalone. > > I hacked up subsurface to just dump the per-dive data to a > "dive-%08x.log" file. That's *fairly* close to what the computer does > internally, although this dumped data contains the date in the first > 32-bit word, which is what the parser expects. On the dive computer, > the date is encoded in the filename - see the > > dc_buffer_append(file, buf, 4); > > in eon_steel_device_foreach() where I append it to the data buffer > instead, since the parser doesn't have access to the filename. > > (The dive date is *also* encoded in the dive data, but in a very > inconvenient format with a dynamic type, so I wanted the data from the > filename for simplicity). > > So here are the dumps of the dives I have on that dive computer so > far, in that "parser format". > > That first dive is just me lowering the dive computer into the > neighbors pool. The other 21 dives are the ones we did in Bonaire. > > Dirk has one of the Intel engineers create a contraption to lower the > thing into the pool multiple times, so that I can see what happens to > the directory listing when it no longer fits in one "readdir" reply > (the packets may be 64 bytes each, but they are chained up to be > replies that can apparently be up to 1kB in size - at least I haven't > seen anything bigger than that yet. And I don't know what happens when > the directory listing is bigger than that, because the 22 dives I have > so far create only about 460 bytes of "readdir reply"). > > Linus

5 18

Connection with Smart Z hangs
by Martin Lang 03 Nov '14

03 Nov '14

Hi, since my Windows machine stopped working and I cannot read out my Uwatec Smart Z computer anymore on this computer, I tried doing directly with my Ubuntu workstation. Unfortunately subsurface hangs always during import of the dive logs. So I tried the test application from libdivecomputer. >martin@Asterix:~/Downloads$ ./smart /dev/ttyS1 >DATETIME 2014-10-22T09:19:17Z (1413969557) >VERSION 0.5.0-devel (61e9847196b4e7f4e2c80e47dd6cd7070c9c4418) >uwatec_smart_device_open >INFO: Discover: address=ebd76f01, name=Aladin Smart Z, charset=00, hints=8000 >INFO: Connect: address=ebd76f01, lsap=1 After that the window freezes and the smart application hangs. The system is an Ubuntu 14.10 system. Any help is highly appreciated.

5 4

Cochran DC Data Structures
by John Van Ostrand 03 Nov '14

03 Nov '14

The Cochran DCs have a distinct data download and format. Basic communication; Recent model Cochran computers (Commander, EMC and probably the Gemini) use a 3 pin interface to a custom USB<->RS-232 FTDI chip interface provided by Cochran. Initial connections to the device are made at 9600, n, 8, 2, with no flow control. The DC will not respond to commands until it is first prompted. Prompting the device with 1 flush of output queues and 6 flushes of input queues triggers the device to send a heartbeat byte of 0xAA every second. Commands sent before an AA byte is issued are ignored. Most commands respond using the same serial parameters as used to send the command however large data transfers like logbook and sample download responses are sent at a higher rate. The rate depends on the DC model. The EMC baud rate is 825,600bps while the Commander is 115,200. For example, to download a typical command, like a configuration block one would do this: Open port @ 9600, n, 8, 2, no fc Flush output Flush input (repeat 6 times) Wait to receive 0xAA heart beat byte send 0x96 0x00 receive 512 bytes However for a logbook download: Open port @9600, n, 8, 2, no fc Flush output Flush input (repeat 6 times) Wait to receive 0xAA heart beat byte send 0x15 (4 byte address) (4 byte size) 0x05 reconfigure port to 825600 receive bytes set port back to 9600 There is one exception to this protocol. To download the miscellaneous block of data we send one byte, wait for a heart beat then send the remaining command and wait for a response. The example shows opening the port for every command only to illustrate the settings. In practice the port is opened only once and all blocks of data can be downloaded. The series of reads are as such: 67 byte "id" block (cmd: 0x05, 0x9D, 0xFF, 0x00, 0x43, 0x00) if this id block doesn't have the string "(C)" then read another id block 67 byte "id" block (cmd: 0x05, 0xBD, 0x7F, 0x00, 0x43, 0x00) Read 2 or 4 config blocks 512 bytes "config" block (cmd 0x96, 0x00) 512 bytes "config" block (cmd 0x96, 0x01) 512 bytes "config" block (cmd 0x96, 0x02) 512 bytes "config" block (cmd 0x96, 0x03) Within the config block will be the settings of the computer. In some cases the owner's information is there. More importantly the first block contains the number of dives in computer memory. This number can be as high as 1024. A miscellaneous block can be read. 1500 bytes "misc" (cmd: 0x89, 0x05, 0xCA, 0xFD, 0x00, 0xDC, 0x05) Using information from the config we can read the logbook. Logs for each dive are 256 bytes for an older computer and 512 bytes for a new computer. Each log has a dive start section containing the information known at the dive start, like date/time, SIT, temp, starting tissue pressures, and much of the computer's configuration at the time the dive started. Importantly it contains the byte offset into sample memory where the dive samples begin. This start section is exactly half the size of the log so 128 or 256 bytes. The second half is the end-dive section that contains summary information about the dive itself. It contains the ending memory offset of the dive samples, dive time, avg depth, max depth, min temp, etc. NOTE: The cmd below shows an EMC command. The Commander command uses 3 byte addresses and sizes. ??? bytes "logbook" (cmd 0x15 (4 byte address), (4 byte size) 0x05 Sample data occurs every second during the dive, off-gassing seconds and inter-dive events like altitude and temperature changes and unit-on events. Sample data is delivered in either 2 bytes/second (commander) or 3 bytes/second (EMC). Bits 0-6 of the first byte is always the change in depth in 1/4ft increments, with bit 6 indicating negative.Bit 7 is a flag bit, 0 indicated a depth sample 1 indicates a dive event, like ascent warning, or gas change. The second byte varies. On the first sample it's the ascent rate/min in 1/4ft units. Bit 7 indicates a negative. On the second sample it's the temperature, in 1/2 degrees F above 20. These two alternate throughout the dive. On the EMC there is a third byte which is also overloaded. Twenty four seconds of samples are needed to assemble the third sample. The first 20 bytes of this sample contain the tissue pressures, the next four contain the NDL minutes (in 2 bytes) (if not in deco) or deepest stop deco time (2 bytes) plus the total deco time (last two bytes). So a full cycle of samples on an EMC takes 24 seconds which contains 24 depth samples, 12 ascent rate samples, 12 temp samples, one set of tissue pressures, and the NDL or Deco time remaining. ??? bytes "sample" (cmd 0x15 (4 byte address) (4 byte size) 0x05 There is more detail to this protocol but this describes the basics. Examples use EMC protocol. The base memory for samples and for logbook varies based on the model. The size of memory varies based on model and based on the features enabled for the model. The date format varies between models. I suspect that lots of other parts of memory can be read using these commands. I haven't explored that. -- John Van Ostrand At large on sabbatical

2 1

[PATCH 1/8] Added define so apps can tell if new functionality is there.
by John Van Ostrand 03 Nov '14

03 Nov '14

--- include/libdivecomputer/parser.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/libdivecomputer/parser.h b/include/libdivecomputer/parser.h index 0f7021b..4c4a77c 100644 --- a/include/libdivecomputer/parser.h +++ b/include/libdivecomputer/parser.h @@ -93,6 +93,9 @@ typedef enum parser_sample_event_t { /* For backwards compatibility */ #define SAMPLE_EVENT_UNKNOWN SAMPLE_EVENT_FLOOR +/* For apps to determine new functionality */ +#define SAMPLE_EVENT_BATTERY 1 + typedef enum parser_sample_flags_t { SAMPLE_FLAGS_NONE = 0, SAMPLE_FLAGS_BEGIN = (1 << 0), -- 1.8.3.1

1 7

← Newer
1
...
16
17
18
19
20
21
22
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel