The Lynx supports a maximum of 10 transmitters on any one dive: the primary and up to 9 student or group sensors. When in group mode (either 4- or 9-transmitter), buddy mode is disabled and vice versa. So, you can configure a Lynx to monitor yourself, yourself and a buddy, or yourself and up to 9 others in group mode.
The 0x0010 record is fixed length and contains slots for the primary, buddy, and 9 group sensors. Any sensors not used are sent as nulls. I believe that this record reports what is configured in the computer regardless of the actual monitor mode selected since buddy and group modes are mutually exclusive. While you can change transmitter monitoring modes during a dive (e.g., from solo to buddy to group, group to solo, etc.), I don't think you can add or remove transmitter IDs or their assigned slots except in surface mode. Nevertheless, I've coded for that so that once set, the sensor ID for a particular slot (e.g. buddy) can't be reassigned. Here are some sample transmitter ID records: RID Time Pri Bud G1 G2 G3 G4 G5 G6 G7 G8 G9 1000 00000000 420D E40A 0000 0000 0000 0000 0000 0000 0000 0000 0000 This is from my log and shows that my transmitter #3394 (0x0D42) is the primary and my son's #2788 (0x0AE4) is the buddy sensor. RID Time Pri Bud G1 G2 G3 G4 G5 G6 G7 G8 G9 1000 00000000 E40A 420D 0000 0000 0000 0000 0000 0000 0000 0000 0000 This is from my son's log and shows that his transmitter #2788 (0x0AE4) is the primary while mine #3394 (0x0D42) is the buddy. RID Time Pri Bud G1 G2 G3 G4 G5 G6 G7 G8 G9 1000 00000000 9100 0000 4E03 0000 0000 0000 0000 0000 0000 0000 0000 This is from the second sample log I sent and shows a dive monitored in group mode. Transmitter #145 (0x0091) is the primary and transmitter #846 (0x034E) is group #1. Where it gets interesting is that you can also configure to monitor a location beacon. This is another record from the second sample log: RID Time Pri Bud G1 G2 G3 G4 G5 G6 G7 G8 G9 1000 F6010000 4E03 4E03 9100 459D 0000 0000 0000 0000 0000 0000 0000 Here, transmitter #846 (0x034E) is configured as both the primary and buddy, transmitter #145 (0x0091) is configured as group #1, and location beacon #261 (0x9D45) is configured as group #2. In LV's dive log app, this is reported as: [ ] A0846 - You [ ] A0846 - Buddy [ ] A0145 - Student1 [ ] E0261 - Student2 I think the "A" identifies tank pressure transmitters and their serial number is directly recorded in the log. "E" identifies a location beacon and that info must be merged into the ID somehow since the reported ID of 261 is 0x0105 and the actual logged ID is 0x9D45. It could be a bit mask added to identify location beacons but that would mean a bit mask of 0x9C40. However, I suspect that they simply add 40,000 to the location beacon transmitter ID since 0x9D45 is 40,261. Regardless, location beacons don't transmit pressure events so we really don't have to worry about it. So, I don't think it's possible to parse random data since it's a fixed length record and unused slots are always zeroed out. Robert -----Original Message----- From: Miika Turkia [mailto:[email protected]] Sent: Monday, June 12, 2017 8:44 AM To: Dirk Hohndel Cc: [email protected]; John Van Ostrand; Subsurface Mailing List Subject: Re: [PATCH] Fix buffer overrun and primary sensor id issues in Liquivision import I clearly need some sleep, sending empty messages... On Mon, Jun 12, 2017 at 7:12 AM, Dirk Hohndel <[email protected]> wrote: > Hi Robert, > > And welcome to the Subsurface developer team. I'm always excited when > we get new input and new reports. My absolute favorite (of course), > are reports that come with patches - so I already am thrilled to have > you on the team :-) > >> On Jun 11, 2017, at 4:05 PM, Robert Bodily <[email protected]> wrote: >> >> Sorry, I'm new here and not entirely sure of the proper way to do >> this so I'm copying the contents of the patch file here and also >> attaching it to this email. > > The included patch was mangled, but the attached one looks good. > > Miika, John, would you take a look and comment? Normally I'd prefer > something like this in multiple patches (each fixing one issue), but > the patch looks reasonably small, so assuming you have no issue with > the patch's content, I'll be happy to take it as is - but given that I > know next to nothing about the Liquivision import, I'd prefer an ACK > or two. Everything looks good to me (if you can trust someone who just showed not to be able to use email properly:D). The only question I have is, how will this work in case there is other than 9 additional sensors in the configuration? Does the input data include empty values, or are e.g. the buddy/group sensor infos missing (in which case this might parse random data, or is this actually taken care of in the patch). miika _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
