Freaky dive logs

[gobbledegeek]

Folks,

Reviewing the dive logs from my Hollis DG03 just now, I came across these two freaky dive logs. The pictures tell their own tale so I wont elaborate in words.

In brief: I have never dived beyond 40m but one dive shows 74, another dive log is at 2.6m consistently.

screenshots and dive logs attached.

G

Incidental Notes:

1. Battery was replaced last month.  but other dive logs seem ok.

2. I first reported a problem with an Oceanic wireless air transmitter and the DG03 to Hollis Support many years back - the air pressure dropped to zero on a dive  and flipped between 220bar to zero  multiple times. (not this dive in the log). A year later Hollis posted a recall notice for this DC model citing the issue with wireless air transmitters only. I coontinue to use this DC but without my air transmitter.

[JB2Cool]

That first dive of yours looks like it's actually 31 dives all merged together, each with just 2 or 3 minutes interval. Do these dives show up on the dive computer too? If so then it's more of a dive computer issue than a Subsurface issue. If Subsurface is receiving junk from the dive computer then you'll end up seeing junk inside Subsurface.

JB

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/623100a2-6bab-419a-b4b2-b0f0cb77e668%40googlegroups.com.

[gobbledegeek]

On Monday, September 2, 2019 at 5:44:44 PM UTC+5:30, JB2Cool wrote:

That first dive of yours looks like it's actually 31 dives all merged together, each with just 2 or 3 minutes interval. Do these dives show up on the dive computer too? If so then it's more of a dive computer issue than a Subsurface issue. If Subsurface is receiving junk from the dive computer then you'll end up seeing junk inside Subsurface.

JB

I have currently 19 dives in my DC - the 74m dive is the 1st one from Oct 2017 then 5 good dive logs then the bad 2.6m dive as dive number 7 from Oct 2017. My DC had a dead battery and I did not dive until August 2019 when I replaced the battery. Rest of the new dives from 2019 are good.

I guess  we cant debug the DC really so ... I just wanted to be sure this is not a data transfer problem.

Thanks for taking a look.

G

[gobbledegeek]

I have currently 19 dives in my DC - the 74m dive is the 1st one from Oct 2017 then 5 good dive logs then the bad 2.6m dive as dive number 7 from Oct 2017.

Correction : I currently have 12 dives on my DC from 2019 viewable with extra info  and the but when I force download all dives, 19 are downloaded with 1st and 7th the bad ones I posted.

G

[Grey Wolf]

could it be, that the 74m-dive is the first dive, logged before you bought the DC?

than it is a test-dive of the manufacturer......

martin

--

You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/0ba09c06-f162-4a1d-ac37-a67c87846ace%40googlegroups.com.

[gobbledegeek]

On Monday, September 2, 2019 at 8:08:48 PM UTC+5:30, Grey Wolf wrote:

could it be, that the 74m-dive is the first dive, logged before you bought the DC?

than it is a test-dive of the manufacturer......

martin

Hello Martin

No This DC is about  127 dives old. I had plenty of dives successfully uploaded before 2017 as  well ..

G

[Linus Torvalds]

On Mon, Sep 2, 2019 at 7:55 AM gobbledegeek <gobble...@gmail.com> wrote:
>
> No This DC is about 127 dives old. I had plenty of dives successfully uploaded before 2017 as well ..

So it is possible that this is some parse error for libdivecomputer,
and it would be a good idea to send Jef a full dump of the dive
computer data. The

So if you download a full libdivecomputer dump and describe the issue
and send it to

Jef Driesen <j...@libdivecomputer.org>

he might be able to find something interesting.

That said, I do suspect this may just be an effect of the battery change.

The odd up-and-down noisy dive does look like "30+ dives
re-interpreted as one single dive", and that could be due to some
corruption in the dive metadata - or possibly in the libdivecomputer
parsing of it - and is what maybe Jef would possibly be able to figure
out.

That is presumably some of your old dives, with garbage in between the
dives then interpreted as bogus depths (and thus the odd red spikes).

The other 3-hour dive to 2.6m honestly looks like a test dive to me.
Just the shape of the profile - smoot transition to 2.6, staying
there, and smooth transition back up (until the DG03 decides it's
shallow enough to cut it off as a surface event), and the total
duration of pretty much almost exactly 3h, makes me think "somebody
had it in a test chamber/pool after battery change".

Did you send out the dive computer for the battery change?

