long-term usage of nRF24L01+ with PA: no reliable transmission
-
Hello,
I use several nRF24L01+ with PA to transmit sensor data to a central arduino node. I use the library "RF24.h" // http://tmrh20.github.io/RF24.. The arduinos send one package of sensor data once a day. I noticed that everything runs fine for ca. 8 weeks, then there is a mixture of failed and successful transmissions (most fail but some are OK). I tried to change frequency and power and data rate but nothing helps. A reset of the arduino does not help. You need to switch off power to reset the transceivers. I use a Wireless Module Socket Adapter Board, which is already equipped with the needed condensators and the modules are separately powered by 3.3 V. The modules are not original ones but came from banggood.I would like to know if other people have experience with long term usage of the modules - I tried several modules and they all are not reliable.
-
I suggest you post photos of the radio modules that you're using. That way others who have used the same modules are more likely to respond.
-
this is a picture of the used RF module and the adapter
-
Maybe try E01-ML01DP5 Long Range SPI nRF24L01P 2.4Ghz 100mW SMA Antenna IoT Wireless Transceiver
After several years of usage, i can tell i sometimes need to reboot a node after several weeks or months… hard to tell why because i don’t have logs and when node is restarted usely everything works well.
On some nodes i have setup a routine to reboot once a day; difficult to have clues if this is far better or not.
Sometimes, you can have the case where your node finds an unusual « parent id » because the regular parent is not responding so
if you are confident with your topology gateaway and repeaters then you can #define the prefered parent id of each node
especially if some repeaters have a better antenna than others
-
@hlehoux said in long-term usage of nRF24L01+ with PA: no reliable transmission:
Maybe try E01-ML01DP5 Long Range SPI nRF24L01P 2.4Ghz 100mW SMA Antenna IoT Wireless Transceiver
^^^This.
Or, based on your description, use a load switch, like a MOS tube, to completely turn-off power to your transceiver when not in use, and then turn it back on just prior to use. It shouldn't be necessary, but sounds as though it would work for your hardware if nobody has any further answers for you. Good luck!
-
@quaxman I have been running the nRF24L01+ without a PA for several years now in an outdoor environment, though in enclosures. Inside the enclosures is high humidity so I have sprayed a clear coating over the Nanos.
The radio connection I have works (for the life of me, I don't know why). On the radio board I have soldered 8 right angle pins and a 10uF electrolytic cap soldered to GND and +V. On the nano I have soldered short 24AWG wires to a female connector.
My code is based on the Tmrh20 libraries. Most of my code is error management.
Included in that error management is a watchdog timer that will reboot the nano when communication is lost.Your right, reset does not work, but reboot does. I cannot tell you why this works.
It was a tough slog to get to this point of stability and I did experience and overcame much of what you are seeing. I only destroyed 3 radios (of ~20) and those left work well. (On one I think only the transmitter got hosed.) Most of my problems now are self-inflicted.
While I consider Tmrh20 a dedicated genius, this genius is just one person and the nuances of the nRF24l01+ are many.
I am now experimenting with the MySensors libraries and have found them much easier in that the radios work (I don't know why they seem to work better). Using these libraries, my sensors and actuators are controlled by Arduino Nanos with nRF24L01+ radios. The MySensors Gateway is MQTT and runs on a Raspberry Pi 3B+ with an nRF24L01+ radio connected with 10cm of ribbon cable. My MQTT broker runs on a refurbished computer I bought on Amazon for $90 ($100 now) Instead of Windows, I'm running linux. Also on this computer I run a Virtual Box in which I have loaded my home automation controller Home Assistant
This system seems to be working very well, but I yet to have the long term experience, so I cannot say that going this route will help. The downside I have found is the method Home Assistant uses to control devices is not intuitive.
OSD
-
I just remembered the key technique to getting the communications working smoothly.
I do all my communication synchronously. That is as follows:
The master device sends a message to a node. The send command returns a success or fail, but fail does not mean the message was not received, it means that an ACK was not received. The master waits a timeout period for a response. If there is no response, a second attempt is made. If there is a response, the data with the response is processed. If not, the node is ignored.After that transaction, the master repeats this process with the next node and for each node there after. A round-robin.
If a node does not get a request from the master within a certain interval, it reboots itself.
If the system power cycles, the nodes inundate the the master with DHCP requests. Because of so many requests, requests can be ignored or two nodes might receive the same network address (different from NodeID). Eventually, one node will get a valid network address and begin to communicate as expected. This reduces the network traffic and the probability of another node receiving a unique network address improves. Eventually, all nodes connect. "Eventually" can be many, many minutes.
The tree structure of the network means that some nodes send data through other nodes. In asynchronous communication, a node may be trying to send data while another node is sending data through it. I may not be correct in this, but I think that it is possible that this will corrupt one or both data packets. This is why I do the round-robin communication.
The master only has 5 (4?) usable addresses to receive data. Like computer DHCP, addresses can be reserved for specific NodeID's. For example, address 3 an be reserved for NodeID 31, then NodeID 22 can have a reserved address of 43, thus NodeID 22 will always send data through NodeID 31. (addresses are octal). The address 4444 is reserved; this is the address a node requesting an address uses.
To increase the chance of getting a valid address, I put a delay in the first DHCP request based upon the NodeID.
I put the NodeID in EEPROM address 0, as does MySensors. I have one program that sets the NodeID and then my program for all of my nodes is the same.
Nodes that sleep must have the flag set (in the node software) that indicates no data can be passed through it from another node.
All of these hoops are handled by the MySensors libraries, though I force the NodeID. This my impetus to use MySensors. I must wonder though, "How much overhead is there? Do I have enough memory for my code?" So far I haven't had a problem.
OSD
