devel January 2016

devel@libdivecomputer.org

3 participants
8 discussions

Re: Sentinel (and rEvo)
by "Paul-Erik Törrönen" 29 Jan '16

29 Jan '16

> The D<n> command is multiple bytes, right? Yes. As I wrote, I tried the single char commands from the terminal software, and they did not work. > I think you are trying to re-use a bit too much from the backend that > you used as an example. How to best read the response depends on how the > protocol works. Is the length fixed or variable, do we known it in > advance or not, etc. Ok. As I may have mentioned in the beginning, this is totally unknown territory for me. From my understanding though, the code logic should be pretty simple: We do some base assumptions about buffer size, then attempt to read it full, and if the data from the device i less, then we should resize the buffer to match the actual data amount. Going back here: When I successfully get the universal to send (even this seems to be unstable at times) the request byte, it does receive what seems to be an appropriate response. But I think I understand your point, it could be that the chipset on the USB-cable pretending to be a serial device has some assumptions when the client is reading off it, and this has to be matched by the client software? FWIW is it meaningful that the portmon log seems to indicate single byte read most of the time, or is it just an artifact of how portmon logs the communication? Here's a snippet of the portmon log (I grep IRP_MJ for clarity): 87 0.00000698 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 3: 50 50 50 92 0.00001509 ProLink2010oct. IRP_MJ_CLEANUP Silabser0 SUCCESS 93 0.00320152 ProLink2010oct. IRP_MJ_CLOSE Silabser0 SUCCESS 94 0.02598515 ProLink2010oct. IRP_MJ_CREATE Silabser0 SUCCESS Options: Open 121 0.00000503 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 50 130 0.00000531 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 50 139 0.00000531 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 50 145 0.00093783 ProLink2010oct. IRP_MJ_WRITE Silabser0 SUCCESS Length 1: 4D 155 0.00000559 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 64 164 0.00000363 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 0D 173 0.00000363 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 0A 182 0.00000363 ProLink2010oct. IRP_MJ_READ Silabser0 SUCCESS Length 1: 76 0x50 equals P and seems to be the standby byte sent periodically. So this equals to: read: PPP read: P read: P read: P send: M read: d read: \r read: \n read: v ... Poltsi -- Paul-Erik Törrönen poltsi(a)777-team.org +358 40 703 1231 http://poltsi.fi/ Science, it reduces the stupid

2 4

Cochran Changes
by John Van Ostrand 29 Jan '16

29 Jan '16

Hi, Now that our branches match I went through last year's thread on Cochran development, "Cochran_commander refactoring". I think this is a summary of where we left of: 1. dc_context_t pointer doesn't need to be passed to cochran serial open a setup functions. (fixed with patch pending.) 2. Cochran can store more log entries than profiles. So when the profile ring buffer wraps earlier logs will point to profile data from other dives. Jef suggests processing dives in reverse chronological order, adding up profile data used and not processing profiles after it's processed a full ring-buffer of data. I have yet to work on this or consider alternatives. 3. Corrupt dive handling. In some cases (like a low battery especially in cold water) the computer resets during a dive. This results in a "start-dive" block written but no valid "end-dive" block written. We know information from the start of a dive (like date/time, gasses, profile start pointer, etc.) but we don't know information accumulated during or at the end of a dive (like end-profile pointer, max depth, min temp, etc.) I've taken to guessing the end of a dive by starting with the next dive's pre-dive-profile-pointer and backing up until we think we have the previous dive's end. We haven't resolved our differences on this. It seems to down to the question: Do we present a partial or broken profile in the interest of giving the diver something or do we give nothing in the interest of being accurate? -- John Van Ostrand At large on sabbatical

3 4

[PATCH 1/3] Cochran: Remove uneeded "context" argument to serial functions.
by John Van Ostrand 23 Jan '16

23 Jan '16

