Re: subsurface Digest, Vol 107, Issue 22
Hi Dirk, Date: Fri, 30 Oct 2020 12:53:24 -0700 From: Dirk Hohndel I'd love to hear back from as many Windows users as possible before we do a release that uses this new build. I tested the OSTC 4 and the small OSTC (sport, plus and 2) using the classic BT (Via COM-Ports) and this worked just fine. BT LE however fails repeatedly with this error: Subsurface: v4.9.7-223-gbd0d7bd0faa1, built with libdivecomputer v0.7.0-devel-Subsurface-NG (3a300a6a8ff81665463e0172e3fc5e0bcc92ec65) [52.768160] INFO: Discover: address=947BE7B0D9F8, name=OSTC4 26 [52.768192] INFO: Discover: address=008025E056BD, name=OSTCs 1 [52.768212] INFO: Open: address=008025E056BD, port=0 [57.897396] ERROR: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat (10060) [in /__w/subsurface/libdivecomputer/src/socket.c:149 (dc_socket_connect)] regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface Digest, Vol 102, Issue 65
Hi, Date: Thu, 21 May 2020 13:50:57 -0700 From: Linus Torvalds Yeah, IO is working and data is transferring. At least to begin with. The libdivecomputer log is more clear about the actual data transfer, but they look fine too - all the way until it just starts sending all FF (with then very occasional noise of other things that again look like valid data). On the 6D command, the OSTC sends a list of 256 "short (or compact) headers" (16 bytes each, so 4096Bytes in total). If I look into the libdivecomputer log, I see 5 dives in the logbook. 4 at the beginning and one at pos 229 which is a bit odd. But should work anyway. Profile lengths in bytes are 5828, 5276, 6020, 4879, (Normal) but 8470530 for the dive at pos. 229 (not normal)). After sending the 4096bytes the OSTC sends it's "Ready" byte 0x4D and then we have the error: [1.440125] WARNING: Unexpected empty header found. [in /android/subsurface/libdivecomputer/src/hw_ostc3.c:756 (hw_ostc3_device_foreach)] So, assuming the bytes are transferred correctly into the correct locations within subsurface/libdivecomputer I can only guess that this fifth dive causes the issue. Our "official" downloader is libdivecomputer, btw. We decided long ago not to make our own download software but better support third party logbook software. Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
Am 12.01.2020 um 21:00 schrieb Jef Driesen:
On 12/01/2020 20:34, Jan Mulder wrote:
where we expect a string like "[1.5.1]", being the first line in the
http://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt file.
So, the problem is not data returned from the DC, but from the webserver
(and totally unprotected parsing at Subsurface end). But, interestingly,
visiting the mentioned changelog file from a browser (or curl), all
looks just fine.
Looks like www.heinrichsweikamp.net redirects to heinrichsweikamp.net,
and subsurface doesn't follow the redirect automatically. This
probably needs to be configured explicitly in the code somewhere.
Hi Jef,
https://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt and
https://heinrichsweikamp.net/autofirmware/ostc4_changelog.txt both work
and not redirected. I haven't changed any config for the
heinrichsweikamp.net domain but maybe the non-https requests are now
redirected because of an update (heinrichsweikamp.net is a virtual
("cloud") server only?
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Extending the planner profile a few minutes on the surface
Hi, I recently hold a lecture about the Bühlmann ZH-L16 model and was using subsurface-generated heatmaps to show different aspects about gradient factors or bubble-based models. So this is basically a feature request, the last stop is not your 3m stop (Or 6) but the 0m stop (Surface). In order to show the degassing on this "stop" with the heatmaps it would be nice to add some minutes surface time to the planner profile. Ideally with the option for surface oxygen, as well. As in the example from Simon Mittchel (attached image) I talk about the area after "Point of surfacing". regards, Matthias -- heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau Geschäftsführer: Matthias Heinrichs ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re:serial OSTC dive computers on Android
Hi Dirk,
Am 11.08.2018 um 18:26 schrieb subsurface-requ...@subsurface-divelog.org:
> Message: 6
> Date: Sat, 11 Aug 2018 08:32:55 -0700
> From: Dirk Hohndel
> The one group that I hoped we'd get a few more entries for are the
serial OSTC dive computers.
> In the past we had quite a few users of those on this mailing list -
if you have one, and an Android
> phone, I'd love to get the information that Subsurface sees when you
connect it.
I have emailed you two logs for USB based OSTC and Subsurface Mobile
2.1.0(4.8.0.0): OSTC 2N and OSTC cR. Both downloaded just fine.
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
Hi, one question from me: how can upload a fake dive to the OSTC+? This is unfortunately not possible. Only real dives will be stored in the logbook, not simulations and you can't upload dives. Sorry... regards, Matthias -- heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau Geschäftsführer: Matthias Heinrichs ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface configure DC feature and OSTC Plus
Hello,
Am 03.03.2018 um 21:30 schrieb Anton Lundin:
As far as I've know, there is no difference in the communication, if its
done over bluetooth or ftdi-usb-serial. In subsurface case its all
transparent.
Correct. There is the exact same code on our (OSTC) side.
with Matthias and Co, hwOS Tec and hwOS Sport should just behave the
same way when trying to configure them, and hwOS Sport just ignores the
bits it doesn't "understand".
Also correct. We try to make these two branches as compatible as
possible. All settings not included in the hwOS Sport are ignored from
the hwOS Sport.
The odd child in the bunch is the OSTC4. Its a slightly different
protocol, with config variables meaning slightly different things.
The OSTC4 will be fully open-source very soon, as well (We're just
cleaning up the code so it's a bit more understandable). So I hope to
make the OSTC4 configuration-wise as compatible as possible then.
Firmware update is and will be different, though.
We should probably add the OSTC 2 TR to. There are quite a few config
variables thats new and should to be added to.
Beside the firmware update (the OSTC 2 TR has a software-defined radio
receiver which can be updated additionally to the normal firmware) the
OSTC 2 TR is either an hwOS TEC or hwOS Sport OSTC. Nothing special for
you to do.
regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Subsurface configure DC feature and OSTC Plus
Hi Stefan, I read this as: We can add the OSTC Plus in the list together with the > OSTC 2/3/Sport/cR and it should work?! Yes. regards, Matthias P.S.: Do you want an OSTC Plus (surface testing device, not 100% suitable for diving) for tests? Just PM me your address and we'll send you one. -- heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau Geschäftsführer: Matthias Heinrichs ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Testing v392 with OSTC Sport
Am 13.07.2017 um 15:03 schrieb Dirk Hohndel: It tries to associate Bluetooth names (and the correspondong addresses) with known patterns for dive computer names. I'm actually surprised that this didn't end up with an error that it can't determine the address - but maybe the slightly odd BT names of the OSTC devices worked out in our favor here and it was misdetected? I'd prefer a small pop-up with a list to choose from (Detected devices). Makes this all a bit more robust and future proof. In case /we/ choose the rename the newest model different /again/. Divemate had the same problems and they now keep a list of all possible BT names in their code. I still use one of the earliest OSTC3 BLE prototypes personally and it still has it's default name like "BlueMod+SR", for example. Regards, Matthias -- heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau Geschäftsführer: Matthias Heinrichs, Christian Weikamp ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: subsurface Digest, Vol 68, Issue 55
Hi, From: Werner Macho To: Subsurface Mailing List Subject: Testing v392 with OSTC Sport There is no reaction when I switch the Dive Computer to "OSTC Sport" but accidentally I hit the retry button while the Dive Computer was set to "OSTC 3" and everything worked. How is the App deciding to which BLE device it's connecting? To download the logs, both versions (hwOS2 Tech and Sport) are compatible and the Bluetooth name should not matter. OSTC4 is different, of course. Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC over BLE experiences and questions
Am 04.07.2017 um 21:26 schrieb Jan Mulder: the quoted section is highly unclear (to me). Only tracking the counter on Subsurface side will not help the OSTC to decide to stop sending. It needs to be communicated too, and the only way seems the already tried 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? Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC over BLE experiences and questions
Am 04.07.2017 um 17:47 schrieb Matthias Heinrichs: Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00 additional bytes)??! Ok, I should better have looked in our documentation before sending the last mail. Sorry for that. The first bytes in your log are the "small header" as documented: :cf:46:00 (Profile length in bytes) :02 (Sampling rate) :07 (Amount of divisors) :00:02:06 :01:02:06 :02:01:0c :03:09:02 :04:0f:0c :05:02:0c :06:00:00 (7 divisors with ppO2 data) First real samples: :91:01:00 -> 401mbar depth :dc:01:09:00:00:00:00:00:00:00:00:00 -> 476mbar depth + (empty) Sensor data :12:02:00 -> 530mbar depth :44:02:09:00:00:00:00:00:00:00:00:00 -> 580mbar depth + (empty) Sensor data :63:02:00 -> 611mbar depth and so on. All fine sample data. It basically stops transmitting in packet #395 for no known reason. Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC over BLE experiences and questions
Am 04.07.2017 um 17:53 schrieb Jan Mulder: Not sure it is relevant ... dive is made with the OSTC3 in fixed setpoint CCR mode. Going to look at your code tonight. Not relevant. After the final 0xFB, 0xFB comes the first depths sample. And this is wrong already (Well, at least in your Wireshark log) One thing that's interesting (And Jef, didn't we had a bug/incompatibility with this some months ago?) .cf:46:00 (Which I thought is your first sample) is the number of bytes for the profile (See header). The famous, non-documented feature in our profile data which I promised to describe in the documentation months ago... Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC over BLE experiences and questions
Hi Jan, Am 04.07.2017 um 15:23 schrieb Jan Mulder: BT snoop file (made with btmon) is attached. Wireshark is your friend :-) The funny stuff happens between Packet #365 and #366 (most likely). Until then, the header (first 256byte) looks quite perfect (A dive from the 2nd July 2017 to 3082mbar max depth, 57min and 26seconds). It's properly closed with the 0xFB, 0xFB at the end. Then the first depth sample: 0xcf:0x46:0x00 -> 18127mbar depth (+0x00 additional bytes)??! Second sample is just as wrong: 0x02:0x90:0x03:... -> 36866mbar depth (+0x03 additional bytes which are non-sense on their own like a manual gas change within the first two seconds PLUS a normal gas change). I checked my code and I can't see any difference between sending the header bytes and the profile bytes. Look for "comm_send_dive1:" in https://bitbucket.org/heinrichsweikamp/hwos_code/src/7db10ebae205ebb391cb15fe613a3d8301b87cba/src/comm.asm?at=default&fileviewer=file-view-default Hmm... Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: OSTC over BLE experiences and questions
Hi Jan,
Am 04.07.2017 um 14:02 schrieb Jan Mulder:
So, far so good. All this data is correctly received and processed on
the Subsurface/libdc side.
- 0x66: send one dive including profile, for index 0x86
This results in correct reception of the header (256 bytes), followed by
some samples (in total 624 bytes) so a very small fraction of the
selected approx 1 hour dive, that results in approx 20kb).
And then is just stops, until a timeout is hit. No bluez errors (testing
this on Arch Linux, with bluez BT stack), no weird packets in the
snooped BT traffic (file available for analysis if needed), noting
relevant in the journal/systemd logging, no kernel messages).
So it seems that the OSTC3 just stops sending. So my question for
Matthias ... any idea what is going on here?
Do you get the ending 0x4D Byte as the last byte? Then it's possible
that the dive isn't stored correctly ("Internal pointer to the begin of
the profile data" and "Internal pointer to the end of the profile data"
are not correct). The OSTC uses the Bluetooth modules hardware handshake
lines to avoid overfilling the internal buffer but that does not skip
any bytes. I can't see a way that the OSTC just stops sending data
without being stuck completely (Timeout can only happen in the Bluetooth
idle loop) afterwards.
Please email me the raw data and I'll have a look here.
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs, Christian Weikamp
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: BLE download from Heinrichs Weikamp dive computers
Hi all and sorry for the late reply here,
Am 29.06.2017 um 16:37 schrieb Dirk Hohndel:
On Thu, Jun 29, 2017 at 02:19:25PM +0200, Jan Mulder wrote:
basically sure that the service fefb... is the right one. In the code in
master this one is discarded as standard, but by using this anyway I am able
to get the OSTC3 in download mode. I did not succeed up to now to receive
data from the OSTC3, so obviously, the parsing fails right at the start.
If the OSTC showed "Download mode enabled" you successfully transmitted
the initial byte to the OSTC (0xBB) and you should get a 0xBB (command
echo) and a 0x4D "("Ready") back. Try a 0x6D next, the OSTC will respond
with a 0x6D (echo) and 4096bytes of dive log headers.
Matthias, can you confirm that fefb--1000-8000-00805f9b34fb is the
UUID we should be connecting to? Is this a fixed UUID or does it ever
change? Any special tricks we need to get data back from the dive
computer?
It's the same for all computers and that's what I found looking into all
the documentation we have:
UUID: 0xFEFB
This is the TerminalIO GATT service containing all TerminalIO
characteristics
UART Data TX Characteristic:
UUID: 0002--1000-8000-00802500
Type: uint8 array (20 bytes)
Properties: Notify
The TerminalIO client uses the UART Data TX characteristic to receive
UART data from the server (peripheral) via notifications.
UART Data RX Characteristic:
UUID: 0001--1000-8000-00802500
Type: uint8 array (20 bytes)
Properties: Write without response
The TerminalIO client uses the UART Data RX characteristic to write UART
data to the server (peripheral).
UART Credits TX Characteristic:
UUID: 0004--1000-8000-00802500
Type: uint8 (1 byte)
Properties: Indicate
The TerminalIO client uses the UART Credits TX characteristic to receive
UART credits (0 - 255) from the server (peripheral) via indications.
UART Credits RX Characteristic
UUID: 0003--1000-8000-00802500
Type: uint8 (1 byte)
Properties: Write
The TerminalIO client uses the UART Credits RX characteristic to grant
UART credits (0 - 255) to the server (peripheral).
So pretty much the same what you found out already.
I looked around for any dive log software for the OSTC family, but I get the
impression that Subsurface is leading here, so no BLE capable stuff found
that can act as a reference.
"Divemate" works via BLE but the code is no open source, unfortunately.
Also a question to Matthias - what software is the reference for BLE
downloads?
BLE to PC/MAC? None. BLE to iOS or Android: Divemate.
We also have some documents for Android and iOS implementation:
http://www.heinrichsweikamp.net/downloads/TerminalIO_V2_Android_SampleAndDocumentation_r03.zip
http://www.heinrichsweikamp.net/downloads/TerminalIO_V2_iOS_SampleAndDocumentation_V3_0.ZIP
We got these in 2015, so not sure how useful they are...
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs, Christian Weikamp
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH 3/3] Notify Ostc 4 users about new firmwares
Hi Dirk,
Am 29.12.2016 um 07:36 schrieb Dirk Hohndel:
I don't have an OSTC 4, sadly. Matthias, any chance you could get one to
Anton?
Yes, of course. Anton, please get in touch with us about that :-)
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs, Christian Weikamp
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: 4.5.2
Hi all, Sorry for that, we had to include some minor changes to remove some annoying bugs in our internal logbook. So life doesn't get boring for you ;-) Cheers, Matthias Am 07.11.2015 um 23:05 schrieb Dirk Hohndel: Just a quick heads up. Heinrichs Weikamp surprised us with a firmware change that breaks downloading from their dive computers. It would have been nice had we known this was coming, but it is what it is. I decided to merge Jef's latest updates to libdivecomputer (YAY Jef!!!) into our branch and respin Subsurface as 4.5.2 using the updated libdivecomputer. I'll also use this opportunity to make a first AppImage available - let's see if people are interested in this. Most binaries are ready, I'll announce this shortly on our website, FB, G+, etc. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Bluetooth
Am 19.09.2015 um 01:48 schrieb Dirk Hohndel: On Sep 18, 2015, at 2:38 PM, Guido Lerch wrote: My OSTC 3 does not have blue tooth does it ? I believe only the newest models from Heinrichs & Weikamp support Bluetooth. Matthias? If the OSTC3 has USB it has no Bluetooth, "OSTC3" with Bluetooth have dual mode Bluetooth (2.0 and 4.0). All "OSTC2" (With Qi wireless charging and the hwOS firmware) have 2.0 and 4.0 Bluetooth. "OSTC Sport" with red buttons have 2.0 Bluetooth only, "OSTC sport" with black buttons have the 2.0 and 4.0 Bluetooth as well. Cheers, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [GSoC] Week 6 (Native Bluetooth support)
When I manage to connect to the OSTC 2 device and to initiate the data transfer I get the same result. It gets stuck somewhere in the middle. The libdivecomputer back-end initiate a read request for a 1024 buffer and can read only 923 bytes from device's buffer. I will let you know if the new firmware fixes this problem. That is definitely we need to work on with Matthias. I got sidetracked (I simply work on too many things - I need more areas where others take over and I don't need to worry about them) and never spent the time to really figure out what was broken. That's a known issue of the 1.80. Update to 1.81 and this will be fixed automatically. Regards, Matthias ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
