Re: OSTC over BLE experiences and questions

[Richard Houser]

I have a later Aeris A300CS (purchased just after the VTX launch) with about 30 
dives on it and really like it *now*.  Some things did change, and it's 
important to have an updated firmware.  I use the VTX compression mount on my 
lower arm, for what it's worth.

Never had the mirror issues underwater, but it came with a plastic screen 
protector which I promptly applied before the first dive. Perhaps that was 
taking out much of the glare?  Can you confirm if yours is bare glass?  I did 
experience the wash out effect and needing to keep brightness above 50% 
mid-day.  The OLED was amazing for a series of night/twilight dives, btw. Small 
text is not a big issue for me personally.  I can easily read that in clear 
water, but don't recall really needing to leave the main screen or compass 
during a dive (more curious about temperature).

*now* - Four major snags along the way:

I ran into a defect where the computer silently added a bunch of nitrogen 
during a surface interval at the end of a 6 dive series while I was prepping to 
go back in and went into a deco condition 30 sec underwater. I submitted the 
dive logs, etc., and Oceanic published a specific firmware update to patch it.

The main UI was also updated more similar to the VTX in the later firmwares. 
When they did that, they switched the low battery indicator to a green battery 
indicator. I managed to miss that detail, thought it was good, and had it 
completely die on me at Bonne Terre. Stupid UI decision on that indicator 
color, but can be worked around easy enough. They were discontinuing further 
features on the A300CS in favor of the VTX, so the interfaces will likely start 
to diverge again.  The new interface is much better, though overall.

The PO2 warning is crazy annoying, and you can't really turn it off if you have 
audible alerts on.  It's hard coded at .2 below your PO2 limit, so for 1.4 
constantly trips at 1.2.  When diving EAN36, that's basically right into the 
middle of the ideal depth range I tend to want to be at for the reef, and it 
sounds off each and every time you cross that threshold descending a foot of 
so.  You have to set it to 1.6 to avoid having the warning going off 
constantly, and that messes things up a bit in planning mode.  If I recall, you 
could not set it higher, so tech divers would likely need to do without audible 
alarms.  I find those audible alerts particularly handy for things like ascent 
rate, just really wish the PO2 alert matched the set limit.

Initially no transmitted pressure readings.  Support had me remove the battery 
and short two contacts inside the device.  After that, the transmitter has 
worked fine.

On July 11, 2017 1:18:55 PM EDT, Linus Torvalds  
wrote:
>On Tue, Jul 11, 2017 at 6:57 AM, Matt Thompson 
>wrote:
>>
>> The Aeros 300CS, the Oceanic VTX, and the Aqua lung i750TC are all
>basically
>> the same computer, all manufactured by Pelagic Pressure Systems, all
>> suitable for grooming ;). They also all do BLE, hopefully the same
>flavor.
>>
>> I have screenshots of my i750 from nRF Connect that I can send to the
>list
>> tonight when I get to my hotel.
>
>I actually have an Aeris A300CS, and hated it with a passion. The
>screen turns into a mirror underwater, and it doesn't have all the
>data I want on it, and the "secondary screen" (which you get to with a
>button press) ends up having such a small font that together with the
>mirror-effect, it was completely unreadable.
>
>Plus the battery only lasted for a couple of days of diving in my
>experience (admittedly, that may have been a "five hours underwater
>each day" trip). And that was with the default screen brightness
>(60%?). If I had been forced to actually rely on it, I would have had
>to up the brightness to 100% and probably thus lose even more battery.
>
>So I was singularly unimpressed. I had it with me for one dive trip
>and never touched it again.
>
>Maybe I had a dud. Maybe they fixed the shaving mirror effect in the
>VTX. Or maybe there's just something wrong with me, but I really
>didn't like the A300CS even though I really wanted to.
>
>Annoyingly, it seems like I have lost the tank sensor for it. And I'm
>annoyed mainly because I think that tank sensor would work with my
>Perdix AI.
>
>ANYWAY.
>
>After that rant, I can report that I did take a quick look at the
>A300CS BLE, and it should be something we can support.
>
>The thing uses a Blue Radios "nBLUE" bluetooth chip that implements
>serial over BLE GATT (yet another "the standard didn't make a standard
>serial protocol, so we made our own". Damn to hell all the f*cking
>incompetent morons on the bluetooth committee).
>
>Oops, I'm ranting again.
>
>ANYWAY #2.
>
>The good news is like the OSTC3 chip, that nBLUE chip is actually
>documented, because it's used in various random IoT projects. For
>example
>

Re: OSTC over BLE experiences and questions

[Linus Torvalds]

On Tue, Jul 11, 2017 at 7:30 PM, Dirk Hohndel  wrote:
> The problem is that we try to identify the dive computer by name. EZ and a
> number really isn't all that unique... Way too easy to get false positives
> :-(

I think we'll have to move over to using uuid's anyway, it's just the BLE way.

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Dirk Hohndel]

The problem is that we try to identify the dive computer by name. EZ and a 
number really isn't all that unique... Way too easy to get false positives :-(

⁣--
>From my phone​


 Original Message 
From: Matt Thompson 
Sent: Tue Jul 11 19:23:35 PDT 2017
To: Dirk Hohndel 
Cc: Subsurface Mailing List , Linus Torvalds 

Subject: Re: OSTC over BLE experiences and questions

On Jul 11, 2017 8:43 PM, "Dirk Hohndel"  wrote:


seriously, the Aqua Lung i750TC identifies itself as EZ003889 via BLE?
Please tell me that's wrong.


/D


The numeric portion of that is the serial number, but yes, that is how it
identifies.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Matt Thompson]

