That aren’t very good news. Just an additional question. You talk about the iconHD protocol. I use a quad air. Did they use the same protocol?
Just tell me, if I can provide more details or log files, to help you to debug the problem. Markus > Am 12.01.2021 um 22:54 schrieb Jef Driesen <[email protected]>: > > On 11/01/2021 20:49, Linus Torvalds via subsurface wrote: >> On Mon, Jan 11, 2021 at 11:37 AM Markus Hinkelmann via subsurface >> <[email protected] >> <mailto:[email protected]>> wrote: >>> >>> I tried to import my dives from my Mares Quad Air using the Interface >>> „Mares BLUELINK Pro“ to subsurface. >> I'm afraid that the Mares BlueLink Pro has been the most problematic >> piece of BLE hardware we have ever seen. >> It has been known to work - often very very slowly - but it has always >> been extremely flaky. I've never figured out why. > > The Bluelinkpro is indeed trouble. > > There is the outstanding issue of sending the commands "all at once" versus > "in two pieces". In some cases the former seems to work better, while in > other cases it's the other way around. So far I haven't been able to find any > pattern. It could depend on the dive computer model, the operating system, > the bluetooth stack, etc. > >>> The computer was able to connect to the interface using the mode >>> „BT-classic“ but the import fails. >> I didn't even know that it supported BT-classic at all. I've only ever >> seen it do BLE. >> I was going to say that BT-classic cannot possibly work, but: > > Both log files have transport=32, so that means BLE was used. Maybe > subsurface automatically falls back to BLE if rfcomm isn't available? > >>> A dump file was not created, but I was able to create a libdivecomputer log >>> file (see attachment). >> Strangely, it actually partially does seem to have worked. There are a >> few valid reply packets with the valid '0xAA' packet reply byte, and >> the communication actually starts. Color me I'm surprised. >> So that log shows us sending several commands to it, and starting to >> do a data transfer. Yeah, we get a few NAK packets (0xEA) back >> instead of 0xAA, and a couple of "no reply at all" cases, but even >> then the re-try ends up working a few times. >> But then at some point, even when retrying, it just returns an >> all-ones (0xff) answer, and after five failres for that command we >> just give up. >> Honestly, this _might_ be one of those cases where "if you try again, >> eventually it might work". > > I suspect the single byte 0xEA response, indicates the device received the > command packet, but can't answer for some reason. Maybe the received command > was corrupted, and couldn't be interpreted as a valid command, or the dive > computer wasn't ready yet to process the next command? But it's still > responding somewhat normal, and retrying usually works just fine. > > Then we have a few cases where we have no response at all. Difficult to tell > what is going on behind the scenes. Retrying often seems to work at first, > but I have the impression it all starts to go downhill from here. After a > while we start to receive garbage data, and we aren't able to recover > anymore. We're probably out of sync with the dive computer somehow. And that > garbage data is probably some data send by the dive computer in response to > one of the earlier commands that happens to arrive too late? > > One thing that could contribute to the problem is that the iconhd protocol > doesn't use any form of checksums. So it's nearly impossible to detect > corrupt packets. Only the commands have a small protection in the sense that > the type byte is repeated (with the second byte xor'ed with 0xA5). That could > explain why it's difficult to recover once things start to go wrong. Of > course that doesn't explain why things start to go wrong in the first place. > >> But equally honestly, I've pretty much given up on the Mares BlueLink >> adapter. I don't know why it's so flaky. The Mares mobile app seems to >> be able to talk to it, but when I did a packet trace, I didn't see it >> do anything special, so I don't know what is going on. It might be >> some very subtle timing issue that the Mares app is aware of. > > If I remember correctly, we haven't seen any errors at all in the traces from > the Mares application. I also have no idea why it seems to just work there, > but not for us. It looks like they just don't seem to hit this problem. > Strange. > > The Mares applications sends the command in two parts: > > W: CMD CMD ^ 0xA5 > R: ACK(0xAA) > W: CMD_DATA > R: RSP_DATA > R: EOF(0xEA) > > I've always assumed this is done because the dive computer first acks the > command byte to indicate it's ready to receive the command payload. At this > point it knows how many bytes to expect, and is ready with whatever it needed > to do. > > The only thing that could screw up is some extra latency (due to a slow BLE > link) that exceeds some internal timeout. In that case the dive computer will > see the CMD bytes without the payload. Of course we did still send those > bytes, and the dive computer will get those later. And then it will probably > start to interpret those as the next command. > > If we send the whole command at once, without first waiting for the ack, we > avoid the extra roundtrip latency. But depending how this is implemented in > the firmware and the amount of buffering, the command payload could be > arriving too fast, before the firmware is ready to receive those byte, and > they could get dropped. > > There are certainly some differences in the hardware. For example the iconhd > uses CDC-ACM, so this is probably a feature of the microcontroller, while > some of the other models use an external (silabs) usb-serial chip. Timings > can also be different on the different operating systems and bluetooth stacks. > > Jef
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
