search

InfiniTimeOrg / InfiniTime

Firmware for Pinetime smartwatch written in C++ and based on FreeRTOS
GNU General Public License v3.0
2.75k stars 941 forks source link

Watch does not automatically reconnect to GadgetBridge after turning airplane mode on and off #302

Closed GithubUser5462 closed 2 years ago

GithubUser5462 commented 3 years ago

InfiniTime version: 1.0.0 RC3 Gadgetbridge version: 0.56.1

Steps to reproduce:

  1. Pair InfiniTime with Gadgetbridge, enable the "Reconnect automatically" setting in GB
  2. While the two are connected turn airplane mode on and then off after the watch is disconnected
  3. GB tries to reconnect, first with status "Connecting" and then gets stuck with "Waiting for reconnect"

The workaround I have found is to fully disconnect in GB - status "Not connected" and then pair the watch again. Restarting the watch or Gadgetbridge did not seem to help.

I don't know if the problem is with GB or IT but it would be nice if the two could automatically reconnect in this scenario if possible.

petterhs commented 3 years ago

hmm I'm not able to reproduce this issue running same versions. Do you experience the same if you toggle Bluetooth off/on on the phone?

GithubUser5462 commented 3 years ago

Yes, exact same result. If it works for you I guess the problem could be with the phone or the watch. I'll try with another phone.

JF002 commented 3 years ago

This kind of issue is really hard to debug, and is probably caused by a mix of PineTime HW, InfiniTime, phone HW and software stack. InfiniTime does advertise itself automatically as soon as it's disconnected during 3 minutes. It also restarts advertisting every time the display is switched on. Then, it's up to the companion app to receive these advertising messages and reconnect to the watch.

pfeerick commented 3 years ago

Not knowing that behaviour is most likely the 'cause' of the problem... i.e. I would probably have had a similar complaint if I didn't know that turning the screen on wakes up advertising. But only the OP can answer that question.

InfiniTime does advertise itself automatically as soon as it's disconnected during 3 minutes. It also restarts advertisting every time the display is switched on. Then, it's up to the companion app to receive these advertising messages and reconnect to the watch.

Maybe a future thought could be have periodic advertising... say once every five minutes or so, for 10 seconds or whatever (I'm sure there's some convention that can be followed - or not!) ... i.e. try and make itself available if the phone wants to reconnect.

GithubUser5462 commented 3 years ago

I made a couple more tries to try to understand what is happening. It seems that it is not limited to Gadgetbridge since it also happens with nRF Connect.

In nRF Connect when I disable/enable bt the "bonded" tab in nRF Connect gets wiped, but the scanner does detect watch - as not bonded. If i try to manually connect sometimes it connects, but most of the time it timeouts/errors - logger says Error 133 (0x85) GATT ERROR. Which is probably not very helpful.

pfeerick commented 3 years ago

Whether the device is bonded or not has no impact on the device appearing in the scanner tab. It is merely a list of all the devices which are currently advertising, with greyed out entries for those devices that have recently advertise, but not presently advertising (Bluetooth advertising of presence). Disabling and enabling bluetooth should also not lose bonding or pairing... that suggests there is something wrong with your configuration.

Can you try this... Start a scan (in NRF Connect), wait for a few seconds and confirm the InfiniTime is not active. Then whilst NRF Connect is still scanning, press the button on the pinetime momentarily so the screen comes on. Does it show up then? If so, it is working as intended.

On Thu, 22 Apr 2021, 1:27 am github user, @.***> wrote:

I made a couple more tries to try to understand what is happening. It seems that it is not limited to Gadgetbridge since it also happens with nRF Connect.

In nRF Connect when I disable/enable bt the "bonded" tab in nRF Connect gets wiped, but the scanner does detect watch - as not bonded. If i try to manually connect sometimes it connects, but most of the time it timeouts/errors - logger says Error 133 (0x85) GATT ERROR. Which is probably not very helpful.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JF002/InfiniTime/issues/302#issuecomment-824152373, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ66KKSSXGTJEWYYJZ56UDTJ3VFVANCNFSM43III6HQ .

diegosolor commented 3 years ago

I have the same unstable connection problem with gadgetbridge, only workaround is unpair/repair the pinetime

jjrugui commented 3 years ago

