Garmin Fenix 6 Connection Drops

[canuk-1]

Hi - super happy to get our production DFC.

It is working flawlessly with Garmin Forerunner 945 (ie. getting power and cadence).

Garmin Fenix 6s successfully connects but connection drops in and out continuously thru the ride (functioning duty cycle of about 10%). Have tested this over multiple rides. Any thoughts?

Thanks!

[melissalee08]

Experiencing similar issues with Fenix 6s. I do wonder if this is because my notifications during activity were turned on. My watch kept going off with group chat notifications and it seemed to coincide with the connection dropping/not picking up power. My previous ride didn't seem to have as severe connection drops.

I've turned off notifications during activity and will report back tonight or tomorrow when I get the chance to do another workout.

[veneman]

Thanks for letting us know about this. The Fenix 6X Pro is what we've tested DFC the most with and we haven't seen any dropouts as described. We'll keep this open to gather info on what may be the root of this.

Any additional information like the Fenix firmware and what devices you have connected to the watch as well as what the watch is connected to would be helpful. E.g. Fenix software version 19.20, connected to iPhone, connecting to a Viiiiva heart rate monitor via ANT.

[canuk-1]

Thanks Jason!

We will confirm we are on the latest firmware, turn off all other sensors and give it a whirl.

Thanks for you attention on this and Happy New Year!

Thanks, Chris

---

From: Jason Veneman @.> Sent: Friday, December 31, 2021 5:37:28 PM To: intelligenate/dfc @.> Cc: canuk-1 @.>; Author @.> Subject: Re: [intelligenate/dfc] Garmin Fenix 6 Connection Drops (Issue #2)

Thanks for letting us know about this. The Fenix 6X Pro is what we've tested DFC the most with and we haven't seen any dropouts as described. We'll keep this open to gather info on what may be the root of this.

Any additional information like the Fenix firmware and what devices you have connected to the watch as well as what the watch is connected to would be helpful. E.g. Fenix software version 19.20, connected to iPhone, connecting to a Viiiiva heart rate monitor via ANT.

— Reply to this email directly, view it on GitHubhttps://github.com/intelligenate/dfc/issues/2#issuecomment-1003460867, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATSCNRDGZ34X6PUBCWDH4T3UTYWCRANCNFSM5LAHFFAQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.***>

[melissalee08]

Updates on my end: Turned off in-activity notifications, no difference. I don't have any other sensors except Bluetooth headphones, which brings me to...

I did a ride on 12/29 and connection was good. There were some drops but nothing crazy. The software on my Fenix updated that night, and I also installed the Speed/Cadence beta the same night (I think). My power drop issues started after I reinstalled the original firmware. Not sure if canuk-1 had reinstalled the original firmware after trying out the Beta. If so, that might be the key?

No issues with cadence though...

Hardware: Fenix 6S, software version 20.0, connected to Peloton and Peloton x JBL headphones, Android, no other sensors.

[canuk-1]

Hi there.

As of this AM, Fenix 6s continues to not stay connected:

• The Fenix firmware is the latest (v19.20; v20.0 was yanked).
• The DFC is the firmware as shipped
• No other sensors or bluetooth devices are connected (apart from on-board).
• The DFC successfully connects
• The cadence/power drops in and out (mostly out).

The Forerunner 745 continues to work flawlessly. Connection to DFC turned off when the Fenix was used per above.

Jason - I'm happy to test the Beta if you think that would be a meaningful test case.

[doudar]

@veneman , if the Fenix 6 is connecting via BLE, it sounds possible that it’s getting connection parameters that it’s incompatible with.

For the ESP-32 we can set connection timeouts and expected time between tx intervals like this:

https://github.com/doudar/SmartSpin2k/blob/ceefb349b6f914751ff2aa509d2bc6c06047ea33/src/BLE_Common.cpp#L149-L152

Not certain what platform you’re currently using.

[Stoobiedoo]

Hi, I'm using a Fenix 5X with no dropouts. Software Version 17.30 (4769c95) Paired with HRM-Pro Software 7.4 Stock, as shipped, DFC firmware. I turn off my phone Bluetooth while riding because my headphones seem to preferentially go to the phone instead of Peloton. Not sure if that has an impact on Bluetooth connection stability.

[veneman]

@melissalee08 Thanks for providing those details. Installing the beta then going back to the production shouldn't make a difference. I'll double check again but I've done that before and the machine code ends up being bit-for-bit identical as if it was a fresh install. It's curious you mention that you had no issues with the cadence though. The cadence and power are always sent together so it's puzzling how one could be fine but not the other.

@canuk-1 Thanks for the details. You can keep using the production firmware since the beta one doesn't add anything for Garmins. Are you noticing both cadence and power drop out at the same time on the Fenix? Have you tried using both the Forerunner and Fenix at the same time? DFC will connect to two devices simultaneously (that's what I usually do) and I'm curious if that changes anything in your case.