On Jul 11, 2017 8:43 PM, "Dirk Hohndel"  wrote:


seriously, the Aqua Lung i750TC identifies itself as EZ003889 via BLE?
Please tell me that's wrong.


/D


The numeric portion of that is the serial number, but yes, that is how it
identifies.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Dirk Hohndel]

On Tue, Jul 11, 2017 at 07:32:47PM -0500, Matt Thompson wrote:
> > So I was singularly unimpressed. I had it with me for one dive trip
> > and never touched it again.

I had Linus' 300CS as well for a few dives and came to the same
conclusion.

> Well I'm doing my first real dives with it tomorrow so I'll see how it
> goes.  I've done a few lake dives with it and the information on the main
> screen is good.  The compass is useless and the reflection is annoying.
> I'm DM'ing at an Aqualung shop so it's part of the "uniform."

That is a reasonable explanation, of course.
Still interested in your opinion, though.

> > Annoyingly, it seems like I have lost the tank sensor for it. And I'm
> > annoyed mainly because I think that tank sensor would work with my
> > Perdix AI.
>
> If you can find it I can confirm that it is exactly the same sensor and it
> does work with the Perdix AI.

Rub it in...

> > Can you verify that the nRF information from your i750TC matches the
> > UUID's on that web page? Because that's what my A300CS had - if they
> > are different, we're not going to have exactly the same BLE code..
>
> I looked and I could not find a matching UUID in the bunch.  I never could
> get my i750 to bond with the nRF tools so it might not be good information
> but...
> 
> I just went down and expanded each level of the services that nRF reported
> and snapped screenshots. I've shared them at
> https://goo.gl/photos/nvohKVPoTd9kfQm89

seriously, the Aqua Lung i750TC identifies itself as EZ003889 via BLE?
Please tell me that's wrong.


/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Linus Torvalds]

On Tue, Jul 11, 2017 at 5:32 PM, Matt Thompson  wrote:
>>
>> So I was singularly unimpressed. I had it with me for one dive trip
>> and never touched it again.
>
> Well I'm doing my first real dives with it tomorrow so I'll see how it goes.
> I've done a few lake dives with it and the information on the main screen is
> good.  The compass is useless and the reflection is annoying.  I'm DM'ing at
> an Aqualung shop so it's part of the "uniform."

So I just googled the i750TC images, and it actually looks a bit
different from the A300CS.

For example, one of my complaints about the A300CS was that it didn't
even show dive time on the primary screen, and you had to go to the
secondary screen (with the small font) to see that. That was just
crazy bad.

I absolutely require a few main things that an air-integrated dive
computer should show without extra key presses:

 - depth and dive time (duh!)
 - deco state (NDL when not doing deco, ceiling and tts when deci)
 - cylinder pressure and "gas time remaining" estimate

and the A300CS literally missed that dive time thing. I don't know how
you can design a dive computer that doesn't show dive time.

(There are other things I like to see, but they should be in smaller
text or might be behind a button: time-of-day, gas mix, compass
bearing, things like that)

The i750TC has fixed that, according to the screenshots I saw. It has
all those (and apparently time-to-surface even when in no-deco mode,
which sounds fine and might make the switch to deco mode less
jarring).

So my main "WTF?" complaint is gone right there.

If it also doesn't have quite as reflective a screen, it might
actually be a nice dive computer.

(The reflective screen is obviously only a problem in bright sunlight,
but it was really _so_ reflective that it was actually hard to see
even at 30ft under some conditions. At the safety stop it was just
really bad - imagine having to dive upside down just to see the
screen).

The i750TC also looks a bit better - it doesn't have the gaudy chrome
accents that the A300CS did.

So it's clearly a _related_ dive computer with a lot in common, but
it's not the exact same thing.

And yeah, the compass on the A300CS was an annoying mess, and didn't
work as a compass at all. The interface was *so* jerky and so ugly and
incomprehensible that it just not usable. It sounds like the i750TC
didn't fix on that part.

>> Annoyingly, it seems like I have lost the tank sensor for it. And I'm
>> annoyed mainly because I think that tank sensor would work with my
>> Perdix AI.
>
> If you can find it I can confirm that it is exactly the same sensor and it
> does work with the Perdix AI.

