Developing and Deploying devices

[Dirk Hohndel]

On Tue, Apr 12, 2016 at 06:55:54PM +0200, Jeroen Massar wrote:
> >>
> >> A Poll would be the proper way to select this.
> > 
> > You must be new here :-)
> 
> Absolutely ;)

There will be no poll for the name :-)

> Lets first select if we want to do BT or WiFi. I am partially leaning to
> BT, but due to speed, more to WiFi, but due to switching between normal
> wifi and box wifi, to BT...

My strong preference is to do this with BLE. I've done some experiments
yesterday with a handful of dive computers that I have access to (my wife
keeps asking me why I need 15 dive computers... THAT's why...)

With the exception of the Suunto EON Steel, all the dive computers have
tiny amounts of data per dive when using the binary data only. Definitely
small enough to transport via BLE. Especially when you think about the
typical use case. That use case is NOT "download all dives from this dive
computer". It's "download today's dives". So that's typically two dives,
maybe as many as five. So even with a high sample rate we are talking a
few kB of data - something easily tranferred in a few seconds. Actually,
for most dive computers, the communication with the dive computer (which
transfers for all practical purposes the same amount of data) is slower
than BLE (yes, there are exceptions like the Cobalt).

> I guess in both cases, a binary blob might just work, sort of a 'proxy'
> fetch on the API layer of where DC would be.
> 
> As effectively, if we treat it this way, we are going to be 'proxying'
> libdc API calls over either BT or WiFi. Depending on interaction though
> we might need to shim it a bit more.

That's not how I'd do it. I'd tell the Box: "there's a VENDOR / MODEL dive
computer attached to USB, please download the dives since fingerprint XYZ".
It then downloads the binary data and tells the connected computer / phone
/ tablet "GOTIT". Then we negotite the transfer of the binary data.

> >> I was thinking of just going down the DIY route... but if somebody can
> >> do the above, that would be pretty amazing.
> > 
> > The advantage of this being supported by CHIP is that it would be
> > supported out of the box with no user intervention.
> 
> Having that is I think a key component to this project becoming a success.

Agreed.

> > I want to prevent ANY
> > need for us to tell the user "... and now start the terminal emulator
> > inside your terminal emulator window and log in as root..." :-)
> 
> Yeah, not a good model. Low Wife Approval Factor thus born to fail in
> the time of Apple.

I took the liberty to rename this to "Spouse approval factor" - I have a
good friend with a PhD from MIT who constantly has to help her husband to
deal with "technology stuff" (his words)... technology savviness is not
something that we should stereotype to be gender specific.

> >> Except for possible updates, the device does not need IP.
> >> In the config we can just have a "Enable IPv4" and "Enable IPv6" option.
> > 
> > Or we can have no config at all beyond the initial out of box experience
> > install mentioned above... that would be my preference :-)
> 
> If we go to BT route, we might be able to get away with it.

That's part of my hope :-)

> Upgrades is something we need to check at one point though.

True. Let me dream again. Could this be so completely "zero configration"
that the user could simply press the magic button and install the latest
version and have it just work? Literally, go back to the magic CHIP
installer screen, select Subsurface Box, install the lastest version and
it all works. That seems like the ideal solution to me.

> Also, being able to enable/disable the wifi AP to save power another,
> thus a three way switch: "Home, Away, Off" might be needed.

Or wifi is on in "initial install mode" (see magic button) and otherwise
off...

> >> And even config can be done using BLE if wanted.
> > 
> > I'll bite. What config?
> 
> Might indeed be the right path to go for if we just do BT...

:-)

/D