Developing and Deploying devices

[Jeroen Massar]

On 2016-04-12 18:42, Dirk Hohndel wrote:
> On Tue, Apr 12, 2016 at 05:39:54PM +0200, Jeroen Massar wrote:
>>>> The device:
>>>> * a name ("OnSurface" ? :)
>>>
>>> Subsurface Box
>>>
>>> But of course this is open to discussion :-)
>>
>> I am not one to do a long bikeshed.
>>
>> A Poll would be the proper way to select this.
> 
> You must be new here :-)

Absolutely ;)

[..]
>>> I have added this to the wiki (except for the home/away thing... to
>>> me that is definitely a V2 functionality)
>>
>> Adding a 'future' section.
> 
> Thanks. I don't want to prevent super cool and exciting ideas for the
> future - I just want to get something out that "works" and do that
> "reasonably soon" :-)
> And engineers easily get excited about things that make the project a lot
> more complex and end up delaying things for limited improvement in
> usefulness.

Yep, for $work we Kanboard everything, add milestones and throw 'cool
but not critical' in the 'future' one, even though I might really want
to do them, that is then what is going to happen.

New and shiny is a tricky thing, that way it is manageable.

[..]
> Yes, I realize that I may have made my point poorly. I want us to focus on
> ONE platform for the "end user"
[..]

I think CHIP will be a good primary development platform, especially due
to the support from them I see.

[..]
> So having the Box just download the raw data, transfer that to Subsurface
> and parse it there seems like the way to go.
> 
> Now how we encapsulate those raw data... let the bike shedding begin.

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...

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.

[..]
>> 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.

> 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.

>> Actually, it would open up their platform for auto-installers of any
>> kind of tools, just plug in in your CHIP, connect the wireless, and
>> chose the function from a ChipStore.
> 
> That was my thought which is why I've started that conversation. This is a
> problem that is in no way specific to Subsurface. Everyone building
> something on top of the CHIP will run in to this at some point.

Definitely.


>> (google is not very friendly for searching for "chip" btw...)
> 
> No kidding. I have found that adding nextthing chip usually helps.

THAT is the trick, thanks!

[..]
>>> Yes, we could also support Xeon servers for those who usually take
>>> one on a trip :-)
>>
>> mmmm those are sometimes heavier than tanks, thus they do not come along
>> on the heli ;)
> 
> The new Xeons are really light :-)
> (in case that isn't common knowledge... I do work for Intel in my day job)

Just the chip, yes, but if you wrap it in a 1U box with disks etc.... ;)

>> I meant the above more for development work, one does not want to cross
>> compile all the time in a lot of cases.
> 
> See above - I think my first response was sub-optimal. I agree that for
> developers this is completely valid

Full agree.

[..]
>> While on vacation I don't want to meddle to much with computer stuff
>> anyway, as well, one is on vacation ;)
> 
> I tend to spend all of my vacation time on
> a) collecting data and then
> b) working on Subsurface to make use of those data :-)

When the statistics bug has bitten, it won't let go ;)

>>> Yes, you can set up a git server on the box with automatic hook based
>>> triggering of cryptographic signatures on your dive data that are then 
>>> uploaded to the Subsurface cloud. And nine pages of configuration 
>>> including ipv6 support and whatever else you can think of. Go ahead,
>>> knock yourself out.
>>
>> 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.

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

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

>> 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...

Greets,
 Jeroen