devel November 2014

devel@libdivecomputer.org

11 participants
16 discussions

[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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel November 2014