Alternative firmwares for nrf51822, nrf52810 and nrf52832

[pix]

Hi, shameless plug here: https://github.com/pix/heystack-nrf5x

I managed to convert an old Tile tag (with an nrf52810) to Haystack.
I used alcatrava's firmware as a base too and fixed some potential memory leaks and updated the SDK / Makefiles.

The code is running since two days, without problems for now.

[dchristl]

Hello,

Thanks for the info, if I ever have time I can include this as an alternative in the documentation. Does your firmware support changing keys/mac?

Kind Regards,
Danny

[pix]

Yes. More than 4500 keys on a nrf51 :-)

You might want to wait until this issue is ironed out. I have a branch with a fix, but I'm waiting for new hardware to test things out.

make all supports building release binaries, which can be patched using the old xxd way.

[dchristl]

Sounds great. Did you happen to take measurements of the power consumption? I had the problem with the firmware that the power consumption was significantly higher with changing keys. By significant I mean about 10-15 times shorter lifetime compared to 1 key to several. This was probably due to the wake up (key - Mac change) and I couldn't solve this with the Nordic forum either. That's why I no longer use my firmware, because changing the battery every month is annoying and expensive

[pix]

Not at the moment -- still looking for a chance to get my hands on an oscilloscope :)

I didn’t run any calculations, but there’s a malloc() issue causing RAM clogging:

uint8_t setAdvertisementKey(const char *key, uint8_t **bleAddr, uint8_t **data)

These allocations are never freed. Also, the keys are stored in RAM instead of being marked as constant, which can cause more frequent resets due to memory faults. Plus, increased RAM usage leads to higher power consumption since more RAM blocks stay powered during sleep.

That could be part of the issue.

[ctandi]

Did you happen to take measurements of the power consumption?

I did, with the Nordic Power Profiler Kit 2 :)

The HolyIoT YJ-16013 (nRF52832) sitting on my table right now is running with an average current draw of 14 µA (2000 ms Advertising Interval, 4 dBm, 80 Keys, 900 sec. rotation interval). I tried setting it to the external 32 KHz oscillator, which I heard could reduce the power consumption even further. However when I edit the sdk_config.h the SoC crashes with

[nrf52.cpu] halted due to breakpoint, current mode: Thread 
xPSR: 0x81000000 pc: 0x00027068 msp: 0x2000ffc0

The HolyIoT 17095 (nRF52832) averages at around 20 µA with the same settings as the 16013. It doesn't have an XTAL.

A HolyIoT 21014 (nRF52810) with 60 keys (rotating every 900 secs) advertising every 3000 ms takes around 10 µA. I also haven't tested using the XTAL instead of the internal source with this model yet.

The no-name beacon with an nRF51822 that I have draws 18 µA with the internal RC circuit and 16 µA with the XTAL in use. (2000 ms, 4 dBm, 40 keys, 900 secs rotation)

[pix]

Thanks for the measurments. I got my hand on a OWON-VDS1022.

I got my first snaps of the sending and key rotation power consumption:

It's been years since I touched an oscilloscope, and my shunt resistor is, well from the back of the drawer, but i'll be able to validate my measurement skills with your input ! Thanks :)

Anyway, the left part show the power profile of waking up from sleep to update the advertising key. On the right is a single transmission (on the 3 channels if I remember my bluetooth correctly)

[pix]

I tried setting it to the external 32 KHz oscillator, which I heard could reduce the power consumption even further. However when I edit the sdk_config.h the SoC crashes wit

I think I tried something like that and failed too.

A HolyIoT 21014 (nRF52810) with 60 keys (rotating every 900 secs) advertising every 3000 ms takes around 10 µA. I also haven't tested using the XTAL instead of the internal source with this model yet.

If you have optimized settings XTAL settings for the HolyIoT (or other), I could add the relevant board headers and flags on the project to build them more easily. That would be great 👍

[vasimv]

NRF51/52 has switching DC-DC regulator (to efficiently convert input voltage into lower voltage the microcontroller uses), it does reduce power consumption greatly if input voltage is more than 2 volts (in comparison with default LDO regulator). It saves much more power than installing 32.768kHz quartz, but requires inductor and few capacitors on the board. Most of boards have the inductor, so you have just enable the DCDC regulator to lower power consumption significally.

[pix]

FYI: I added dcdc build variants (I didn't enable it for yj17024 as low power consumption may not be the target for this board, I might be proven wrong)

I used this:

#ifdef HAS_DCDC
    // Enable DC/DC converter
    COMPAT_NRF_LOG_INFO("Enabling DC/DC converter");
    uint32_t err_code = sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE);
    APP_ERROR_CHECK(err_code);
#endif

Is that enough ?

make all at the root will build all the variants.

[vasimv]

Ugh, not sure how you set it in old nrf52 sdk, sorry. For zephyr SDK this is "CONFIG_BOARD_ENABLE_DCDC=y" in prj.conf at compile time. Probably, "#define POWER_CONFIG_DEFAULT_DCDCEN 1" for enabling by default.