Address turns up on address list (Pi), doesn't connect from Arduino about rf24gateway

[TMRh20]

It looks like the device is getting a valid address via RF24Mesh, but is resetting when you call the connect method.

From the sounds of it, you are trying to run PA+LNA modules off a Pro Mini, which typically won't work well. You either need a power adapter to convert from 5v to 3.3v ( https://m.media-amazon.com/images/I/51mjJNPuXDL._AC_SX679_.jpg ) or you can maybe try calling radio.setPALevel(RF24_PA_MIN,0); to both set the power to minimum and disable the LNA gain.

Do you have any low powered radio modules to test with?

[2bndy5]

radio.setPALevel(RF24_PA_MIN,0)

LNA (the second arg) is more for filtering noise from incoming RX. I'm not sure if disabling it will actually be beneficial for power consumption. However, that second arg may have different behavior if using a clone of an nRF24L chip (as with the infamously terrible Si24R1). On the original nRF24L, the second arg controls LNA which should only be turned off (0) when analyzing ambient noise. The nRF24L+ ignores the second arg (as do most ebyte modules).

[TMRh20]

I'm doing the debugging on an Arduino Nano. This is quite the issue, lots of potential code to go through lol.
Confirmed it happens with the helloworld_tx sketch when the address is set to 04443, so its in the network layer probably.

[2bndy5]

Does this have to be set on the server end as well ... ?

Yes, the radio data rate must match on all nodes in the network for the chosen data rate to work. I'd be surprised if you could get any connection between nodes that have different data rate settings because that's not supposed to work (with any radio hardware).

---

I used these radios for RC robotics, but I haven't been doing much of that since college. I'm here now because I ❤️ coding, and I believe in maintaining my contributions.

I really only get my radios from Amazon, but I have so many sitting around that I haven't needed to go shoping for new ones. AliExpress is too much of a gamble. TaoBao sounds just as bad based on other users' feedback, but I can't even browse that site because I can't read Chinese.

[2bndy5]

Please read Settings that must match. There isn't any reference to the RF24Gateway API there, but it gives you a good idea about how the radio's should be configured (on each end) to work properly.

[letshin]

Thanks for all the help so far. Managed to get it working well (at least over the last 12h of tests, with no drops and good battery consumption) with some changes, writing it down here in case it helps someone.

1. Coded in mesh.releaseAddress(); so there is always an available address. Extended number of addresses to 6 from 4 on the Pi as there are 6 possible pipes.
2. Replaced antennas - this seems to have made a major difference. The modules themselves work, its just that the antennas that were supplied (from Aliexpress, duh!) are not great. Lesson learnt.
3. Shielded the devices - this helps in edge cases. However instead of wrapping foil around I just covered the top using the foil as a shroud as I have a ground plane on both sides of my PCBs.
4. Set mesh.setChild(0); for all battery powered nodes, and sleep to maximise battery life
5. I have data showing at what battery levels the RF starts becoming unreliable, so I hard coded a stop in at 0.1v above this level.
6. I put all of the RF connect into the void loop() function, and only ever called them if (!mesh.renewAddress()) {meshStart();}. I don't know if this makes a difference, but all my modules consistently fail to connect on the first round... and reconnect on the second attempt. This takes the form of 1130: MAC Send fail to 00 via 00 on pipe 0. I suspect this is just the mesh.renewAddress() function failing.

There are a number of other redundancies and QOL I've added in but the above are the main ones. Now hopefully my final question but I've also managed to get the 250kbps working but wanted to ask why it shows two separate things in the two screenshots below:

The one above shows that its Data Rate = 1 MBPS but since 250kbps works with data transmission from a client to the server and ncurses shows the correct value:

Why is that happening when the power levels (HIGH) are correctly reported. Is there anything to be worried about?

[letshin]

Thanks. I also found out that specifically, for shielding, it is essential to make sure that the gap between the foil and the board at the antenna end is as small as possible. The smaller the gap, the better. In hindsight this makes perfect sense (leakage, fermi cages, wavelengths, etc. ) but yeah now even the small antennas that weren't working are now working when straight (I) instead of angled (L).

[letshin]