@Stoobiedoo Thanks for providing the usage report. I'll add the 5X to the compatibility table.

@doudar Thanks for pointing to the connection parameters. We're running with the nRF5 SDK and have the connection parameters set based on one of the examples as follows:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(500, UNIT_1_25_MS)            /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(1000, UNIT_1_25_MS)           /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds). */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

That gives it a range of .5s to 1s which seems pretty wide. It's up to the central device (i.e. the watch or app) to set the connection parameters if the provided ones are not compatible. I'll see what it gets set to across a few different devices.

[melissalee08]

@veneman

Yep. I thought it was strange too. You can see a slight drop near the 18:18 mark but otherwise the cadence seems to be mostly there. There is some variance with the output on my Peloton but that is to be expected anyway.

[doudar]

@doudar Thanks for pointing to the connection parameters. We're running with the nRF5 SDK and have the connection parameters set based on one of the examples as follows:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(500, UNIT_1_25_MS)            /**< Minimum acceptable connection interval (0.5 seconds). */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(1000, UNIT_1_25_MS)           /**< Maximum acceptable connection interval (1 second). */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds). */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(5000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

That gives it a range of .5s to 1s which seems pretty wide. It's up to the central device (i.e. the watch or app) to set the connection parameters if the provided ones are not compatible. I'll see what it gets set to across a few different devices.

There could be a chance that FIRST_CONN_PARAMS_UPDATE_DELAY is too long for the for the watch defaults and the update connection parameters routine isn't getting called prior to the watch's default CONN_SUP_TIMEOUT. So it drops the connection.

I might suggest lowering FIRST_CONN_PARAMS_UPDATE_DELAY to 1000ms . I don't see an issue with lowering it at least. Typically you won't have problems with trying to set the connection parameters anytime after you've connected and sent one broadcast.

[canuk-1]

Completed test with both Garmin 6s and Forerunner 745. Unfortunately it showed that both experience drop-outs - it's just that its better on the 745. Video of test at: https://youtu.be/0bwCW-MsGnc.

It may be unrelated but I did install the beta software and the nRF Connect app also regularly lost connection to the DFC.

[Lunchtime0614]

I can confirm this is also happening with a Coros Pace 2 watch as well as the Wahoo App on iOS. I didn't look at my graphs on Coros until now but notice how the graphs stop prior to the end of the rides - I assume coros is ignoring the dropped data thus the graph being longer than the actual ride time. I also confirmed this by monitoring the data on my watch and wahoo app while riding...periodically it'll show no data being received.

The first ride was as DFC shipped, the second is after I loaded the beta firmware but then flashed back to stock (after noting the speed was not picked up).

[pfmos]

As an additional data point:

Using a Fenix 6 Pro (sw ver 20.01, ANT/BLE/BT ver 6.11), Google Pixel Buds, Original Peloton bike, Pixel 6 Pro with Bluetooth on near the bike but not connected to anything.

Absolutely no drop outs and works flawlessly. On original firmware.

[canuk-1]

@pfmos @veneman I note the different peripheral packages for the 6 Pro which may explain the differing results with other Fenix 6 models.

Per Garmin, latest Fenix 6 peripheral software versions:

