Re: Mares Smart Dive Computer + Bluelink pro
Hi Dirk, surely, I'll do it ASAP. Is this the right one? https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/subsurface-mobile-build-arm-debug.apk Thanks Il lun 24 set 2018, 18:20 Dirk Hohndel ha scritto: > Hi Fabio, > > And thanks for joining the developer mailing list. > > I have made a new beta version of Subsurface-mobile for Android available > which > includes the patch that Linus mentioned. > Have you had a chance to try this? > It would be good to see the logs from that new version when you attempt to > download > via the BlueLink Pro. > > Thanks > > /D > > > On Sep 24, 2018, at 9:13 AM, Fabio Capriati > wrote: > > > > Hi, > > I'm new here. I open a thread here to track this issue if someone is > interested to. > > I chated with Dirk and Linus about Mares Smart computer and Bluelink > interface issue. > > That's last Linus' mail with the problem analysis. > > > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mares Bluetooth dongle
On Mon, Sep 24, 2018 at 12:23 PM Linus Torvalds wrote: > > Our code to pick a characteristic is basically almost entirely random > and just "this worked for the cases we had" with then the Heinrichs > Weicamp thing being a complete special case because of the whole "need > to do flow control in software" thing. > > I suspect I just need to bite the bullet and have a per-divecomputer > set of uuid's etc, with the existing code as a fallback. Or something. I didn't end up doing the uuid matching yet. Instead, I tried to just fix up the fairly hardcoded "pick the first characteristic for writing, the last for reading", and make that whole logic be a lot more flexible. So now it actually looks at which characteristics have which properties, and tries to do the sane thing based on that. It still works for me Shearwater and my Suunto, and it does seem to make sense. So maybe it now works for the Mares BlueLink. And if not, I'd really like to see the subsurface debug log from a trial.. Dirk, I've sent you a merge request on github. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OT: Aqua Lung I100 Cable
On Mon, Sep 24, 2018 at 12:05 PM Dirk Hohndel wrote: > > Cool. Once Linus merges that, we'll be able to add support for it in 4.8.3 I merged Jef's i100 work, and pushed it out. It looks like the parsing is literally identical to the I200, just with the header at a different offset. Anyway, the "you need a cable that costs almost as much as the dive computer" is sadly still true (even if a _slight_ exaggeration). Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mares Bluetooth dongle
> On Sep 24, 2018, at 12:23 PM, Linus Torvalds > wrote: >> >> You bought another dive computer? > > No. I went into the local dive shop to ask if they can rent them, but > they don't. But the owner has seen me there enough that he just said > "take it for a few days". NICE. > So I have a Mares Quad Air to play with for a few days, and I decided > to just buy the bluetooth donge that they didn't have in the store. It > was prime, but sadly not "two day" prime, just "get it by Thursday". I hate that. >>> Because the Mares BLE case really looks like we should be able to get >>> it working fairly trivially. >> >> I am traveling Tue/Wed this week - but usually I can create a test APK on a >> very >> quick turnaround. So the moment you have a patch you want me to try, getting >> an APK out "only" requires me to be near my computer and have a few minutes >> to start of a build and upload it. > > I should have a patch later today. Need to go grocery shopping and > mull over just how to select the endpoints so that I don't screw up > any of our existing cases. I keep wondering if the HW is indeed the only one where we really are looking for a fixed UUID... i.e., maybe that's the same on the Mares and we just hard code things? Have we ever compared notes on the Perdix AI? > Our code to pick a characteristic is basically almost entirely random > and just "this worked for the cases we had" with then the Heinrichs > Weicamp thing being a complete special case because of the whole "need > to do flow control in software" thing. > > I suspect I just need to bite the bullet and have a per-divecomputer > set of uuid's etc, with the existing code as a fallback. Or something. That seems much more sane... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mares Bluetooth dongle
On Mon, Sep 24, 2018 at 11:46 AM Dirk Hohndel wrote: > > On Sep 24, 2018, at 11:36 AM, Linus Torvalds > > wrote: > > > > I'm hoping to have hardware to test by Thursday, but I'm actually > > hoping I could have a test-patch for people to try before that. > > You bought another dive computer? No. I went into the local dive shop to ask if they can rent them, but they don't. But the owner has seen me there enough that he just said "take it for a few days". So I have a Mares Quad Air to play with for a few days, and I decided to just buy the bluetooth donge that they didn't have in the store. It was prime, but sadly not "two day" prime, just "get it by Thursday". > > Because the Mares BLE case really looks like we should be able to get > > it working fairly trivially. > > I am traveling Tue/Wed this week - but usually I can create a test APK on a > very > quick turnaround. So the moment you have a patch you want me to try, getting > an APK out "only" requires me to be near my computer and have a few minutes > to start of a build and upload it. I should have a patch later today. Need to go grocery shopping and mull over just how to select the endpoints so that I don't screw up any of our existing cases. Our code to pick a characteristic is basically almost entirely random and just "this worked for the cases we had" with then the Heinrichs Weicamp thing being a complete special case because of the whole "need to do flow control in software" thing. I suspect I just need to bite the bullet and have a per-divecomputer set of uuid's etc, with the existing code as a fallback. Or something. I'm not writing code yet, I've only got to the "I understand what's wrong" phase. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OT: Aqua Lung I100 Cable
> On Sep 24, 2018, at 12:02 PM, Jef Driesen wrote: > I pushed the code for the i100 this morning. Cool. Once Linus merges that, we'll be able to add support for it in 4.8.3 /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OT: Aqua Lung I100 Cable
On 23-09-18 22:42, Linus Torvalds wrote: On Sun, Sep 23, 2018, 13:23 Simon Eigeldinger wrote: I just got me an Aqua Lung I100. Thought it was coming with a cable, but no. do i need the special interface cable or can i use some standard off the shelf cable? Sadly, I think it needs the special aqualung USB cable that retails for something ridiculous like $85 USD. Even more sadly, I don't think libdivecomputer actually supports the i100 at all. I assume that it is very similar to the i200 and i300 that *are* supported, but it might take some debugging and some help from Jef Driesen to get a download going correctly even with the cable.. I pushed the code for the i100 this morning. Jef ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mares Bluetooth dongle
> On Sep 24, 2018, at 11:36 AM, Linus Torvalds > wrote: > But from everything I see, I think that the Mares code should just > magically start working if I fix that stupid choice of > characteristics. > > I'm hoping to have hardware to test by Thursday, but I'm actually > hoping I could have a test-patch for people to try before that. You bought another dive computer? > Because the Mares BLE case really looks like we should be able to get > it working fairly trivially. I am traveling Tue/Wed this week - but usually I can create a test APK on a very quick turnaround. So the moment you have a patch you want me to try, getting an APK out "only" requires me to be near my computer and have a few minutes to start of a build and upload it. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Mares Bluetooth dongle
Ok, so I've parsed the bluetooth logs that were provided by Allen Hall (back in April) and by Fabio Capriati (recently), and I think I see what is going wrong. We actually do *almost* the right thing. We even pick the right GATT service from the device. It looks like (if I'm reading things correctly) that device has a service 544E326B-5B72-C6B0-1C46-41C1BC448118 which in turn has a few characteristics: 1d1aae28-d2a8-91a1-1242-9d2973fbe571 99a91ebd-b21f-1689-bb43-681f1f55e966 and that characteristic 1d1aae28 then has a "Client Characteristic Configuration" descriptor to enable notifications and we'll get the read data from that. And we just do a write to the 99a91ebd one. That part is actually exactly what we expect: enable notifications on one characteristic, and write to another. And the protocol is the exact same normal Mares protocol that libdivecomputer already supports. So it should all just work, EXCEPT there is *third* characteristic on that service too with uuid d8b3ab7c-4101-ec80-c441-9b0914f6ebc3 and that's the thing that seems to mess us up. We end up trying to enable notifications on that third characteristic, because our logic to pick the read-vs-write ones is way way too simplistic. We basically assume that the notifications come in on the last characteristic, and that the writes go out on the first characteristic. Both of which are wrong for this one. But from everything I see, I think that the Mares code should just magically start working if I fix that stupid choice of characteristics. I'm hoping to have hardware to test by Thursday, but I'm actually hoping I could have a test-patch for people to try before that. Because the Mares BLE case really looks like we should be able to get it working fairly trivially. Unlike the Garmin Descent, which still confuses the heck out of me, despite me having the hardware to look at and traces to follow. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OT: Aqua Lung I100 Cable
Am 23.09.2018 um 22:42 schrieb Linus Torvalds: On Sun, Sep 23, 2018, 13:23 Simon Eigeldinger wrote: I just got me an Aqua Lung I100. Thought it was coming with a cable, but no. do i need the special interface cable or can i use some standard off the shelf cable? Sadly, I think it needs the special aqualung USB cable that retails for something ridiculous like $85 USD. Thanks for replying. Yes i guess thats what i also have seen. Even more sadly, I don't think libdivecomputer actually supports the i100 at all. I assume that it is very similar to the i200 and i300 that *are* supported, but it might take some debugging and some help from Jef Driesen to get a download going correctly even with the cable.. Maybe thinking of selling it again. Maybe getting a Mares Puck would be better and then buying the also not so cheap pc interface for around € 40. As a blind diver there is no accessible dive computer at the moment but a logging device would be enough at least to take it with me as a blackbox. Any other computers which are cheap and do the job? Mostly i need air and nitrox. the dive profile can be exported into a csv file which can then be read as it is possible using subsurface though this is also not a completely accessible task but might be possible. though we try to contact a local electronics school which might be able to build a accessible dive computer which at least could show some information through vibrations. Greetings, Simon --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Silly problem with dive sites and GPS downloading
> On Sep 24, 2018, at 9:33 AM, Linus Torvalds > wrote: > > I'd actually argue that a dive site could be described as an "area", True. Because our data isn't confusing and inconsistent enough, we could add a "focus point" plus NW and SE corner :-) >> (b) a dive itself can be described in multiple ways. >> (1) Simply by the coordinates of the site. >> (2) by the entry and exit point. >> (3) by the path that the diver actually took (turning the whole dive profile >> into a 3D path). >> >> Today we do (b)(1). > > Yes. > > Except I'd go even further, and say that we could have a fourth case: > a dive could be described as simply a location, *WITHOUT* having a > dive site associated with it. > > Because I'd be a lot happier about our divesite handling if we didn't > force a dive to be associated with a site. But then it doesn't get a name. The moment you have a name, you have implicitly defined a site. > I think a dive site exists independently of any dives. A dive site it > about having a location, a description, and a name, but is *not* > defined by you diving it. > > And similarly, you can have a dive without having a "site". Even if > the dive has a single location, that location may not be a "site". That part I disagree with. It may not be an "official site", it may not match some random definition of "site", but a dive with a location and name has happened at a spot that we should track as a dive site. > The most common case of that "non-site" case is drift-dives, where you > might drift between possibly several sites (or drift into or out of > one). Yes, this goes back to the earlier argument that a dive site really should have three coordinates, but I think we can agree that everyone considers German Channel a dive site. > But people literally do blackwater dives too, where you absolutely do > *not* have a site at all. You're literally just in a fairly random > location. You're doing it for Yes, this isn't a Site in the sense of a place that everyone comes back to, yet your dive happened somewhere... and that's the site where you went diving. I think we are going to seriously confuse ourselves if we allow dives to have location and name independent of a dive site. We used to do that and as much as I know that you hate where it got us to, we moved away from that for VERY GOOD REASONS. > So what I think would be better is that we separate the dive sites > from the location further. > > For example, I'd love to have a dive site database, but I'd love that > database to have *NOTHING* to do with the dives I do. It would be > literally used only to look up names based on the GPS coordinates I > have. > > If subsurface would take my GPS coordinates, and automatically name > the location of my dives, that would be really cool. I could still > edit the name (without editing the dive site database), because many > of the places I dive, there's a buoy that can take me to several > different areas just depending on which direction I swim. > > So maybe the divesite database would be "Molokini Crater" for stuff in > a certain GPS range, and I'd get that automatically just based on the > GPS info I have (either from the subsurface phone app tracking, or > from a dive computer like the Garmin that has gps). > > But then I might edit it to say "Enenu'i" or "Reef's End" or > "Aquarium" depending on which part of Molokini I was diving (ok, so > the GPS might be able to separate Enenu'i from Reef's End, but when > moored at the Reef's end site, you do tend to go off in different > directions and the "sites" have different names). > > So I think it would be much nicer if we just made the dive location be > per-dive, and stopped associating dives with "sites" entirely. Having > some nice way to get to a site based on "this is close to your dive" > would be great, but I think it shouldn't be tied together the way it > is now. > > Then, if we had a separate dive site database, and you *don't* have > GPS location, you could just select a site when you edit the dive, and > that would *copy* the gps information from the site database to the > dive, but it wouldn't make that hard link (again, you might then edit > the per-dive data, maybe by just moving the marker around - without > that having any effect what-so-ever on the divesite database). > > The problem, of course, is that it does require that dive site > database editor. Which we've never had. Because we mixed up the dive > location editing with the divesite database. > > But separating out the divesite database would be good for another > reason: if we ever were to have some external "cloud database" of dive > sites that people can share, it obviously needs to be separate from > peoples dives anyway. > > I think we could easily do the separation part, but the difficult part > is doing that divesite editor (even if it is entirely private, the > "cloud database" is just a pipedream right now, and has been for > years) That's a completely new
Re: Silly problem with dive sites and GPS downloading
On 09/24/2018 11:33 AM, Linus Torvalds wrote: On Mon, Sep 24, 2018 at 9:04 AM Dirk Hohndel wrote: (a) a dive site, as an independent entity from a dive, does have a logical GPS location. One can argue where that is and in many ways that's a matter of taste and opinion (e.g., is it where you enter the water, or is it where the "interesting" part of the dive happens), but in general a dive site has just one coordinate. I'd actually argue that a dive site could be described as an "area", not a single point, but I think your argument that a "dive" and a "divesite" are entirely separate things is correct. (b) a dive itself can be described in multiple ways. (1) Simply by the coordinates of the site. (2) by the entry and exit point. (3) by the path that the diver actually took (turning the whole dive profile into a 3D path). Today we do (b)(1). Yes. Except I'd go even further, and say that we could have a fourth case: a dive could be described as simply a location, *WITHOUT* having a dive site associated with it. Because I'd be a lot happier about our divesite handling if we didn't force a dive to be associated with a site. ++ I think a dive site exists independently of any dives. A dive site it about having a location, a description, and a name, but is *not* defined by you diving it. And similarly, you can have a dive without having a "site". Even if the dive has a single location, that location may not be a "site". The most common case of that "non-site" case is drift-dives, where you might drift between possibly several sites (or drift into or out of one). But people literally do blackwater dives too, where you absolutely do *not* have a site at all. You're literally just in a fairly random location. You're doing it for So what I think would be better is that we separate the dive sites from the location further. For example, I'd love to have a dive site database, but I'd love that database to have *NOTHING* to do with the dives I do. It would be literally used only to look up names based on the GPS coordinates I have. If subsurface would take my GPS coordinates, and automatically name the location of my dives, that would be really cool. I could still edit the name (without editing the dive site database), because many of the places I dive, there's a buoy that can take me to several different areas just depending on which direction I swim. So maybe the divesite database would be "Molokini Crater" for stuff in a certain GPS range, and I'd get that automatically just based on the GPS info I have (either from the subsurface phone app tracking, or from a dive computer like the Garmin that has gps). But then I might edit it to say "Enenu'i" or "Reef's End" or "Aquarium" depending on which part of Molokini I was diving (ok, so the GPS might be able to separate Enenu'i from Reef's End, but when moored at the Reef's end site, you do tend to go off in different directions and the "sites" have different names). So I think it would be much nicer if we just made the dive location be per-dive, and stopped associating dives with "sites" entirely. Having some nice way to get to a site based on "this is close to your dive" would be great, but I think it shouldn't be tied together the way it is now. Then, if we had a separate dive site database, and you *don't* have GPS location, you could just select a site when you edit the dive, and that would *copy* the gps information from the site database to the dive, but it wouldn't make that hard link (again, you might then edit the per-dive data, maybe by just moving the marker around - without that having any effect what-so-ever on the divesite database). Yeah - I think that's right on. It handles the simple case "I dove on these coordinates" Then, if you WANT to create a dive site in the dive site database, or in the magical future world of ponies and rainbows you want to associate it with a pre-existing dive site from a magical dive-site database, you totally can. The problem, of course, is that it does require that dive site database editor. Which we've never had. Because we mixed up the dive location editing with the divesite database. But separating out the divesite database would be good for another reason: if we ever were to have some external "cloud database" of dive sites that people can share, it obviously needs to be separate from peoples dives anyway. I think we could easily do the separation part, but the difficult part is doing that divesite editor (even if it is entirely private, the "cloud database" is just a pipedream right now, and has been for years) I like the idea of a dive site database/editor and would be happy to work on such a thing. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Silly problem with dive sites and GPS downloading
On 09/24/2018 11:04 AM, Dirk Hohndel wrote: So Linus said some interesting things about this topic - and others have added in the past. I'd like to try and connect some of the dots here - please correct me if I get things wrong... (a) a dive site, as an independent entity from a dive, does have a logical GPS location. One can argue where that is and in many ways that's a matter of taste and opinion (e.g., is it where you enter the water, or is it where the "interesting" part of the dive happens), but in general a dive site has just one coordinate. (b) a dive itself can be described in multiple ways. (1) Simply by the coordinates of the site. (2) by the entry and exit point. (3) by the path that the diver actually took (turning the whole dive profile into a 3D path). Today we do (b)(1). It seems that at least with the Garmin we could relatively easily (assuming the diver does turn on dive mode early enough to get a GPS fix before being under water) do (b)(2) I don't think there is equipment that is widely available to do (b)(3) Typically when it's hard to foresee how things will get abstracted out int the future, I tend to suggest using text fields / strings. Right now we store all available GPS information on the Garmin as strings. Maybe we should allow people to do this for other dive computers as well, assuming they have a source for the strings (and we can of course use the GPS info from a phone). Which means we'd need a way to do this dive computer independently. Maybe also an option somewhere, for when the GPS data logger is being used in the Android app, to save all of the collected GPS points as text records onto the dive object as well when applying GPS data. (at least the ones between start and end times of the dive) I'd love to hear people's thoughts on this. Let me see if I can make it even more complicated - because I'm pretty sure more input will definitely make this clearer. A few of the other loggers, at least diviac and divelogs.de, split the location of a dive into two ideas "Location" and "Dive Site". (neither particularly explain the difference spectacularly) The way I've come to understand the split is that Location is "the real geographical place where I set up my gear" and Dive Site is "the place where I was under water". Now with Mk1 GPS or other sets of coordinates, each dive also potentially has a specific "path" - that is a path described across a dive site. Specific examples, to attach concrete examples to abstract concepts: Blue Hole, NM: https://www.google.com/maps/place/Blue+Hole/@34.9404462,-104.6819938,15z/data=!3m1!4b1!4m5!3m4!1s0x871c0b5ae1b0dfe9:0xe7228c5b0ba0698a!8m2!3d34.940447!4d-104.673239 Scuba Ranch, TX: https://www.google.com/maps/place/The+Scuba+Ranch+at+Clear+Springs/@32.7891403,-96.1552064,17z/data=!3m1!4b1!4m5!3m4!1s0x86495b7f045849e7:0x7e45bec3eb6d9080!8m2!3d32.7891403!4d-96.1530177 Flynn Reef, Australia: https://www.google.com/maps/place/Flynn+Reef/@-16.7243694,146.2558661,14z/data=!3m1!4b1!4m5!3m4!1s0x6979cbf27dcbb67d:0x778f3f250b640676!8m2!3d-16.7243701!4d146.2733758 Blue Hole, Scuba Ranch and Flynn Reef are all Locations. Blue Hole has one eponymously named dive site and is super easy. There's also only one entry/exit point. It's a hole. Scuba Ranch is also just one "Location" - there is an entrance where you pay a fee and where you can get your log stamped. There are maybe 10 different parking lots/shore entries (not sure the distinction matters, but maybe it does?) - and in general different local groups have "their" spot where they always dive from. Inside the flooded quarry there are several "Dive Site"s - there's a sunken airplane, two boats, a big metal fish and several dive platforms. If you dive there a bunch, maybe because you're a local, which dive you did might be more interesting than just "Scuba Ranch" - but also you're certainly at Scuba Ranch for all of them. Flynn Reef is a real geographic place with a real name, but being a reef there are more than one spot on it where your boat might moor. From any one of those moorings, there are multiple available "Dive Site"s ... and I'm pretty sure the different dive operators call at least some of them by different names. Throwing the Linus Mk1 GPS start/end tracking in to the mix, and now there are also the possibility of one or more distinct "Dive"s with locations at a given "Dive Site". Flynn Reef has GPS coordinates, it's a place. Nemo's Bommie also probably has GPS coordinates - or more to the point is at least a logical place where saying "these 4 dives were all at Nemo's Bommie" makes sense as a human. Then each dive at that dive site has the potential to also have specific GPS start/end coordinates, even though the dive might be associated with a Dive Site and that Dive Site might be associated with a Location. As you go from General to Specific, the GPS information becomes less likely to be shareable with others. I can
Re: Silly problem with dive sites and GPS downloading
On Mon, Sep 24, 2018 at 9:33 AM Linus Torvalds wrote: > > But people literally do blackwater dives too, where you absolutely do > *not* have a site at all. You're literally just in a fairly random > location. You're doing it for Oops, this got cut short because I was editing something else. It was supposed to be "You're doing it for the sealife, not the particular location". Now, blackwater dives tend to be about plankton etc, but you do have other similar cases where you follow the life, not some geographic feature. We *tried* to find whale-sharks. Again, had that worked better, it wouldn't necessarily be anywhere _near_ a "dive site", it would be "hey, we saw a whale shark and jumped in at this location". Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Silly problem with dive sites and GPS downloading
On Mon, Sep 24, 2018 at 9:04 AM Dirk Hohndel wrote: > > (a) a dive site, as an independent entity from a dive, does have a > logical GPS location. One can argue where that is and in many ways > that's a matter of taste and opinion (e.g., is it where you enter the water, > or is it where the "interesting" part of the dive happens), but in general > a dive site has just one coordinate. I'd actually argue that a dive site could be described as an "area", not a single point, but I think your argument that a "dive" and a "divesite" are entirely separate things is correct. > (b) a dive itself can be described in multiple ways. > (1) Simply by the coordinates of the site. > (2) by the entry and exit point. > (3) by the path that the diver actually took (turning the whole dive profile > into a 3D path). > > Today we do (b)(1). Yes. Except I'd go even further, and say that we could have a fourth case: a dive could be described as simply a location, *WITHOUT* having a dive site associated with it. Because I'd be a lot happier about our divesite handling if we didn't force a dive to be associated with a site. I think a dive site exists independently of any dives. A dive site it about having a location, a description, and a name, but is *not* defined by you diving it. And similarly, you can have a dive without having a "site". Even if the dive has a single location, that location may not be a "site". The most common case of that "non-site" case is drift-dives, where you might drift between possibly several sites (or drift into or out of one). But people literally do blackwater dives too, where you absolutely do *not* have a site at all. You're literally just in a fairly random location. You're doing it for So what I think would be better is that we separate the dive sites from the location further. For example, I'd love to have a dive site database, but I'd love that database to have *NOTHING* to do with the dives I do. It would be literally used only to look up names based on the GPS coordinates I have. If subsurface would take my GPS coordinates, and automatically name the location of my dives, that would be really cool. I could still edit the name (without editing the dive site database), because many of the places I dive, there's a buoy that can take me to several different areas just depending on which direction I swim. So maybe the divesite database would be "Molokini Crater" for stuff in a certain GPS range, and I'd get that automatically just based on the GPS info I have (either from the subsurface phone app tracking, or from a dive computer like the Garmin that has gps). But then I might edit it to say "Enenu'i" or "Reef's End" or "Aquarium" depending on which part of Molokini I was diving (ok, so the GPS might be able to separate Enenu'i from Reef's End, but when moored at the Reef's end site, you do tend to go off in different directions and the "sites" have different names). So I think it would be much nicer if we just made the dive location be per-dive, and stopped associating dives with "sites" entirely. Having some nice way to get to a site based on "this is close to your dive" would be great, but I think it shouldn't be tied together the way it is now. Then, if we had a separate dive site database, and you *don't* have GPS location, you could just select a site when you edit the dive, and that would *copy* the gps information from the site database to the dive, but it wouldn't make that hard link (again, you might then edit the per-dive data, maybe by just moving the marker around - without that having any effect what-so-ever on the divesite database). The problem, of course, is that it does require that dive site database editor. Which we've never had. Because we mixed up the dive location editing with the divesite database. But separating out the divesite database would be good for another reason: if we ever were to have some external "cloud database" of dive sites that people can share, it obviously needs to be separate from peoples dives anyway. I think we could easily do the separation part, but the difficult part is doing that divesite editor (even if it is entirely private, the "cloud database" is just a pipedream right now, and has been for years) Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Mares Smart Dive Computer + Bluelink pro
Hi Fabio, And thanks for joining the developer mailing list. I have made a new beta version of Subsurface-mobile for Android available which includes the patch that Linus mentioned. Have you had a chance to try this? It would be good to see the logs from that new version when you attempt to download via the BlueLink Pro. Thanks /D > On Sep 24, 2018, at 9:13 AM, Fabio Capriati wrote: > > Hi, > I'm new here. I open a thread here to track this issue if someone is > interested to. > I chated with Dirk and Linus about Mares Smart computer and Bluelink > interface issue. > That's last Linus' mail with the problem analysis. > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Mares Smart Dive Computer + Bluelink pro
Hi,
I'm new here. I open a thread here to track this issue if someone is
interested to.
I chated with Dirk and Linus about Mares Smart computer and Bluelink
interface issue.
That's last Linus' mail with the problem analysis.
Bye
Fabio
-- Forwarded message -
From: Linus Torvalds
Date: dom 23 set 2018 alle ore 03:01
Subject: Re: Mares Smart Dive Computer
To: , Subsurface Mailing List <
subsurface@subsurface-divelog.org>
Cc: Dirk Hohndel
On Sat, Sep 22, 2018 at 2:48 PM Linus Torvalds
wrote:
>
> This looks odd, [..]
>
> I need to stare at the code. I suspect this is a more complex set of
> descriptors than what we've seen before, and I'm thinking that our use
> of the QT GATT interfaces is just fundamentally wrong, but happened to
> work with the simpler serives exposed by the devices we already
> support.
Ok, I think I see what's going on.
We've done the service discovery, and then we pick the first
non-standard service and decide that's our preferred service. And we
wait for the discovery of the characteristics of *that* service to
end, but when there are multiple services, the other discovery may
still be going on.
This hasn't shown up on the Suunto or Shearwater dive computers I
have, simply because they only have one single non-standard service.
So we have two issues:
- I think we picked the wrong service to begin with for the Mares case
- the debug log looks horribly messy because some of the discovery is
still going on while we try to start doing IO on that service
I have a patch that I think works around the debug issue, and that I
think will also make it easier to do a better job at picking the right
service (but that second thing is *not* done yet).
Dirk (and anybody else who is interested in debugging BLE), does the
attached patch work for you? It *shouldn't* change any behavior, but
it should result in much better debug output, looking something like
this (this is my Garmin Descent, which I also don't have working, but
that has a fairly complex GATT setup:
Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
c: "{2a00--1000-8000-00805f9b34fb}"
c: "{2a01--1000-8000-00805f9b34fb}"
c: "{2a04--1000-8000-00805f9b34fb}"
c: "{2aa6--1000-8000-00805f9b34fb}"
Found service "{1801--1000-8000-00805f9b34fb}" "Generic Attribute"
c: "{2a05--1000-8000-00805f9b34fb}"
d: "{2902--1000-8000-00805f9b34fb}"
Found service "{6a4e2401-667b-11e3-949a-0800200c9a66}" "Unknown Service"
c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"
c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
Found service "{6a4e8022-667b-11e3-949a-0800200c9a66}" "Unknown Service"
c: "{6a4e4c80-667b-11e3-949a-0800200c9a66}"
c: "{6a4ecd28-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
Found service "{6a4e2500-667b-11e3-949a-0800200c9a66}" "Unknown Service"
c: "{6a4e2502-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
c: "{6a4e2503-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
c: "{6a4e2504-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
c: "{6a4e2505-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
c: "{6a4e2501-667b-11e3-949a-0800200c9a66}"
d: "{2902--1000-8000-00805f9b34fb}"
.. ignoring standard service "{1800--1000-8000-00805f9b34fb}"
.. ignoring standard service "{1801--1000-8000-00805f9b34fb}"
Using service "{6a4e2401-667b-11e3-949a-0800200c9a66}" as preferred service
which shows *all* the services, their characteristics, and the
descriptors. It also shows exactly which service we ended up using as
the preferred one.
You can see above how there are three non-standard services on the
Garmin (the "Unknown Service") ones, and how we just randomly pick the
first one as the preferred one. That's likely wrong for the Garmin,
but we have other issues too (ie unlike the Mares I haven't even
figured out what the protocol is).
I think the Mares has two non-standard services:
Found service "{544e326b-5b72-c6b0-1c46-41c1bc448118}"
Found service "{a86abc2d-d44c-442e-99f7-80059a873e36}"
but it would be interesting to see the whole service -> characteristic
-> descriptor tree.
I think I could figure it out by looking at your trace, but damn,
reading those GATT traces to figure out the descriptors is painful.
Anyway, still working on this all.
Linus
core/qt-ble.cpp | 112 +---
core/qt-ble.h | 6 +--
2 files changed, 85 insertions(+), 33 deletions(-)
diff --git a/core/qt-ble.cpp b/core/qt-ble.cpp
index b4678aa5c..96dc12ad9 100644
--- a/core/qt-ble.cpp
+++ b/core/qt-ble.cpp
@@ -105,20 +105,6 @@ void BLEObject::writeCompleted(const QLowEnergyDescriptor&, const QByteArray&)
void
Re: Silly problem with dive sites and GPS downloading
So Linus said some interesting things about this topic - and others have added in the past. I'd like to try and connect some of the dots here - please correct me if I get things wrong... (a) a dive site, as an independent entity from a dive, does have a logical GPS location. One can argue where that is and in many ways that's a matter of taste and opinion (e.g., is it where you enter the water, or is it where the "interesting" part of the dive happens), but in general a dive site has just one coordinate. (b) a dive itself can be described in multiple ways. (1) Simply by the coordinates of the site. (2) by the entry and exit point. (3) by the path that the diver actually took (turning the whole dive profile into a 3D path). Today we do (b)(1). It seems that at least with the Garmin we could relatively easily (assuming the diver does turn on dive mode early enough to get a GPS fix before being under water) do (b)(2) I don't think there is equipment that is widely available to do (b)(3) Typically when it's hard to foresee how things will get abstracted out int the future, I tend to suggest using text fields / strings. Right now we store all available GPS information on the Garmin as strings. Maybe we should allow people to do this for other dive computers as well, assuming they have a source for the strings (and we can of course use the GPS info from a phone). Which means we'd need a way to do this dive computer independently. I'd love to hear people's thoughts on this. /D > On Sep 24, 2018, at 8:26 AM, Linus Torvalds > wrote: > > On Mon, Sep 24, 2018 at 6:12 AM Monty Taylor wrote: >> >> Maybe at least collect the start/end GPS so we have them in the data, >> and maybe later someone will good idea for visualization? > > For the Garmin Descent, the way it's currently done is that start/end > coordinates are captures as "extra data" strings, with a key of GPS1 > and GPS2 respectively. > > End result: the data does get saved, but only the last coordinate is > then used for the dive site. > > So I agree, there's no huge hurry about this. > > Looking at the actual data I do have, it does seem to be (a) more than > precise enough to warrant showing on the map and (b) not useful as a > _path_. > > For example, I did Blackrock in Maui as a "drift" dive (ok, so it took > an hour and a half to "drift" a few hundred meters because there was > no real current), and for that dive I got > > keyvalue "GPS1" "20.928930, -156.695058" > keyvalue "GPS2" "20.926903, -156.696113" > > which if you look at a map looks exactly right, but if you draw a line > between them it will go straight through the Sheraton Maui, because > obviously the actual dive is *around* the rock. > > So I think Dirk's argument that we don't have good enough GPS location > is wrong - but it is true that it might be hard to show them sanely. > > I think the Garmin Connect app showed the locations as a red and a > green marker. I'm not sure that's great either. > >Linus > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Silly problem with dive sites and GPS downloading
On Mon, Sep 24, 2018 at 6:12 AM Monty Taylor wrote: > > Maybe at least collect the start/end GPS so we have them in the data, > and maybe later someone will good idea for visualization? For the Garmin Descent, the way it's currently done is that start/end coordinates are captures as "extra data" strings, with a key of GPS1 and GPS2 respectively. End result: the data does get saved, but only the last coordinate is then used for the dive site. So I agree, there's no huge hurry about this. Looking at the actual data I do have, it does seem to be (a) more than precise enough to warrant showing on the map and (b) not useful as a _path_. For example, I did Blackrock in Maui as a "drift" dive (ok, so it took an hour and a half to "drift" a few hundred meters because there was no real current), and for that dive I got keyvalue "GPS1" "20.928930, -156.695058" keyvalue "GPS2" "20.926903, -156.696113" which if you look at a map looks exactly right, but if you draw a line between them it will go straight through the Sheraton Maui, because obviously the actual dive is *around* the rock. So I think Dirk's argument that we don't have good enough GPS location is wrong - but it is true that it might be hard to show them sanely. I think the Garmin Connect app showed the locations as a red and a green marker. I'm not sure that's great either. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Silly problem with dive sites and GPS downloading
On 09/22/2018 04:07 PM, Dirk Hohndel wrote: PS. We have another pending problem with the dive site situaiton: the Garmin Descent Mk1 gives us both entry and exit coordinates, and having done four drift dives with it, I actually really *would* like to have our mapping to show it as not a flag, but as a line between two points. But right now we only associate a single GPS coordinate with the dive, and because the Garmin reliably gives an exit coordinate but not an entry one (if you jump into the water before it gets a GPS fix), the downloader will just use the single exit point for the automatic dive site. But that pending problem is an enhancement, not a bug. Yes, and we already had people who said that they want us to associate a path with the dive. And my answer to this continues to be that the visualization is a pain and that I am not convinced that the accuracy of these GPS coordinates is nowhere near good enough to make all this worth it. The visualization of a path would certainly be a pain, but having start and end coordinates for a dive would certainly be neat - and for folks without an Mk1 who are using the gps logger, we can grab an ending GPS coordinate with time matching just as easily as we can grab a beginning one. Maybe at least collect the start/end GPS so we have them in the data, and maybe later someone will good idea for visualization? ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