Thanks. I have done more tests and this is not strictly a library problem. radio.setPALevel(RF24_PA_MIN,0); helps, but I'm not able to quantify as to how much exactly as the Pro Minis and NRFs are both from AliExpress and probably clones. What I mean by this is that it seems that the voltage regulator output from the Pro Minis have anywhere between 3-7% variance.

What I was able to determine is that at around a voltage (across the NRF pins) of 3.17, the address cannot be registered. At around 3.2v the address is registered, but connection doesn't happen, and above a stable voltage of 3.22v, the MQTT connection is possible. I think I will break out the voltage supply for the NRF from my current circuit and use a HT7333 3v3 LDO regulator to supply voltage to the NRF over the Pro Mini's internal regulator (It outputs 4v from a 4056 battery controller). The datasheet says it has a max output of 250mA and the NRF needs up to 120 mA so this should be OK I hope.

Going off topic a bit, in terms of saving power - since I would like to run these off a 18650 battery and since the battery drains the power supply would drop below 3.17v, am trying to figure out a solution. Would increasing the send interval as well as powering the NRF down with help? The issue is that since everything is connected in a mesh, all of the units would have to wake up at the same time, is there a strategy I can look into for this? I've read from nRF24/RF24#243 that clone chips do not lend themselves well to the low-power function. Let me know if I should set up a new question for this. Thanks.

Edit - I'm going to close this issue anyway as the problem seems to be with the chips and not the code

[2bndy5]

No new issue required. Your problem seems to be power related (& there are soooo many power related threads here).

