- devel - libdivecomputer.org

More Uwatec Aladin TEC2G Log Data
by Thomas Gschwind 02 Jun '17

02 Jun '17

Hi there, I am using Subsurface and it reports all my salt water dives deeper than they really are. So I downloaded the latest libdivecomputer sources and looked at the code. The tec2g_header claims that the salinity setting of this dive computer is not supported. After looking at the dumps included in my SmartTRAK log where the dives are correctly reported (SmartTRAK is nice enough to store the original dc data), I am most certain to have located the salinity field in byte 62 of the header. Another indication is that it is also bit 0x10 as it is for the others (see get water in uwatec_smart_parser_cache). Just tried out setting the salinity field to 62 and works perfectly fine for me. Similarly, the timezone field most likely is 16. However, that one I cannot test so well because the immersion time seems to be relative to the dive computers system time which seems to be missing in the SmartTRAK logs. But manually looking at the time zones, it matched for the first 50+ of my dives. I also figured out the max ppo2 configuration and partially the tissue saturation before the dive --- if anybody is interested that data as well. See http://tomsblog.gschwinds.net/2016/08/uwatec-smarttrak-and-aladin-tec2g/ for details. Best, Thomas

3 6

[PATCH] Altered model detection after seeing some bytes change after a firmware update.
by john＠vanostrand.com 26 May '17

26 May '17