Now I'm just doubly annoyed that I can't find it ;)

>> The good news is like the OSTC3 chip, that nBLUE chip is actually
>> documented, because it's used in various random IoT projects. For
>> example
>>
>> http://www.byteworks.us/Byte_Works/Blog/Entries/2012/12/28_Build_Your_Own_Bluetooth_low_energy_based_circuits_using_the_Blue_Radios_BR-XB-LE4.0-S2.html
>>
>> Can you verify that the nRF information from your i750TC matches the
>> UUID's on that web page? Because that's what my A300CS had - if they
>> are different, we're not going to have exactly the same BLE code..
>
> I looked and I could not find a matching UUID in the bunch.  I never could
> get my i750 to bond with the nRF tools so it might not be good information
> but...

No, according to your screenshots it doesn't have that same BLE chip
that I have in my A300CS.

So it's not just a slightly different shell and firmware, there's
likely some real hardware differences. It's probably almost identical,
though.

Sadly, a bit of googling did not find that uuid that it reports, so
the exact details of the i750TC will need to be determined the hard
way with testing and luck.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Matt Thompson]

>
>
> Plus the battery only lasted for a couple of days of diving in my
> experience (admittedly, that may have been a "five hours underwater
> each day" trip). And that was with the default screen brightness
> (60%?). If I had been forced to actually rely on it, I would have had
> to up the brightness to 100% and probably thus lose even more battery.
>
> So I was singularly unimpressed. I had it with me for one dive trip
> and never touched it again.
>
> Well I'm doing my first real dives with it tomorrow so I'll see how it
goes.  I've done a few lake dives with it and the information on the main
screen is good.  The compass is useless and the reflection is annoying.
I'm DM'ing at an Aqualung shop so it's part of the "uniform."


> Annoyingly, it seems like I have lost the tank sensor for it. And I'm
> annoyed mainly because I think that tank sensor would work with my
> Perdix AI.
>
> If you can find it I can confirm that it is exactly the same sensor and it
does work with the Perdix AI.


> The good news is like the OSTC3 chip, that nBLUE chip is actually
> documented, because it's used in various random IoT projects. For
> example
>
>   http://www.byteworks.us/Byte_Works/Blog/Entries/2012/12/28_
> Build_Your_Own_Bluetooth_low_energy_based_circuits_using_
> the_Blue_Radios_BR-XB-LE4.0-S2.html
>
>
> Can you verify that the nRF information from your i750TC matches the
> UUID's on that web page? Because that's what my A300CS had - if they
> are different, we're not going to have exactly the same BLE code..
>
> I looked and I could not find a matching UUID in the bunch.  I never could
get my i750 to bond with the nRF tools so it might not be good information
but...

I just went down and expanded each level of the services that nRF reported
and snapped screenshots. I've shared them at
https://goo.gl/photos/nvohKVPoTd9kfQm89




> I currently lack the time, but in another week or two I *might* be
> able to look at it more if somebody else hasn't beaten me to it.
> Because I clearly lack the good sense to stay away from BLE.
>
>   Linus
>
Well, if someone gets around to it I'll be gathering test data for the next
week!

Thanks,
-Matt
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 12 July 2017 at 01:02, Linus Torvalds  wrote:
> On Tue, Jul 11, 2017 at 2:37 PM, Lubomir I. Ivanov  
> wrote:
>>
>> in terms of complexity, the context menu would be harder for me to do
>> over google maps (HTML / JavaScript), while the Qt Location (QML) one
>> should be trivial.
>
> It sounds like the Qt Location one might be better, then - supports
> offline caching, has reasonable (although perhaps not best-in-class)
> satellite imagery, and allows us to escape to an external browser
> easily..
>
> Are there any issues on mobile where one or the other would be much preferred?
>

we haven't touched the mobile subject, but to my understanding the Qt
Location solution should just work on mobile (untested by me for the
time being).
while the google maps solution requires a browser engine. we are
planning to move away from the deprecated QWebKit to QWebEngine, but
Thiago mentioned that QWebEngine has licensing issues on iOS and
QWebKit has to be used there, which means that we might have to use
QWebKit if we want a map in the mobile version.

so given these complications, Qt Location might be the right choice in
terms of eventual mobile support.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Linus Torvalds]

On Tue, Jul 11, 2017 at 2:37 PM, Lubomir I. Ivanov  wrote:
>
> in terms of complexity, the context menu would be harder for me to do
> over google maps (HTML / JavaScript), while the Qt Location (QML) one
> should be trivial.

It sounds like the Qt Location one might be better, then - supports
offline caching, has reasonable (although perhaps not best-in-class)
satellite imagery, and allows us to escape to an external browser
easily..

