NRF24 nodes failing to connect on channels below ~100
-
I am upgrading a network that has been running for probably 7 or 8 years now to the latest version of the MySensors Libray (2.3.1). The nodes and the serial gateway are purpose built PCBs that contain a 328P, power regulators and the radio boards. The old network operated on the default ch #76 without any significant problems for years,
Now with the latest v2 Library I have the problem that the nodes fail to connect to the gateway during the power up, i.e. network init and presentation fails with NACK's. On the LEDs of the gateway I see that the communication attempts are marked with the RED error led in unison with the NACKs from the debug output of the connecting node. ---Here comes the strange bit: If I eventually get the node to connect with the gateway by putting the node right over the gateway and waiting long enough (minutes) , I can then move the node away across the house and it communicates without a single failure all day and all night long.
At this point there is only one node and one gateway in the picture and the Node's parent is directly set to the gateway address of 0. All "user mode" communication is done with the HW-ACK feature on since we have only a single hop network. Network operates at 250kbits/s and changing power settings do not improve the issue. Nodes use IRQ signaling and I changed RF24.cpp to poll the IRQ line for transmit as well instead of polling status via SPI.
So the question is: What is different during the init and presentation that makes the nodes not connect, but then once the hooked up eventually makes the network function after all.
When switching to a channel above about 100 , i.e. out of the WiFi spectrum I get no, or almost no initial NACK failures.
So what has changed that it can't get through the initial phases of the node connect on a slightly noisy channel even when mere centimeters apart.
-
Latest MS version is 2.3.2 for a start. Also you need to reprogram the node and gateway with the updated library, make sure you update libraries within your Arduino IDE (if using it) and check for any changes from whatever version you have been running (you don't say about this) and the newer 2.3.2
There may well be some things in the node at least you need to address depending on what the node does.
-
Latest MS version is 2.3.2 for a start. Also you need to reprogram the node and gateway with the updated library, make sure you update libraries within your Arduino IDE (if using it) and check for any changes from whatever version you have been running (you don't say about this) and the newer 2.3.2
There may well be some things in the node at least you need to address depending on what the node does.
@skywatch duh !!
-
Sounds like another service (WiFi, BLE, BT, whatever) is jamming. Channel 100 is normaly not allowed, as it is 2.500 GHz. So it is away from anything than can jam. For example, WiFi only goes up to 2.480 GHz.
@eiten The puzzle is , why does the existing network function without fail under the same conditions, while the new network can not even connect when the nodes are a foot apart. But then if eventually they connect I get full expected range with no missing acks ..
-
@eiten The puzzle is , why does the existing network function without fail under the same conditions, while the new network can not even connect when the nodes are a foot apart. But then if eventually they connect I get full expected range with no missing acks ..
@GaryStofer Did you erase the EEPROM? Maybe they stored the child ID number, and since it's a brand new network, they don't connect to it until some kind of timeout when they give up on the old ID? These are just guesses, and not based on any kind of deep familiarity with the code.
I just know that the ID would be stored for quicker connections on the next times it connects to the system, so that would make sense with what you describe.
-
@GaryStofer Did you erase the EEPROM? Maybe they stored the child ID number, and since it's a brand new network, they don't connect to it until some kind of timeout when they give up on the old ID? These are just guesses, and not based on any kind of deep familiarity with the code.
I just know that the ID would be stored for quicker connections on the next times it connects to the system, so that would make sense with what you describe.
yes -- EEprom gets erased by code in the before() section
-
yes -- EEprom gets erased by code in the before() section
@GaryStofer Every time it starts up? That really removes the usefulness of using EEPROM in the first place.
Maybe you're having problems getting a response to the assignment of a child ID, and until it gets that it doesn't work???
-
@GaryStofer Every time it starts up? That really removes the usefulness of using EEPROM in the first place.
Maybe you're having problems getting a response to the assignment of a child ID, and until it gets that it doesn't work???
@ejlane No -- Not every time -- Just when I need it ---
-
@ejlane No -- Not every time -- Just when I need it ---
@GaryStofer Okay, then sounds like you're doing what I would.
Are you able to turn on debug and connect serial to it to troubleshoot that way? Without getting more info on it, I'm out of ideas at the moment.
