Official Ruuvi App: Weather Station

Hi,

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.

Cheers,
François

Hi,

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)

Not 12 bits…

Cheers

Thanks for the report, looks like 10-bit mode would be better in this use

Hi,

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)
              while (LIS2DH12_RET_OK == LIS2DH12_getALLmG(&accx, &accy, &accz)) {
                    acc[0] = accx;
                    acc[1] = accy;
                    acc[2] = accz;
              }

Just my 2 cents… Now, what do I need to debug this thing?

Regards

Hello,

Thanks for the feedback, there’s a reason on why the driver is not yet merged :wink: 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

Hi,

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:

  1. Eddystone URL
    This is the same mode as before. Only temperature, humidity and pressure are
    available through the broadcast URL

  2. 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

  3. 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).

  4. 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.

If you use it, let me know what you think.

Cheers

1 Like

Nice work!

I power profiled the application, on average:

  • 33 µA on modes 1 & 2
  • 40 µA on mode 3
  • 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.

Thanks

I am new to this, but that seems quite good.

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?)

Cheers

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.

You can check the feature-webble branch for example, and associated web bluetooth site for connection example ( sources). Both are still at alpha-stage.

Hello,

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.

Sami

Hello,

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 found these, does it help?
https://learn.sparkfun.com/tutorials/bmp180-barometric-pressure-sensor-hookup-#measuring-weather-and-altitude
https://forum.arduino.cc/index.php?topic=63726.0

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 ?

Hello,

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.

1 Like

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