Are there any issues on mobile where one or the other would be much preferred?

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 12 July 2017 at 00:28, Linus Torvalds  wrote:
> On Tue, Jul 11, 2017 at 2:21 PM, Lubomir I. Ivanov  
> wrote:
>>>
>>> Qt Location does not support street view, so i guess that if we decide
>>> to go with the Qt Location solution we need to enable opening street
>>> view inside a new browser window, which runs google maps and requires
>>> internet access - e.g. when clicked a marker on the Qt Location map we
>>> can show a button "street view for this location".
>>
>> actually the above is not that easy to do, because google's street
>> view will first of all need to have ground imagery for a location.
>
> Don't worry too much about streetview per se.
>
> What I really think we should support is just a way to "escape" from
> the regular map window, regardless of what embedded map we are using.
>
> Right now it's a bit painful to extract GPS coordinates from our data
> - I actually just end up always doing a "git grep" over the git
> repository instead if I need it.
>
> So what would be lovely is just *any* fairly standard way to get the
> data from the currently selected dive points. Not so much for
> something very specific like streetview, but just in general.
>
> Then, if you can feed it into an external source, that external source
> might be just a regular google maps browser window, and then you can
> pick the streetview thing on your own if that is what you want.
>
> But sometimes you might want to instead of a "search around here for
> good restaurants" or whatever.
>
> So the point is not streetview per se, as much as the generic issue of
> "I have one or more dive sites, I want to just interact with something
> else than purely an embedded map in the app".
>

i see,

for both solutions we can add a context menu inside the mapview with
extra functionality, such as:
- copy location to clipboard (sexagesimal / decimal)
- open location in external source
- stats for visible markers
- etc

in terms of complexity, the context menu would be harder for me to do
over google maps (HTML / JavaScript), while the Qt Location (QML) one
should be trivial.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Linus Torvalds]

On Tue, Jul 11, 2017 at 2:21 PM, Lubomir I. Ivanov  wrote:
>>
>> Qt Location does not support street view, so i guess that if we decide
>> to go with the Qt Location solution we need to enable opening street
>> view inside a new browser window, which runs google maps and requires
>> internet access - e.g. when clicked a marker on the Qt Location map we
>> can show a button "street view for this location".
>
> actually the above is not that easy to do, because google's street
> view will first of all need to have ground imagery for a location.

Don't worry too much about streetview per se.

What I really think we should support is just a way to "escape" from
the regular map window, regardless of what embedded map we are using.

Right now it's a bit painful to extract GPS coordinates from our data
- I actually just end up always doing a "git grep" over the git
repository instead if I need it.

So what would be lovely is just *any* fairly standard way to get the
data from the currently selected dive points. Not so much for
something very specific like streetview, but just in general.

Then, if you can feed it into an external source, that external source
might be just a regular google maps browser window, and then you can
pick the streetview thing on your own if that is what you want.

But sometimes you might want to instead of a "search around here for
good restaurants" or whatever.

