We are currently working on an experimental project to mount your RuuviTag Pro Bluetooth Sensors on our paragliding wings to collect and analyze flight data in dynamic conditions.
We noticed that your firmware is open-source, and the specifications of the sensors seem to meet the sensitivity and responsiveness we require.
However, before proceeding with a purchase, we would like to ask a couple of questions to ensure that the RuuviTag Pro is the right choice for our application.
Two things come to my mind:
The responsiveness of the sensors (especially the temperature sensor), how quickly would they detect a change in air temperature in a windy environment?
Ideally, we would like to mount two devices on the same paraglider. Is there a way to synchronize the sensor readings? Would it be necessary to write new firmware to achieve this?
The current firmware advertises ( broad cast) data and accepts requests for data from the base.
There is no provision for Ruuvi to Ruuvi communication.
Do you want to sync temp? Pressure? Humidity? XYZ orientation? I don’t understand why you want to sync any of those. For that matter why do you want two on one craft ( unless you want to have redundancy o in the event of a disaster ?
We want to measure the difference in temperature and pressure between the two ends of the wing, which is why we need two sensors placed at different points.
For this reason, it would be ideal to perform synchronous measurements in order to identify variations between the ends of the wing at the same moment.
We were considering a solution in which the sensor readings are taken only upon request from the central device that will process the data.
Do you think this approach could make sense to address the problem?
Thanks for your message. I believe @otso would be the right person to give insight into your specific firmware related questions. This sounds like an interesting project!
The measurements are taken at roughly 2.56s interval and there is no mechanism to synchronise the measurements to each other.
Some of our users have made custom firmwares for detecting fast changes in environment, generally the approach is to push data over Bluetooth GATT connection rather than receiving advertisements. If you have e.g. 10 Hz sampling interval the samples are 50 ms apart at most - what kind of difference and jitter is acceptable for your application? Bluetooth does add a lot of randomness to timing by design.
I think it would be possible to make a solution where a central device opens and keeps two Bluetooth connections open and polls for measurement, but under the hood the connection has “connection interval” i.e. how often the devices actually sync data and requests between each other.
If you pick a high connection interval the latency of requests is going to be high and retried requests take a long time as they have to wait until next interval, and if you pick a low interval the devices have to keep their radios active which will drain battery fast.
Temperature sensor of RuuviTag pro is also relatively slow, Sensor Step Time or Sensor Measurement Delay - Ruuvi. The delay comes from thermal mass of the enclosure and no air circulation. Pressure sensor is a lot faster, practically instant.
Overall, I don’t think RuuviTag is ideal sensor for this application, but we have had users doing data collection for algorithm development with custom firmware.
We are still in the exploratory phase, so we don’t yet know exactly how much precision will truly be necessary. What is certain is that the idea of having potentially desynchronized readings by more than a second could be a problem.
By significantly increasing the sampling rate, the issue would probably be greatly reduced. Do you happen to have any references to firmware that use a GATT connection that we could study?
The slowness of the temperature sensor, on the other hand, is a major issue in our case. Do you think it would be possible to reduce it by allowing air to circulate inside? Perhaps by modifying the case?
For our application, battery life and water resistance are not major concerns.
Sources are still available, but it makes more sense to rebuild the changes on top of latest firmware.
If you want to do a quick proof of concept, battery consumption is not a problem and you don’t know exactly how fast sampling you need, my recommendation would be to use the current broadcasting model as a base and modify it to send at 10 Hz.
Broadcasting data is going to cause missed packets, but you will get timestamps which you can use to reconcile the data points. The packet loss rate depends on your receiver, anything that shares Bluetooth with WiFi antenna is going to drop a lot more than a dedicated Bluetooth receiver.
We do have samples of external TMP117 temperature sensor available, using external sensor speeds up the step response as there is a lot less of mass that needs to settle to new temperature.
The pressure sensor DPS310 on RuuviTags has a really fast maximum sampling rate, it is designed to be used in drones among other things. You could use the same approach as above blog post and configure DPS310 to store data into internal FIFO and stream it out via GATT if you want to go for faster sampling.
Please contact sales@ruuvi.com and cc me at otso@ruuvi.com if you want to move forward with this approach, we can at least set up a call to discuss our experiences in data collection with RuuviTags.