From: John Van Ostrand <john(a)vanostrand.com> --- src/cochran_commander.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/cochran_commander.c b/src/cochran_commander.c index 99fe369..d2c47b0 100644 --- a/src/cochran_commander.c +++ b/src/cochran_commander.c @@ -42,7 +42,7 @@ typedef enum cochran_endian_t { } cochran_endian_t; typedef struct cochran_commander_model_t { - unsigned char id[8 + 1]; + unsigned char id[2 + 1]; unsigned int model; } cochran_commander_model_t; @@ -199,10 +199,10 @@ static unsigned int cochran_commander_get_model (cochran_commander_device_t *device) { const cochran_commander_model_t models[] = { - {"AM\x11""2212\x02", COCHRAN_MODEL_COMMANDER_AIR_NITROX}, - {"AM7303\x8b\x43", COCHRAN_MODEL_EMC_14}, - {"AMA315\xC3\xC5", COCHRAN_MODEL_EMC_16}, - {"AM2315\xA3\x71", COCHRAN_MODEL_EMC_20}, + {"\x11""2", COCHRAN_MODEL_COMMANDER_AIR_NITROX}, + {"73", COCHRAN_MODEL_EMC_14}, + {"A3", COCHRAN_MODEL_EMC_16}, + {"23", COCHRAN_MODEL_EMC_20}, }; unsigned int model = 0xFFFFFFFF; -- 2.4.11

1 0

Re: [Subsurface-divelog/libdc] Sync with Jef's upstream (#6)
by Linus Torvalds 25 May '17

25 May '17

On Thu, May 25, 2017 at 11:35 AM, Jef Driesen <jef(a)libdivecomputer.org> wrote: > > > The explanation is in the commit message: > > Note that the interpretation of the PPO2 status bit appears to be > reversed (0=external and 1=internal). You mis-understand. It's not the particular status bit polarity I worry about. It's simply that whole "average PPO2 data" piece. IOW, this code: #ifdef SENSOR_AVERAGE sample.ppo2 = data[offset + 6] / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); #else fundamentally makes no sense as it is now. There are two possibilities I see for that sample.ppo2 value: (a) it too only exists for the internal sensor case (b) it exists even when we have an external sensor, and then contains the single PPO2 value that the external sensor gives us. but the code right now is wrong in *either* case. So if it's case (a), then that whole #ifdef SENSOR_AVERAGE logic should be _inside_ the PPO2_EXTERNAL check. And if it is case (b), then we should have an "else" case for that PPO2_EXTERNAL case, and give the user that single PPO2 value. See what I'm saying? As it is, the code makes no sense and absolutely cannot be right. Linus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

1 0

Re: [Subsurface-divelog/libdc] Sync with Jef's upstream (#6)
by Linus Torvalds 25 May '17

25 May '17

On Wed, May 24, 2017 at 10:13 AM, janmulder <notifications(a)github.com> wrote: > > In addition some merge conflicts are resolved. So since I want to know what's going on, I ended up doing my own merging and re-resolving things, and while I did that I became convinced that there is a bug in the PPO2 reporting for the predator. The code does this: #ifdef SENSOR_AVERAGE sample.ppo2 = data[offset + 6] / 100.0; if (callback) callback (DC_SAMPLE_PPO2, sample, userdata); #else if ((status & PPO2_EXTERNAL) == 0) { sample.ppo2 = data[offset + 12] * parser->calibration[0]; if (callback && (data[86] & 0x01)) callback (DC_SAMPLE_PPO2, sample, userdata); sample.ppo2 = data[offset + 14] * parser->calibration[1]; if (callback && (data[86] & 0x02)) callback (DC_SAMPLE_PPO2, sample, userdata); sample.ppo2 = data[offset + 15] * parser->calibration[2]; if (callback && (data[86] & 0x04)) callback (DC_SAMPLE_PPO2, sample, userdata); } #endif which means that if you don't have SENSOR_AVERAGE defined, and if it's an external sensor, now there's no sensor reporting AT ALL. Which seems bogus. So either that average PPO2 should be sent if there's an external sensor, or that SENSOR_AVERAGE case should also be inside that "check for external sensor". The code as it stands now makes no sense. Anton, I think this is all yours. Comments? Linus ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ libdivecomputer-devel mailing list libdivecomputer-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdivecomputer-devel

1 1

*****SPAM***** ✔Fw: what a nice day
by devel 02 May '17

02 May '17

Spam detection software, running on the system "mhg.gr8dns.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Hi! I've had a really nice day and I just wanted to share something really cool with you, please take a look http://mensch.truelaserdesign.com My best to you, devel [...] Content analysis details: (5.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see <http://www.spamcop.net/bl.shtml?14.184.230.7>] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (5loicmichel5[at]wanadoo.fr) 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_IMAGE_RATIO_06 BODY: HTML has a low ratio of text to image area -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: truelaserdesign.com] 3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL [14.184.230.7 listed in zen.spamhaus.org] 0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

*****SPAM***** Re: some helpful information
by 5loicmichel5 27 Apr '17

27 Apr '17

Spam detection software, running on the system "mhg.gr8dns.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Yo! I've found some information that may be helpful for you, check it out http://www.gentlegiantsrescue-american-staghounds.com/rough.php?dddc 5loicmichel5 [...] Content analysis details: (5.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (5loicmichel5[at]wanadoo.fr) 1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist [URIs: gentlegiantsrescue-american-staghounds.com] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 1.4 RCVD_IN_BRBL_LASTEXT RBL: No description available. [14.186.199.63 listed in bb.barracudacentral.org] 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 HTML_IMAGE_RATIO_06 BODY: HTML has a low ratio of text to image area -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 1.9 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level above 50% [cf: 100] 0.8 RDNS_NONE Delivered to internal network by a host with no rDNS 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 0

Removal of deprecated functions and header files
by Jef Driesen 13 Apr '17

13 Apr '17

Hi, I'm planning to cleanup the public api, and remove the vendor_product_parser_create(), vendor_product_device_open() and vendor_product_extract_dives() functions. The first two functions should be called indirectly through the dc_device_open(), dc_parser_new() and dc_parser_new2() functions instead. And the vendor_product_extract_dives() is an internal function that shouldn't have been part of the public api in the first place. I don't think anyone is still using those functions, so I don't expect any problems. The only thing to watch out is that their header files (along with all the vendor.h header files) will be removed as well. So make sure to remove any unnecessary include statements from your code. The complete list of functions that will be removed: atomics_cobalt_device_open atomics_cobalt_parser_create citizen_aqualand_device_open citizen_aqualand_parser_create cochran_commander_device_open cochran_commander_parser_create cressi_edy_device_open cressi_edy_parser_create cressi_leonardo_device_open cressi_leonardo_parser_create cressi_leonardo_parser_create2 diverite_nitekq_device_open diverite_nitekq_extract_dives diverite_nitekq_parser_create divesystem_idive_device_open divesystem_idive_device_open2 divesystem_idive_parser_create divesystem_idive_parser_create2 hw_frog_device_open hw_ostc3_device_open hw_ostc3_parser_create hw_ostc_device_open hw_ostc_extract_dives hw_ostc_parser_create mares_darwin_device_open mares_darwin_extract_dives mares_darwin_parser_create mares_iconhd_device_open mares_iconhd_parser_create mares_nemo_device_open mares_nemo_extract_dives mares_nemo_parser_create mares_puck_device_open mares_puck_extract_dives oceanic_atom2_device_open oceanic_atom2_device_open2 oceanic_atom2_parser_create oceanic_veo250_device_open oceanic_veo250_parser_create oceanic_vtpro_device_open oceanic_vtpro_device_open2 oceanic_vtpro_parser_create oceanic_vtpro_parser_create2 reefnet_sensus_device_open reefnet_sensus_extract_dives reefnet_sensus_parser_create reefnet_sensuspro_device_open reefnet_sensuspro_extract_dives reefnet_sensuspro_parser_create reefnet_sensusultra_device_open reefnet_sensusultra_extract_dives reefnet_sensusultra_parser_create shearwater_petrel_device_open shearwater_petrel_parser_create shearwater_predator_device_open shearwater_predator_extract_dives shearwater_predator_parser_create suunto_d9_device_open suunto_d9_parser_create suunto_eon_device_open suunto_eon_extract_dives suunto_eon_parser_create suunto_eonsteel_device_open suunto_eonsteel_parser_create suunto_solution_device_open suunto_solution_extract_dives suunto_solution_parser_create suunto_vyper2_device_open suunto_vyper_device_open suunto_vyper_device_read_dive suunto_vyper_extract_dives suunto_vyper_parser_create uwatec_aladin_device_open uwatec_aladin_extract_dives uwatec_memomouse_device_open uwatec_memomouse_extract_dives uwatec_memomouse_parser_create uwatec_meridian_device_open uwatec_meridian_extract_dives uwatec_smart_device_open uwatec_smart_extract_dives uwatec_smart_parser_create zeagle_n2ition3_device_open and the header files: atomics.h citizen.h citizen_aqualand.h cochran.h cochran_commander.h cressi.h cressi_edy.h cressi_leonardo.h diverite.h diverite_nitekq.h divesystem.h divesystem_idive.h hw.h mares.h mares_darwin.h mares_iconhd.h mares_nemo.h mares_puck.h oceanic.h reefnet.h shearwater.h shearwater_petrel.h shearwater_predator.h suunto.h suunto_eonsteel.h suunto_solution.h suunto_vyper.h uwatec.h uwatec_aladin.h uwatec_memomouse.h uwatec_meridian.h uwatec_smart.h zeagle.h zeagle_n2ition3.h Jef

1 0

Linking liberary with CLR
by Vincent Hagen 01 Mar '17

01 Mar '17

Hi, For a small project of mine I tried to link your library to a C# project. This failed due to the fact that your library is unmanaged, so I tried creating a C++/CLR wrapper to do this, but I kept failing. Now isn't C++/CLR really in my comfort zone and even though I created a .lib file out of your .def file the compiler didn't seem to pick up the .dll itself and I have no clue how to do it. Does anyone have any experience in linking C++/CLR to this libdivecomputer? Or even better, with C#? Kind regards, Vincent

2 1

hash function for suunto solution
by Kristaps Dzonsons 20 Jan '17

20 Jan '17

Hi, The Suunto Solution seems to be the only dc that doesn't support fingerprints. This annoys me because I can't fully rely on dc_device_set_fingerprint(3) and I like that function. So I've added a hash function that creates a suunto solution fingerprint, then added the infrastructure to set, compare, and pass to the caller. Caveat emptor! I haven't tested it because I don't have a suunto solution. Downsides to using a hash function? It might be duplicated. However, given that this is a 128 bit hash, that's not terribly likely. If this is ok, I can update the docs to reflect that setting the fingerprint is fully supported. Best, Kristaps

2 1

dc_datetime function documentation
by Kristaps Dzonsons 12 Jan '17

12 Jan '17

Hi, Enclosed is a patch that documents all of the dc_datetime functions. The CAVEATS are important because calling gmtime et al from a library might not be expected. (They touch the zoneinfo files, which may not be available on embedded or sandboxed systems.) I also specifically note the differences to "struct tm" in terms of the year and month field. Best, Kristaps

2 6