Problem with repeater with nrf52840-dongle

Hi Wassim,

I am actually making a project based on your project and I have a problem with repeaters and I was wondering if this problem had occurred to you in any way. I am using the nRF52 to read temperature and voltage and I needed a repeater to get the packets to a raspberry Pi. The problem is when I use the repeater, there is a bug that happens that makes all my nrf52 idle for the packets reception. They continue transmitting but can’t receive. I know that the problem comes from the Repeater because when I reset it, everything goes back to normal.

Thank you

Ok, we can debug that. I have some repeaters running stable for more than a year, and did not notice any instability, which means, if an issue appears, it would appear at once so can easily be tracked and fixed.

I’ve been using the NRF52840 for the sensor nodes, but for the repeaters, my currently deployed system is based on the uart dongle that has an nRF52832

But I used the nRF52840 usb dongle as gateway too. So to be sure we can identify the issue you have can you provide more details about your repeater hw and sw ?

  • hw : is it the official nRF52840 usb dongle or any other custom nRF52840 pcb design ?
  • sw : are you using the directory 08_usb_dongle ? Did you paych the sw or modify it ?
  • also, do you fall on the issue right away from start up, or how long till the reception stops ? Does the reception systematically fail after some time or any noticable event like switching more sensors or does it happen randomly ?
  • can you try with an nrf52832 ? Just to compare ?
  • did you configure the user registers config to enable repeat functions ?
  • can you debug with printf and a connected dongle ? Can you debug with gpio ? Do you use Ozone ?

Many questions just to narrow the problem down and see if I can reproduce it.

For info, I’m rewriting the mesh framework on Zephyr, but it’s not complete yet, so the nrf sdk version is the one that can be used in deployed systems as of now.

  • hw: it is the official nrf52840-dongle even tho I will probably make a custom design in futur updates
  • sw : I am using de 08_usb_dongle and I modified it for the purpose of my project
  • the issue is not coming right at the start and the reception is stopping after a random timelapse from 15 mins to 6 hours.
  • I do not have the nRF52832, I didn’t find this model on the site of any seller I’m buying from
  • do you mean the “is_router” configurations ? If so, i did configure it but I do not use UICR configuration anymore since I wanted to be able to modify those configurations directly with the mesh network
  • I can’t debug with the connected nrf and I didn’t try GPIO debugging, I do not use Ozone

You should know that I do not send packets in broadcast like the 08_usb_dongle project initially do and I want my repeaters to be able to send their own packets too.

Ok, I see, we can proceed in steps. I’ll test the usb dongle repeat function and you can try to test an unmodified sw if possible, or minimally modified. You can also flash the 04_uart_dongle over your nrf52840 with minimal changes.

As I’m running the 04_uart_dongle for years now, that is the most reliable, we have to narrow dow if the issue comes from :

  • shifting to the nRF52840
  • shifting to the 08_usb_dongle project
  • adding your changes to customize the project

One way or the other, we need a debug vector to catch the bug, I assume we’re left with printf on your side usb or uart. Can you connect a uart pc to a pin of the dongle , if needed ?

Also just to better understand the context and the needed sw quality, is this an academic project or a commercial or industrial one ?

I will try to start a test with the 04_uart_dongle for the night.

Is it possible to debug with the JLINK or what setup could I use for debugging, that’s a point I was wondering …

It is a R&D project so it could be use as commercial.

The 04_uart_dongle project wouldn’t work over the nRF52840-dongle so I started an old version of the 08_usb_dongle to see if the problem persists.

yes, if you need to modify an existing firmware or write your own, some sort of issues can only be solved with a debugger, dumping all registers at each step is not realistic.

Below some notes, Ozone is not specific to Zephyr I use it with the nrf sdk project, all you need is to load the .elf file

When it comes to the nrf52840 usb dongle, it is intended for debug, you should rather use the dev kit first, it’s much easier, nevertheless, I also developed a 3d print for pogo pin adapter that allows to debug the usb dongle too, available here, see also the gallery

