Well I did it and it worked. I only tried the āWeather Stationā app bit this was OK. I made some changes to verify that I was using the software I had compiledā¦ but yes it was OK.
I also made a change to the way the accelerometer value are āscaledā using ām-g per bitā and ābit resolutionā and it does seem to wok. I find this clearer than what was there before of what āojousimaā is doing, but it hasnāt been fully tested ;). I do it like this
add 32768, since the accelerometer is a 16 bits 2's complement the full range is
from -32768 to +32767 so this moves the value range into positive territory
clean LSB essentially >> (16 - resolution) with resolution 8, 10 or 12
substract (1<<(resolution-1) ) so we get back the signed info within the set resolution
scale based on the number of m-g per bit
I also added a ādistroā target to the Makefile. Currently it only creates the weather app zip file. I also can automatically upload it to google drive with the use of gdrive but I comented that out for now).
So givent that, if you still want it, Iāll be glad to create a pull request.
I also have a problem. I have 2 Ruuvi tags, and one of them got stuck into ābooterā mode. I can access it, upload zip and what not, but it is stuck in booter mode and the app wonāt startā¦ even after pressing button, removing the battery,ā¦ etc. I donāt think it is a problem with the uploaded app, since the other Ruuvi was running the same app and I tried uploading the standard app. So I am afraid that the button is stuck. Any advice?
After a few tries, uploading my app, the thing resets itself properlyā¦ no idea why.
Well I was looking at your updated codeā¦ and I think there is a bit of a problem with the BURST mode (I havenāt tested anythng yet ;)) In the burst mode, you set High Resolution bit, i.e. 12 bits and use the FIFO. The problem is that the manual states (3.6)
Me againā¦ I hope I am not bothering you, well not too much anyway.
Iāve looked more into your updated LIS2DH12 module. Iāve actually (locally) made a number of modifications to it as well as the āmain.cā in the weather app to reflect the changesā¦ Now I am stuck cozā I need to debug this thing and that requires hardware I donāt have.
Anywayā¦ there is a number of issues I want to raise about that updated driver.
1- I do not think FIFO mode is properly set
The app does set the LIS2DH_FIFO_EN_MASK on Reg5 but
it does not set FIFO_CTRL_REG, which I think means it is still
in bypass mode
2- I really thing that when using the FIFO, you should use the stream mode.
it should really simplify your life... essentially it will take care of itself
You can also avoid the reset in timer_lis2dh12_event_handler (which I thing you were
doing wrong anyway the reset should occur with FIFO_CTRL_REG not Reg5)
3- g_sensorData should have a size of 32, which is the maximum possible number of data you
can read from the FIFO, and you should use FIFO_SRC_REG to figure out how many
data can be read. Currently it is way too ad-hoc.
4- Combining 2 and 3 above, you should be able to handle every case without much trouble.
5- LIS2DH12_getALLmG should return LIS2DH12_RET_NULL when all data have been
read from the "cache"
6- When reading the data, the weather app should get to the latest one, something like
(depends on 5)
Thanks for the feedback, thereās a reason on why the driver is not yet merged Weād be happy to help with debugging, Iāll PM you the details. Please join our slack channel if you havenāt already (send email to info@ruuvi.com), Itās generally quicker to get answers in there.
I havenāt yet had time to look at the pull request / driver changes in detail, Iāll do that in next few days
I am starting to get my head around how the thing works.
I have now a version of the Weather Station application that will update the accelerometer data in āreal timeā . It can be retrieved at Experimental Weather Station app (It works for me, but use at your own risks)
In this version, the environmental variables (temperature, humidity, pressure) are updated every 5 secs like in the original, but the accelerometer data will be updated faster. Like in the original, the beacon advertises data at 2Hz.
Pressing the āmode changeā button will loop through the following modes:
Eddystone URL
This is the same mode as before. Only temperature, humidity and pressure are
available through the broadcast URL
High Resolution
This is similar to the previous highres mode. The accelerometer values are sampled
and updated at 1 Hz. Use 10 bits, normal power mode (2 ĀµA) at 1 Hz
High resolution mode 2
This is similar to the High Resolution mode. The accelerometer data are sampled
at 10 Hz and updated at 2 Hz. Use 10 bits, normal power mode at 10 Hz (4 ĀµA).
High Resolution mode 3
The accelerometer data are sampled at 25 Hz and updated at 2 Hz. Use 8 bits, low power mode at 25 Hz (4 ĀµA).
In both mode 2 and 3, the sample selected to update the beacon value is the one presenting the largest variation to the theoretical rest value i.e.
abs(1000 - sqrt(x**2 + y**2 + z**2))
Note that in mode 3, because it is using 8 bits (i.e. 16 millig values) you never get 1000, only 992 or 1008.
45 ĀµA on mode 4
Iād expect battery life to be 2-3 years in indoor environment.
Youād might be interested in Nordic tutorial about radio event notification: that should allow you to raise interrupt right before advertisement is sent and update the data, allowing faster data rates and smaller delay between sample and broadcast.
Interrupts is a good idea, and we could get rid of the intermediate buffer as long as the sampling and broadcast rates are compatible.
I was thinking more along the lineā¦ Broadcast the environmental data more slowly (say 30/60 secs) using the Eddystone URL (reusing the IMO useless id byte to provide extra precision for temperature whilst remaining compatible with the current scheme) and use an āImmediate Alert Serviceā profile to signal movementā¦ but I still have a lot of question marksā¦( is IAS possible over a LE conect?)
Implementing BLE services is possible, although there is a learning curve.
The way I started was to take Bluetooth Developer Studio -example from SDK and then implement services with BDS.
When you have the Nordic plugin for BDS installed, you can automatically generate code for BLE standard profiles and your own profiles. Nordic has also implemented some standard services in the SDK.
Iām wondering, is it possible to show air pressure as QNH (ie at mean sea level), which is used in weather forecasts. Currently it seems to show the air pressure as it is at the present location (QFE). I suppose it would only need a simple altitude correction.
Doing altitude correction is somewhat tricky, as you need to know the altitude of the tag. Maybe you could measure the altitude while installing and add a correction factor to your receiver?
Actually the tricky part for me is adding the correction factorā¦ I know the altitude, but have no clue what to do with itā¦ Is there a āhow-toā guide somewhere?
Iām new to this and not really a programmer, but I wanted to ask if thereās a way to integrate the weather station data as a room sensor in the iOS Home App? Iād like to have the data show up in there without having to load the web page for each sensor.
A friend who is a programmer suggested Homebridge but I didnāt get any hits for that in the forum. Does anyone know if this is something thatās being worked on?
Thanks
I took a quick look, it seems that Homebridge runs on Raspberry Pi 3 and NodeJS. As we already have NodeJS code for receiving and interpreting Ruuvi advertisements available, it would certainly be doable.
I have the android weather station app working fine on ruuvi tag.
I understand you are about to bring out iOS version soon.
Perhaps on this version, you could improve the alerts in terms of adding vibration alert option as well as longer/stronger alert tones. If you use tag for say lost luggage, then vibration alert is essential. Also, in android if you get one notification on screen, then further notifications are silent until you clear all other tag notifications. It would be great to improve alerts as above in new iOS app ?
Also, can you use commercial bluetooth gateway with wifi to connect to say Streamr service and do you recommend one suitable ? Can the phone be used as gateway to Streamr service ?
We do not officially recommend any commercial WiFi-BLE gateways as of right now but weāre using Raspberry Pis ourselves. You could also look into Rigado, their gateways might suit your needs.
The Android app Ruuvi Station can be used to send data to a proxy server which then relays data to stream, for example with https://github.com/ruuvi/ruuvi.streamrproxy.js. .The library is at alpha stage, but Iām running it at stream.ruuvi.com. You can set up the Ruuvi Station to use stream.ruuvi.com/ruuvistation as the gateway url to send your data to me, or you can clone that repository on your server, run NPM install and copy the example configuration to āstreamr-configuration.jsā . Then youāll need to route the port 80 on your server to the nodes application port or configure the gateway URL to send to your serverās port.
If there is enough interest in this weāll make proper tutorials and docs on streamr integrations.
Iāve been interested in this for some time. I have Ruuvi tags in my boat and am tracking inside, outside, and motor room temp/pressure/humidity and acceleration. Iād like to implement a graph/trend served file on my raspberry pi.
Do you mean a setup where you have a raspberry pi collect the data from tags and then serve graphs of the data? If so, you may be interested in this setup. In the comments near the bottom thereās an updated, pre-made raspberry pi image if you donāt want to setup the individual parts yourself
I had ruuvi mobile station working fine until I installed IoTool and now neither app works !
Data does not change in weather station display and Iotool app does not pick up ruuvi tag. Tag seems to work on core beacons app. Any ideas to get both of them working ?
Thanks