Hi Anton, i'm on the phone, so expect every kind of sintax errors.
El 12/07/2015 20:53, Salvador Cuñat salvador.cu...@gmail.com escribió:
Looks like the first byte is a version(?) marker to. 0x64 in the old
files in dives/ and 0x65 in the ones posted on the forum.
Yes it's correct,
Hi Anton,
2015-07-10 0:48 GMT+02:00, Anton Lundin gla...@acc.umu.se:
Looks like the first byte is a version(?) marker to. 0x64 in the old
files in dives/ and 0x65 in the ones posted on the forum.
Yes it's correct, but this byte doesn't seem to be related to the
software tool but to the data
On 10 July, 2015 - Salvador Cuñat wrote:
Hi Anton.
2015-07-09 0:13 GMT+02:00 Anton Lundin gla...@acc.umu.se:
On 26 April, 2015 - Anton Lundin wrote:
On 03 April, 2015 - Anton Lundin wrote:
Anyhow. I'm out of ideas on how to produce some data to try to import.
After my
Hi Anton.
2015-07-09 0:13 GMT+02:00 Anton Lundin gla...@acc.umu.se:
On 26 April, 2015 - Anton Lundin wrote:
On 03 April, 2015 - Anton Lundin wrote:
Anyhow. I'm out of ideas on how to produce some data to try to import.
After my experience with OSTCProfile, i don't think any users will
On 26 April, 2015 - Anton Lundin wrote:
On 03 April, 2015 - Anton Lundin wrote:
Anyhow. I'm out of ideas on how to produce some data to try to import.
After my experience with OSTCProfile, i don't think any users will have
data they would like to import either.
Something have changed in
On 03 April, 2015 - Anton Lundin wrote:
On 30 March, 2015 - Anton Lundin wrote:
On 29 March, 2015 - Salvador Cuñat wrote:
/snip
All OSTCTools .dive files I could achieve are OSTC-2N/C series. It would
be great to have some testing for logs from OSTC3, FROG or SPORT
On 2015-04-02 18:29, Dirk Hohndel wrote:
On Sun, Mar 29, 2015 at 08:46:29PM +0200, Salvador Cuñat wrote:
+
+/*
+ * Parse data buffers instead of dc devices downloaded data.
+ * Intended to be used to parse profile data from binary files during
import tasks.
+ * Actually included Uwatec
2015-04-03 9:13 GMT+02:00 Jef Driesen j...@libdivecomputer.org:
The dc_parser_new() function requires a valid device handle. In this
offline parsing scenario, you don't have that. That's a shortcoming which
is already on my todo list:
The dive callback of the dc_device_foreach() function
Good morning Dirk.
2015-04-02 18:18 GMT+02:00 Dirk Hohndel d...@hohndel.org:
+ dc_datetime_t datetime = { 0 };
so you renamed dt to datetime - nothing wrong with that, but it makes the
patch more verbose and harder to see what's new, what's just renaming...
- rc =
Good morning, again, ;-)
2015-04-02 18:29 GMT+02:00 Dirk Hohndel d...@hohndel.org:
I think that we'll end up using something like this when doing the BT
device communication in Subsurface. So this should be done in a generic
way that allows us to take a buffer and hand it off to the correct
On 30 March, 2015 - Anton Lundin wrote:
On 29 March, 2015 - Salvador Cuñat wrote:
/snip
All OSTCTools .dive files I could achieve are OSTC-2N/C series. It would
be great to have some testing for logs from OSTC3, FROG or SPORT devices.
Anton, Could you provide some .dive file from
On Sun, Mar 29, 2015 at 08:46:29PM +0200, Salvador Cuñat wrote:
Add function libdc_buffer_parser() intended to parse raw data buffers
prepared for libdivecomputer. We have to commit elsewhere the
necesary assembly tasks to achieve consistent data.
Actually only OSTCTools import makes use
On 29 March, 2015 - Salvador Cuñat wrote:
/snip
All OSTCTools .dive files I could achieve are OSTC-2N/C series. It would
be great to have some testing for logs from OSTC3, FROG or SPORT devices.
Anton, Could you provide some .dive file from your OSTC3?
I've managed to get
Back in October/November, some users asked for support to import logs from
OSTCTools software, both in this mailing list and in the user forum.
The logs I've seen (those provided by a user in the the forum and my own
dives) happen to be very simple, just a few data heavily zero padded and
then
14 matches
Mail list logo
