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

I’ve 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’ve 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’ve really done a great engineering job on these little tags!

Just recently I discovered the additional capabilities provided by hacking the tag’s 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’m wondering what the most straightforward way is to get the vibration firmware running given that I don’t 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’t (or shouldn’t) 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?


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’re 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’ll 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’m actually more interested in the acceleration streamer example, since I’d 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 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’s 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’s 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’t 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: