Hi,
is it possible to connect to a RuuviTag in a similar way as you would connect to e.g. a Bluetooth GPS device and read the measurement data?
Or is the only possibility to pick up the data from the advertising messages [that is: without developing and flashing custom firmware]?
User case: recording athmospheric pressure (-> altitude) and temperature continuously during long-term (several hours) outdoors activity, to be paired with location data from the GPS.
Regards,
Käpsyttelijä
It is possible, yes. Ruuvi Station iOS app is doing it if connection mode is enabled in sensor’s settings. Ruuvi Station Android app listens only advertisements.
If you would like to read detailed info about it, you can find documentation here: docs.ruuvi.com
Hi,
thanks for the quick reply.
I didn’t mean using some general application, I meant reading the data with my own application, as the data needs to be combined with the data read from an external Bluetooth GPS device. My earlier phone had a pressure sensor, so I could take the pressure data from there , but nowadays it is hard to find a phone with pressure sensor.
As far as I understood, the standard way of reading characteristics in Android environment (i.e. “onCharacteristicRead” for standard GATT services) does not work for RuuviTag (for other than device information).
However, I can see that it supports NUART service. So I’m wondering whether it would be possible to read the sensor data the NUART RX and TX characteristics, e.g. once per second. Because I also noticed that, through advertising messages, you actually get new data only every appr. 2,5 seconds, that is twice per 5 seconds, because you normally get two consecutive messages with the same measurement sequence number. Cf. from the [old] phone’s pressure sensor I got readindg 5x per second, which I then averaged to reduce random noise.
Regards,
Käpsyttelijä
Hello,
The sensor is sampled once per measurement, so even if you read the data faster you would only get repeated samples.
It is possible to speed up the sampling rate, but that will lower the battery life. If you’re actually happy with the final data rate and are looking to take more samples for averaging, it would make most sense to use the sensor’s built-in oversampling to save power.
Let me know if you’re interested in doing a custom firmware for yourself, I can search for the configuration constants to help you get started
Hi,
What does “sensor is sampled once per measurement” mean in practice? I.e. whats the measurement rate?
= =
I did read Ruuvi Firmware - Part 16: BLE GATT Connection - Ruuvi, but decided that, at this stage, developing custom firmware is a bit of an overkill, as I started my ble studies from zero four days ago (I was, however, familiar with classic bluetooth).
So I will now first test the ready-made advertising messages, that is scan continuously, to see if I’m happy with the results. I just need to restart the ble scanner every 30 minutes to avoid Android turning scanning to so-called opportunistic mode.
The reasons why I was interested in connecting to the RuuviTag were quite many:
(1) Continuous scanning drains battery (at least this is what the Internet tells me). I have to test whether the effect is significant.
(2) Scanning requires that Location is enabled on the device. Which I don’t like, and don’t need, because I use a more accurate external GPS device. If one could connect to the RuuviTag, one might first scan once to get the MAC address, save it, and then later reconnect using the MAC address.
(3) Every new Android API version brings more and more restrictions to scanning.
(4) The combination of scanning settings and RuuviTag’s advertising rate generates a random delay which makes pairing data with location data from the GPS less accurate.
(5) I’d like to get a new measurement at least every second, because any sensor invariably has random noise. (If more frequent sampling reduces battery life from a year to a month or such like, that’s not an issue in the intended usage).
So let’s see whether I end up learning still another programming language in order to create custom firmware…
Compared to a phone’s built-in pressure sensor RuuviTag would have the advantage that the pressure reading is not sensitive to handling (unless one squeezes the tag quite hard putting the thumb on the little hole in the housing). A built-in pressure sensor literally senses PRESSURE (not just athmospheric pressure), and I had to develop quite an extensive analysis to clean the raw data from huge spikes and valleys whenever the phone was handled.
Hello,
1 / 2.57 seconds, about 0.39 Hz.
You can use the NUART and register to notifications of new measurements as soon as they’re available, it’s also more reliable than scanning for broadcasts.
Customising the sampling interval is not too difficult, pressure sensor configuration is at ruuvi.firmware.c/src/application_config/app_config.h at 6e1d33f9110c88985ba0e59768b84fb4cf33673d · ruuvi/ruuvi.firmware.c · GitHub and broadcasting configuration is at ruuvi.firmware.c/src/application_config/application_mode_default.h at 6e1d33f9110c88985ba0e59768b84fb4cf33673d · ruuvi/ruuvi.firmware.c · GitHub. You’d need to set the broadcast interval to shorter, number of repeats to 1 and configure pressure sensor to run at e.g. 10 Hz. Bigger hurdle is in installing all the needed software and SDKs to compile the firmware.