The odd 30+ dives mess could be due to some reset procedure at the
same time that libdivecomputer isn't aware of and then misparses the
old data due to that.

It sounds like all the dives after the battery change look good, and I
_suspect_ that you can just ignore the two odd dives, but maybe Jef is
interested.

(That said, the fact that the DG03 is an old dive computer that isn't
even sold any more might make Jef less than enthusiastic at looking at
some odd dump. I'm cc'ing him here as a heads-up in case he doesn't
follow the google group discussions, so that it doesn't take him
entirely by surprise if you send him a dump out of the blue)

Linus

[Gobbledegeek]

Hello Jef,

Hope you can take a peek into the attached bin file from one of my transfer attempts earlier and debug this?

On Mon, Sep 2, 2019 at 10:19 PM Linus Torvalds <torv...@linux-foundation.org> wrote:

So it is possible that this is some parse error for libdivecomputer,
and it would be a good idea to send Jef a full dump of the dive
computer data.

Attaching the bin file ss2bin with Jef CC'ed ...

 

The other 3-hour dive to 2.6m honestly looks like a test dive to me.
Just the shape of the profile - smoot transition to 2.6, staying
there, and smooth transition back up (until the DG03 decides it's
shallow enough to cut it off as a surface event), and the total
duration of pretty much almost exactly 3h, makes me think "somebody
had it in a test chamber/pool after battery change".

Bingo! As a matter of fact - I now recall that I went to dive shop in Bali to change the batteries and while I was making other purchases  there was this tabletop glass chamber filled with water and a DC inside it - clearly a pressure device to test for leakages after reassembling the DC.  The date for this 2.6m dive is 25th Oct 2017 -  I  would have reset the data/time to Indonesia local only after the battery change so it looks like the timestamp when the battery died was preserved! Only anomaly  -  it was definitely not in the test chamber for  3h although I did not specifically look and track the time (I spent many hours in the dive shop that day) . I am sure my DC would have been placed in it for at least 15-20mins while I was busy interacting with the sales rep over other purchases.

 

(That said, the fact that the DG03 is an old dive computer that isn't
even sold any more might make Jef less than enthusiastic at looking at
some odd dump. I'm cc'ing him here as a heads-up in case he doesn't
follow the google group discussions, so that it doesn't take him
entirely by surprise if you send him a dump out of the blue)

                 Linus

I went in to this shop with little hopes of finding a replacement for a broken wrist strap for this old DC.  And  I was all set to spend $$$ on a new DC with a tinge of regret at the anticipated expense. To my pleasant surprise there is a remake/rebranded version of this DC under the brandname Beauchat - only physical difference being the buttons are covered over with a tough rubber shroud in the new model while   mine are shiny steel/metal rounds as seen in the pic on the other thread I opened (everything else same same including screen layout and engraved graphics, not sure of air integration - the reason DG03 was recalled and my conversation with the sales guy veered off even as I was inquiring further). And so the replacement strap for the Beauchat was a perfect fit on my DG03  and together with the battery replacement and removal of  a badly scratched plastic screen guard I had  a DC as good and shiny as new yay! (oddly google search is not throwing up the model that is an exact remake/copy now - I didn't note the model number then).

So it is possible there are newer DC rebranded with the same internals as the DG03 that makes this more relevant to current times. But let Jef take a call on that. I will post a note on the exact model/part number from Beuchat for the record - once I locate it.

--

--G0bbleDeGeek

[Jef Driesen]

On 2019-09-03 17:07, Gobbledegeek wrote:
> Hope you can take a peek into the attached bin file from one of my
> transfer
> attempts earlier and debug this?

Sure. Doesn't matter for me whether it's an old model or not :-)

Anyway, I think your device has indeed been reset somehow. If I extract
all the ringbuffer pointers, I get this:

pointers: rb_logbook_first=0240, rb_logbook_last=02d0
pointers: rb_profile_first=0a40, rb_profile_last=4e40