So the point is not streetview per se, as much as the generic issue of
"I have one or more dive sites, I want to just interact with something
else than purely an embedded map in the app".

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 11 July 2017 at 21:12, Lubomir I. Ivanov  wrote:
> On 11 July 2017 at 20:58, Linus Torvalds  
> wrote:
>> On Tue, Jul 11, 2017 at 10:48 AM, Lubomir I. Ivanov  
>> wrote:
>
>>> so Marble seems to have the best of both worlds for now - google tiles
>>> and offline support.
>>
>> Yeah, but Marble has been a big painpoint too. So practicalities of
>> actually implementing this and maintaining it should be pretty high.
>>
>> One thing that would be good - and that Marble doesn't do all that
>> well - is to have better integration with the outside world. For
>> example, I've occasionally wanted a "escape to real google maps" just
>> for things like location sharing (and you mentioned streetview earlier
>> - not an issue when you're on a reef in palau, but it *is* a potential
>> issue when you're looking at the parking lot of a shore-dive).
>>
>> So Marble has its good sides, but it has certainly its own share of
>> painpoints too.
>>
>
> Qt Location does not support street view, so i guess that if we decide
> to go with the Qt Location solution we need to enable opening street
> view inside a new browser window, which runs google maps and requires
> internet access - e.g. when clicked a marker on the Qt Location map we
> can show a button "street view for this location".
>

actually the above is not that easy to do, because google's street
view will first of all need to have ground imagery for a location.
if it doesn't, it won't auto-search for the nearest spot with ground
imagery (this can also confuse the user) and instead it will just show
a black screen - e.g. here is what happens for the Palau island for a
correctly formed URL:
https://www.google.com/maps?q=c=8.093611,134.718583=11,0,0,0,0

the controls are gone, but if one zooms out with the mouse wheel it
will return to the satellite view.

so it's probably best to just support a button such as "open google
maps for this location" and the google maps interface will indicate if
street view is supported for a location.

also as a side note, i don't have any contacts @ google but it would
be great if we can get a confirmation if there is some sort of a trick
to make the google maps API work fully offline. from my tests it just
seems that they "embedded" online mode as a requirement.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 11 July 2017 at 20:58, Linus Torvalds  wrote:
> On Tue, Jul 11, 2017 at 10:48 AM, Lubomir I. Ivanov  
> wrote:
>>
>
>> but the ESRI implementation inside QtLocation supports offline mode.
>
> The ESRI data seems good enough. It did sound like you had worries
> about the actual implementation?
>

i have at least one Qt Location API question related to the markers,
but currently i'm using a workaround and it seems to work OK.

>> so Marble seems to have the best of both worlds for now - google tiles
>> and offline support.
>
> Yeah, but Marble has been a big painpoint too. So practicalities of
> actually implementing this and maintaining it should be pretty high.
>
> One thing that would be good - and that Marble doesn't do all that
> well - is to have better integration with the outside world. For
> example, I've occasionally wanted a "escape to real google maps" just
> for things like location sharing (and you mentioned streetview earlier
> - not an issue when you're on a reef in palau, but it *is* a potential
> issue when you're looking at the parking lot of a shore-dive).
>
> So Marble has its good sides, but it has certainly its own share of
> painpoints too.
>

Qt Location does not support street view, so i guess that if we decide
to go with the Qt Location solution we need to enable opening street
view inside a new browser window, which runs google maps and requires
internet access - e.g. when clicked a marker on the Qt Location map we
can show a button "street view for this location".

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Linus Torvalds]

On Tue, Jul 11, 2017 at 10:48 AM, Lubomir I. Ivanov  wrote:
>
> here is a comparison between ESRI (from my test app) and google maps:
> http://i.imgur.com/9iYjlqD.jpg

Judging by that, I'd say that the ESRI data is certainly "good enough".

It's better than the google data was just a few years ago, I suspect.

> google seem to support at least one more zoom level and an overall
> cleaner picture.

Yeah, google has been getting better satellite data just this year,
and that's obviously not even counting the areas where they have
really good low-altitude data (ie denser areas with small-plane
photography).

And they went through another satellite data improvement a couple of years ago.

> but the ESRI implementation inside QtLocation supports offline mode.

The ESRI data seems good enough. It did sound like you had worries
about the actual implementation?

> so Marble seems to have the best of both worlds for now - google tiles
> and offline support.

Yeah, but Marble has been a big painpoint too. So practicalities of
actually implementing this and maintaining it should be pretty high.

One thing that would be good - and that Marble doesn't do all that
well - is to have better integration with the outside world. For
example, I've occasionally wanted a "escape to real google maps" just
for things like location sharing (and you mentioned streetview earlier
- not an issue when you're on a reef in palau, but it *is* a potential
issue when you're looking at the parking lot of a shore-dive).

So Marble has its good sides, but it has certainly its own share of
painpoints too.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Lubomir I. Ivanov]

On 11 July 2017 at 19:50, Linus Torvalds  wrote:
>
> So good satellite information is really important for these things. More so 
> than the offline cacheability, which is just "a good thing to have because 
> internet often sucks in those places".
>

here is a comparison between ESRI (from my test app) and google maps:
http://i.imgur.com/9iYjlqD.jpg

location is one of the northmost islands of Palau:
https://www.google.com/maps/place/8%C2%B005'37.0%22N+134%C2%B043'06.9%22E/@8.09361,134.716955,726m/data=!3m2!1e3!4b1!4m5!3m4!1s0x0:0x0!8m2!3d8.09361!4d134.718572

google seem to support at least one more zoom level and an overall
cleaner picture.
but the ESRI implementation inside QtLocation supports offline mode.
i've checked and i don't think QtLocation supports google map tiles as sources.

so Marble seems to have the best of both worlds for now - google tiles
and offline support.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Linus Torvalds]

On Tue, Jul 11, 2017 at 6:57 AM, Matt Thompson  wrote:
>
> The Aeros 300CS, the Oceanic VTX, and the Aqua lung i750TC are all basically
> the same computer, all manufactured by Pelagic Pressure Systems, all
> suitable for grooming ;). They also all do BLE, hopefully the same flavor.
>
> I have screenshots of my i750 from nRF Connect that I can send to the list
> tonight when I get to my hotel.

I actually have an Aeris A300CS, and hated it with a passion. The
screen turns into a mirror underwater, and it doesn't have all the
data I want on it, and the "secondary screen" (which you get to with a
button press) ends up having such a small font that together with the
mirror-effect, it was completely unreadable.

