devel

devel@libdivecomputer.org

291 discussions

Re: [Reefnet Sensus Ultra] help for a beginner
by Anton Lundin 25 Jun '15

25 Jun '15

On 23 June, 2015 - stan.speleo(a)notgmail.fr wrote: > Le 22.06.2015 23:44, Anton Lundin a écrit : > > > >I'd suggest you use the higher level api, dc_device_open, > >dc_device_foreach, dc_device_close to download the dives from the > >logger. > > > >//Anton > > Thanks ! > I've found the three functions dc_device_open, dc_device_foreach, > dc_device_close in the device.h header. > Is there somewhere explained how to call those three functions ? Or a small > working exemple which can help me ? Take a look at examples/universal.c , thats a good example. Its also good practice to keep the mailinglist in CC, for anyone else who searches for answers and this can find them in the archives. //Anton -- Anton Lundin +46702-161604

2 2

Re: [Reefnet Sensus Ultra] help for a beginner
by Anton Lundin 22 Jun '15

22 Jun '15

On 17 June, 2015 - stan.speleo(a)notgmail.fr wrote: > Le 17.06.2015 13:42, Anton Lundin a écrit : > >On 17 June, 2015 - stan.speleo(a)notgmail.fr wrote: > > > >>Hi, > >> > >>I am trying to use the libdivecomputer lib in order to GET and SET the > >>INTERNALS (INTERVAL, THRESHOLD, ENDCOUNT, AVERAGING) of the Reefnet > >>Sensus > >>Ultra logger. > >>On Linux. > >>I have not found any software on linux which can manage this task. > >> > >>I have as well another less important question : how to get a csv data > >>for > >>the dives ? This would be great because the only software I could find, > >>"Subsurface", gives the data in an xml format, which I have to parse in > >>order to proceed it by myself. > >> > > > >Subsurface can export your profile into csv too. I'm currently not at a > >sane computer so i can't tell you exactly how, but the functionality is > >there. > > > >Othervise you could write your own tool which uses libdivecomputer for > >the download and emits the information in whatever format you like. > > > > > >//Anton > > Thanks a lot ! > > You answered to me instead of the mailing-list, is it by choice ? Or should > I forward to the dev list ? > To: stan.speleo(a)notgmail.fr Subject: Re: [Reefnet Sensus Ultra] help for a beginner Cc: devel(a)libdivecomputer.org And it ended up in the archives to: http://libdivecomputer.org/pipermail/devel/2015-June/000729.html So, it went to the list as well. > That answers half of my problem, and that's already great :-) > The other part, which is (I think) not supported by Subsurface, is to SET > and GET the INTERNALS. I would be very happy to get some hints in order to > do it by myself with libdivecomputer. > I have no clue how that protocoll works, but I've added support for configuring a bunch of other computers from subsurface, and i might take a look at the Reefnet stuff. Othervise you might be able to add it yourself. Relevant bits in subsurface source can be found in: configuredivecomputer.cpp configuredivecomputerthreads.cpp qt-ui/configuredivecomputerdialog.cpp qt-ui/configuredivecomputerdialog.ui //Anton -- Anton Lundin +46702-161604

3 5

RFC: New api for gas changes
by Jef Driesen 08 Jun '15

08 Jun '15

Hi, I have been working on a new api for gas changes. The idea is that old gas change events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2) will be replaced with a new DC_SAMPLE_GASMIX sample. The corresponding sample data is an integer with the index of the gas mix. The actual oxygen and helium percentages can be retrieved with the DC_FIELD_GASMIX api. The main advantage over the old events, is that the gas mix index allows to distinguish two identical gas mixes. I have attached two patches. The first patch contains the new api, and with the second patch all backends are ported to the new api. Please note that applying these patches will break existing applications. They will still build, but they will no longer get any gas change events. In order to maintain backwards compatibility, I'm planning to introduce the new api as follows: The old events will get marked as deprecated, but not removed yet. That ensures existing applications will continue to work with no changes. In the meantime, applications can start to use the new api. And once v0.5 is out, the old events will be removed. Comments are welcome! PS: I'm leaving tonight for a diving trip, so I probably won't be able to respond to questions or comments during the next week. Jef

3 7