logbook: idx=0, address=0240, rb_entry_first=92d0, rb_entry_last=0c80 <-
Oldest dive
logbook: idx=1, address=0248, rb_entry_first=0c90, rb_entry_last=0fb0
logbook: idx=2, address=0250, rb_entry_first=0fc0, rb_entry_last=1280
logbook: idx=3, address=0258, rb_entry_first=1290, rb_entry_last=1610
logbook: idx=4, address=0260, rb_entry_first=1620, rb_entry_last=1980
logbook: idx=5, address=0268, rb_entry_first=1990, rb_entry_last=1d00
logbook: idx=6, address=0270, rb_entry_first=1d10, rb_entry_last=28b0
logbook: idx=7, address=0278, rb_entry_first=28c0, rb_entry_last=2c80
logbook: idx=8, address=0280, rb_entry_first=2c90, rb_entry_last=3030
logbook: idx=9, address=0288, rb_entry_first=3040, rb_entry_last=33b0
logbook: idx=10, address=0290, rb_entry_first=33c0, rb_entry_last=3700
logbook: idx=11, address=0298, rb_entry_first=3710, rb_entry_last=3ab0
logbook: idx=12, address=02a0, rb_entry_first=3ac0, rb_entry_last=3d50
logbook: idx=13, address=02a8, rb_entry_first=3d60, rb_entry_last=40e0
logbook: idx=14, address=02b0, rb_entry_first=40f0, rb_entry_last=4310
logbook: idx=15, address=02b8, rb_entry_first=4320, rb_entry_last=4680
logbook: idx=16, address=02c0, rb_entry_first=4690, rb_entry_last=48a0
logbook: idx=17, address=02c8, rb_entry_first=48b0, rb_entry_last=4bc0
logbook: idx=18, address=02d0, rb_entry_first=4bd0, rb_entry_last=4e40
<- Most recent dive
logbook: idx=19, address=02d8, rb_entry_first=f1e0, rb_entry_last=2b70
logbook: idx=20, address=02e0, rb_entry_first=2b80, rb_entry_last=5990
logbook: idx=21, address=02e8, rb_entry_first=59a0, rb_entry_last=9400
logbook: idx=22, address=02f0, rb_entry_first=9410, rb_entry_last=b4e0
logbook: idx=23, address=02f8, rb_entry_first=b4f0, rb_entry_last=e2f0
logbook: idx=24, address=0300, rb_entry_first=e300, rb_entry_last=1ad0
logbook: idx=25, address=0308, rb_entry_first=1ae0, rb_entry_last=4e80
logbook: idx=26, address=0310, rb_entry_first=4e90, rb_entry_last=7a60
logbook: idx=27, address=0318, rb_entry_first=7a70, rb_entry_last=a8d0
logbook: idx=28, address=0320, rb_entry_first=a8e0, rb_entry_last=de00
logbook: idx=29, address=0328, rb_entry_first=de10, rb_entry_last=0d20
logbook: idx=30, address=0330, rb_entry_first=0d30, rb_entry_last=3d90
logbook: idx=31, address=0338, rb_entry_first=3da0, rb_entry_last=6aa0
logbook: idx=32, address=0340, rb_entry_first=6ab0, rb_entry_last=6c60
logbook: idx=33, address=0348, rb_entry_first=6c70, rb_entry_last=6df0
logbook: idx=34, address=0350, rb_entry_first=6e00, rb_entry_last=7000
logbook: idx=35, address=0358, rb_entry_first=7010, rb_entry_last=7240
logbook: idx=36, address=0360, rb_entry_first=7250, rb_entry_last=7430
logbook: idx=37, address=0368, rb_entry_first=7440, rb_entry_last=7620
logbook: idx=38, address=0370, rb_entry_first=7630, rb_entry_last=7820
logbook: idx=39, address=0378, rb_entry_first=7830, rb_entry_last=7bf0
logbook: idx=40, address=0380, rb_entry_first=7c00, rb_entry_last=7f80
logbook: idx=41, address=0388, rb_entry_first=7f90, rb_entry_last=8260
logbook: idx=42, address=0390, rb_entry_first=8270, rb_entry_last=8630
logbook: idx=43, address=0398, rb_entry_first=8640, rb_entry_last=8950
logbook: idx=44, address=03a0, rb_entry_first=8960, rb_entry_last=8d30
logbook: idx=45, address=03a8, rb_entry_first=8d40, rb_entry_last=9020
logbook: idx=46, address=03b0, rb_entry_first=9030, rb_entry_last=9360
logbook: idx=47, address=03b8, rb_entry_first=9370, rb_entry_last=9730
logbook: idx=48, address=03c0, rb_entry_first=0020, rb_entry_last=3000
logbook: idx=49, address=03c8, rb_entry_first=0020, rb_entry_last=3000
logbook: idx=50, address=03d0, rb_entry_first=9f60, rb_entry_last=a310
logbook: idx=51, address=03d8, rb_entry_first=a320, rb_entry_last=a680
logbook: idx=52, address=03e0, rb_entry_first=a690, rb_entry_last=aa10
logbook: idx=53, address=03e8, rb_entry_first=aa20, rb_entry_last=ae40
logbook: idx=54, address=03f0, rb_entry_first=ae50, rb_entry_last=b1a0
logbook: idx=55, address=03f8, rb_entry_first=b1b0, rb_entry_last=b520
logbook: idx=56, address=0400, rb_entry_first=b530, rb_entry_last=b780
logbook: idx=57, address=0408, rb_entry_first=b790, rb_entry_last=b9c0
logbook: idx=58, address=0410, rb_entry_first=b9d0, rb_entry_last=bbf0
logbook: idx=59, address=0418, rb_entry_first=bc00, rb_entry_last=beb0
logbook: idx=60, address=0420, rb_entry_first=bec0, rb_entry_last=c1a0
logbook: idx=61, address=0428, rb_entry_first=c1b0, rb_entry_last=c550
logbook: idx=62, address=0430, rb_entry_first=c560, rb_entry_last=c8d0
logbook: idx=63, address=0438, rb_entry_first=c8e0, rb_entry_last=cc50
logbook: idx=64, address=0440, rb_entry_first=cc60, rb_entry_last=cf50
logbook: idx=65, address=0448, rb_entry_first=cf60, rb_entry_last=d2d0
logbook: idx=66, address=0450, rb_entry_first=d2e0, rb_entry_last=d620
logbook: idx=67, address=0458, rb_entry_first=d630, rb_entry_last=d960
logbook: idx=68, address=0460, rb_entry_first=d970, rb_entry_last=dc10
logbook: idx=69, address=0468, rb_entry_first=dc20, rb_entry_last=df70
logbook: idx=70, address=0470, rb_entry_first=df80, rb_entry_last=e250
logbook: idx=71, address=0478, rb_entry_first=e260, rb_entry_last=e5a0
logbook: idx=72, address=0480, rb_entry_first=e5b0, rb_entry_last=e8b0
logbook: idx=73, address=0488, rb_entry_first=e8c0, rb_entry_last=ec30
logbook: idx=74, address=0490, rb_entry_first=ec40, rb_entry_last=f040
logbook: idx=75, address=0498, rb_entry_first=f050, rb_entry_last=f470
logbook: idx=76, address=04a0, rb_entry_first=f480, rb_entry_last=f7e0
logbook: idx=77, address=04a8, rb_entry_first=f7f0, rb_entry_last=fba0
logbook: idx=78, address=04b0, rb_entry_first=fbb0, rb_entry_last=ff30
logbook: idx=79, address=04b8, rb_entry_first=ff40, rb_entry_last=0c30
logbook: idx=80, address=04c0, rb_entry_first=0c40, rb_entry_last=0ce0
logbook: idx=81, address=04c8, rb_entry_first=0cf0, rb_entry_last=0f40
logbook: idx=82, address=04d0, rb_entry_first=0f50, rb_entry_last=1290
logbook: idx=83, address=04d8, rb_entry_first=12a0, rb_entry_last=27d0
logbook: idx=84, address=04e0, rb_entry_first=27e0, rb_entry_last=2a90
logbook: idx=85, address=04e8, rb_entry_first=2aa0, rb_entry_last=2e00
logbook: idx=86, address=04f0, rb_entry_first=2e10, rb_entry_last=3170
logbook: idx=87, address=04f8, rb_entry_first=3180, rb_entry_last=33f0
logbook: idx=88, address=0500, rb_entry_first=3400, rb_entry_last=3700
logbook: idx=89, address=0508, rb_entry_first=3710, rb_entry_last=39e0
logbook: idx=90, address=0510, rb_entry_first=39f0, rb_entry_last=3b60
logbook: idx=91, address=0518, rb_entry_first=3b70, rb_entry_last=3f90
logbook: idx=92, address=0520, rb_entry_first=3fa0, rb_entry_last=42e0
logbook: idx=93, address=0528, rb_entry_first=42f0, rb_entry_last=4610
logbook: idx=94, address=0530, rb_entry_first=4620, rb_entry_last=4740
logbook: idx=95, address=0538, rb_entry_first=4750, rb_entry_last=4ad0
logbook: idx=96, address=0540, rb_entry_first=4ae0, rb_entry_last=4e20
logbook: idx=97, address=0548, rb_entry_first=4e30, rb_entry_last=5260
logbook: idx=98, address=0550, rb_entry_first=5270, rb_entry_last=5620
logbook: idx=99, address=0558, rb_entry_first=5630, rb_entry_last=59e0
logbook: idx=100, address=0560, rb_entry_first=76c0, rb_entry_last=7920
logbook: idx=101, address=0568, rb_entry_first=7930, rb_entry_last=7b00
logbook: idx=102, address=0570, rb_entry_first=7b10, rb_entry_last=7d10
logbook: idx=103, address=0578, rb_entry_first=7d20, rb_entry_last=8000
logbook: idx=104, address=0580, rb_entry_first=8010, rb_entry_last=8430
logbook: idx=105, address=0588, rb_entry_first=8440, rb_entry_last=8850
logbook: idx=106, address=0590, rb_entry_first=8860, rb_entry_last=8c20
logbook: idx=107, address=0598, rb_entry_first=8c30, rb_entry_last=8fa0
logbook: idx=108, address=05a0, rb_entry_first=8fb0, rb_entry_last=92c0
<- Last valid entry
logbook: idx=109, address=05a8, rb_entry_first=fff0, rb_entry_last=fff0
...
logbook: idx=255, address=0a38, rb_entry_first=fff0, rb_entry_last=fff0