Plus the battery only lasted for a couple of days of diving in my
experience (admittedly, that may have been a "five hours underwater
each day" trip). And that was with the default screen brightness
(60%?). If I had been forced to actually rely on it, I would have had
to up the brightness to 100% and probably thus lose even more battery.

So I was singularly unimpressed. I had it with me for one dive trip
and never touched it again.

Maybe I had a dud. Maybe they fixed the shaving mirror effect in the
VTX. Or maybe there's just something wrong with me, but I really
didn't like the A300CS even though I really wanted to.

Annoyingly, it seems like I have lost the tank sensor for it. And I'm
annoyed mainly because I think that tank sensor would work with my
Perdix AI.

ANYWAY.

After that rant, I can report that I did take a quick look at the
A300CS BLE, and it should be something we can support.

The thing uses a Blue Radios "nBLUE" bluetooth chip that implements
serial over BLE GATT (yet another "the standard didn't make a standard
serial protocol, so we made our own". Damn to hell all the f*cking
incompetent morons on the bluetooth committee).

Oops, I'm ranting again.

ANYWAY #2.

The good news is like the OSTC3 chip, that nBLUE chip is actually
documented, because it's used in various random IoT projects. For
example

  
http://www.byteworks.us/Byte_Works/Blog/Entries/2012/12/28_Build_Your_Own_Bluetooth_low_energy_based_circuits_using_the_Blue_Radios_BR-XB-LE4.0-S2.html

and anybody with a bit of time and the lack of good sense to avoid BLE
programming could probably implement that in subsurface.

Can you verify that the nRF information from your i750TC matches the
UUID's on that web page? Because that's what my A300CS had - if they
are different, we're not going to have exactly the same BLE code..

I currently lack the time, but in another week or two I *might* be
able to look at it more if somebody else hasn't beaten me to it.
Because I clearly lack the good sense to stay away from BLE.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Bluetooth / BLE dive computers

[Dirk Hohndel]

OK, now I got curious and fired up the trusted Google...

There are a LOT of new BLE dive computers out there.

COSMIQ+ by Deepblu 

Odd looking device, I don't think we support any of their dive computers.


TUSA IQ1204 

This one is solar powered (Uemis tried that six years ago) and does BLE.
Very little information to be found otherwise.


Aqua Lung i750TC 

The internets say that this is a clone of the Oceanic VTX, except with
only one deco algorithm. But they also point out that the VTX and the
i750TC are in fact slightly newer and different compared to the Aeris
300CS - here's hoping that they didn't change the BLE code


Sherwood Sage 

A hose based computer from the same PPS family of companies (Aqua Lung
bought Pelagic Pressure Systems, so it seems like Oceanic, Hollis, the
disappearing Aeris, Sherwood, Tusa, and Aqua Lung now all are built by the
same company). Anyway, the Sage looks remarkably like a hose based flavor
of the VTX/i750TC. Has anyone seen a Sherwood Sage?  Walmart has it for a
thousand bucks :-)


Oceanic ProPlus X 

Another console, but much bigger than the Sage and competing with the
Cobalt, I guess.  libdivecomputer supports the earlier versions of the
ProPlus, but not the ProPlus X, yet. It sounds like the X adds BLE
support.


Scubapro Aladin H

Yikes, a matrix screen. I thought we had moved on from that. Hose based,
ugly, but BLE support. Not in libdivecomputer, yet.


Scubapro Aladin Sport

Looks like the same thing, only not air integrated, available both wrist
or console mounted. $415 and up. One of the cheaper BLE enabled dive
computers.


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Dirk Hohndel]

On Tue, Jul 11, 2017 at 08:57:05AM -0500, Matt Thompson wrote:
> On Jul 11, 2017 08:34, "Dirk Hohndel"  wrote:
> 
> > I know that there's the Aeris 300CS (aka shaving mirror) that does BLE.
> > I'm sure that there already are more and that even more will be coming out
> > over the next year or two.
> 
> The Aeros 300CS, the Oceanic VTX, and the Aqua lung i750TC are all
> basically the same computer, all manufactured by Pelagic Pressure Systems,
> all suitable for grooming ;). They also all do BLE, hopefully the same
> flavor.

Oh, I didn't realize that the i750TC was yet another clone of that same
dive computer. Usually these rebranded devices do in fact behave the same
way.

> I have screenshots of my i750 from nRF Connect that I can send to the list
> tonight when I get to my hotel.

That would be great. Linus actually has an Aeris 300CS sitting around
somewhere. Once his hobby project isn't taking up as much of his time
anymore (merge window closes) I hope he'll have more time again to devote
to the project that really matters (Subsurface). Actually, kidding aside,
I am impressed that he responded to requests and fixed bugs in Subsurface
and libdivecomputer in the middle of the kernel merge window this time
around. Without his work we still would have no BLE support...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Dirk Hohndel]

On Tue, Jul 11, 2017 at 03:44:44PM +0200, Jan Mulder wrote:
> > 
> > I asked Linus to take a look at that commit, given that he understands
> > that code much better than I do.
> 
> Yes, very good. Despite me changing it, I also do not fully understand why
> the code was as it was.

Story of a maintainer's life :-)

