<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 12, 2016, at 5:16 AM, Jeroen Massar <<a href="mailto:jeroen@massar.ch" class="">jeroen@massar.ch</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2016-04-12 11:53, Robert Helling wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">I have been thinking a bit more about setting up a small device<br class="">(C.H.I.P. or similar) to do the dive computer read out and communication<br class="">with the mobile device.<br class=""><br class="">One thing I am worried about is how to collaboratively develop for such<br class="">a target. It is quite likely that we have to modify system files and<br class="">settings (like startup, maybe configure BT or networking, instilling<br class="">packages etc). How can we put that in version control? Do everything<br class="">with a script and version control that script? For configuration files,<br class="">one could have those in a directory under git and then have a small<br class="">script that writes them in the appropriate places (and sets permissions<br class="">etc). But maybe people have better ideas. Am I reinventing a packaging<br class="">system?<br class=""></blockquote><br class="">You would be re-inventing that.<br class=""><br class="">Hence the best way to go is to just use the packaging system of the<br class="">distro that gets chosen.<br class=""></div></div></blockquote><div><br class=""></div>So the CHIP uses a Debian based system. But as I said in my last two</div><div>emails, exposing that to end users is already declaring defeat.</div><div><br class=""></div><div>Yes, we can use the Debian tools behind the scenes (and no, I have</div><div>ZERO interest in going back to the fights with distros, and ESPECIALLY</div><div>with Debian, on how to package things and what is and is not in accordance</div><div>to their ideology). But the user experience needs to be very very different.</div><div><br class=""></div><div>This will require help from the CHIP guys to pull off (or from whatever</div><div>platform we end up using).</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">The other thing is deployment. Initially, that’s simple, we provide disk<br class="">images. But then, what is the upgrade path? Connect to wifi and do git<br class="">pull? apt-get upgrade/update? Get a new disk image? That needs to be<br class="">thought about as well for devices like this.<br class=""></blockquote><br class="">Very good questions and still at the right time.<br class=""><br class="">We should definitely have a list of requirements as one of the first<br class="">things, as otherwise how do we know what we really want and who is going<br class="">to be working on what (duplicate stuff or stuff that never gets used is<br class="">rather an annoying downer for many people).<br class=""></div></div></blockquote><div><br class=""></div><a href="http://trac.subsurface-divelog.org/wiki/SubsurfaceBox" class="">http://trac.subsurface-divelog.org/wiki/SubsurfaceBox</a></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Assuming that the small size, flexibility and capabilities of a<br class="">Adruino/USB/BT 'stick' is likely too little for us, lets go for a<br class="">'bigger' device which can run a proper-ish Linux.<br class=""></div></div></blockquote><div><br class=""></div>YES. Please. Given the price point and capabilities of the CHIP I see</div><div>no reason to go to something less capable than that.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">As an initial list of things see below, (do we have a wiki or git repo<br class="">where we could put this list in markdown or similar format, makes<br class="">discussing easier...)<br class=""><br class="">The device:<br class=""> * a name ("OnSurface" ? :)<br class=""></div></div></blockquote><div><br class=""></div>Subsurface Box</div><div><br class=""></div><div>But of course this is open to discussion :-)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * a case<br class=""> - mostly water-proof-ish<br class=""> - nice bright yellow plastic so it can't get lost<br class=""></div></div></blockquote><div><br class=""></div>please add to the wiki</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * selection of hardware [see note below though]<br class=""> - CHIP<br class=""> - Pi<br class=""> - other?<br class=""><br class=""> * battery that can at least make it functional for "a day"<br class=""> - we assume you get to land at one point where it is dry<br class=""> and that you can charge the thing, but it should not be<br class=""> after an hour of usage, the battery should at least survive<br class=""> a day of going out and diving<br class=""></div></div></blockquote><div><br class=""></div>I have a few words about that on the wiki, feel free to expand</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * Dive Computer connectivity<br class=""> - USB Host to Dive Computer<br class=""> - USB<->IRDA connector support<br class=""> - others?<br class=""> Likely USB is the minimum, and that then things can plug<br class=""> into it that actually connect to the DC.<br class=""></div></div></blockquote><div><br class=""></div>Linux gives us a wonderful starting point as all the devices will</div><div>just work and even the iRDA USB plugs usually are supported.</div><div>This will require some testing to ensure that the right modules</div><div>are loaded, but that's fairly straight forward</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * Connectivity between device and mobile:<br class=""> - Bluetooth LE<br class=""> - low throughput<br class=""> - would require custom things for transfering items<br class=""> + does not require switching WiFi on mobile device<br class=""> - WiFi for connectivity<br class=""> + high throughput<br class=""> + can use standard HTTP transfers etc<br class=""> - does require switching WiFi on mobile device<br class=""> (but see below: Home/Away switch)<br class=""></div></div></blockquote><div><br class=""></div>I have added this to the wiki (except for the home/away thing... to</div><div>me that is definitely a V2 functionality)<br class=""><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""> * "OS" Selection: I'll stick to this Linux-based thing ;)<br class=""> but we'll have to select a "Distro", and this will<br class=""> also select what 'upgrade' options we have:<br class=""> - Debian<br class=""> - I am partial to this where possible<br class=""> simply because of 'apt-get update && apt-get dist-upgrade"<br class=""> - would mean we simply roll Debian packages in a<br class=""> 'addon' repo originally and if we can get them<br class=""> into mainline Debian there, for setting everything up<br class=""> - Depending on storage: small form factor might just<br class=""> need custom strip-down distro<br class=""> Could build this from components/kits offered by others<br class=""> eg using OpenWRT as a base etc.<br class=""> -> it does affect upgrade methods...<br class=""> - something else?<br class=""></div></div></blockquote><div><br class=""></div>I would be amiss if I didn't point out the Yocto Project as a way</div><div>to create an image, but realistically, I'd much rather build on top</div><div>of what the device vendor ships, in this case a simple Debian</div><div>distribution.<br class=""><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Then the actual work for binding stuff together:<br class=""><br class=""> * Installation of (minimal?) Subsurface on the device<br class=""> - if Debian or other such system: packages!<br class=""></div></div></blockquote><div><br class=""></div><div>As I said before, forget Uemis (I certainly have) and just go with</div><div>the command line version of libdivecomputer. I have that working</div><div>already. And as Jef points out, if we transfer the binary data</div><div>instead of XML we also get super-dense data files that would</div><div>make things more feasible for BLE</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * Upgrade system<br class=""> - if Debian or other such system: packages!<br class=""><br class=""> * First-time Setup Interface<br class=""> - SDcard slot option:<br class=""> could have an program that writes a simple configuration<br class=""> file to that medium config can be on a partition formatted<br class=""> with FAT32 or something else that any computer can read<br class=""> This 'program' could just be a menu option in SubSurface<br class=""> as we have all GUI parts sorted out there already.<br class=""> - won't work without a computer<br class=""> - WiFi option:<br class=""> it should just become an AP when initially enabled<br class=""> the user then connects, gets an IP, connects to http://<ip><br class=""> and gets a nice web interface for configuration<br class=""> - in combo with broadcast mentioned below, mobile tool<br class=""> could actually just be the configuration tool<br class=""> with some kind of REST interface on the device.<br class=""> - USB:<br class=""> - Would require a non-host USB port next to host USB<br class=""> - Requires a computer<br class=""> -> not a really good option<br class=""></div></div></blockquote><div><br class=""></div><div>So as I said, I'm talking to the CHIP guys about this. This is</div><div>something that needs support from whoever builds the device.</div><div>We could of course have some company assemble the boxes</div><div>and flash them with a custom image, but I'd much rather work</div><div>with NextThing on creating an easy way for all of the projects</div><div>running on CHIP to bootstrap.</div><div><br class=""></div><div>What I suggested to them is that CHIP should ship with an open</div><div>WiFi access point running and a web server to connect to and</div><div>then a simple web interface where you enter a URL from which</div><div>a package is then installed. Super easy for end users.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * Configuration Interface<br class=""> After setup we should be able to reconfigure<br class=""> Likely this will be a component of the Mobile edition when wifi<br class=""> or heck the full version; but with BE or SDCard this would be<br class=""> quite a different tool to do.<br class=""></div></div></blockquote><div><br class=""></div><div>My vision so far (and I need to add this to the wiki) is that we have</div><div>a simple command/respond system that works over BLE. There</div><div>isn't THAT much configuration that we need. Pick the dive computer,</div><div>transfer the last fingerprint we have. Download from dive computer.</div><div>Wait for that to finish. Transfer to Subsurface/Subsurface-mobile</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * "Home"/"Away" switch:<br class=""> - When switched to "Home" it will try to connect to the local<br class=""> home WiFi Network, that way it becomes available to the home<br class=""> network and one can use it that way, thus avoiding need<br class=""> to have to have your mobile device switch between the home-wifi<br class=""> and the device wifi.<br class=""> - When switched to "Away" it will be a AP, your mobile device<br class=""> can then connect to it and use it directly.<br class=""></div></div></blockquote><div><br class=""></div><div>V2</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> * Device discovery (for WiFi)<br class=""> - Simple edition: allow the user to enter the IP/hostname of<br class=""> the device in the mobile tool<br class=""> - Broadcast packet on local WiFi:<br class=""> Likely UPNP packets are a good tool for that, but we can use<br class=""> whatever is good. This way tool can autodetect it.<br class=""> (this option should of course have the option of being disabled<br class=""> in the configuration, I hate broadcasting stuff myself...)<br class=""> * Security policy: minimal exposure of anything<br class=""></div></div></blockquote><div><br class=""></div>Interesting question. Since I am still hoping to convince everyone</div><div>of a BLE solution instead of a much more elaborate setup that</div><div>some here seem to envision, discovery becomes easy. BLE </div><div>advertisement. Connection. Go. If people are really worried that</div><div>someone else can download data from their dive computer we</div><div>could of course add a PIN but frankly... WHY?</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="">Yes, that is a long list of things, but if we have the list we want,<br class="">then people can say "I'll tackle that part" and together we can get<br class="">there quite fast.<br class=""></div></div></blockquote><div><br class=""></div>That's why I started the wiki.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Note that the hardware could just be a variety of things, having it<br class="">based on Debian could just mean that somebody runs this on a cheap<br class="">laptop (great for devel, but indeed then you do not really need a mobile<br class="">version anymore), while others use a mini-device. Or the in-house<br class="">edition that you have on your desk could just be a VM on a bigger device<br class="">etc, while you keep the tiny one in your dive bag.<br class=""></div></div></blockquote><div><br class=""></div><div>Yes, we could also support Xeon servers for those who usually take</div><div>one on a trip :-)</div><div><br class=""></div><div>Seriously, we need to very very very clearly separate two user groups:</div><div><br class=""></div><div>A) people who are comfortable installing debian on some random device</div><div>and making all this work</div><div>B) actual divers and users of Subsurface-mobile on their iPhone with no</div><div>discernible knowledge of computers</div><div><br class=""></div><div>On every dive trip I'm on I somehow end up meeting about zero or one</div><div>people in group A and everyone else is in group B. For group B we should</div><div>pick ONE device, ONE solution, ONE way of doing this. Keep it as simple</div><div>as humanly possible.</div><div><br class=""></div><div>Yes, you can set up a git server on the box with automatic hook based</div><div>triggering of cryptographic signatures on your dive data that are then </div><div>uploaded to the Subsurface cloud. And nine pages of configuration </div><div>including ipv6 support and whatever else you can think of. Go ahead,</div><div>knock yourself out.</div><div><br class=""></div><div>But that is for YOU and for three others in group A that can actually agree</div><div>on the same features and the same hardware to use and the same distribution </div><div>to use etc. But for everyone else we need something that is really, really simple</div><div>and really really reliable and well tested. Otherwise why bother.</div><div><br class=""></div><div><br class=""></div><div>/D</div><div><br class=""></div></div></body></html>