Getting data at higher sampling rate with RuuviTag and Raspberry Pi

Hey everyone,

I am experiencing a bit of a problem with getting data at higher sampling rate from RuuviTag using Raspberry Pi 3 B. Specifically, I tested a RuuviTag with the default firmware in the RAW mode. I modified the example to continuously get data from my RuuviTag. So far this setup worked fine – I get roughly the correct number of samples (smaller than perfect 1 Hz though).

The problems start when I try to increase the sampling rate of the tag by modifying firmware. I followed this thread [1]. So I set MAIN_LOOP_INTERVAL_RAW to 100u (also tested with 500u) in bluetooth_application_config.h [2], compiled the firmware and generated a DFU packet as follows:

nrfutil pkg generate --debug-mode --application _build/ruuvi_firmware.hex --hw-version 3 --sd-req 0x91 --key-file ~/git/ruuvitag_fw/keys/ruuvi_open_private.pem

Then I use nRF Connect to load the new firmware to the tag and it gets loaded successfully – at least I do not get any errors and the tag’s LED starts to blink with a higher frequency. When I launch my script again on the Raspberry Pi – I get fewer samples.

Does anyone have any idea why this happening or at least point me to the direction of where this problem might have occurred (e.g. script running on the Pi, firmware modification, BLE settings on the Pi)?

Thanks in advance.

[1] - Changing the broadcasting interval
[2] -

Ok, it seems that I have found the problem. I have compiled the latest firmware (v2.3.0) and loaded it to the RuuviTag. The latest firmware comes with a new data format #5 as compared to the default firmware (v1.2.12 – was shipped with my RuuviTag) with uses data format #3.

So I observed the following, when I retrieve the data with a callback [1] using the newest firmware and data format I can only get one packet. Afterwards, everything hangs. I also did not observe any correlation with the advertising interval. So it is probably the issue of RuuviTag Sensor Python Package.

I managed to compile the default firmware (v1.2.12) and reduce the advertising interval. Using similar callback functionality I get more samples as expected.

Perhaps, you should look into this bug.

[1] -