I can confirm the same issue with reconnection as @diegosolor . Connections gets lost and some times pinetime does not appear in gadgetbridge. Only solution in that case is to restart the watch.

For reference I'm using a Oneplus Nord with A droid 11. I'm a bit lost with how to debug it but let me know if I can do anything to provide help/info about the reconnection issue.

pfeerick commented 3 years ago

Sometimes I have to tell gadgetbridge to connect twice... I.e. connect, press and hold to disconnect after a few seconds of no activity, and then connect again. With the pinetime screen on to ensure it is actually advertising. If you need to restart the watch, you could be running what seems to be a time-related issue when the bluetooth locks up at somewhere around 20 hours of uptime, and the watch needs restarting.

blaueente commented 3 years ago

Independent of airplane mode: Mine (1.0.0) disconnects sometimes from gadgetbridge, and then does not appear on the nRF scanner, and then can only be reconnected by restarting the pinetime AND re-pairing. This also happened after a very short time, not 20h.

jjrugui commented 3 years ago

I'm having the exact same behaviour as @blaueente . I get multiple disconnects per day and I need to restart the pinetime in order to be able to pair it again.

In gadgetbridge it is not enough to click reconnect since it seems it does not manage to reconnect, so only option is: remove pinetime from gadgetbridge -> restart pinetime -> pair again.

Anyil89 commented 3 years ago

I am on arch Linux arm danct12s Image. I’m using it on my pinephone, when I restart my phone like when I update the Bluetooth says it’s disconnected. But it was connected before the reboot. (my PineTime) But sometimes rarely it will reconnect itself after a while but 80% of the time I have to restart my watch to make it reconnect or disconnect from amazfish and then reset that back up. For it to register.

jjrugui commented 3 years ago

Today I upgraded Gadgetbridge to latest version 0.58.0 and so far I had a way more stable connection and automatic reconnect working. I'll give more info after testing it for a couple days but I highly recommend the upgrade.

NCLI commented 3 years ago

On the latest version of Gadgetbridge. I pretty much have to restart the PineTime every 20 hours to connect, but it does then reconnect immediately after booting back up. Quite annoying, and I often miss calls because it takes a while for me to realize that the connection has dropped.

1989gironimo commented 3 years ago

I can add, that not only activating airplane mode causes this behavior. Disabling bluetooth for a while triggers this issue as well, even on the newest firmware (1.2 at this time) and newest gadgetbridge (0.58.1) on GrapheneOS (RQ3A.210705.001.2021.07.07.19)

I even have to remove it from gadgetbridge first, restart the phone AND the Pinetime to get a working connection, so this might be somewhat related, but not the same issue..

raananelefant commented 3 years ago

I can report that upon Airplane mode on/off, PineTime, running Infinitime FW v1.1.0 w/Hebrew support, cannot reconnect automatically/manually using latest Gadgetbridge (v0.58.2).

Workaround is "disconnecting" watch via GB, re-pairing via Android settings (PineTime disappears from "Previously connected devices") and then connecting via GB.

Phone is a Planet Computer Cosmo Communicator running Android v9, Build number Cosmo-9.0-Planet-02032021-V25, Custom build version alps-mpp-p0.mp1-V5.313

Roterfux commented 3 years ago

Same issue with firmware 1.3.0. Force restarting the watch and deleting the device in GB helps. This is a bad workaround.

aemkai commented 3 years ago

I have the same problem. Watch doesn't reconnect to Gadgetbridge or nRF Connect and also could not be found by BL-Scan of phone. BL-Symbol on watch is off. Cycle Bluetooth connection or reset of phone doesn't help. After reset of watch BL connection is established automatically and without problems with both apps and BL symbol on watch is on. Issue appears @ about 20 hours runtime. Firmware tested with V1.2.0, self compiled V.1.2.0 and self compiled V1.3.0

tealeg commented 3 years ago

Another one here. I just received two PineTime's, the current firmware is v1.2.0. The behaviour is identical on both devices, and with two different Android phones running Gadgetbridge.

My experience is as per #527 - there's no need for airplane mode, or any shenanigans on the phone, at some point, when the watch is idle, it will disconnect and will no longer advertise until a restart is forced. As others have noted, the Bluetooth indication on the watch face disappears, and (naively) I assume the Bluetooth radio has been powered down.