Re: Subsurface + Suunto Vyper Air
by Linus Torvalds 15 May '15

15 May '15

On Thu, May 14, 2015 at 8:51 AM, John Nevius <john.nevius(a)gmail.com> wrote: > "in deco" shows in the 'pop-up' box that shows when you fly the cursor over > the dive profile. First dive of the series, so there was no prior nitrogen > loading and I forgot to mention I was diving EAN32 > > What is best way to share the dive profile? You could just save that single dive as an xml file (select the dive(s) you want to export, go to File->Export and export selected dives as "Subsurface XML"), we'd see it from that. That said, I don't think you need to do that. The "in deco" in your profile info window does indeed mean that subsurface thinks we have a deco obligation from the dive computer. So libdivecomputer gave us a DC_SAMPLE_DECO sample that is either DC_DECO_DECOSTOP or DC_DECO_DEEPSTOP. And I think it's that "DC_DECO_DEEPSTOP" that confuses subsurface. I don't think we should set in_deco because of a deepstop. Dirk, this goes back a long time to commit e3ab1c0701fc "Update deco handling". But fixing that probably wouldn't even fix your issue. The whole libdivecomputer deco handling is a bit odd, and it turns out that libdivecomputer considers a "Mandatory safety stop" to be something that triggers "in deco" through DC_DECO_DECOSTOP, and the most likely reason you got that was indeed that mandatory safety stop thing. Dirk, at least for the Suunto D9, the actual "deco" event seems to be DC_SAMPLE_EVENT + SAMPLE_EVENT_DECOSTOP not that "DC_SAMPLE_DECO + (DC_DECO_DECOSTOP | DC_DECO_DEEPSTOP)" Of course, that makes no sense. We shouldn't have to parse random events when libdivecomputer has that "SAMPLE_DECO" thing. So arguably this is more of a libdivecomputer issue. I do not think that suunto deepstops or mandatory safety stops should cause DC_SAMPLE_DECO events. Suunto's create those "mandatory safety stop" things fairly aggressively. You'll get them for fast ascents etc. Dirk, Jeff, and the libdivecomputer mailing list added to the participants list of this mail. Linus

2 1

[PATCH] Dump function for the OSTC3
by Anton Lundin 01 May '15

01 May '15

