Vibration monitoring example - How to DFU to a new tag?

I鈥檝e been using RuuviTags for a while now to monitor environmental conditions at our garden plot (off-grid via GSM) and have been very impressed with their reliability and longevity. I鈥檝e just recently replaced the first battery after around three years of continuous outdoor operation, which is absolutely amazing for a device reporting measurements wirelessly at a rate of about one per second. You鈥檝e really done a great engineering job on these little tags!

Just recently I discovered the additional capabilities provided by hacking the tag鈥檚 firmware, in particular the vibration monitoring example discussed in the blog caught my interest. So I ordered a brand new RuuviTag Pro to try and recreate that example (is that even a good idea since the example is ~3 years old, were there any hardware changes in the meantime that would cause issues with codes from these older blog posts?). Since the example code is based on nRF SDK 15.2 but my tag came with a quite recent (15.3 based) firmware, I鈥檓 wondering what the most straightforward way is to get the vibration firmware running given that I don鈥檛 own a cable or DevKit for flashing firmware updates? I tried flashing the app-only as well as app+sd built from source code via DFU, both resulting in a continuous red light and no operation. I understand I can鈥檛 (or shouldn鈥檛) downgrade the bootloader to SDK 15.2, are there any other options to get the vibration firmware uploaded to my tag? Or should I use one of my older RuuviTags (1.2.12 firmware) and upgrade using an app+sb+bootloader DFU images built from the example code? Is a cable connection the best option for flashing the older firmware examples from the Ruuvi blog?

Hello,

The firmware in linked blog post works only up to RuuviTag B6 revisions. Later boards have hardware changes, most importantly sensors are powered by GPIO pins in RuuviTag B8 and RuuviTag Pro board variants. It should be compatible with your three year old tag.

It is best to have a wired connection to tags if you鈥檙e working with experimental firmwares, especially across SDK versions. If you want to try the blog version, you can try to update your 1.2.12 tag with DFU to 3.31.1 and then to acceleration broadcaster with Release Acceleration broadcaster 路 ojousima/ojousima.logger.c 路 GitHub, but after running those updates the tag needs a wired connection to return back to 1.2.12, 3.X or Espruino/Eddystone firmwares. Also if something goes wrong with the updates, you鈥檒l need a wired connection to unbrick the tag.

Thanks @otso, that makes a lot more sense now! I will try with one of the older 1.2.12 tags then. I鈥檓 actually more interested in the acceleration streamer example, since I鈥檇 like to analyze the high frequency vibration data outside the tag, like it is done in the first vibration blog post. I assume the DFU package you linked to was produced by this line in package.sh script, right? So if I run this command on the build output from the acceleration streamer branch, I should be able to generate the corresponding DFU package for that branch, right?

Regarding the wired connection, I read that I could use a TagConnect TC2030-CTX-NL in place of the DevKit. Would I still need a programmer (like J-Link or the nRF52-DK) if I go with the TagConnect, or would the cable itself suffice for flashing firmwares to the RuuviTag? The DevKit looks a bit steep for what I have in mind, but if the cable needs an additional programmer, then there is not much to be saved by going the cable route I guess.

It might and should work with the application hex, but it鈥檚 a good thing to have a wired programmer to rescue tag if it goes wrong.

You need some kind of a programmer to go with the cable. nRF52 devkit works, Segger has some programmers that work too. It鈥檚 possible that someone has made a Raspberry Pi HAT or similar to act as a programmer too. In any case, you need something to connect to your PC for programming the other end of the cable has 10 pins at 2x5 1.27mm pitch header.

I tried and couldn鈥檛 get the app hex flashed. nRF Connect would just immediately quit the transfer once I selected the file, no progress bar shown as for successful DFU transfers.
Anyways, I decided to go with the wired connection for further experimentation and just ordered a DevKit :smiley:

Hi @otso ,

would it be possible to get an updated version of the Vibration monitoring example?

I鈥檓 also interested in analyzing the accelerometer data stream in real time outside the tag. I ordered a recent tag just to discover that the example is not relevant anymore :-/

There are a lot of examples for environmental sensors, but none for the latest tags if you want to use the accelerometer.

I have updated version of broadcaster code here: GitHub - ojousima/ojousima.acceleration_bcast.c: Acceleration Broadcaster for RuuviTag Pro

While it does not send raw data over GATT, you could replace the function here: ojousima.acceleration_bcast.c/app_sensor.c at 2c5ca2a3b204314fe6d609c979722f15ea4e0532 路 ojousima/ojousima.acceleration_bcast.c 路 GitHub to output the contents of fifo_rambuffer.

The acceleration and vibration monitoring examples have to be tailored to the application which is why we don鈥檛 have one ready-made package for testing.

I am very curious as to what you would like to use the acceleration readings for.

How would you actually do this? I鈥檇 like to gather the acceleration data from a system. With the data I could improve the efficiency of my system by tweaking little things.

I鈥檓 trying to determine the flight time of an object, so the ~100Hz sample rate just isn鈥檛 enough.

Ruuvitag could work like magic in my case if I am just able to read the acceleration values from the tag fast enough.