If your radio module has a glob of goo (as seen in nRF24/RF24#243), then you bought one of the most notably bad clones (see RFM7x lib for empirical research). AliExpress is well-known for misleading customers about nRF24L01 modules' authenticity. Unfortunately, some authentic nRF24L(+) modules are manufactured cheaply by omitting a capacitor intended for the builtin antenna, so power supply problems are difficult to avoid.

Would increasing the send interval as well as powering the NRF down with help?

Anything you can do to limit TXing would help conserve overall power consumption. However, powering down the radio essentially disconnects it from the network and doesn't allow for triggering IRQ upon RXing. Remember that messages getting forwarded (during calls to update()) also incur TX operations.

[letshin]

Thanks, I think I have stabilised the power with a Li-Ion battery. Have been playing around with the code as the connection is still unstable am have identified a few debug messages I don't understand. Whenever I have connection issues, it seems that I am getting an issue either with a MAC send fail on a pipe:

39481: NET message 5b 07 04 04 01 01 01 0a 80 01 01 0a 3e 64 06 40 00 00 10 00 28 00 00 45 
12:44:47.043 -> 39489: MAC Sending to 00 via 00 on pipe 124
12:44:47.043 -> 39493: NET Pipe 0 on node 04 has address 1243e3e
12:44:47.043 -> 39522: MAC Send fail to 00 via 00 on pipe 124
12:44:47.091 -> 39526: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮:+⸮��⸮�+⸮⸮*⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u
12:44:47.091 -> 

or an ACK fail on pipe 124:

12:56:51.871 -> 36306: MAC Network ACK fail from 00 via 00 on pipe 124

There are a couple of failures associated with using pipe 124 - this is normally on starting a sketch from scratch. What is pipe 124 please?

Other than this, nodes that have been working also stop working (after its been working for a bit) when it attempts to send data through what I think is a non-existent node/pipe. For example:

14:47:43.029 ->  382: NET message 002d
14:47:43.029 ->  385: MAC Sending to 055 via 034 on pipe 1c
14:47:43.029 ->  391: NET Pipe 45 on node 05 has address 1cce3e
14:47:43.029 ->  442: MAC Send fail to 055 via 034 on pipe 1c

But 055 doesn't exist on ncurses:

I've tried to force an address renew before sending MQTT data to see if this does anything.

One other question is that the class documentation states that RH24ethernet update() "Keeps the TCP/IP stack running & processing incoming data". Can I only call this every 30s for example, and would putting this into !mesh.checkConnection() if loop break the mesh functionality (forwarding information from other nodes). Would doing any of this reduce to RX/TX operations to reduce overall power consumption?

[TMRh20]

I don’t think you should ever see pipe124, the radio only has 6 pipes. This could suggest problems with your code, overrunning a buffer or something.On May 23, 2023, at 6:01 AM, Zhao ***@***.***> wrote: Thanks, I think I have stabilised the power with a Li-Ion battery. Have been playing around with the code as the connection is still unstable am have identified a few debug messages I don't understand. Whenever I have connection issues, it seems that I am getting an issue either with a MAC send fail on pipe 124: 39481: NET message 5b 07 04 04 01 01 01 0a 80 01 01 0a 3e 64 06 40 00 00 10 00 28 00 00 45 12:44:47.043 -> 39489: MAC Sending to 00 via 00 on pipe 124 12:44:47.043 -> 39493: NET Pipe 0 on node 04 has address 1243e3e 12:44:47.043 -> 39522: MAC Send fail to 00 via 00 on pipe 124 12:44:47.091 -> 39526: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮:+⸮��⸮�+⸮⸮*⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u 12:44:47.091 -> or an ACK fail on pipe 124: 12:56:51.871 -> 36306: MAC Network ACK fail from 00 via 00 on pipe 124 The setup address is: 12:47:13.745 -> setup_address node=04444 mask=07777 parent=0444 pipe=04 Would there be any point in trying a different pipe, and is an ACK from the server needed? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[letshin]

I don’t think you should ever see pipe124, the radio only has 6 pipes. This could suggest problems with your code, overrunning a buffer or something

I just tried it again using the default mqtt_basic.ino example and am getting the pipe 124 again

17:36:41.008 -> 7618: NET message 5b 07 01 04 01 01 01 0a 04 01 01 0a c5 64 06 40 00 00 01 00 2c 00 00 45 
17:36:41.008 -> 7626: MAC Sending to 00 via 00 on pipe 124
17:36:41.008 -> 7630: NET Pipe 0 on node 04 has address 1243e3e
17:36:41.008 -> 7735: MAC Network ACK fail from 00 via 00 on pipe 124
17:36:41.152 -> 7739: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮�(⸮��⸮⸮'⸮⸮'⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u

[TMRh20]

Will have to take a look at this behaviour later in that case. The debug stuff is kind of a mess.On May 23, 2023, at 10:38 AM, Zhao ***@***.***> wrote: I don’t think you should ever see pipe124, the radio only has 6 pipes. This could suggest problems with your code, overrunning a buffer or something I just tried it again using the default mqtt_basic.ino example and am getting the pipe 124 again 17:36:41.008 -> 7618: NET message 5b 07 01 04 01 01 01 0a 04 01 01 0a c5 64 06 40 00 00 01 00 2c 00 00 45 17:36:41.008 -> 7626: MAC Sending to 00 via 00 on pipe 124 17:36:41.008 -> 7630: NET Pipe 0 on node 04 has address 1243e3e 17:36:41.008 -> 7735: MAC Network ACK fail from 00 via 00 on pipe 124 17:36:41.152 -> 7739: NET Sending ⸮⸮�⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮��⸮�(⸮��⸮⸮'⸮⸮'⸮��⸮��⸮��⸮��⸮��⸮��%u: MAC FWD multicast frame from 0%o to level %u —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[2bndy5]

The pipe value there is a HEX number. 0x124 is 0444 in octal. Seems like its trying to send the net-ack using the node address' mask value, but its been a while since I had to understand the debug statements. The really confusing part of that debug statement is how the pipe number is computed because it isn't obvious from looking at the src code... I have to keep re-reading the RF24Network::logicalToPhysicalAddress() function with a specific network context in mind.

[letshin]

OK thanks. Just looked at the source, which I should have done earlier. It seems like the lowest hanging fruit is to increase delay(2) and txTimeout =25 values to see if that improves anything. I notice that some of these errors as well are corelated to whether the antenna is bent or straight - somehow straining the wire in the antenna housing makes a difference, what also makes a difference may be shielding the NRF + PA + LNA circuit like what has been listed in the RF24 help files. I'll try and find a unit that is exhibiting the ACK/send fail error and make these modifications and see what happens.

[2bndy5]

Keep in mind that the network code runs slower with all the debugging prompts enabled. I found that RF24Mesh can have a slightly harder time connecting when the node (master and/or sibling) is spending time printing to stdout.

[letshin]

The pipe value there is a HEX number. 0x124 is 0444 in octal. Seems like its trying to send the net-ack using the node address' mask value, but its been a while since I had to understand the debug statements. The really confusing part of that debug statement is how the pipe number is computed because it isn't obvious from looking at the src code... I have to keep re-reading the RF24Network::logicalToPhysicalAddress() function with a specific network context in mind.

One other thing to try might be to change the value in RF24Network_config.h:16, perhaps alternate between two or three addresses for each subsequent try?

#define NETWORK_DEFAULT_ADDRESS 04444

I have some questions:

1. Could it be that if two devices - say as a working example one of them has low battery and is continuously trying to get an address assigned by the host keeps pinging 04444 (but resetting before it gets further halfway through TX due to current spikes), and a second device starts trying to connect at the same time, they get their wires crossed and further progress isn't possible?
2. What are allowable values for NETWORK_DEFAULT_ADDRESS?

[2bndy5]

1. No it isn't possible because there's header data (describing the net level origin) that gets carried with the address request message.
2. Whatever suites your needs. This is why it is defined as a macro and not a hard coded "magic number".

[TMRh20]

There is definitely something funny going on with the debug printing.

If I add the following line Serial.print("PP "); Serial.println(conversion.send_pipe); right before the debug print of MAC Sending... the pipe comes out correct.

I'm hoping this issue is just regarding the debug statements, or else we may have some sort of bug to figure out. Will dig into this soon.

In either case, this happens whenever a node is trying unsuccessfully to renew its address. I still think there is basically an issue with the radios and their hardware configuration. RF24Mesh works very well with fully functional radios.

[2bndy5]

Regarding the inaccurate debug output: It might be something with static memory (possibly specific to Linux not Arduino). When I re-wrote those debug statements, I can't remember if I tested them thoroughly on the RPi; I do remember using the revised debug statements with the python wrappers (before pyRF24 existed).

[letshin]

I still think there is basically an issue with the radios and their hardware configuration. RF24Mesh works very well with fully functional radios.

This will be 100%, if not partially, true. I've done more testing and there are a few scenarios. Not so sure about point 4. Possibly because not implemented well by myself.

1. [Hardware] The PA/LNA modules come with what looks like a 2.2 dbi antenna. When these are not bent at 90 degrees (left straight) I get the "124" error. It connects when the antennas are bent in what I assume makes the antenna more taut and somehow changing pickup/resonance frequency, or something else?
2. [Hardware] When I pop on a 10 dbi antenna, connections happen when the antenna is left straight and not bent.
3. [Hardware] Sometimes for no reason, the 124 error pops up even with the 10 dbi antenna in whether left extended or at 90 degrees. Same for the 2.2 dbi antenna
4. [Software] When setting RF24's setDataRate, only RF24_1MBPS works. Setting RF24_2MBPS or RF24_250KBPS gives the 124 error. Does this have to be set on the server end as well (in my case, the RPi's ncurses cpp file, and re-compiled?).

Few other scenarios where the 124 error occurs there is no discernable reason. Possibly not enough current - untested. But above points point to possible hardware issues. I'm tempted to design my own PCB (of the NRF module) and get these made instead of buying from AliExpress etc. for future projects and for better QC. How do you both normally use these devices? Do you use the AliExpress ones or source from somewhere else or have your own PCB design - is there a point for the latter?

[TMRh20]

I've found the best luck just getting radio modules from Amazon so that I can return them if I get some bad clones. All my PA+LNA modules are shielded with extra capacitors.
I designed some PCBs for the RPi, just a connector for the radios, with a 5v-3.3v converter and some extra capacitors, but for Arduinos I just use a 5v-3.3v adapter typically. The 'good' nrf24 modules I have work very nicely, either PA+LNA or not. The SI24R1 modules need to be kept at a lower power level.

[letshin]

5v-3.3v

Do you use Buck or LDO converters. Any model number you can share as I found a couple of days ago that 3v3 LDOs (from 4.2V / Li Ion) I bought from Amazon have a transient response when supplying power to the PA + LNA module. Do you use a bandpass filter for them (I assume these might be what the extra capacitors are for)?

some extra capacitors

Think you (think it was you anyway) said in previous posts you recommend 1uF right. I've been using these as close as possible to the board as you recommended.

[TMRh20]

Caps should be at least ~10uF to 100uf plus a ~100nf cap for filtering. I just used an AMS1117 on the latest RPi PCB.

[2bndy5]

Oh, I've only used LDO regulators. Capacitors serve more than 1 purpose:

1. Stabilize (filter out the noise/ripple) the power for the nRF24L IC. All Bi-Junction Transistors (as used for various applications like voltage regulators) need this filtering/stabilization to happen (read the corresponding datasheet).
2. Some manufacturers skip adding a capacitor to the antenna to keep costs down, so that's why it matter how close the capacitor is to the radio module.

Its important to read the datasheet for the voltage regulators you employ (especially if making a custom PCB). I would not recommend buying regulators from Amazon because there are also known "fakes" out there. For voltage regulators, I would stick to more reputable/official sources like mouser.com or digikey.com (which links to the datasheet for every product that they sell).

[letshin]

Caps should be at least ~10uF to 100uf plus a ~100nf cap for filtering. I just used an AMS1117 on the latest RPi PCB.

Thanks. Checked the AMS1117 datasheet and the standard application has pull down caps to ground on both VIN and VOUT. Was this all you used or did you add additional filters? The reason I ask is because I used the HT7333 in a similar setup (as per the datasheet) but am getting a transient response (voltage ripple) when supplying power to the NRF boards which seems to be from the current draw leading to a momentary drop. Otherwise for other cases the voltage is stable. Might be an Amazon dud like @2bndy5 said since they are supposed to be fine up to 250mA.

Edit: Forgot to add that I had tested with more caps up to 80uF (several 10uF caps in parallel) that smoothed the ripple but didn't really help with the connectivity issues. I probably should math it out instead of doing it iteratively or try a 100uF cap. It was a typo earlier - I'm using 10uF (106 polymer) caps across the V and G of the NRF modules.

[2bndy5]

Multiple capacitors with varying capacitance are a good thing. When filtering out noise, it is good to set a threshold for small spikes and another threshold for large spikes.

[letshin]

Thanks. In rf24gateway.cpp there are these lines:

    gw.begin();
    mesh.setStaticAddress(8, 1);

    //uint8_t nodeID = 22;
    //gw.begin(nodeID,3,RF24_2MBPS);

    //uint16_t address = 0;
    //gw.begin(address,3,RF24_2MBPS);

Can I replace gw.begin(); with gw.begin(0,3,RF24_2MBPS); - do the clients need to operate on the same channel as well?

Also please assume that I will change radio.failureDetected > 0 || radio.getDataRate() != RF24_1MBPS) to match the value above as well

[TMRh20]

So I was able to replicate this debug printing issue without using RF24, Network or Mesh, just with the following code:

#include "printf.h"

void setup() {
  Serial.begin(115200);
  while (!Serial) {
    // some boards need this because of native USB capability
  }
  printf_begin();
  Serial.println(F("RF24Network/examples/helloworld_tx/"));

}

void loop() {
  // put your main code here, to run repeatedly:
  delay(1000);
  uint16_t to_node = 03;
  uint16_t conversion = 05;
  uint8_t testing = 3;
  printf_P(PSTR("%u: MAC Sending to 0%o via 0%o on pipe %x\n\r"), millis(), to_node, conversion, testing);//conversion.send_pipe);
  printf("%u: ",millis());
  printf("MAC Sending to 0%o via 0%o on pipe %x\n\r",to_node, conversion, testing);
}

The second rows of printf with the millis() printing separated works fine... tried with %ul and %u, something about printing the millis() messes it up. Putting in a workaround for RF24Network.

[TMRh20]

AMS1117 datasheet and the standard application has pull down caps to ground on both VIN and VOUT. Was this all you used or did you add additional filters?

That is all I used, and it works great.

[letshin]

Some additional comments on how the Send/ACK fail 'pipe 124' error happens:

1. It is most easily reproducibly solvable when the antenna is removed from the NRF+PA+LNA module. I don't understand why this happens and have ordered a couple of new SMA antennas from Amazon to try them out.
2. Changing the dataSpeed on both the client and the server to anything other than 1MBPS causes the 'pipe 124' error to occur. Reverting it stops the error when it is already present.

For 2, is there anything else I need to do as I have matched up the dataSpeed requirements (I think). From RF24Gateway_ncurses.cpp:321 on the Pi-side:

       #define dataRate RF24_1MBPS // RF24_1MBPS,  RF24_2MBPS, RF24_250KBPS

        if (radio.failureDetected > 0  || radio.getDataRate() != dataRate)
        {
            radio.failureDetected = 0;
            std::ofstream myFile;
            myFile.open("failLog.txt");
            if (myFile.is_open())
            {
                myFile << ++failCounter << "\n";
                myFile.close();
            }
            delay(500);
            mesh.begin();
            //custom settings Zedit
            //radio.setPALevel(RF24_PA_HIGH,1);
            radio.setDataRate(dataRate);// ZEdit refer to definition above
        }

Edit; Received better antennas from Amazon a couple of hours ago - have tested these and they improve performance. The old antennas that could not connect whilst straightened (I shape) and not bent (L-shape) can now connect from the Pro Minis whilst straightened when the 6 dbi antennas are connected to the Pi. My caps and resistors are arriving from Farnell tomorrow so I will test these too.

[TMRh20]

when the antenna is removed from the NRF+PA+LNA module. I don't understand why this happens

Have you added shielding to the module yet? This might just be the antenna overwhelming the device.

For 2, is there anything else I need to do

Nope, as long as you have the datarate set the same on both master and other devices, it should just work. Make sure you aren't setting a different channel or something else too.

[letshin]

Have you added shielding to the module yet? This might just be the antenna overwhelming the device.

Yes, added. Its strange.

Nope, as long as you have the datarate set the same on both master and other devices, it should just work. Make sure you aren't setting a different channel or something else too.

Is it enough to edit the cpp file or do I need to edit the .h files as well? Stupid question, but confirming: It is enough to call radio.setDataRate(dataRate); after mesh.begin() right?

One other thing I've also found is that for the can't connect error, what also seems to help is stopping RF24Gateway_ncurses on the pi (ctrl+c), deleting dhcplist.txt, waiting a bit (as you've suggested, not 30s as I force an address renew now every time a connection is attempted), and that seems to resolve the situations some of the time.

Tested the above further and it seems that the number of direct connections are restricted to 4. Quickly checked the config documents and found the definition #define MESH_MAX_CHILDREN 4 so I guess that's why extras weren't connecting... which is why deleting dhcplist helps, so reliability is a must for the modules.

In both your experiences, what is the maximum number of children that a Pi, say, can support?

Shielding seems to stabilise things and help.. but only in edge cases - not a major contributor to disconnections.

[TMRh20]

Yes call after mesh.begin and just the cpp fileOn May 26, 2023, at 8:29 AM, Zhao ***@***.***> wrote: Have you added shielding to the module yet? This might just be the antenna overwhelming the device. Yes, added. Its strange. Nope, as long as you have the datarate set the same on both master and other devices, it should just work. Make sure you aren't setting a different channel or something else too. Is it enough to edit the cpp file or do I need to edit the .h files as well? Stupid question, but confirming: It is enough to call radio.setDataRate(dataRate); after mesh.begin() right? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[TMRh20]

In both your experiences, what is the maximum number of children that a Pi, say, can support?

My main Pi runs 15-17 nodes with most reporting data every 3 seconds or so on average. This is about all the devices can handle comfortably with the overhead of TCP/IP + Mesh. The other one runs 10 nodes which are very reponsive.

Deleting the dhcplist isn't really a solution, as stated before, if the radios are fully functional, the system works well with the numbers specified above.

[TMRh20]

The printDetails() call happens in gateway.begin() so if you are setting the dataRate after begin, the setting changes after it is printed... You can call printDetails a second time, after your configuration is set, or set the datarate in begin().