Divecomputer-reading from Mobile devices (Was: Divemate Fusion)

Dirk Hohndel dirk at hohndel.org
Sat Apr 9 17:15:52 PDT 2016


> On Apr 9, 2016, at 5:05 PM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> 
> On Sat, Apr 9, 2016 at 5:00 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>> 
>> Just to keep people updated... right now the biggest challenge is that some dive computers (like the Atomics Cobalt 2 which I randomly picked for my tests) draw too much power over USB and the C.H.I.P isn't able to stay stable when connecting one of those...
> 
> Ugh. That's going to be a problem with just about any of those
> embedded ARM board solutions out there. Almost all of them end up
> saying "use a powered hub".
> 
> Very annoying.
> 
> It's obviously "fixable" by packaging the board by duct-taping
> together a powered hub and a USB battery pack, and feeding both the
> hub and the CHIP from that battery pack.
> 
> Because duct tape solves everything.

Yes. At least for the Cobalt I was able to work around it by having the C.H.I.P claim that it can provide unlimited Amps. I will admit that I don't understand WHY that helps but it was given as a workaround for other devices that draw too much power and it did do the trick. With that I was now able to download the complete content of my Cobalt into a local XML file :-)

As expected, the individual dives run roughly 4k per hour dive time. This is with the libdivecomputer default XML output (to make my life easier I just used dctool for the download). I think our XML for example is much denser... so I think the amount of data will be manageable.

Now I need to take my crude sample BLE app and turn it into something where the control device (so Subsurface or Subsurface-mobile) can send it instructions, figure out when the C.H.I.P has data available and then initiate a transfer...

But I think I'm more or less out of time for today, so this will have to wait until I get another chance to waste a few hours :-)

/D


More information about the subsurface mailing list