I present this discussion here (rather than on the GitHub see https://github.com/ruuvi/ruuvi-sensor-protocols/blob/master/dataformat_08.md in particular issues #26 and #28 ) so as to solicit responses from a larger user community. I realize some of this information is redundant and more specific detail is located at GitHub.
The bluetooth advertising pack restricts the payload size.
The current proposal includes:
- Packet format number: 1 byte
- Temperature in 0.005 degrees Centigrade 2 bytes
- Humidity in 0.0025% 2 bytes
- Atmospheric pressure in 1Pa 2 bytes
- Power information, ie battery voltage in milli-volts and transmission power in 2dBm 2 bytes
- Movement counter, incremented by the accelerometer 2 bytes
- Measure Sequence number 2 bytes
- reserved 2 bytes
- CRC8 1 byte
- MAC address 6 bytes are allocated because Apple APIs do not provide it
I offer the following observations:
A) Accelerometer values should be provided.
B) Experience with RawV2 format leads to the understanding that a 1 byte movement counter is too small. Even small movements increment the counter by 6 to 12. This causes the counter to wrap too quickly. Two bytes should be sufficient
C) Measurement sequence number of 2 bytes at a transmission period as used by RawV2_slow of 6.240 seconds causes this to wrap after only 4.7 days
D)Partial byte fields are sometimes appropriate depending on the range of values being represented as seen in the power field. Combining bits from different bytes to create a field is not difficult, nor is biasing a field to reduce the value range.
E) Some fields are unnecessarily(even un-scientifically) precise due to the accuracy of the currently used sensors. Both temperature and humidity report varying values from one sample to the next even under static conditions. This precludes interpreting small changes as a trend. Anticipating that alternate sensors might be used in the future it is unreasonable to expect to provide more than tenths of a degree or tenths of a percent of humidity of precision.
I offer the following changes to the proposal:
I) Providing Accelerometer values which represent the orientation of the tag. With a range of 180 degrees, a field width of 5 bits for each of 3 axis would provide a precision of 5.6 degrees while requiring only 15 bits (i.e. less than 2 bytes) which are currently “reserved”.
As seen with battery and TX power it is not that difficult to extract bits and combine them.
Ia)The MAC address for bluetooth devices requires the high order 2 bits always be set. These 2 bits could be used for data with the receiver reconstructing the MAC address with a simple MAC[0] |= MAC[0] + 0xC0. Using the 2 high order bits of the MAC and the remaining bit of “reserved” would increase precision of accelerometer to precision of 2.7 degrees.
II) measurement sequence number: increasing it to 3 bytes may be more than is necessary as with a RawV2_fast period of 1 second would wrap in xxx days.
III) Humidity which is in the range of 0…100 would better be reported in tenths of a percent requiring a max of 0x3E8. This requires only 10 bits allowing the additional 4 bits to be used to extend measurement sequence number.
IV) Up to an additional 4 bits could be obtained by restricting the “currently supported” format codes to use only the second nibble (bits 4-7) or first nibble using 8X for this secure format. This would allow for an additional 7 future formats for a total of 16 active formats. This requires the receiver to mask the first byte of all packets with to determine the format, a very simple operation. Existing applications which support previous formats, without the masking operation, would not match this and future formats which they don’t support.
V) Battery voltage, although interesting, is really worthless for the ultra low power used by the Ruuvi tags. It has been shown to be unable to predict failure. Tags with values seemingly high enough when encountering a significant reduction in temperature stop functioning and tags with very low values continue to operate.
VI) Temperature precision should also be reduced to tenths of a degree centigrade (.18 degrees F).
Bits from item IV, V and VI could be better used to extend other fields or provide fields for future sensors.
I look forward to your responses.
Revised 11/11/19 18:54EST