FAQ: transmission frequency

The frequency, inverse of the the interval, for the distributed firmware is different for each mode,

version	raw (highres) ms	URL ms
		coded	measured
2.2.2	1000
1.2.12	1000	500	508
1.0.1	1000	500

This seemingly very rapid transmission is an attempt to remediate the inherent poor percentage of sucessful packet reception of the BLE packets.

Here is a sample of packet reception times as seen by a raspberry pi zero Nothing was moving, the ruuvi and the pi were 4 meters apart, indoors. Notice the missing samples.

 >hcidump -t|\
grep --line-buffered  --before-context=3  --after-context=4 'addr C7:10:3C:68:24:C2'|\
egrep --line-buffered '2018|RSSI'
2018-11-07 22:54:05.340086 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -65
2018-11-07 22:54:05.840114 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -84
2018-11-07 22:54:06.342644 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -85
2018-11-07 22:54:06.850133 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -85
2018-11-07 22:54:07.355129 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -79

2018-11-07 22:54:08.364490 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -84
2018-11-07 22:54:08.866807 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -83
2018-11-07 22:54:09.376688 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -84
2018-11-07 22:54:09.880479 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -83

2018-11-07 22:54:10.385499 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -78
2018-11-07 22:54:10.884945 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -84
2018-11-07 22:54:11.891446 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -85

2018-11-07 22:54:12.393816 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -79
2018-11-07 22:54:12.900664 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -79
2018-11-07 22:54:13.402499 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -89

2018-11-07 22:54:15.421055 > HCI Event: LE Meta Event (0x3e) plen 43
      RSSI: -79

Reducing the frequency has some effect on the battery lifetime, especially in harsh environments.

Additional thoughts

• Changing the frequency: As of 11/22/20 firmware version 2.5.9 stable and 3.28.13 beta the only way to vary the frequency of transmission is to modify the source (see https://github.com/ruuvi/ruuvi.firmware.c/issues/172 for ideas on that).
• Reducing the frequency to more than 5 seconds has minimal, if any, effect on battery life as it approaches self life.
• As the number of bluetooth devices in a given environment increases, it may be beneficial to reduce the frequency to avoid collisions. See https://blog.ruuvi.com/bluetooth-beacon-density-maximum-92bcb947ee99 .
• Bluetooth advertising does not provide for retransmission in the event that the receiver detects an error or misses a packet. Increasing the frequency may mitigate this by transmitting the same data multiple times.
• Ruuvi tags "radiolocially" near the receiver have a better chance of being received without error so the frequency might be reduced.
• Some sensors, in particular humidity, have an settling time and increasing the frequency will only report the same values.
• Some conditions being observed change very slowly so decreasing the frequency may not effect the data even if some packets are lost.
• Some conditions, for example orientation (Z-axis), may change to a new value then back to a previous value and if the frequency is too slow the change will go unreported.
• Too many devices transmitting at a high frequency can overwhelm the gateway or other downstream facilities (for example the database). Both RuuviCollector and Ruuvi-Discover has a mechanism to mitigate this but only on a global (i.e. all tags ) basis.