NRF51822 Beacons Stop Transmitting After Several Hours Without Firmware Changes

[fansel]

I've been experiencing an issue with NRF51822 beacons purchased from AliExpress(http://www.holyiot.com/tp/2019042814310092401.pdf). These beacons work as expected for several hours but then unexpectedly stop transmitting. This issue occurs without any modifications to the firmware (besides patching the firmware with the keyfile .

Steps to Reproduce:

1.Follow README.md precisely with 3 keys per device 2.The beacon transmits signals normally for several hours. 3.After a few hours, the beacon stops transmitting without any manual intervention or apparent cause or change of iPhone nearby.

Expected Behavior: The beacon should continuously transmit signals until the battery runs out.

Actual Behavior: The beacon stops transmitting after several hours of normal operation.

Troubleshooting Steps Taken:

Restarted the beacon, which resumes normal operation for a few hours before the issue reoccurs. No firmware updates or changes were made prior to this issue. Beacon Model: NRF51822 (AliExpress no external crystals. So I used Board_simple) Used a BLE tracker to check if signals are still being received from nearby devices.

Additional Information: This issue has been observed in multiple units of the same model.

[fansel]

Hey @rkreutz, I noticed that you've added support for nRF beacons without external crystals to acalatrava repository https://github.com/acalatrava/openhaystack-firmware. I'm suspecting that the issue I'm encountering might be related to the internal crystal of the nRF chip. During your work on this project, did you face any issues associated with the nRF chip's internal clock, or do you have any insights on this? I'm quite new to BLE programming and struggling with debugging the beacon.

[rkreutz]

The issue I had was mostly related to the chip not having an external crystal and thus not sending any signals, using the internal crystal should work unless your chip is busted somehow. Sorry I can't be of any much help...

[rkreutz]

Actually @fansel you mentioned you simply patched the firmware rather than building it then patching, could you maybe try building the firmware from source with the board config without external crystal, then patching and finally flashing it?

[fansel]

Just tried that, I will keep you posted how it goes. So far no device advertised longer than a few hours with the precompiled software of this repo. So I guess tomorrow evening I will know more. I also flashed acatravas software to a few devices yesterday and they already advertise for over 26 hours. By the way, thanks a lot for your implementation of the open-haystack Mac client. Runs perfectly fine! 👍 My only thought is that it would be very nice if I only had to run one server for fetching the reports and still be able to use both clients. (Macless-haystack and the native mac app) If I have some time in the next couple weeks, I may will be able to look into it :)

[rkreutz]

Aaa you were using macless-haystack firmware, I haven't tried it tbh, I'd suggest sticking with alvacaras implementation, been running a couple beacons with it for over six months now. As for the apps, there is a mobile app on openhaystack as well that should pretty much with the server I've put up, alternatively shouldn't be too hard to tweak macless-haystack to use the same request/response as openhaystack. Good luck 👍

[jrperson]

My tags are doing the same thing using the macless firmware. I first noticed this with the pre-compiled firmware that I loaded onto the Aliexpress NRF51822 (no external xtal). I then tried compiling the macless firmware myself and got the same result. I noticed that macless used "BOARD_SIMPLE" by default and didn't have the C class that alvacaras has for "ALIEXPRESS_BOARD_NO_XTAL_H". So I updated the macless firmware to use that board type and compiled and run into the same issue still. I would just run the alvacaras firmware, but I really want to run multiple public keys. My guess is something with the key changes is causing a failure. I am starting a process of debugging to find out what is happening. So, nothing new to add yet other than I am having the same issue and haven't found a quick solution yet.

[rkreutz]

You guys mentioned it stopped working after a while, would it coincide with the key being rotated? Maybe is some issue with the timer to rotate the keys on a board with no XTAL? Or maybe you are fetching the records with the wrong key?

[dchristl]

Unfortunately, the implementation for the nrf51/nrf52 might not work well. Although I've had a chip running for several months, I can't thoroughly test all variations. Additionally, these chips are relatively expensive and very power-intensive (when changing keys). Unfortunately, I couldn't resolve this with the help of support. Therefore, I would consider the firmware in this repo deprecated/not supported anymore. However, I'm happy to accept pull requests.

[jrperson]

You guys mentioned it stopped working after a while, would it coincide with the key being rotated? Maybe is some issue with the timer to rotate the keys on a board with no XTAL? Or maybe you are fetching the records with the wrong key?

That is where my hunch has me digging.

I'll keep digging and post what I find here. @dchristl I'll post a pull request if I get it figured out.

[jrperson]

Update: I think I figured out the source of the problem: using rtc1 directly. I swapped out the rtc1 timer to use app_timer instead and ran a test with 1 minute key change interval and it ran fine over the course of a few hours. I just flashed the same firmware with a 30 minute key change interval and will do a long term test. I'll let you know tomorrow how it went.

[dchristl]

Thank you, I'm happy if you open a pull request after successfully tested and I will release it.

[jrperson]

My testing has been working perfectly for over 24 hours now. I just pushed a pull request.

[fansel]

Wow great, i will check it out!!