jamesstott commented 3 years ago

Same problem here as well with v1.3.0 an Gadgetbridge.

1989gironimo commented 3 years ago

Another one here. I just received two PineTime's, the current firmware is v1.2.0. The behaviour is identical on both devices, and with two different Android phones running Gadgetbridge.

My experience is as per #527 - there's no need for airplane mode, or any shenanigans on the phone, at some point, when the watch is idle, it will disconnect and will no longer advertise until a restart is forced. As others have noted, the Bluetooth indication on the watch face disappears, and (naively) I assume the Bluetooth radio has been powered down.

The watch also gets disconnected after some time (even if it's connected all the time), as someone described above and doesn't reconnect anymore after approx. 20h.

Well, in my case (I've tested it already several times) it is NOT sufficient just to restart the watch. -> restart the watch -> disable bluetooth or switch on airplane mode -> delete the watch-entry in Gadgetbridge -> re-pair the watch -> disconnect the watch (because it's connected, but it doesn't receive the time for example) -> connect the watch again -> have a connected watch with accurate time and working notifications

EDIT: Tried it without re-pairing and voila, just a restart of the watch is necessary, so I was wrong. (But Gadgetbridge still hangs as described if I try to go this route)

innateessence commented 3 years ago

I just wanted to chime in and say, if I reboot my phone, it won't connect to my pinetime without unpairing and repairing with GadgetBridge. (stuck on waiting for reconnect) I suspect the same will be true if I toggle airplane mode or disable/enable Bluetooth.

PineTime:

Phone:

GadgetBridge:

heinrich-ulbricht commented 3 years ago

Chiming in with the same problem. Received watch, updated firmware from 1.2.0 to 1.3.0, paired with Gadgetbridge, disabled Bluetooth, enabled Bluetooth... no connection anymore.

PineTime:

Phone:

GadgetBridge:

Restarting (resetting?) the watch via button long-press fixed it for the moment. Until I disable and enable Bluetooth again.

(Maybe adding an BT advertisement indicator to the watch UI might help see if it's advertising at all?)

Edit Well, after one night in airplane mode watch and phone don't connect anymore. Restarting the watch does not help this time. This a bummer. I really hope this somehow gets sorted out since the watch is not usable in this state. :(

Edit2 Had a successful reconnect after going out of BT reach for some minutes, coming back and tapping "Reconnect" in GB.

Edit3 Ok everytime I disable+reenable Bluetooth on the phone I have to delete the watch from GB and re-pair it :(

bearclaws8 commented 3 years ago

I can confirm I have the same problem with a new PineTime. Just like @heinrich-ulbricht I received watch, updated firmware from 1.2.0 to 1.3.0, paired with Gadgetbridge, disabled Bluetooth, enabled Bluetooth... no connection anymore.

I have had some better connectivity with nRF Connect compared to GB. GB seems to dislike reconnecting when toggling Bluetooth while nRF will usually reconnect. However, after a while, like noted in issue #527 the PineTime itself will no longer broadcast via BLE.

Might it be that this issue and #527 are connected but due to two different issues, one that GB is a flaky and the other where PineTime stops broadcasting?

Is it possible to add into the settings the ability to turn Bluetooth on/off and force the service to restart without restarting the entire device? On/off may be nice for those looking to maximize battery and security and restarting the BLE broadcast may help with debugging.

Avamander commented 3 years ago

GB seems to dislike reconnecting

It doesn't if the disconnection is too long, primarily because making a new connection itself is very unreliable right now. Once InfiniTime can keep a connection in-range and has working reconnects, Gadgetbridge's auto-reconnection can be dialed up.

bearclaws8 commented 3 years ago

It doesn't if the disconnection is too long, primarily because making a new connection itself is very unreliable right now. Once InfiniTime can keep a connection in-range and has working reconnects, Gadgetbridge's auto-reconnection can be dialed up.

@Avamander thank you for the clarification.

heinrich-ulbricht commented 3 years ago

This issue seems to be a rather complex one due to the number of potentially involved parts (and parties):

Furthermore only some users seem affected. (Otherwise this would have priority over new features? Can we estimate how many users are affected?) So the issue might prove hard to reproduce for those who are capable of analyzing and/or fixing this issue.

From an end user's point of view it's frustrating. The connection between watch and phone is unusable for me. Going out of range sometimes is enough to kill the Bluetooth connection, but I also often go to full flight mode (with Bluetooth disabled) and back. I then have to re-pair, which takes time and after some time I don't bother anymore. I also see that this issue has been known a long time already which gives me the fear it will never be fixed.

From a developer's point of view I'd like to help get this sorted out. I just don't know how and somebody would have to tell me what to do to diagnose this. Reading logs with adb? Can do. Fire up a dev environment? Not so sure. What else?

How is the current state for this issue? Is somebody currently working on it? Can we assume that this will sort itself out with future updates to software and/or hardware?

Back in the Windows Phone times I used to write: I really want this to work. Seems like I'm back again writing: I really, really, reeeeeally want this to work!!

Cuperino commented 3 years ago

My PineTime is having similar issues. It won't reconnect after a few minutes. Nevertheless, existing connections can last for hours. I have not yet checked what's the longest it will last.

Upon resetting I sync to both my laptop, using Siglo, and my stock Android phone, using GadgetBridge, one after the other before the PineTime's screen turns off. After disconnecting, the paired device needs to be removed from GadgetBridge and the PineTime needs to be reset for it to connect to either device.

UPDATE: I managed to re-connect the PineTime with GadgetBridge after two days without pairing. The paired device had to be removed and re-paired to GadgetBridge for it to connect. This was on firmware 1.3.0.

PineTime:

FW: v1.3.0 and v1.2.0
HW: v1.0.0

Phone:

Google Pixel 3a
Android 11 (Build number RQ3A.210705.001)

GadgetBridge:

version: 0.59.0
CompanionDevice pairing: enabled

Laptop:

Dell XPS 13 7390 2-in-1
KDE neon Testing Edition
Linux Kernel 5.11.0-27-lowlatency

Siglo:

version: Flathub stable released on August, 04 2021
Debo-rah commented 3 years ago

The same here. Sometimes it helped to reinstall gadgetbridge, sometimes it helped to reboot the watch. After updating to firmware v.1.3 it seemed a little better, but then I got the same problem as someone mentioned above, that it got stuck at the infinitime logo, even though I DID validate the new fimware.

FW: v1.3.0 and v.1.2.0 HW: v1.0.0

Phone: Google Pixel 2 Android 10 (Lineage 17.1)

GadgetBridge: version: 0.59.0

aemkai commented 3 years ago

I read somewhere, that about 20 hours after booting the connection can't be restored. This fits with the behaviour of my watch. Till 20 hours short or longer breaks on connection (e.q. phone is out of range for several minutes) doesn't matter, the watch reconnects immediatley when in range again. After 20 hours, it doesn't reconnect, even after a short break of only one or two minutes. After a reboot, the watch reconnects immediate and without problems.

Couldn't this problem be solved by an watchdog, which resets the relevant part every 20 hours?

Using Gadgetbridge (tried with 0.58.0 / 0.58.1 / 0.58.2) and Infinitime v1.2.0 and 1.3.0

heinrich-ulbricht commented 3 years ago

@aemkai I read this, too, but this seems like a second problem. For me I 100% can reproduce non-connectivity by disabling+enabling my phone's Bluetooth adapter. No connection afterwards. Fixed by removing+re-adding the watch from Gadgetbridge.

As for reconnecting after being out of range: this seems to work. I fooled myself once or twice when I disabled location services, then went out of Bluetooth range and wondered why it didn't reconnect after coming into range again. Seems like location needs to be enabled for this to succeed.

aemkai commented 3 years ago

@heinrich-ulbricht i can disable and re-enable without problems. The bluetooth icon at the watch also disappears and vice versa. Location is disabled most time without problems. Maybe the issue isn't caused by the watch and should be searched at the app in combination with the OS.

Avamander commented 3 years ago

@aemkai If you look at this current thread then you can see how the issue isn't OS or companion-specific.

aemkai commented 3 years ago

@Avamander Why? Some users say, a restart of watch isn't sufficient. Others must remove the watch from Gadgetbridge and add it again. This doesn't seem to be an issue of the watch (alone). The next point is, why some users have problems, others not. An explanation could be the difference between pre- and self-compiled firmware, but this doesn't mitigate the other points.

Avamander commented 3 years ago

@aemkai I'm not sure what's unclear? The issue exists across multiple OSs and companions (which can also handle other watches great), it's unlikely to be specific to those.

aemkai commented 3 years ago

@Avamander This doesn't explain my considerations. Also I wrote "app in combination with the OS". Not every app has the same behaviour even on different builds of the same OS. Then e.q. energy saving or privacy settings have different behaviours. If OS/companion isn't the issue, why isn't a reset of the watch the solution? For example @Debo-rah wrote, she had to reinstall Gadgetbridge. How should this need be caused by the watch?

Avamander commented 3 years ago

@aemkai

why isn't a reset of the watch the solution?

Because Bluetooth stacks can make assumptions when bonded, that InfiniTime violates.

How should this need be caused by the watch?

It wasn't, the reinstall was very likely unnecessary.

aemkai commented 3 years ago

@Avamander I played arond a little bit with the 2 watches, changed airplane mode, bluetooth dis-/enable, (dis-)bonding etc. and got it (I dont know how exactly) to an point, where a connection to both watches wasn't possible, neither with Gadgetbridge nor with nRF Connect. I reset one watch, no improvement. I reset the phone, and afterwards both watches (also the non-reset) connected without problems. Maybe there is an issue at Pinetime - i won't exclude that - but i think, there is also a problem in interaction of different components, and - in my oppinion - it's to hasty to exclude this also.

tmilburn commented 3 years ago

I get the feeling there is an integer overflow bug somewhere. At a 32768Hz clock rate a 32 bit signed integer overflows after just over 18 hours. I have definitely seen the Bluetooth inactive when checked at 19h30m of uptime and other commenters have mentioned 20 hours.

bearclaws8 commented 3 years ago

@tmilburn could an integer overflow cause other devices to refuse to see/connect to the watch after it is reset? I have noticed that after a few instances of PT dropping Bluetooth, and me restarting the watch, Android will begin to not even see it via Bluetooth without the phone being restarted. Neither OS Bluetooth settings, Gadgetbridge, nor nRF Connect will pick it up. Granted this is likely an Android issue/limitation but wasn't sure if it was a behavior that may indicate something the watch was doing.

Disregard if this is not helpful.

heinrich-ulbricht commented 3 years ago

Today I may have experienced a combination of both issues. The watch did not connect. I removed it from Gadgetbridge and tried to add it again. Usually this helps. But not this time as I also had to reset the watch for Gadgetbridge to find it. This might be the ~20 hour issue.

I wonder how this issues can be tackled. Solving it needs a combination of people able to

  1. reproduce the issue(s),
  2. provide data and logs to analyze,
  3. locate the error(s) and
  4. finally fix them.

We definitely have folks here who can reproduce the issues. I also suspect we've got folks to fix errors. But points 2 and 3 might be difficult. Does somebody know which logs we could check to get useful hints? I'll try an adb logcat the coming week. Who knows if something comes up. Unfortunately I have no dev kit at hand so I cannot look into watch logs (I suppose).

bryantqo commented 3 years ago

Happening daily for me as well. Restart watch, delete from GB, re-pair

tmilburn commented 3 years ago

@heinrich-ulbricht

  1. Reproducing the issue is relatively easy, keep the watching running for 20 hours. There could be a way to speed this up by starting timers with an initial value close to the signed int rollover.
  2. Android logs might be helpful in showing if the issue was whilst connected or whilst advertising
  3. I have been looking through the bluetooth stack at all the timers to see if there are any issues with them and so far no luck in finding the error.
tealeg commented 3 years ago

20 hours is a read herring or a different issue, mine does it sometimes in less than one hour.

On Mon, 23 Aug 2021, 18:15 tmilburn, @.***> wrote:

@heinrich-ulbricht https://github.com/heinrich-ulbricht

  1. Reproducing the issue is relatively easy, keep the watching running for 20 hours. There could be a way to speed this up by starting timers with an initial value close to the signed int rollover.
  2. Android logs might be helpful in showing if the issue was whilst connected or whilst advertising
  3. I have been looking through the bluetooth stack at all the timers to see if there are any issues with them and so far no luck in finding the error.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JF002/InfiniTime/issues/302#issuecomment-903918173, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAE7FZNUSCGYBJZ6RADJJ3T6JX3RANCNFSM43III6HQ .

pbryan commented 3 years ago

I don't think it's a red herring. When phone and watch are left in proximity, I see ~20 hours consistently. 

On Mon, 2021-08-23 at 10:56 -0700, Geoffrey J. Teale wrote:

20 hours is a read herring or a different issue, mine does it sometimes in less than one hour.

On Mon, 23 Aug 2021, 18:15 tmilburn, @.***> wrote:

@heinrich-ulbricht https://github.com/heinrich-ulbricht

  1. Reproducing the issue is relatively easy, keep the watching running for 20 hours. There could be a way to speed this up by starting timers with an initial value close to the signed int rollover.
  2. Android logs might be helpful in showing if the issue was whilst connected or whilst advertising
  3. I have been looking through the bluetooth stack at all the timers to see if there are any issues with them and so far no luck in finding the error.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JF002/InfiniTime/issues/302#issuecomment- 903918173, or unsubscribe https://github.com/notifications/unsubscribe- auth/AAAE7FZNUSCGYBJZ6RADJJ3T6JX3RANCNFSM43III6HQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

bryantqo commented 3 years ago

Could it not be both? Regardless there is a disconnect and it doesn't want to reconnect. Another thing I can test is going out of range to see if it reconnects.

bearclaws8 commented 3 years ago

I can confirm that on my setup it will reconnect after separation. I am frequently away from my phone for several hours and my watch reconnects without issue (within the 20 hours). However, I have had difficulty with multiple reconnects.

To me it seems the duration of disconnect due to separation does not matter (within the 20 hours) but disconnecting too frequently has sometimes shortened the "clock" for the watch not reconnecting. This usually happens when I'm running around so I haven't been able to pay enough attention to reproduce reliably.

I used to have more frequent issues like @tealeg but haven't had that happen much lately. Usually the shorter time for not reconnecting was due to me coming into and out of range very frequently over that timeframe.

tmilburn commented 3 years ago

I managed to run a test to confirm that one of the issues is that the watch does not advertise when the uptime has surpassed 18 hours 12 minutes (65536 seconds or 2147483648 (2^31) ticks). I connected to the watch at 18 hours successfully and checked that the connection was still up at 18:13. At this point I manually disconnected and attempted to reconnect. This failed and I subsequently couldn't detect any advertisement packets from the watch.

There must be an integer overflow somewhere causing this problem but I haven't managed to track it down yet. Nor do I have an open unit which I can attach a debugger to.

pbryan commented 3 years ago

Nice detective work!

On Tue, 2021-08-24 at 01:03 -0700, tmilburn wrote:

I managed to run a test to confirm that one of the issues is that the watch does not advertise when the uptime has surpassed 18 hours 12 minutes (65536 seconds or 2147483648 (2^31) ticks). I connected to the watch at 18 hours successfully and checked that the connection was still up at 18:13. At this point I manually disconnected and attempted to reconnect. This failed and I subsequently couldn't detect any advertisement packets from the watch. There must be an integer overflow somewhere causing this problem but I haven't managed to track it down yet. Nor do I have an open unit which I can attach a debugger to. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

aemkai commented 3 years ago

I managed to run a test to confirm that one of the issues is that the watch does not advertise when the uptime has surpassed 18 hours 12 minutes (65536 seconds or 2147483648 (2^31) ticks).

How did you calculate the 2^31 ticks? The tick frequency should be 1024 Hz (see DateTimeController.cpp and FreeRTOSConfig.h), so 65536 seconds are 67.108.864 ticks (= 2^26). Thus, in my eyes an overflow of a 16-bit-variable should be more likely

Addendum: In DateTimeController, systickDelta is calculated with "0xffffff" (L34 + L48) - instead 0x_ff_ffffff as maximum value. So the "overflow value" is only 24-bit, but the variable has 32 bit.

In CurrentTimeClient.cpp (L 90 ff.) and CurrentTimeServie (L 35), both part of bluetooth time service - the UpdateTime()-function is called by nrf_rtc_counter_get(), which also returns a 32-bit-value. Maybe, the missing two 'ff' are responible to the error, but im not firm enough to check that. But breaking it down, the error must occur every 4,55 hours, if I'm right [2^24 = 16.777.216, 16k78/(10246060) = 4,55], so possibly I'm barking up the wrong tree?