Likewise the FR745 is on ANT/BLE 6.11. I think all this suggests the Fenix 6/6s has a different chipset (and maybe requires tweaked connection parameters)?

[pfmos]

@canuk-1 Garmin releases betas for most of their watches on a pretty regular cadence. I'd check and see if there is something newer available. Maybe that will help.

[canuk-1]

Thanks @pfmos. 6.1.1 is the latest for Fenix 6Pro and FR745 and 3.00 the latest for Fenix 6/6s. @veneman FYI, my FR745 (with 6.1.1 ANT/BLE) is rock solid unless the Fenix 6s is simultaneously connected (as I showed in the video I provided). Not sure that help...

[melissalee08]

@canuk-1 you're probably on to something there about different chipsets and requiring tweaked connection parameters, especially since both our Fenix 6S are on different software (you're on the version before 20.0, IIRC).

[canuk-1]

Thanks @melissalee08 - indeed our Fenix 6s is on the 19.20 firmware but I believe the specific ANT/BLE firmware wasn't updated in 20.0 (I believe last updated with 19.10). Per the Fenix 6 forum...

[veneman]

Thanks for the additional info everyone.

The different wireless capabilities between the Fenix 6 models certainly points to different chipsets.

I did some tests logging the connection parameter updates that are received by DFC and found the following:

Device	Min Interval	Max Interval	Latency	Timeout
Edge 130	800	800	0	400
Fenix 6X	792	792	0	400
Dash L50 (1)	28	28	0	350
Dash L50 (2)	80	80	6	350
Dash L50 (3)	800	800	0	400

One thing of note from this is that the Stages Dash updates it three times within the first few seconds it's connected, settling on the last. The values returned are in "units" which can differ for each parameter so 800,800,0,400 corresponds to 1s,1s,0s,4s.

In the connection code an explicit call has been added to update the connection parameters. This is included in the latest speed & cadence only beta that's posted.

Next up is testing with a lowered FIRST_CONN_PARAMS_UPDATE_DELAY as suggested. If that works well I'll post a new power & cadence beta with all the latest updates.

[mkgraham82]

I have Fenix 6 Pro solar. FW20.20 Riding original Peloton

Rode today and saw a power meter connected notification while riding. Did not think much of it.
Post ride I saw this:

And this

Two distinct dropouts seen. It doesn't bother me over a 45 min ride but it would be nice to know why this happens.

Thanks Matt

[Lunchtime0614]

Thanks for the additional info everyone.

The different wireless capabilities between the Fenix 6 models certainly points to different chipsets.

I did some tests logging the connection parameter updates that are received by DFC and found the following:

| Device | Min Interval | Max Interval | Latency | Timeout |

| ------ | ------------ | ------------ | ------- | ------- |

| Edge 130 | 800 | 800 | 0 | 400 |

| Fenix 6X | 792 | 792 | 0 | 400 |

| Dash L50 (1) | 28 | 28 | 0 | 350 |

| Dash L50 (2) | 80 | 80 | 6 | 350 |

| Dash L50 (3) | 800 | 800 | 0 | 400 |

One thing of note from this is that the Stages Dash updates it three times within the first few seconds it's connected, settling on the last. The values returned are in "units" which can differ for each parameter so 800,800,0,400 corresponds to 1s,1s,0s,4s.

In the connection code an explicit call has been added to update the connection parameters. This is included in the latest speed & cadence only beta that's posted.

Next up is testing with a lowered FIRST_CONN_PARAMS_UPDATE_DELAY as suggested. If that works well I'll post a new power & cadence beta with all the latest updates.

@veneman I used the latest beta today on a 45 min ride with my Coros Pace 2. Almost feels like it has more drops than production...note the green speed graph with all the zeros. Cadence I'm not sure why it doesn't go to the end of the ride - that's what the production version does, power and cadence not fully recorded (unless Coros is just shortening the graphs to cover the dropouts).

[veneman]