At first sight, this looks perfectly normal, because all the pointer
pairs are nicely consecutive. But there are a few anomalies as well:

The last valid entry is #108, which means there is plenty of space left
for extra entries. Yet, the newest dives (#0 to #18) are not located at
the end, but at the start of the ringbuffer!

If you look closer at entry #108, its last address (0x92c0) jumps
perfectly to the first address (0x92d0) of entry #0.

So it looks like after dive #108, instead of continuing at entry #109
the dive computer jumped back to entry #0. And somehow it kept that
profile pointer (0x92d0), but actually started writing at the start of
the profile ringbuffer (0x0a40). So you end up with a dive that is much
larger than it should be, because that begin pointer is wrong.


In theory this can easily be fixed by updating entry #0 with the correct
first pointer. I can provide the instructions on how to do that if you
want. But you can also just ignore that particular dive. Once you have
enough dives it will get overwritten anyway.

Jef

[gobbledegeek]

On Wednesday, September 4, 2019 at 2:35:50 PM UTC+5:30, Jef Driesen wrote:

In theory this can easily be fixed by updating entry #0 with the correct
first pointer. I can provide the instructions on how to do that if you
want. But you can also just ignore that particular dive. Once you have
enough dives it will get overwritten anyway.

 

Hi Jef

Will this help me recover all the other 100+ dives accurately? Right now the import is only adding 19 dives with the two broken dives included.

If yes I would appreciate a fix and instructions from your side. My data backup habits are unfortunately like my car/house key habits - I can never remember where I left my stuff last and never find what I need, when I need it urgently.  In other words I do recall importing 100+ dives a few years back but cant recall where or if I  (ever) backed it up. :)

Thanks!

G

[Jef Driesen]

On 2019-09-05 09:07, gobbledegeek wrote:
> On Wednesday, September 4, 2019 at 2:35:50 PM UTC+5:30, Jef Driesen
> wrote:
>> In theory this can easily be fixed by updating entry #0 with the
>> correct
>> first pointer. I can provide the instructions on how to do that if you
>> want. But you can also just ignore that particular dive. Once you have
>> enough dives it will get overwritten anyway.
>

> Will this help me recover all the other 100+ dives accurately? Right
> now
> the import is only adding 19 dives with the two broken dives included.
> If yes I would appreciate a fix and instructions from your side. My
> data
> backup habits are unfortunately like my car/house key habits - I can
> never
> remember where I left my stuff last and never find what I need, when I
> need
> it urgently. In other words I do recall importing 100+ dives a few
> years
> back but cant recall where or if I (ever) backed it up. :)

No, you won't be able to recover those older dives. Although some of the
logbook entries are still present, their profile data has already been
overwritten. The logbook can store 256 dives (containing only the
date/time), but the profile area is much more limited. Fixing the
pointer would just fixup that one particular dive. You certainly won't
get more dives.

I may be able to manually extract dives #98 to #108, but all others are
certainly lost.

Jef