Radio problems

  • Hi,

    I have a EnergyPulseMeter in the garage with NRF24L01+ but statistics shows that quite many (~14%) send fails.
    The gateway have NRF24L01+PA+LNA (Antenna version) and connected to Vera.
    It's two inner walls and one outer (brick) wall between the sensor and gateway.

    I have also added a 4.7uF capacitor over the 3.3V and GND pins on both gateway and sensor.

    I have now tested gateway with:
    which led to little improvement (12% lost messages) with NRF24L01+ on sensor which is too much to my opinion.

    So I am trying to change to NRF24L01+PA+LNA (Antenna version) on the sensor as well.
    It didn't work so I added the similar code to sensor:
    gw.begin(incomingMessage, AUTO, false, AUTO, RF24_PA_LOW);

    But still no success..

    (FYI, I tested the radio on the desk and it works and I am using 1.4b1)

    Do you have any idea what to do?

  • Mod

    @jocke4u Build a network sniffer and see what's goin on!

  • Admin

    Is the sensor /w antenna located in the actual meter-metal-box?

  • @hek No, only the sensor TSL257. Arduino and Radio currently on the firewood in the garage 🙂

    @Yveaux Sure that can be one way to sniff the traffic, but isn't a bit strange it finds its way with small NRF24L01+ but not with antenna one?!

  • Hero Member

    @jocke4u I can't claim to have built and tested that many sensors but I have read most of the error reports on the forum over the last couple of months. I see some possibilities here:

    1. Power source for the sensor is not ideal ... which could be fixed with a decoupling cap just like you did ... only ...
    2. Decoupling capacitor in question is not ideal, perhaps try a larger capacitor, 10 or 22 uF or perhaps try another type, like ceramic. I assume you're using electrolytic like in the store?
    3. Perhaps there is something wrong with the radio you're testing, Ebay quality control and all that.
    4. Some have reported big differences in reception based on the orientation of the radio.
    5. Some have also reported big differences in cable length (shorter cables to the radio or prototype board being better)
    6. The NRF24L01+PA+LNA probably consumes more power at the same setting (?) (RF24_PA_LOW/-12dbm) though it should still be within the limits of the Arduino mini pro I guess? If you have the radio connected directly to the arduino I mean, feeding it power through its circuitry? If possible, and you have a 3.3V source, like batteries, you could bypass the Arduino and power the radio directly from the batteries. Perhaps there is something with your board creating an issue like the sensor itself. Like I said, I have no clue here.

  • @bjornhallberg

    1. Yes, I read that in the troubleshooting section
    2. I read about another guy in thread where he tested 22uF without success but 47 uF worked, so I did the same today. No success but then I restarted the gateway and it started to send/receive. Yes, I am using electrolytic capacitor. Is ceramic better?
    3. Sure the quality can be questioned sometimes but it seems to work. I have just ordered two additional NRF24L01+PA+LNA just in case 🙂
    4. It's not very good if the reception is a lot different based on radio orientation, especially if NRF24L01+PA+LNA is used (~1000m distance) in this short distance
    5. I have pretty short cables. Everything mounted on universal PCB with header pin connector and short cables. The cables are maybe not the best; used a stripped cat5e
    6. Can be something to investigate if no success in other labs

    The current setup have not yet been operated for that long time but it looks better:

    Messages received in interval (sensor sends every 20 sec so 2 sec tolerance)
    0-22 sec          181    91,4%
    23-40 sec          16    8,1%
    41-100 sec          1    0,5%
    101-100000 sec      0    0,0%
    Total messages    198    100,0%

    Maybe I should increase the capacitor on gateway to 47uF as well....

  • Hero Member

    How are you powering the sensor? Is there a step-up regulator involved?

  • Hero Member

    @jocke4u said:
    Everything mounted on universal PCB with header pin connector and short cables.

    -What is the universal PCB you mention?

    I had a problem where a NRF24L01+PA+LNA would not work on a breadboard setup whereas a basic NRF24 would. I thought it was a dud... then when i built the iBoard Ethernet gateway, i thought i would give it another go and it worked straight away!

    Good luck!

  • Hero Member

    Ok, so a bigger capacitors seemed to have helped. I don't know for sure if ceramic would be better. It would at least be more expensive and harder to find when you want capacitance in uF values. If you can't pick them up locally and cheaply, don't bother.

    I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?

  • @ServiceXp

    How are you powering the sensor? Is there a step-up regulator involved?

    See below. The Arduino board is Nano.

    @bjornhallberg said:

    I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?

    I am using a USB charger and have tested some different ones (Samsung's SGS2, iPhone, aftermarket) but I have to admit that those tests have not been very scientific. Now I am doing one change at time and let the device run for a couple of hours.

    The statistics I have pulled is from dataMine in Vera3 which logs this variable change and therefore I allow extra 2 sec for OK result. Most of OK tests happens on 20 sec (as the sensor sends every 20 sec) but many is 40 sec which means that the previous send failed. The statistics this morning was worse (over 10% failed) that previously posted so I am not sure whether the large capacitor helped.

    I also increased the capacitor on gateway to 47uF

  • Hero Member

    @jocke4u Say what you will of iphones but those chargers are pretty solid, if they don't work, no wall wart will. It's too bad you can't give the radio another source of 3.3V though. I assume the Nano follows specs and derives its 3.3V output from the FTDI. Just to rule out that the Nano or the FTDI is the the culprit. An external step down module for instance.

    I agree that the setup should cover the distance you mention just fine if it were working at peak efficiency, but even so it might be interesting to change the orientation or move the sensor closer just for troubleshooting purposes.

  • Mod

    Over and over I have read that daisy chaining the radio or giving it power from the Arduino is a source of problems.
    I found that out the hard way with a board where I put the radio at the end of a chain.
    My next iteration of my board will give it power direct from the source which will hopefully solve the short-range-issue...

  • Hardware Contributor

    Arduino nano makes its 3,3V from the ft232RL chip. According to its specs it can give 50 ma maximum current.
    NRF24L01+PA+LNA can use up to 115 ma in tx.
    I think that to use a NRF24L01+PA+LNA on a nano requires a separate LDO 5->3,3V regulator.

  • Thank you for all your answers.
    I think I have a couple of "AMS1117 5V-3.3V Step Down Module" (or similar) that I can connect to a USB charger. Need to verify though. says "output: 3.3 V, 800 mA"

    Some hacks to do 🙂

  • Hi again,
    First I would like to thank you all for the support/ideas etc and I really want to get sensors stable and reliable. Sure this EnergyMeterPulseSensor is not the most critical one and sure the sketch can be improved not to loose KWH readings/accumulations (Watts is a snapshot) when send fails. But with more critical sensors where something else is triggered.
    Anyway, since I have problem with the EnergyMeterPulseSensor sending data (not counting pulses) I need to get that working and set the "foundation" for future sensors. Sure I have some other test sensors...

    Yesterday I took the following actions.

    • Reverted back to NRF24L01+ due to lower power consumtion
    • Still using 47 uF capacitor to radio power
    • Reverted back to the standard code with gw.begin(incomingMessage); (not using RF24_PA_LOW)


    • Still using NRF24L01+PA+LNA
    • Still using 47 uF capacitor to radio power
    • Added AMS1117 5V-3.3V Step Down Module connected to a separate USB charger feeding the radio
    • Reverted back to the standard code with gw.begin(); not using RF24_PA_LOW

    But unfortunately no success.

    So I wonder what you have as hardware reference architecture;

    • Do you have a verified and reliable solution?
    • What components do you use?
    • What working distance do you have between gateway-sensors ?


  • Hero Member

    Have you tried MySensors 1.3b yet?

  • @ServiceXp
    I have had 1.3b before but without capacitor etc.
    Maybe time to go back to 1.3b3, to see if that works better.

  • Hero Member

    At least In my environment, I had zero communication problems with v1.3. Can't say that about 1.4.

  • Mod

    @ServiceXp said:

    Can't say that about 1.4.

    Do you mean you're having problems with 1.4 then or did you just not have any experience with it yet?

  • DAMN 😞 😞
    I think dataMine played a prank on me and the statistic is probably not correct (not logging everything). Will hook in my MQTT monitor to extract statistics in a way I control it.
    Currently I am running 1.3b3 and will run a test sensor for a while to see how it's works and then eventually go for 1.4 again.
    Thanks for your support and I have learnt more about power and capacitors 🙂

  • Hero Member

    I think both.. The radio problems I had drove me crazy, and then there's still the temps not converting to F using the existing 1.4b library. Which is not a big problem thanks to @hek help.

    I literately had zero issues with the 1.3b library.

  • Mod

    @ServiceXp I'm not aware of any major issues with 1.4 at the moment and @hek is about to tag it. If you are really having (radio) issues related to 1.4 we should fix them asap.

  • Hero Member


    At this point I think I found the solution, but have not built up another test bed to make sure the solution worked. The temp conversion problem is persistent,

  • Mod

    @ServiceXp you said in this post:

    That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF wink and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far.

    This sounds to me that the issue is solved...
    I can imagine that 1.4 requires a bigger cap while 1.3 doesn't. 1.4 uses auto acknowledge which can send burst packets. This could put a bigger load on your power supply.

Log in to reply

Suggested Topics

  • 12
  • 23
  • 4
  • 39
  • 85
  • 14
  • 1
  • 13