@htims05 Thanks for the report on that. Yours is the only non-Fenix 6 that's reported dropouts like this and you also mentioned trouble with the Wahoo app. I'll run a longer test with the Wahoo app and see how it goes. FWIW, before releasing the speed and cadence beta I did a test of a simulated ride going to a Garmin Edge 130 and didn't see any issues.

[Lunchtime0614]

@veneman interesting. I'll reset the watch and the DFC back to production and see it that changes anything.

For what it's worth the Coros is using Bluetooth 4.2

[Lunchtime0614]

@veneman interesting. I'll reset the watch and the DFC back to production and see it that changes anything.

For what it's worth the Coros is using Bluetooth 4.2

No luck. I reset the watch and DFC and it still drops. You can see the power or cadence on the watch just disappear for 5-10 seconds every few minutes.

[veneman]

Just posted a new power and cadence beta that updates the initial connection parameters by giving them a very wide range, changes the FIRST_CONN_PARAMS_UPDATE_DELAY to 1000ms, and adds a call to update connection parameters when a request from a device is received. No issues were seen in either a simulated or live test connecting to a Fenix 6X and Zwift.

[mkgraham82]

@veneman uploaded your new prerelease this morning and rode for 45 mins. Fenix 6 pro solar. Absolutely no drops. Looks good!

[melissalee08]

Installed the update yesterday and still getting dropouts. Strange that cadence is (still) doing ok. On the watch if there was no power data there was no cadence data either.

FTR I am on a Fenix 6S, software version 2.0. no other sensors connected to the bike. Watch was connected to my phone with notifications turned off during activity.

[canuk-1]

I'm afraid that likewise the new Beta did not fix the dropouts on our Fenix 6s. Forerunner 745 continues to do great unless both are connected at the same time - then the FR745 continually drops as well.

[veneman]

Thanks for trying the beta out. To better debug this I have a new Fenix 6 on the way to test with. That should help get to the bottom of this faster. @melissalee08 That's strange that the cadence data looks like it's there but not the power. Both of those are always sent together so if one is there the other should be too. The cadence should look more stochastic like below. I'm guessing that it's interpolating between the times that it gets data. .

[veneman]

@canuk-1 @melissalee08 @htims05 Just posted an update that fixes the dropouts on a Fenix 6 in my testing.

Here's the details: In my initial testing with a Fenix 6 with the production firmware on DFC I saw the same kind of dropouts others have seen with the 6. The NRF SDK error was 0x08 which is a BLE_HCI_CONNECTION_TIMEOUT and is related to not receiving data from the watch. Others seeing that error had success changing the clock source that the microcontroller uses and, voila, that did it!

The clock was set to use the external crystal oscillator and wasn't working for the 6 when set to the oscillators accuracy of 20PPM. Setting it to 100PPM did work when just the watch was connected but when also connecting to Zwift it started dropping out again. Setting it to the internal clock seemed to work fine with both connected and I didn't see any dropouts in over an hour.

Using the internal clock uses slightly more power but won't matter with it powered via USB.

[melissalee08]

Looks good! Thanks @veneman!

[canuk-1]

@canuk-1 @melissalee08 @htims05 Just posted an update that fixes the dropouts on a Fenix 6 in my testing.

Here's the details: In my initial testing with a Fenix 6 with the production firmware on DFC I saw the same kind of dropouts others have seen with the 6. The NRF SDK error was 0x08 which is a BLE_HCI_CONNECTION_TIMEOUT and is related to not receiving data from the watch. Others seeing that error had success changing the clock source that the microcontroller uses and, voila, that did it!

The clock was set to use the external crystal oscillator and wasn't working for the 6 when set to the oscillators accuracy of 20PPM. Setting it to 100PPM did work when just the watch was connected but when also connecting to Zwift it started dropping out again. Setting it to the internal clock seemed to work fine with both connected and I didn't see any dropouts in over an hour.

Using the internal clock uses slightly more power but won't matter with it powered via USB.

Thanks so much! Confirmed working on Fenix 6s. Now do you get to buy a Fenix 7?

Hopefully there are no objections but I will mark this closed.

[Lunchtime0614]

I know this is now closed but also wanted to confirm that it is working on a Coros Pace 2 as well.