> In my testing I have not seen any cases of 32 being not enough. So, yes,
> comfortable with it. The 118 dives where a serious stress test.
> 
> > Not advocating to do this, just trying to understand how you picked 32.
> 
> It is coming from the Telit code samples :-) I just copied it, tested it
> with this value, and it just works.

That's an excellent reason

> > Thanks for all the work on that. I keep hoping that with every flavor of
> > BLE that we add we will cover more of the "typical" cases and that the
> > next one to add will become easier.
> 
> Indeed. The step to OSTC was a pretty difficult one, with that weird credit
> thing, 4 characteristics to deal with, and a different parser concept than
> the "one-packet is fine" types as before.

In a way each one was remarkably different from the previous one. I'm
hoping that we are getting closer to having the typical cases covered.

> And in the meantime, I tried Android, with Qt 5.9.1 but no success yet.
> Cannot open device (BLE that is, BT just works).

Often that means that they are not connected / bonded. Since we don't try
to do the scan / connect ourselves, we are relying on Android doing that
for us. What reliably works for me is to have nRF Connect scan, connect,
then bond, and THEN start Subsurface-mobile. But of course it's possible
that there's yet more oddity here with the chip used on the OSTC...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Matt Thompson]

On Jul 11, 2017 08:34, "Dirk Hohndel"  wrote:



I know that there's the Aeris 300CS (aka shaving mirror) that does BLE.
I'm sure that there already are more and that even more will be coming out
over the next year or two.


The Aeros 300CS, the Oceanic VTX, and the Aqua lung i750TC are all
basically the same computer, all manufactured by Pelagic Pressure Systems,
all suitable for grooming ;). They also all do BLE, hopefully the same
flavor.

I have screenshots of my i750 from nRF Connect that I can send to the list
tonight when I get to my hotel.

-Matt
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Jan Mulder]

On 11-07-17 15:24, Dirk Hohndel wrote:


2) As suggested by Anton, I implemented a more friendly read one level
above. ble_serial_read() now reads not only one packet, but reads up to the
requested size parameter. For example, the OSTC libdc parser code reads from
individual bytes, up to 1K blocks for the larger data parts (profile data).
I cannot test this adapted behavior of the serial ble read for other that
OSTC, but I have good hopes that this will work for any serial over BLE
libdb interface (assuming that these call this function with the proper size
parameter).


I asked Linus to take a look at that commit, given that he understands
that code much better than I do.


Yes, very good. Despite me changing it, I also do not fully understand 
why the code was as it was.





3) Implemented "credit management". Despite a simple concept, and seemingly
good documentation in the earlier mentioned TIO document, it is a tricky
process. Asking for to much or to little credit will stall the download at
some point, tripping a timeout. I spend (too) much time understanding why my
download stopped in a deterministic way after correctly downloading 14 dives
(and almost 13K 20-byte BLE packets).


That is an interesting concept... especially since it takes a bit for the
credits to be recorded. Are you comfortable that 32 is a reasonable lower
threshold? Would it be more reliable (with slightly more overhead) if we
moved that to 40? Or 64?


In my testing I have not seen any cases of 32 being not enough. So, yes, 
comfortable with it. The 118 dives where a serious stress test.



Not advocating to do this, just trying to understand how you picked 32.


It is coming from the Telit code samples :-) I just copied it, tested it 
with this value, and it just works.



Thanks for all the work on that. I keep hoping that with every flavor of
BLE that we add we will cover more of the "typical" cases and that the
next one to add will become easier.


Indeed. The step to OSTC was a pretty difficult one, with that weird 
credit thing, 4 characteristics to deal with, and a different parser 
concept than the "one-packet is fine" types as before.


And in the meantime, I tried Android, with Qt 5.9.1 but no success yet. 
Cannot open device (BLE that is, BT just works).


--jan

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Dirk Hohndel]

On Tue, Jul 11, 2017 at 02:02:23PM +0200, Jan Mulder wrote:
> 
> Time for an update (finally). Good news this time. I just successfully
> downloaded 118 dives from my OSTC3 over BLE.

Excellent.

> To be complete in my
> description, this download ended in a libdivecomputer parsing failure on
> dive 119, but at this point in time, I do not expect this to be a BLE
> related thing. Simply downloading a couple of new dives, just works without
> error at the end.

So both Linus and I have seen this happen when downloading a larger number
of dives, occasionally you get a failure. Maybe the BLE error correction
isn't as good as one would hope? Don't know. Kinda frustrating. But then
again, the main use case should always be "download the last few dives
that I did" which is more likely to succeed.

> I did the following to the Subsurface code (functionally, code details can
> be read from the commits I'm going to produce).
> 1) I undid the the aggressive "read until there is no more data coming" in
> the BLEObject::read(). Not only because it breaks non-OSTC usage, but simply
> because it is wrong.

Agreed :-)

