Updating factory-shipped firmware

Hello all,

As you may have noticed, Google is planning to discontinue the Nearby Notifications. This means that the 1.2.12 firmware which currently ships with button-activated mode change into URL-mode will be obsolete.

As our user base has grown we have received some great feedback, now would be a great time to address the ideas for next software version.

  • Should we bring the 2.X branch / GitHub master out of beta? So far I haven’t heard anyone saying that they’d gone back to RAWv1 or URL mode after starting to use the RAWv2 format.
    On the other hand, a lot of users are perfectly happy with RAWv1 as it is, and update would probably break some existing applications.
  • Battery measurement: Current battery voltage is not a great predictor of remaining runtime, especially in cold temperatures. It seems that we could get better results by synchronizing the ADC to radio transmissions.
  • Button: Current process to enter bootloader by holding down button B while tapping R is a bit cumbersome. Maybe a long press on button “B” could trigger a reset and start tag on bootloader?
  • Button: As the URL mode is no longer useful, what kind of action a short press should trigger? Switching between RAWv1 and RAWv2? Fast mode and long-life mode?
  • GATT: So far the GATT profile which ships with 2.2.2 has caused more confusion than new use-cases. GATT-connectible devices show up on bluetooth scans for headphones etc which some users find annoying. There’s also a security concern on allowing DFU updates without physical access. Have you used the GATT profile for something, or should we disable it by default?
  • NFC: Some kind of NFC event when the NFC field is weak can lead to a hangup in NFC driver and lead to increased current consumption. We’re investigating how to fix this issue.

Please let us know your thoughts on these matters as well as anything else you’d like to see

1 Like
  • Should we bring the 2.X branch / GitHub master out of beta? So far I haven’t heard anyone saying that they’d gone back to RAWv1 or URL mode after starting to use the RAWv2 format.
    On the other hand, a lot of users are perfectly happy with RAWv1 as it is, and update would probably break some existing applications.

I’d bring it out of beta and make the RAWv2 the new default, something will always break eventually so it’s not that big of a deal. A bigger issue/risk in my opinion is the “Windows XP syndrome” where something old and obsolete stays the “norm” for so long that developers start to assume it will always be like that and take shortcuts and/or hardcode stuff, rather than taking future updates and compatibility into account

  • Button: Current process to enter bootloader by holding down button B while tapping R is a bit cumbersome. Maybe a long press on button “B” could trigger a reset and start tag on bootloader?

:+1: for this idea, long press of B should just reset the tag, and having B pressed while booting should enter the bootloader as it is now, that way people can still keep using the “old way”

  • Button: As the URL mode is no longer useful, what kind of action a short press should trigger? Switching between RAWv1 and RAWv2? Fast mode and long-life mode?

I’d pick the latter one, and in fact I have my custom firmware do exactly that, which may be of use

  • GATT: So far the GATT profile which ships with 2.2.2 has caused more confusion than new use-cases. GATT-connectible devices show up on bluetooth scans for headphones etc which some users find annoying. There’s also a security concern on allowing DFU updates without physical access. Have you used the GATT profile for something, or should we disable it by default?

In my opinion it’s better to disable it by default but have a convenient way to enable it if someone needs it. Having it enabled by default serves no purpose for users who don’t need it or even know about it, and will just result in lesser security as well as worse battery life if the tag needs to be listening for connections

I would mostly support what Scrin said. Hell yeah, go ahead, break things… (;

About the usage of buttons: Would it be possible to have some sort of factory reset, maybe by pressing/holding buttons while powering up? The hardware of the tags is so versatile, there will probably never be one-size-fits-all sort of firmware, so it should be easy and inviting to experiment with different firmwares. On the other hand, flashing a firmware always feels a bit scary and risky, especially for beginner to medium level users, when updating ota, and without access to a devkit.
So having a reliable way to undo whatever can be done to a tag with ota updates would imho really help.

So ideally resetting would:

  • re-instantiate the default firmware (like a from a shadow firmware - i think we see this more and more on IoT devices these days)
  • or, if this not possible (e.g. because of size), at least erase the last ota’d firmware und put the tag in a mode where a new firmware can be reliably ota’d
  • erase all data and stuff (i still have tag around that ‘magically’ acquired a name while playing with firmwares which it is not willing to forget ;))
1 Like

Interesting ideas. Having an “actual” factory reset would require “bundling” the “original firmware” with the bootloader, which would increase its size, though as far as I’ve understood the firmware size is rarely an issue on ruuvitags so it could work I guess.

On the other hand a “full erase” feature on the bootloader would be useful, if its possible. It has been observed numerous times in the past how leftover data from previous firmwares have caused odd issues with new firmwares, which have been often resolved by either fully erasing the tag with a devkit, or flashing a special “erasing firmware” first and then the intended firmware after that, which is probably not the best experience for inexperienced users :thinking:

Regarding “change / break things” remember that this is not a web application, nor is it a phone/tablet app where once a change is made everyone get’s it. Users only get “new” code when they specifically install it. Unless they are adding to their fleet of tags and they already have old code.

Why not have the tag support BOTH RAWv1 (aka 03) AND RAWv2(aka 05) formats! Use button to cycle through formats. The version I am currently using supports several formats.

Many tune-ables should be available via NFC rather than providing alternate sets of modes.
For example

// Initalize “tunables” from header file values. Might be changed by NFC command: ToDo (some day)
static uint16_t ble_tx_power = BLE_TX_POWER;
static uint16_t advertising_interval_raw = ADVERTISING_INTERVAL_RAW; // why are these even different??
static uint16_t advertising_interval_url = ADVERTISING_INTERVAL_URL;
static uint16_t advertising_interval; /* not tunable set by execution /
static uint32_t main_loop_interval_raw = MAIN_LOOP_INTERVAL_RAW;
static uint32_t main_loop_interval_url = MAIN_LOOP_INTERVAL_URL;
static uint32_t main_loop_interval; /
not tunable set by execution */
static uint16_t lis2dh12_activity_threshold = LIS2DH12_ACTIVITY_THRESHOLD;
static uint8_t lis2dh12_scale = LIS2DH12_SCALE;
static uint8_t lis2dh12_resolution = LIS2DH12_RESOLUTION;
static uint8_t lis2dh12_samplerate_raw = LIS2DH12_SAMPLERATE_RAW;
static uint8_t lis2dh12_samplerate_url = LIS2DH12_SAMPLERATE_URL;

Thank you all for the feedback.

Having a complete factory reset would be somewhat tricky and it would reserve quite a bit of flash which would be a problem for the Espruino.

Bootloader itself remains as it was unless user explicitly overwrites it, and it can always be entered by holding down “B” at boot. There are some corner cases which prevent the bootloader from operating properly, but those are generally not repeatable.

This specific case is probably caused by your receiver Bluetooth hardware, at least my Mac remembers last name it has seen on a tag even if I stop broadcasting it. Erasing all stored data, especially Eddystone settings would great though - right now there is no way to recover a forgotten Eddystone password on a tag as the settings are stored on location which does not get overwritten.