Provide mechanism to adjust tune-able parameters (example advertising interval) - enhancement

[DG12]

Various values including advertising_interval, main_loop_interval, ble_tx_power, oversampling and log interval should be configurable by users. This has been requested many times. The current approach requires the user to have extensive C programing knowledge, understanding of the firmware structure and ability to set up the tool chain. This approach is arduous and error prone.

An implementation can be to use static variables for these items and initialize them to defaults with DEFINEs. These are updated during initialization from Non-volatile memory. This change requires very little effort.

Once this is done a user, friend or ruuvi staff(for a fee) can modify the defaults with the Ruuvi Development Kit and some documentation.

To remove the requirement of purchasing the Ruvvi Development kit and reduce the possibility of errors a friendly utility can be written which explains the various tune-able variables, the ramifications of changing them and accepts user updates . It validates the values as the user enters them. (see demonstration implementation at http://www.MyBeacons.info/tune.html)

When the user has completed the desired configuration it creates a Device Firmware Upgrade file.

This is then flashed to the tag using nRFconnect to the "User Information Configuration Registers" (UICR). There is no concern for wear as this area will be written to rarely. This is a 32 word area which is more than sufficient.

The core firmware can be revised without needing to re-establish the tune-ables likewise the tune-ables can be modified and updated without the need to re-flash the core firmware. This allows the user to easily test various values. Multiple tags can be easily flashed with the same values.

When a tune-able is added or changed it is only necessary to revise the user utility.

Discussion about this issue began 2 years ago as referenced in ruuvi/ruuvitag_fw#152.
I bring this up again as users have recently required assistance getting the necessary source and tool chain working when all they wanted to modify 1 or 2 of these variables.

[ojousima]

I agree that having e.g. a mechanism where people could configure the tags in Ruuvi Station over GATT would be a nice to have, but the effort/usefulness ratio of adding the mechanism isn't very good compared to other work.

[DG12]

If you could implement the use of static variables and initialize them from UICR that would at least allow update by Ruuvi DK. Perhaps someone else would write a means to set UICR.

[ojousima]

The problem with making features available for everyone is that it also implies future support. Someone would end up using the UICR + devkit configuration for thousands of units, and we'd have no other choice than to support it. Eventually, when the number of configuration options would exceed the area in UICR we'd need to implement an alternative mechanism. Then we'd need to support and test for coexistence of both mechanisms.

I do understand the need and usefulness of having certain configuration options in UICR for easy setup. However, to implement such configuration in official branch of firmware the feature must be future-proof enough so we can commit to supporting it.

[thauta]

Do we have some documentation on what to modify if I would like to e.g. decrease advertisement interval, and try to compile it myself?

[DG12]

Have you tried the debug image? It runs faster.

It should be as simple as modifying :
ruuvi.firmware.c/src/application_config/application_mode_longlife.h

See ruuvi.firmware.c/src/application_config/application_modes.h for additional notes.

See https://github.com/ruuvi/ruuvi.firmware.c for details about setting up the environment and compiling/linking and making the image.
Do you have the Nordic & Ruuvi Devkits?
Why do you want to decrease the interval?

[d3lity]

On page https://ruuvi.com/software-update/ it says:

New firmware version has only one broadcasting mode. It’s not possible to switch between fast and slow broadcasting mode using the button on PCB. Special firmware version with slow broadcasting interval will be released later.

When can we expect this slow broadcasting firmware version?

Or somekind of extreme battery saver firmware for those tags in very hard to reach places and for cheapskates.

I updated one of my tags with nRF Connect from 2.5.9 to 3.31.1 and noticed too late this (v3.30.3 note) :

To install 2.x firmwares a wired connection (i.e. Ruuvi and Nordic development kit boards and USB cable) are required.

[ojousima]

When can we expect this slow broadcasting firmware version?

I added issue about this to next release so it will be prioritized. I cannot promise exact schedule, but it will be included. It should be noted that smart phones have difficulties with connecting to slow advertising tags, which makes a lot of 3.X features unusable on them