> 2) As suggested by Anton, I implemented a more friendly read one level
> above. ble_serial_read() now reads not only one packet, but reads up to the
> requested size parameter. For example, the OSTC libdc parser code reads from
> individual bytes, up to 1K blocks for the larger data parts (profile data).
> I cannot test this adapted behavior of the serial ble read for other that
> OSTC, but I have good hopes that this will work for any serial over BLE
> libdb interface (assuming that these call this function with the proper size
> parameter).

I asked Linus to take a look at that commit, given that he understands
that code much better than I do.

> 3) Implemented "credit management". Despite a simple concept, and seemingly
> good documentation in the earlier mentioned TIO document, it is a tricky
> process. Asking for to much or to little credit will stall the download at
> some point, tripping a timeout. I spend (too) much time understanding why my
> download stopped in a deterministic way after correctly downloading 14 dives
> (and almost 13K 20-byte BLE packets).

That is an interesting concept... especially since it takes a bit for the
credits to be recorded. Are you comfortable that 32 is a reasonable lower
threshold? Would it be more reliable (with slightly more overhead) if we
moved that to 40? Or 64?

Not advocating to do this, just trying to understand how you picked 32.

Thanks for all the work on that. I keep hoping that with every flavor of
BLE that we add we will cover more of the "typical" cases and that the
next one to add will become easier.

I know that there's the Aeris 300CS (aka shaving mirror) that does BLE.
I'm sure that there already are more and that even more will be coming out
over the next year or two.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Jan Mulder]

On 05-07-17 20:01, Jan Mulder wrote:

On 05-07-17 18:23, Linus Torvalds wrote:

On Wed, Jul 5, 2017 at 8:57 AM, Matthias Heinrichs
 wrote:


Theoretically, this should happen through the flow control lines from 
the
Bluetooth Chipset to our applications processor. When using BLE (Due 
to the
much lower end-to-end baud rate), the flow control already is very 
active

and controlling the bytes from the OSTC to the Bluetooth chipset. When
looking at the snoop file, it shouldn't hurt to reset this credit 
counter
from time to time to 255. Or try a higher number like 65536? 
Specification

says 255 but have you tried higher values?


It says it's only a single byte, so 255 is the max..

  Linus



I made some progress by sending new credits, but it seems a bit more 
complex that just sending a new 255 credits from time to time, but I'm 
sure it going to work. I already had about 800 packets incoming during 
my testing, but things seems very fragile. So too much WIP to push 
anything out.


This all said, I really appreciate that you (Matthias and Linus) give 
input to this subject.


Time for an update (finally). Good news this time. I just successfully 
downloaded 118 dives from my OSTC3 over BLE. To be complete in my 
description, this download ended in a libdivecomputer parsing failure on 
dive 119, but at this point in time, I do not expect this to be a BLE 
related thing. Simply downloading a couple of new dives, just works 
without error at the end.


I did the following to the Subsurface code (functionally, code details 
can be read from the commits I'm going to produce).
1) I undid the the aggressive "read until there is no more data coming" 
in the BLEObject::read(). Not only because it breaks non-OSTC usage, but 
simply because it is wrong.
2) As suggested by Anton, I implemented a more friendly read one level 
above. ble_serial_read() now reads not only one packet, but reads up to 
the requested size parameter. For example, the OSTC libdc parser code 
reads from individual bytes, up to 1K blocks for the larger data parts 
(profile data). I cannot test this adapted behavior of the serial ble 
read for other that OSTC, but I have good hopes that this will work for 
any serial over BLE libdb interface (assuming that these call this 
function with the proper size parameter).
3) Implemented "credit management". Despite a simple concept, and 
seemingly good documentation in the earlier mentioned TIO document, it 
is a tricky process. Asking for to much or to little credit will stall 
the download at some point, tripping a timeout. I spend (too) much time 
understanding why my download stopped in a deterministic way after 
correctly downloading 14 dives (and almost 13K 20-byte BLE packets).


--jan
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Martin Měřinský]

> the problem with actual maps is that they are made for land use and
> often enough water is just some blue area without any details. Yes,
> there is openseamap but that is intended for boating so the details
> available are again mostly not interesting to divers. Currently,
> there is probably no alternative to satellite images that also show
> reefs etc.

OK, I didn't thought about that. I dive mostly lakes and quarries. So
for me, access roads are more important than reefs :-)

Martin
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: the marble (map) replacement dilemma

[Robert Helling]

Hi,

> On 11. Jul 2017, at 07:18, Martin Měřinský  wrote:
> 
> I would like to see OpenStreetMap. (Google/OSM map layers can be
> configurable).
> 
> Map tiles could be used from Gnome Maps or Viking cache (if available).
> It would reduce used disk space and offer offline maps (for already
> cached tiles).

the problem with actual maps is that they are made for land use and often 
enough water is just some blue area without any details. Yes, there is 
openseamap but that is intended for boating so the details available are again 
mostly not interesting to divers. Currently, there is probably no alternative 
to satellite images that also show reefs etc.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface