Disconnecting tag with v3.30.2 FW

Hi,

Iā€™m using a Ruuvi-Tag connected Ruuvi Station (0.7.2) on my iPhone. Today I updated the firmware using the integrated firmware updater to the most current version 3.30.2. Since then the tag has a short disconnect every two minutes.

Unfortunately I donā€™t know which firmware I used before that worked flawlessly :frowning:
It had already the connect feature and I think the history was already available, too. I browsed through github and flashed nearly every firmware from 3.30.3 back to 3.28.12 via nRF Toolbox on my tag, but every firmware had the same issue.

Is there any way to get older firmware binaries for my tag than 3.28.12 or any other way to get this fixed?

Best regards,

Matthias

Hello,

How old the batteries are in your tags? Low battery causes reboots which would cause disconnect. Itā€™s not possible to return to 2.X versions via Bluetooth update, and 2.X versions donā€™t have GATT connection option anyway.

The battery voltage was about 2.9 volts, but just to be sure I just put a new one in. Didnā€™t help though. Still a short disconnect every two minutes.

I just noticed another strange thing: if I force-close Ruuvi Station and reopen it, it showā€™s me the connected notification followed by an ā€œAir Humidity too high!ā€ alert. In the settings the air humidity alert is disabled though.

Removing the sensor in Ruuvi Station and adding it back doesnā€™t help either,

Thank you for the details.

@Rinat Please take a look here

Hi! Could you please check if Absolute Humidity alert is on.

In order to do it, please go too Menu ā†’ App Settings ā†’ shake the device ā†’ Experimental functions ā†’ toggle on the switch and ensure checkmarks are enabled for DP and AH Alerts


Then go to sensor settings and check if Absolute Humidity Alert is On.

For the short disconnect issue I have no idea tbh. This is not controlled by the iOS application, we donā€™t force the app to disconnect every two minutes. Iā€™ll monitor if I can reproduce, but I donā€™t have any clue why it could happen.

Thanks for the great tip @Rinat, it worked :slight_smile:

With enabling DP and AH Alerts in the Sensor Settings Menu a new absolute Air Humitdity Alert option appeared and it was enabled. Disabling this one got rid of the alert. Thank you.

For the disconnects: if i keep the Sensor Settings open I see that the app really loses the connection to the sensor. Unter connection Connected changes for about a second to ā€œConnecting ā€¦ā€ and then back to Connected.

ā€œData Received Viaā€ toggles between ā€œHeartbeatā€ and ā€œAdvertisementā€, not sure if thatā€™s normal behaviour if keep connection is enabled.

Measurement Sequence Number keeps rising, so I donā€™t think the tag is restarting since then it should reset to 0, right?

seems that the tag actually disconnects without reboot. I assume itā€™s not going out of range, given this I have no idea why it disconnects. Are you on the latest iOS (14.7.1)? There are some evidence of faulty bluetooth on iOS level.

Is there a log that shows what the previous version of firmware was before upgrade?

@Rinat I just tried on my ipad which runs on iOS 14.6: I disabled ā€œKeep Connectionā€ on my phone, force closed ruuvi station and then installed ruuvi station on my ipad, added the tag, enabled ā€œKeep Connectionā€ and enabled the connection alert. Same behaviour here.
RSSI is always between -32 and -35, Iā€™m at the moment at FW v3.30.3+default and the disconnects are every 97 seconds. No matter if on iOS 14.7.1 or iOS 14.6.

I could just disable the connection alert because the tag immediately reconnects so for the basic use case it doesnā€™t matter that connection gets dropped for a second, but I would like to get notified when I get out of range.

@dgerman I donā€™t know of an entry that shows the previous used firmware. In my case I tried many versions after I noticed this bug. Even the last 5 entries wouldnā€™t help me :wink: But if Iā€™d get older firmware binaries from somewhere, I would test them all until I find the one that works. Unfortunately I never compiled any software myself, so I donā€™t feel confident that I manage to build the older 3.x firmwares from the source.

I think I tried all back to v3.28.12, which is the first automated release on github

I got another RuuviTag now, seems that it is HW B5. Mine is B6. Donā€™t know if this is relevant.
With both tags on FW v3.30.2 I got the disconnects every 97 seconds.

I found another firmware binary on jenkins:
https://jenkins.ruuvi.com/job/ruuvi.firmware.c%20-%20deploy/8/artifact/src/targets/ruuvitag_b/armgcc/

This one seems to be a few days older than the first binary on github (30.12.2019 vs 24.12.2019) but with this firmware there are no disconnects. :slight_smile:
I have no idea what the version number is. Firmware update dialog in ruuvi station says ā€œdc3bc5aā€.

With this firmware ruuvi station shows only ā€œHeartbeatā€ in the ā€œData Received Viaā€ field.

@h4ppy I have http://mybeacons.info/3.30.0-rc3.default.full.hex.gz available.

I can put up older ones too. Let me know

Thanks, I found them on jenkins. Just trying them through one by one until it breaks :slight_smile:
Seems that it still works with 3.28.13. But I have to order / find new batteries. Flashing firmwares up and down without devkit really draws a lot of power.

Ok, I narrowed it down:
Up to ruuvitag_b_armgcc_ruuvifw_default_v3.28.14rc1_dfu_app.zip keep connected still works without disconnects.
From ruuvitag_b_armgcc_ruuvifw_default_v3.29.0-rc3_dfu_app.zip on I have disconnects every 97 seconds.

1 Like

Thank you for narrowing the version down.

Difference between 3.29 and 3.30 is that 3.30 keeps advertising after connection has been established so other devices can hear the current data.

@Rinat can you replicate the issue with these versions?

It still works with 3.28.14rc1 (which doesnā€™t show any values in ruuvi station, so I canā€™t use it) and breaks already with 3.29.0-rc3. Iā€™ll use v3.28.13 for now. But I have another tag here so I can help to narrow the issue down further and maybe help fixing it somehow.