After running NRF24L01+ for a few years I recently decided to upgrade to several NRF24L01+PA+LNA (Antenna version) using the link from this page. Initially the performance was worse. Fail to find gateway, fail to send data and lots of NACKs. However eventually I was able to get them working. Below is a summary of tweaks and suggestions from various Mysensor Forum posts that helped stabilize my sensor network.

1. Add 47uf capacitor between 3v and ground pin on the transceiver.

2. Add plastic-wrap then a tinfoil shield as per other threads. Tinfoil needs to to touch the base of the antenna (ground).

3. My 5V switching power supply to the Arduino Nano was causing problems. Some sort of noise on the wire? When I disconnected the transformer and powered the arduino by laptop usb, the signal was much more reliable. So I added a 1000uf capacitor between ground and 5V coming from the transformer which filtered out the noise coming from the power supply. This is probably not applicable to battery powered devices.

4. Use static node addressing for each node - automatic addressing sometimes randomly make bad routing decisions bypassing repeater nodes and choosing far away nodes.
   // Far-from-gateway sensor node
   #define MY_NODE_ID 2
   // Parent is a repeater node
   #define MY_PARENT_NODE_ID 1
   #define MY_PARENT_NODE_IS_STATIC

5. Lower the power on the transceiver. Try each power level reboot the node and pay attention to: Setup speed, how many NACKs.
   // RF24_PA_MIN = -18dBm;
   // RF24_PA_LOW = -12dBm;
   // RF24_PA_HIGH = -6dBm;
   // RF24_PA_MAX = 0dBm
   #define MY_RF24_PA_LEVEL (RF24_PA_LOW)

6. Run the RF24 scanner example for a long time to find a channel that is free from noise. I ran it for a day to pick up neighbourhood noise and loaded the results into a spreadsheet to graph. Set the clearest channel on all my nodes. e.g.
   #define MY_RF24_CHANNEL (105)

7. In domoticz I lowered the ACK time from 1200 to 400 to avoid broadcast storms/collisions. On the nodes after each send or receive add a "wait(LONG_WAIT);" to allow ACKs to settle between transmissions ( e.g. 500ms).

8. Run a ping-pong test between two battery powered mobile nodes to find optimal locations for your gateway, repeaters and sensors. Find the outer limits and keep the nodes well within those limits. Try not to place a node at the outer range limit, add repeaters. Sometimes moving a few feet in one direction can have a big difference.

Just finished a similar project using WS2812B.

• MySensors/Domoticz support.
• Infrared Remote support (common 44 key color picker)
• Color change & fade animations ++.

https://github.com/dmonty2/ir_remote_leds/tree/mysensors

A journal update on NRF24L01+PA+LNA (Antenna version). After 4-5 months two of them stopped transmitting. I had also purchase and installed the 3.3v regulator base socket to help improve overall transmission reliability.

Loaded the RF24 library GettingStarted example onto two arduinos connected to laptop and a desktop. Changed the code to match MySensors pinout and data-rate, along with a free channel found by the RF24 scanner example.

RF24 radio(9,10);

...snip...

  radio.begin();
  radio.setDataRate(RF24_250KBPS); 
  radio.setChannel(120);
  //radio.setPALevel(RF24_PA_MIN);
  radio.setPALevel(RF24_PA_LOW);
  //radio.setPALevel(RF24_PA_HIGH);
  //radio.setPALevel(RF24_PA_MAX);

I Moved laptop to far edges of the range and tried various power levels for NRF2L01 as well as the PA+LNA. Sketch default is RF24_PA_LOW which turns out to have the farthest range with the least packet loss and fastest turn around time packet time. I also cycled through the various radios to weed out the ones that were week. Even with the 3.3v base socket, a capacitor helps as well as cellophane+tinfoil on the PA LNA modules.

I then put one of the arduinos onto a battery pack and placed it next to each of my sensors. Then used the laptop to see packet loss next to repeater nodes and gateway. When near the edge of the range moving the antenna a few feet in different directions will cause packet loss. When a sensor is at the edge it is better to move radios closer to each other or a add a repeater. I thought PA LNA would be better in all locations but it turns out that the cheaper base radios sometimes perform better.

@gohan said in Connecting the Radio:

@dmonty did you use the shielded radio module?

Yes they are shielded.

I found another way to find optimal sensor location using an on/off loop script as a ping. Start the ping running then move the antenna to find best mount point location.

To find the strongest location it helps to find the weak-signal boundaries where packets are lost, then make sure the antenna is on the inside of the boundary. Move the antenna:

• X+, X-
• Y+, Y-
• Z+, Z-

#!/bin/sh
# Desc: Domoticz ping script to help find optimal location for sensor antenna.
# Auth: Dean Montgomery
# Date: April 21, 2020

# Url of domoticz server.
HOST="http://192.168.0.1:8080"
# ID=14 is device idx of a light switch found on the Divices page of domoticz.
ID=14

while true; do
  CMD="${HOST}/json.htm?type=command&param=switchlight&idx=${ID}&switchcmd="
  echo "=== ON ==="
  wget -q -O - "${CMD}On"
  sleep 1
  echo "=== OFF ==="
  wget -q -O - "${CMD}Off"
  sleep 1
done

It may help to include a dummy ping light switch in all sensor nodes dedicated for this purpose.

A journal update on NRF24L01+PA+LNA (Antenna version). After 4-5 months two of them stopped transmitting. I had also purchase and installed the 3.3v regulator base socket to help improve overall transmission reliability.

Loaded the RF24 library GettingStarted example onto two arduinos connected to laptop and a desktop. Changed the code to match MySensors pinout and data-rate, along with a free channel found by the RF24 scanner example.

RF24 radio(9,10);

...snip...

  radio.begin();
  radio.setDataRate(RF24_250KBPS); 
  radio.setChannel(120);
  //radio.setPALevel(RF24_PA_MIN);
  radio.setPALevel(RF24_PA_LOW);
  //radio.setPALevel(RF24_PA_HIGH);
  //radio.setPALevel(RF24_PA_MAX);

I Moved laptop to far edges of the range and tried various power levels for NRF2L01 as well as the PA+LNA. Sketch default is RF24_PA_LOW which turns out to have the farthest range with the least packet loss and fastest turn around time packet time. I also cycled through the various radios to weed out the ones that were week. Even with the 3.3v base socket, a capacitor helps as well as cellophane+tinfoil on the PA LNA modules.

I then put one of the arduinos onto a battery pack and placed it next to each of my sensors. Then used the laptop to see packet loss next to repeater nodes and gateway. When near the edge of the range moving the antenna a few feet in different directions will cause packet loss. When a sensor is at the edge it is better to move radios closer to each other or a add a repeater. I thought PA LNA would be better in all locations but it turns out that the cheaper base radios sometimes perform better.

@alowhum @gohan - I used the non-shielded module found in the "Shopping Guide" on this page: https://www.mysensors.org/build/connect_radio. Used bought from the seller that the link took me to.

The Connecting the Radio page get's you up and running. Would be nice if the "Shopping Guide" - grouped optimal matching components into a plug-n-play style "Shopping Cart". e.g. Optimal recommended component groups for:

1. Gateway node.
2. Repeater node.
3. Sensor node.

a) usb powered.
b) transformer powered.
c) battery powered.
d) solar powered.

I think my next experiment may be to pick up the 3v regulated power sockets to see if they will help in increasing the power and range as I've read the 3.3v regulator on the Arduino Nano is not very good at powering the radio.

After running NRF24L01+ for a few years I recently decided to upgrade to several NRF24L01+PA+LNA (Antenna version) using the link from this page. Initially the performance was worse. Fail to find gateway, fail to send data and lots of NACKs. However eventually I was able to get them working. Below is a summary of tweaks and suggestions from various Mysensor Forum posts that helped stabilize my sensor network.

1. Add 47uf capacitor between 3v and ground pin on the transceiver.

2. Add plastic-wrap then a tinfoil shield as per other threads. Tinfoil needs to to touch the base of the antenna (ground).

3. My 5V switching power supply to the Arduino Nano was causing problems. Some sort of noise on the wire? When I disconnected the transformer and powered the arduino by laptop usb, the signal was much more reliable. So I added a 1000uf capacitor between ground and 5V coming from the transformer which filtered out the noise coming from the power supply. This is probably not applicable to battery powered devices.

4. Use static node addressing for each node - automatic addressing sometimes randomly make bad routing decisions bypassing repeater nodes and choosing far away nodes.
   // Far-from-gateway sensor node
   #define MY_NODE_ID 2
   // Parent is a repeater node
   #define MY_PARENT_NODE_ID 1
   #define MY_PARENT_NODE_IS_STATIC

5. Lower the power on the transceiver. Try each power level reboot the node and pay attention to: Setup speed, how many NACKs.
   // RF24_PA_MIN = -18dBm;
   // RF24_PA_LOW = -12dBm;
   // RF24_PA_HIGH = -6dBm;
   // RF24_PA_MAX = 0dBm
   #define MY_RF24_PA_LEVEL (RF24_PA_LOW)

