Ruuvi air ble protocol

I got my new air today and I am listening to the BLE packages on an rpi.

I get the following issue:

byte#
0           1  2      3  4       5  6    7  8      9  10    11    12    13     14         15     16     17 18 19
Package
06         10 83     3B A0      C0 86    00 1B     02 32    05    00    FF     FF         DD     D0     8F BA BE

dataFormat  temp      hum        press   pm25      co2     voc   nox   lum    reserved.  mes#   flags   MAC end#


temp, hum, press, pm25 co2 all give reasonable numbers comparable with the iphone app display
mes# seems to count up ok.

VOC, NOx Lum are junk

flag is always D0 = 1101 0000 which makes voc=255 + 5 and nox=255 + 0

any pointer would be appreciated.

ps and the iPhone app shows data format E1 which is not received by the RPI, mine is 06 format which makes sensor from the length of the data received

Hello @kw123 ,

Thanks for your message! Let’s add @otso to this conversation, he might be able to provide you some insights about your issue.

Hello,

Production version of Ruuvi Air does not have luminosity sensor and will always report 0xFFFF = Not available.

VOC and NOx flags have the least significant bit in them, in your case VOC is 5 + 1 =6 and NOx is 0 + 1 = 1

[edit] Data format 6 is sent with BLE4, data format is sent with BLE5. Your Raspberry Pi probably has BLE4 compatible receiver and therefore cannot receive the E1 data.

Ok that explains it.

I had the flag as most significant bit not the least significant bot. my mistake

May I suggest to remove the luminosity part from the protocol for type 6.

you can close this topic.

thanks

Karl

1 Like

Thanks for the details about the Luminosity sensor.

Note that the RPI5 should be able to use BLE5, that’s the one I will test soon with my Ruuvi Air, hopefully I will be able to read the E1 data format.

there a BLE type5 external dongles that work with the RPI 2/3/4/5.. they should receive the e1 data format? They are < $10 at amazon.. Also using BLE and WIFI together on the internal chip always creates performance issues (same hardware for BLE and wifi)

Karl.

.. and just for my understanding
why has the humidity value 2 bytes? ±0.5 (using 1 byte) accuracy should be plenty in range 0-100%
Is the sensor used is actually that accurate ?

Hello and sorry for the late reply.

In theory they should work, however we have not tried them or how they would work with existing integrations.

The absolute accuracy of humidity sensor is around ±3%, but relative accuracy and resolution of sensor is a lot better, down to 0.01%. It becomes meaningful when measuring absolute humidity in cool temperature. Our original data format actually did have resolution of 0.5%, but it was too coarse for plotting.