It was extraneous becaue it's included in the dc_device_t struct. --- src/cochran_commander.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/src/cochran_commander.c b/src/cochran_commander.c index 9fb8c6b..97e0531 100644 --- a/src/cochran_commander.c +++ b/src/cochran_commander.c @@ -221,7 +221,7 @@ cochran_packet (cochran_device_t *device, dc_event_progress_t *progress, static dc_status_t -cochran_commander_serial_setup (cochran_device_t *device, dc_context_t *context) +cochran_commander_serial_setup (cochran_device_t *device) { int rc; @@ -229,7 +229,7 @@ cochran_commander_serial_setup (cochran_device_t *device, dc_context_t *context) rc = serial_configure (device->port, 9600, 8, SERIAL_PARITY_NONE, 2, SERIAL_FLOWCONTROL_NONE); if (rc == -1) { - ERROR (context, "Failed to set the terminal attributes."); + ERROR (device->base.context, "Failed to set the terminal attributes."); serial_close (device->port); return DC_STATUS_IO; } @@ -247,7 +247,7 @@ cochran_commander_serial_setup (cochran_device_t *device, dc_context_t *context) // Set the timeout for receiving data (5000 ms). if (serial_set_timeout (device->port, 5000) == -1) { - ERROR (context, "Failed to set the timeout."); + ERROR (device->base.context, "Failed to set the timeout."); serial_close (device->port); return DC_STATUS_IO; } @@ -256,7 +256,7 @@ cochran_commander_serial_setup (cochran_device_t *device, dc_context_t *context) char answer[1]; int n = serial_read(device->port, answer, 1); if (n != 1) { - ERROR (context, "Failed to receive device heartbeat."); + ERROR (device->base.context, "Failed to receive device heartbeat."); return EXITCODE (n); } @@ -265,16 +265,16 @@ cochran_commander_serial_setup (cochran_device_t *device, dc_context_t *context) dc_status_t -cochran_commander_serial_open(cochran_device_t *device, dc_context_t *context) +cochran_commander_serial_open(cochran_device_t *device) { // Open the device. - int rc = serial_open (&device->port, context, device->name); + int rc = serial_open (&device->port, device->base.context, device->name); if (rc == -1) { - ERROR (context, "Failed to open the serial port."); + ERROR (device->base.context, "Failed to open the serial port."); return DC_STATUS_IO; } - return cochran_commander_serial_setup(device, context); + return cochran_commander_serial_setup(device); } @@ -304,7 +304,7 @@ cochran_commander_device_open (dc_device_t **out, dc_context_t *context, cochran_commander_device_set_fingerprint((dc_device_t *) device, NULL, 0); - rc = cochran_commander_serial_open(device, context); + rc = cochran_commander_serial_open(device); if (rc != DC_STATUS_SUCCESS) { dc_device_deallocate((dc_device_t *) device); return rc; @@ -586,7 +586,7 @@ cochran_read_logbook (dc_device_t *abstract, dc_event_progress_t *progress) serial_sleep(device->port, 800); // set back to 9600 baud - cochran_commander_serial_setup(device, abstract->context); + cochran_commander_serial_setup(device); // Request log book rc = cochran_commander_read(abstract, progress, 0, d->logbook, @@ -686,7 +686,7 @@ cochran_read_samples(dc_device_t *abstract, dc_event_progress_t *progress) serial_sleep(device->port, 800); // set back to 9600 baud - cochran_commander_serial_setup(device, abstract->context); + cochran_commander_serial_setup(device); // Read the sample data rc = cochran_commander_read (abstract, progress, d->sample_data_offset, @@ -817,7 +817,7 @@ cochran_commander_device_dump (dc_device_t *abstract, dc_buffer_t *data) serial_sleep(device->port, 800); // set back to 9600 baud - cochran_commander_serial_setup(device, abstract->context); + cochran_commander_serial_setup(device); // Read the sample data, from 0 to sample end will include logbook rc = cochran_commander_read (abstract, &progress, 0, -- 2.4.3

1 2

[PATCH 1/6] Fixed rounding error with ascent rates.
by John Van Ostrand 11 Jan '16