This adds a dump function for the ostc3 series computers. This function dumps the whole external eprom, that contains the dive-headers and the dive data. Signed-off-by: Anton Lundin <glance(a)acc.umu.se> --- I haven't seen the code for the simulator, but the relevant parts are that the dive headers are located at: ; 1st: 200000h-2000FFh ; 2nd: 201000h-2010FFh ; 3rd: 202000h-2020FFh ; 100: 264000h-2640FFh ; 256: 2FF000h-2FF0FFh And in those headers at byte 2 and 5 are the pointers to where in the memory the actual dive profile are, in little endian. It shouldn't be too hard to write simulator code for that. src/hw_ostc3.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 62 insertions(+), 1 deletion(-) diff --git a/src/hw_ostc3.c b/src/hw_ostc3.c index a5f96bf..4487d15 100644 --- a/src/hw_ostc3.c +++ b/src/hw_ostc3.c @@ -109,15 +109,17 @@ static const unsigned char ostc3_key[16] = { }; static dc_status_t hw_ostc3_device_set_fingerprint (dc_device_t *abstract, const unsigned char data[], unsigned int size); +static dc_status_t hw_ostc3_device_dump (dc_device_t *abstract, dc_buffer_t *buffer); static dc_status_t hw_ostc3_device_foreach (dc_device_t *abstract, dc_dive_callback_t callback, void *userdata); static dc_status_t hw_ostc3_device_close (dc_device_t *abstract); +static dc_status_t hw_ostc3_firmware_block_read (hw_ostc3_device_t *device, unsigned int addr, unsigned char block[], unsigned int block_size); static const dc_device_vtable_t hw_ostc3_device_vtable = { DC_FAMILY_HW_OSTC3, hw_ostc3_device_set_fingerprint, /* set_fingerprint */ NULL, /* read */ NULL, /* write */ - NULL, /* dump */ + hw_ostc3_device_dump, /* dump */ hw_ostc3_device_foreach, /* foreach */ hw_ostc3_device_close /* close */ }; @@ -443,6 +445,65 @@ hw_ostc3_device_set_fingerprint (dc_device_t *abstract, const unsigned char data } +static dc_status_t +hw_ostc3_device_dump (dc_device_t *abstract, dc_buffer_t *buffer) +{ + hw_ostc3_device_t *device = (hw_ostc3_device_t *) abstract; + + // Erase the current contents of the buffer. + if (!dc_buffer_clear (buffer)) { + ERROR (abstract->context, "Insufficient buffer space available."); + return DC_STATUS_NOMEMORY; + } + + // Make sure the device is in service mode + dc_status_t rc = hw_ostc3_device_init (device, SERVICE); + if (rc != DC_STATUS_SUCCESS) { + return rc; + } + + // Enable progress notifications. + dc_event_progress_t progress = EVENT_PROGRESS_INITIALIZER; + //unsigned int size = (RB_LOGBOOK_SIZE * RB_LOGBOOK_COUNT) + SZ_MEMORY; + unsigned int size = 0x400000; + progress.maximum = size; + device_event_emit (abstract, DC_EVENT_PROGRESS, &progress); + + // Allocate the required amount of memory. + if (!dc_buffer_resize (buffer, size)) { + ERROR (abstract->context, "Insufficient buffer space available."); + return DC_STATUS_NOMEMORY; + } + + unsigned char *data = dc_buffer_get_data (buffer); + + unsigned int nbytes = 0; + while (nbytes < size) { + // packet size. Can be almost arbetary size. + unsigned int len = 4096; + + // Limit the packet size to the total size. + if (nbytes + len > size) + len = size - nbytes; + + // Read a block + rc = hw_ostc3_firmware_block_read (device, nbytes, data + nbytes, len); + if (rc != DC_STATUS_SUCCESS) { + ERROR (abstract->context, "Failed to read block."); + return rc; + } + + // Update and emit a progress event. + progress.current += len; + device_event_emit (abstract, DC_EVENT_PROGRESS, &progress); + + nbytes += len; + } + + return DC_STATUS_SUCCESS; +} + + dc_status_t hw_ostc3_device_version (dc_device_t *abstract, unsigned char data[], unsigned int size) { -- 2.1.0

2 3

Subgravity H3?
by William Perry 22 Mar '15

22 Mar '15

A fried of mine has a couple of these to play with and is raving about them as technical / caving computer - wondering if anyone has looked at adding support for downloading to libdivecomputer? One of its big features is downloading over NFC to android devices, but it can also download over USB. I might have a chance to borrow a unit to play with once I get back from Cozumel. Not much of a USB sniffer guy, but I can try to throw it onto a linux VM and see what kind of interfaces it exposes, etc. Hopefully it just exposes info on a filesystem. -bill

1 0

Reparsing data
by Shawn Willden 18 Mar '15

18 Mar '15

Is there a convenient way (short of figuring out the API and writing a program... which I can do but I'd rather not) to parse a dump file? I have managed to download from my old Uwatec Aladin Air Z, and most everything is good but I'm not getting gas consumption data. Looking at uwatec_memomouse_parser.c, it seems like the parser should be getting tank pressure from the data, but I'm not seeing it in subsurface. So, I'd like to reparse a dump file so I can walk through it in the debugger and figure out what's going on. I looked at hacking up examples/universal.c, but it's pretty set on downloading from a computer. Also if anyone knows of any documentation for the Uwatec data format, that might be helpful, but I suspect I can get a really good idea of what's going on by just walking through the code as it dissects the data. -- Shawn

2 5

Question about Suunto EON Steel on MacOS
by Janice McLaughlin 09 Mar '15

09 Mar '15

I was just looking at the Suunto Eon Steel support added and was wondering if anyone had tried it on a Mac. Specifically: Since the EON appears to identify as a USB HID device, the oh so wonderful MacOS kernel driver will probably grab it right? Which means in suunto_eonsteel_device_open(), the call to libusb_claim_interface(eon->handle, 0) will fail. (Been there, done that). But there is no return code checking on the call so the open will continue. Is that on purpose? Or by accident? And there is no corresponding call to libusb_release_interface() in close either .... It's obviously working fine on Linux and Windows, but I can't see how it would work on a Mac unless I'm misinterpreting what the device actually looks like from a USB point of view. I don't have one to test with but wanted to look into adding support for it. I dug around Suunto DM5 and, at least on the Mac, it seems to be using hidapi although again, since I don't actually have one in my hands .... Thanks, Janice ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

3 5

Kernel error / Uwatec Smart via irda
by Nick Hardy 09 Feb '15

09 Feb '15

I am trying to download dives from my Uwatec Smart Com on Ubuntu 14.10. I have tried to eliminate as much complexity and have downloaded the smart test app to gather info about the problem. In the below system log, I have captured the following actions: 1. insert the usb irda dongle. 2. run irattach irda0. 3. run a quick irdadump to make sure the system sees the dive computer. 4. run smart. The following lines are output: DATETIME 2015-02-09T01:21:20Z (1423444880) VERSION 0.5.0-devel (61e9847196b4e7f4e2c80e47dd6cd7070c9c4418) uwatec_smart_device_open INFO: Discover: address=16c40100, name=Aladin Smart Com, charset=00, hints=8000 INFO: Connect: address=16c40100, lsap=1 A few seconds later, a system error message pops up. The smart application never completes and can not be killed. The smart.log file is created, but nothing is ever written to it. I have cloned the current git tree and compiled the app successfully but it generates the same error. I'm happy to help debug if you'd like. Thanks! Nick Hardy System log follows: Feb 8 18:19:21 nick-Lenovo-IdeaPad-Z410 kernel: [184101.176165] usb 3-2: new full-speed USB device number 17 using xhci_hcd Feb 8 18:19:21 nick-Lenovo-IdeaPad-Z410 kernel: [184101.304370] usb 3-2: New USB device found, idVendor=9710, idProduct=7780 Feb 8 18:19:21 nick-Lenovo-IdeaPad-Z410 kernel: [184101.304373] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Feb 8 18:19:21 nick-Lenovo-IdeaPad-Z410 mtp-probe: checking bus 3, device 17: "/sys/devices/pci0000:00/0000:00:14.0/usb3/3-2" Feb 8 18:19:21 nick-Lenovo-IdeaPad-Z410 mtp-probe: bus: 3, device: 17 was not an MTP device Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: executing: '/sbin/modprobe irda0' Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: + modprobe: FATAL: Module irda0 not found. Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: Trying to load module irda0 exited with status 1 Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: executing: 'echo nick-Lenovo-IdeaPad-Z410 > /proc/sys/net/irda/devname' Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: executing: 'echo 1 > /proc/sys/net/irda/discovery' Feb 8 18:19:22 nick-Lenovo-IdeaPad-Z410 irattach: Starting device irda0 Feb 8 18:20:15 nick-Lenovo-IdeaPad-Z410 irattach: executing: '/sbin/modprobe irda0' Feb 8 18:20:15 nick-Lenovo-IdeaPad-Z410 irattach: + modprobe: FATAL: Module irda0 not found. Feb 8 18:20:15 nick-Lenovo-IdeaPad-Z410 irattach: Trying to load module irda0 exited with status 1 Feb 8 18:20:15 nick-Lenovo-IdeaPad-Z410 irattach: executing: 'echo nick-Lenovo-IdeaPad-Z410 > /proc/sys/net/irda/devname' Feb 8 18:20:15 nick-Lenovo-IdeaPad-Z410 irattach: Starting device irda0 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.824122] BUG: unable to handle kernel NULL pointer dereference at (null) Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.824218] IP: [< (null)>] (null) Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.824270] PGD 189e66067 PUD 1dd796067 PMD 0 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.824323] Oops: 0010 [#2] SMP Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.824360] Modules linked in: ctr ccm pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm bnep mcs7780 uvcvideo irda crc_ccitt videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common uas videodev usb_storage media ath3k btusb bluetooth binfmt_misc 6lowpan_iphc nls_iso8859_1 arc4 ath9k ath9k_common ath9k_hw ath mac80211 intel_rapl x86_pkg_temp_thermal intel_powerclamp cfg80211 coretemp kvm_intel kvm snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_controller snd_hda_codec ghash_clmulni_intel aesni_intel aes_x86_64 snd_hwdep snd_pcm lrw snd_seq_midi gf128mul glue_helper snd_seq_midi_event snd_rawmidi ablk_helper snd_seq i915 cryptd snd_seq_device snd_timer mei_me snd soundcore mei drm_kms_helper drm i2c_algo_bit ideapad_laptop lpc_ich shpchp joydev video sparse_keymap serio_raw mac_hid parport_pc ppdev lp parport hid_generic usbhid hid psmouse ahci r8169 libahci mii Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825401] CPU: 1 PID: 26737 Comm: smart Tainted: G D OE 3.16.0-30-generic #40-Ubuntu Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825484] Hardware name: LENOVO 20292/VIUU4, BIOS 8DCN38WW 11/28/2013 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825547] task: ffff880018bbbd20 ti: ffff880158a64000 task.ti: ffff880158a64000 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825615] RIP: 0010:[<0000000000000000>] [< (null)>] (null) Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825687] RSP: 0018:ffff880158a67dc8 EFLAGS: 00010206 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825736] RAX: ffffffffc094b300 RBX: ffff880087eb2a80 RCX: ffff880033d5df08 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825801] RDX: ffff880033d5df08 RSI: 0000000000000002 RDI: ffff8802433e7000 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825865] RBP: ffff880158a67e40 R08: ffff880158a64000 R09: 0000000000000206 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825930] R10: 0000026625c2ce74 R11: 00000000000006f7 R12: ffff880158a67e58 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.825994] R13: ffff8802433e7000 R14: 0000000000000000 R15: 0000000000000024 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] FS: 0000000000000000(0000) GS:ffff88025f240000(0063) knlGS:00000000f757c940 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] CR2: 0000000000000000 CR3: 0000000186023000 CR4: 00000000001407e0 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] Stack: Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] ffffffffc0943956 0000000000000000 ffffffff82347a4d ffff880087eb2a80 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] 0000000258a67e58 0000000000000000 ffff880018bbbd20 ffffffff820b9740 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] ffff880158a67e08 ffff880158a67e08 ffff880087eb2a80 0000000000000024 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] Call Trace: Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffffc0943956>] ? irda_connect+0x156/0x490 [irda] Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff82347a4d>] ? aa_sk_perm.isra.4+0x6d/0x170 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff820b9740>] ? prepare_to_wait_event+0x100/0x100 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff826669f7>] SYSC_connect+0xe7/0x120 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff8201195d>] ? __switch_to+0x48d/0x5e0 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff82667a5e>] SyS_connect+0xe/0x10 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff826a2f26>] compat_SyS_socketcall+0x3d6/0x500 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] [<ffffffff8278cb5a>] sysenter_dispatch+0x7/0x21 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] Code: Bad RIP value. Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] RIP [< (null)>] (null) Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] RSP <ffff880158a67dc8> Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.828073] CR2: 0000000000000000 Feb 8 18:21:22 nick-Lenovo-IdeaPad-Z410 kernel: [184222.891236] ---[ end trace 9e0b0d278edbbe8d ]---

2 2

[PATCH] Predator: don't report PPO2 unless in CC mode
by Dirk Hohndel 07 Feb '15

07 Feb '15

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(a)hohndel.org> --- src/shearwater_predator_parser.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/shearwater_predator_parser.c b/src/shearwater_predator_parser.c index 32200f1ef552..eac3a3b21fe7 100644 --- a/src/shearwater_predator_parser.c +++ b/src/shearwater_predator_parser.c @@ -325,9 +325,11 @@ shearwater_predator_parser_samples_foreach (dc_parser_t *abstract, dc_sample_cal sample.temperature = temperature; if (callback) callback (DC_SAMPLE_TEMPERATURE, sample, userdata); - // PPO2 - sample.ppo2 = data[offset + 6] / 100.0; - if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); + // PPO2 -- only return PPO2 if we are in closed circuit mode + if (data[offset + 11] & 0x10 == 0) { + sample.ppo2 = data[offset + 6] / 100.0; + if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); + } // Gaschange. unsigned int o2 = data[offset + 7]; -- 1.8.0.rc0.18.gf84667d

1 1

← Newer
1
...
12
13
14
15
16
17
18
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

devel