The 04 directory, can be adapted to nrf52840, or using 08 as is, is a good start, that is not a simple firmware, just a warning, as it is using queues to optimise packets throughput, in case you mixedadditional transmissions, it might create a conflict, but we’ll see this step by step.

I have been able to debug with Ozone and my JLink, now i didn’t find the .elf file as mentionned, is it supposed to be created by the MakeFile ?

I used the .out file instead but I don’t really know how I could print out things to my debugger.

My test with the 08 was not successful, I still have the same issue.

I have been able to run with a repeater for over 16 hours now by disabling the “is_listening” config on the dongle which is not a repeater. Can that be the problem ?

  • First yes, the “.out” is equivalent to the “.elf” as it contains all the debug information for step debugging.

  • For printing, I used the log functions e.g. see “NRF_LOG_INFO” that has output on a uart tx pin. Theoretically, it’s possible to configure the the log to the RTT debugger but I never did that with the nRF-SDK as manipulating the “sdk_config.h” is really tiresome and need a huge time to do a small change.

  • “is_listening” is a config that activate rx on idle after end of tx, without it, the radio would not be receiving unless you modified that.

As a sum up. Do you reproduce the issue with the 08 program unmodified ? Or did you still had to patch it for your use case. I have noticed a stability issue with the unmodified 08 program but it only happens after weeks sometimes months that the dongle stops receiving, it’s hard to imagine that this is the same issue happening to you much more frequently, at the end due to that, I abandoned the nRF-SDK 08 example for nRF52840 and I started developing the second generation with two libraries both of which using Zephyr RTOS

  • Thread on nRF52840, which is a realy networking standard, the test was quite successfull
  • simple mesh on nRF52832 and nRF52840, a re-write of the mesh project you’re using but it is not complete.

What I recommend is to enable debug information to see permanent log output and see you catch something when that happens, or leave it running with debugger connected and see if you hit a crash location.

The limitation with the nRF52832 was the only reason why I had to refresh the simple mesh implementation, but for any nRF52840 I moved to using OpenThread, do you think that could be interesting for you ? For info Thread is the new protocol that big companies are using like Google, Apple, for commercial reliable products, in comparison the mesh lib I’m developing are just hacks for small and simple use cases.

Also for info, you probably have see the design of the Mesh stack I’ve developed, this is important to understand to see which queue is used in which context.

I do reproduce the issue with the 08 barely modified, I now think I have solved my issue but I don’t really know why, I had 2 tests running for 16 and 21 hours without having the problem. I think it may be because of a broadcast ping I was sending from the main router (with the RPI) or maybe because I tried to “bypass” the limit of the tx_power (which I think it’s 4 dB) with 8 dB.

About Thread, I think it would be good for futur projects. However, I was asked to do this project with a simple Mesh Project because our client want it to be really secure (i.e. separated from IPv4/IPv6). I still took the time to check about it and I was wondering, is it only doable with Linux based machines. If so, is it possible to create a Thread network directly from a RPi ?

Thanks for your answers.

I’m glad it’s running for you now. To be more confident on versions, it’s possible to only test versions that have a git commit, that way you can go back and forth.

You probably will have the chance to test robustness further.

Thread vs custom_mesh is a good question. Please be aware that this custom mesh I called as simplemesh, is a bare minimum mesh layer intended for applications that need almost full custom protocol for some reason, like high efficiency, or scheduling, but that comes at the cost of other features. Unless you develop your own secure layer, simplemesh has nothing to do with security, it was not even in my scope for home temperature sensors.

Thread stack can run on rasp, that’s what I used on the link above.

Thread is much more secure than any custom protocol. The ip connection to the internet is fully optional and configurable.

The only advantage of simplemesh is code size and simplicity, nothing else, everything else is better on Thread. But Thread or openThread stack is really complex I have to warn you, you need someone advanced linux developper to handle it, that’s where simplemesh is maily firmware only, almost no stack, so server side is simple too.