11 Jan '16

--- src/cochran_emc_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/cochran_emc_parser.c b/src/cochran_emc_parser.c index 635f050..5d430f4 100644 --- a/src/cochran_emc_parser.c +++ b/src/cochran_emc_parser.c @@ -246,7 +246,7 @@ cochran_emc_parser_samples_foreach (dc_parser_t *abstract, // Ascent rate is logged in the 0th sample, temp in the 1st, repeat. if (time % 2 == 0) { // Ascent rate - ascent_rate = (s[1] & 0x7f) / 4 * (s[1] & 0x80 ? 1 : -1); + ascent_rate = (float) (s[1] & 0x7f) / 4 * (s[1] & 0x80 ? 1 : -1); sample.ascent_rate = ascent_rate * FEET; if (callback) callback (DC_SAMPLE_ASCENT_RATE, sample, userdata); } else { -- 2.4.3

1 5

[PATCH 001/007] Missed a conflict in the last pull.
by John Van Ostrand 08 Jan '16

08 Jan '16

--- src/libdivecomputer.symbols | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/libdivecomputer.symbols b/src/libdivecomputer.symbols index fd8f44a..a870a22 100644 --- a/src/libdivecomputer.symbols +++ b/src/libdivecomputer.symbols @@ -170,8 +170,5 @@ shearwater_predator_extract_dives shearwater_petrel_device_open diverite_nitekq_device_open diverite_nitekq_extract_dives -<<<<<<< HEAD cochran_commander_device_open -======= citizen_aqualand_device_open ->>>>>>> 134da18190b5ea1581d789564979e3e4c73cd243 -- 2.4.3

1 6

Re: Getting back to Cochran coding.
by Jef Driesen 08 Jan '16

08 Jan '16

On 2016-01-07 17:13, John Van Ostrand wrote: > Now that the main dive season is well over and I'm only getting out > every > couple of weeks I felt the urge to get back on this. It's been a year > since > my last exchange. > > Jeff, do you still have a branch for my code? Do you need a full patch > or > just a merge patch? I'm quite new at git so it's best if you're > explicit > when explaining. I still have a local branch with all your cochran patches. We can continue from there again. I haven't really touched that code since last time. Been occupied with other things. It's probably a good idea to rebase everything on current master, but I'm not sure I'll have time this weekend to take care of that. Jef

1 0

Getting back to Cochran coding.
by John Van Ostrand 07 Jan '16

07 Jan '16

Hi, Now that the main dive season is well over and I'm only getting out every couple of weeks I felt the urge to get back on this. It's been a year since my last exchange. Jeff, do you still have a branch for my code? Do you need a full patch or just a merge patch? I'm quite new at git so it's best if you're explicit when explaining. -- John Van Ostrand At large on sabbatical

1 0

Re: Sentinel (and rEvo)
by Jef Driesen 01 Jan '16

01 Jan '16

On 2015-11-01 10:53, Paul-Erik Törrönen wrote: > Hello, finally got all the necessary pieces to do a log download on the > Sentinel, and I followed the instructions on the libdive web-page. > > I captured the USB/serial traffic in 2 separate files, the first one¹ > is > when the original piece of software (OPOS, Prolink) is fired up and > connects to the rebreather. > > The second² is when I hit the dowload button on the OPOS and it fetches > the (2) dives. > > ¹ http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-connect.log.7z > ² http://poltsi.fi/Sukeltaminen/Sentinel/Log/sentinel-download.log.7z > > Regarding the rEvo, I probably will be able to borrow one diveCan SW > for a > couple of days during the week, so I will get back to you regarding > that. Unfortunately I don't have time at the moment to look into adding a new communication backend. Sorry, but maybe you can have a look yourself? I quickly ran your logs through my portmon parsing scripts, and it seems the dive computer sends back plain ascii data. The attached *.log file contains the I/O operations, and the *.txt contains the raw data received from the dive computer. Jef

2 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel January 2016