As of now, the Data Format with the highest precision is Format 3, which still has some room for improvement. The format 3 uses 14 bytes out of 24 bytes maximum, so ten more bytes can be added to that. Based on discussions on Slack, some ideas that could be added/changed:
- Add more precision to (relative) humidity, as it’s the least precise measurement at the moment, and is insufficient when used for calculating other values, such as absolute humidity and dew point.
- Add a unique ID, as iOS devices don’t expose the MAC address of other devices so iOS devices can’t tell current format 3 tags from each other.
- Add a uptime counter or packet sequence number counter, useful for packet de-duplication when there are multiple receivers for one database.
- Add a movement counter. The accelerometer (LIS2DH12) supports sending interrupts from motion detection, so use these to increment a movement counter. Makes it possible to build alarms that react on even the shortest movements between actual measurements.
Based on these, I have created a proposed next data format:
edit: NOTE! Scroll down for updated drafts, this one here is outdated.
offset = description 0 = Data format (8bit) whatever the next number will be 1-2 = Temperature (16bit signed) in 0.005 degrees (-163.84 to 163.83 range) 3-4 = Humidity (16bit unsigned) in 0.0025% (0-163.84% range, though realistically 0-100%) 5-6 = Pressure (16bit unsigned) as it is in format 3 7-8 = Acceleration-X (16bit signed) as it is in format 3 9-10 = Acceleration-Y (16bit signed) as it is in format 3 11-12 = Acceleration-Z (16bit signed) as it is in format 3 13-14 = Battery voltage (16bit unsigned) as it is in format 3 (or higher precision if available? the current range goes up to 65 volts which is not realistic) 15 = Movement counter (8bit unsigned), incremented by interrupts from LIS2DH12 16-17 = Packet sequence number (16bit unsigned), each packet has this incremented by one, used for packet de-duplication and calculating packet loss 18-23 = Tag ID, the 48bit MAC address (rather than the hw ID on the nRF chip to provide compatibility with current datasets that differentiate tags based on the MAC)
Some notes/comments on this:
- If a significantly large unique ID is to be added, there is not much room for large counters, so a time-based uptime counter is not really feasible, a running packet sequence number would be more useful.
- Since the current format is really lossy for the temperature, it would be nice to change that and achieve more precision (and actually easier parsing in most situations).
- Since the temperature and humidity would be changed dramatically, the old order serves no purpose, so I reordered temperature, humidity and pressure to match the order generally preferred (and also used when displayed on ruu.vi)
For sure I haven’t taken something into consideration, so please share your thoughts, comments, suggestions and ideas for this.
At least one thing to discuss would be the battery voltage and the movement counter, if the battery voltage would be reduced to 1.5 bytes (12bits), it would have a range from 0V to 4.095V, which is sufficient for that, and then the remaining 0.5 byte (4 bits) could be added to the movement counter, to increase its range from 0-255 to 0-4095.
This would definitely add more complexity to parsing the values, as the value offsets would not be full bytes, but it would provide a longer time between the movement counter “resets”, but is it worth the extra complexity?