6. Run the RF24 scanner example for a long time to find a channel that is free from noise. I ran it for a day to pick up neighbourhood noise and loaded the results into a spreadsheet to graph. Set the clearest channel on all my nodes. e.g.
   #define MY_RF24_CHANNEL (105)

7. In domoticz I lowered the ACK time from 1200 to 400 to avoid broadcast storms/collisions. On the nodes after each send or receive add a "wait(LONG_WAIT);" to allow ACKs to settle between transmissions ( e.g. 500ms).

8. Run a ping-pong test between two battery powered mobile nodes to find optimal locations for your gateway, repeaters and sensors. Find the outer limits and keep the nodes well within those limits. Try not to place a node at the outer range limit, add repeaters. Sometimes moving a few feet in one direction can have a big difference.

@maghac

Cool. I've played with WS2812B and FastLed in another project. But I'm not sure if they are good enough for general illumination though?

Yes, the WS2812B are most definitely accent-style lighting with beautiful animations.

The code also drives a relay switch to turn on my larger light. It shows up in Domoticz as two lights.

Just finished a similar project using WS2812B.

• MySensors/Domoticz support.
• Infrared Remote support (common 44 key color picker)
• Color change & fade animations ++.

https://github.com/dmonty2/ir_remote_leds/tree/mysensors

I tracked down the issue. My real sketch had too many large variables using up too much memory. Because the Lights were being declared later they were getting clobbered. After decreasing the number of sensors everything started working fine.

Tried MockMySensors Example - with a light on/off loop and no radio and Domoticz updates light status based on Arduino code. This means Domoticz supports receiving update status for lights.

I tried uploading a simple Light on/off delay loop sending only light status from the node. I can confirm that the master node receives the message on the serial interface. However Domoticz does not log any incoming actions. So my thoughts are now that Domoticz does not handle light-status send-updates from the nodes.

    msg_S_LIGHTS.setSensor(ID_S_LIGHT);
    msg_S_LIGHTS.setType(V_STATUS);
    send(msg_S_LIGHTS.set(isLightOn==1 ? "1" : "0"),true);

Message Type: V_STATUS
Payload Type: P_STRING

    msg_S_LIGHTS.setSensor(ID_S_LIGHT);
    msg_S_LIGHTS.setType(V_STATUS);
    send(msg_S_LIGHTS.set(isLightOn),true);

Message Type: V_STATUS
Payload Type: P_BYTE

    msg_S_LIGHTS.setSensor(ID_S_LIGHT);
    msg_S_LIGHTS.setType(V_TRIPPED);
    send(msg_S_LIGHTS.set(isLightOn),true);

Message Type: V_TRIPPED
Payload Type: P_BYTE

Version 2.1.1

This morning I found I did some serial debugging on the sender and master node.
I had to re-initiate the Sensor ID and the Sensor Type before sending.

    isLightOn = 1;
    msg_S_LIGHTS.setSensor(ID_S_LIGHT);
    msg_S_LIGHTS.setType(V_STATUS);
    send(msg_S_LIGHTS.set(isLightOn),true);

Without doing this the wrong type is sent from the node itself.

9234 TSF:MSG:SEND,1-1-0-0,s=15,c=0,t=3,pt=0,l=10,sg=0,ft=0,st=OK:SdGrgLight
9243 TSF:MSG:READ,0-0-1,s=15,c=0,t=3,pt=0,l=10,sg=0:SdGrgLight
9249 TSF:MSG:ACK
9991 MCO:REG:REQ
9996 TSF:MSG:SEND,1-1-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
10002 TSF:MSG:READ,0-0-1,s=255,c=3,t=27,pt=1,l=1,sg=0:1
10007 MCO:PIM:NODE REG=1
10009 MCO:BGN:STP
10150 MCO:BGN:INIT OK,TSP=1
27173 TSF:MSG:SEND,1-1-0-0,s=9,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=OK:1
27938 TSF:MSG:SEND,1-1-0-0,s=15,c=1,t=0,pt=1,l=1,sg=0,ft=0,st=OK:1

Sent Message
Sender: 1
Last Node: 1
Next Node: 0
Destination: 0
Sensor Id: 15
Command: SET
Message Type:V_TEMP
Payload Type: P_BYTE
Payload Length: 1
Signing: 0
Failed uplink counter: 0
Status: OK (OK=success, NACK=no radio ACK received)
Payload: 1