nRF24L01+ Only working when you touch finger to module. Using particle-rf24 Library

[Mahonroy]

Hey guys,
We are using the particle-rf24 library with the nRF24L01+ modules (with PA and LNA onboard). A certain percentage of our boards will only transmit if you touch the RF module with your finger. We had this exact same problem on a different device without the Photon, and the problem turned out to have to do with the CE pin not being pulled high for long enough.

We figured that this would be the solution for the Photon, but adding that extra delay on the CE pin being high is not doing the trick. Can you guys offer any suggestions?

Some additional info:

1. Swapping the RF module to one that does not have a PA always works perfectly.
2. All of the modules always receive just fine, its the transmission piece that malfunctions.

[kennethlimcp]

Does the other device has another wireless transmitter? Wifi, bluetooth etc…

[Mahonroy]

The other devices are just microcontrollers and RF module (and then something like a sensor, or a relay, etc.)

[kennethlimcp]

I would try placing the nRF24L01+ further away from the Photon and see what happens.

Does the nRF24L01+ respond to commands?

[Mahonroy]

Every part of the nRF24L01+ works perfectly fine (can communicate with it, receive payloads, read registers, etc.). The only part that does not work is the transmission part - if you touch your finger to the antenna it works however. RF modules that don’t have a PA onboard work perfectly.

[Mahonroy]

Here are different things I have tried so far with no luck:

• Added 1.5ms extra delay before bringing the CE pin back low.
• Added 200uS delay when transitioning between sending and receiving.
• The SPI communication between the Nordic module and Photon looks to be at 2Mhz. I slowed this down to about 0.5Mhz, no change.
• Disabled the Photons wifi before testing the RF module in case there was interference from the Photons 2.4Ghz.
• Verified that the TX_DS flag on the STATUS register was occurring after each transmission.
• Verified that the Nordic module can always receive payloads just fine, its just the transmission that is the problem.

[kennethlimcp]

Not really clear what’s going on here since it sounds like some physical hardware quirks where having an external antenna solves it.

Do you know how much current is being drawn?

[Electronic_Project]

@Mahonroy

,

@Mahonroy
I have the same issue, please inform me did you solve it?

[Backpacker87]

@Mahonroy, I have also experienced this phenomenon with the finger and the fact that it works fine without PA and does not work with PA.

I suggest you add a 10uF capacitor across Vin and GND on the NRF radio. Also, what antenna are you using with your setup? Lastly, I have found that this finger issue is related to grounding.

Which module are you using specifically? These little guys can save you headache if you have not run across them https://www.amazon.com/gp/product/B01IK9GCPE/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

[JustinCase]

Created an account just to post here. I’ve been having that problem and it was driving me nuts. I thought I had fixed it once but it reared its ugly head again. I tried everything and just like everyone here it only happened with the PA/LNA models and on top of that only in one setup. Tried with and without a capacitor between Vcc and ground. Tried different values. Removed the ‘shield’ I had installed on it (cling wrap + foil) and nothing worked. Only my magic finger touching the damn CE wire worked.

So after finding this post I figured the problem wasn’t just me. Since that tiny module people keep recommending was mentioned I took a look at it and noticed all the capacitors so I thought why not try a 0.1uF between CE and ground to see if that could stabilize the signal (couldn’t check on a score if it was noisy). It almost did the trick. Now the communication happens ‘correctly’ but it doesn’t seem very stable. There’s a delay before the packet gets transmitted. As soon as I put my finger back on the CE wire all communications happen instantly like normal. Perhaps with these new informations someone could shed some light on the problem. Since a 0.1uF improved but didn’t completely solve, is there another value I could try or some other thing to clean the CE signal? I’m going to try a few more values but I’m a programmer so this is all guesswork to me!

Thank you.

Update. It turned out the rail I was connecting that 0.1uF cap wasn’t even connected to ground and when I connected it the NRF stopped working completely. So back to square 1.

[ian.c]

@Backpacker87

Lastly, I have found that this finger issue is related to grounding.

I'd listen to @Backpacker87 here. If RF performance on a board changes because of you touching a component that's a really good indication that there's either interference or other noise in the circuit. Proper shielding, grounding, and decoupling might help, but interference can come from many sources. However, in order to 'properly' troubleshoot an RF problem, especially if you have a PA and LNA in the design, you need to look at the signal at every stage and operating mode and observe the signal and measure noise.

That said, I looked at the datasheet and it looks like you drive CE high for TX? Do you know if the output driving CE has enough power to hold it high? If the driver is unstable you might see problems without a cap and adding one could maybe make it worse. You might need to pull the CE high using a resistor and then drive it low using your output, or use a driver circuit so that CE isn't held high just by the your output pin. Of course, I don't know your circuit so read up on pull-ups and maybe BJT drivers and figure out if that works for you before trying anything.

[JustinCase]

Thanks for the answer. I tried listening to @Backpacker87 but as I said, I’m a programmer. I can read on the subject but, been there done that. I’ve reached the end of my wits!

You are right, we have to drive CE high to transmit. A 10us pulse for 1 packet transmission (recommended use) or kept high to transmit until TX buffer empty.

But it’s not the RF performances that is the problem but the NRF’s ‘detection’ of the pulse on CE. I drive it high for 10us (tried longer too) then low and it’s like the signal is being ‘held’ somewhere. As soon as I bring my finger close to the wire the packet is transmitted and without error. It’s just the CE pulse that is problematic. I can do the pulse and wait 10 seconds before bringing my finger close and sure enough the packet is sent at that time.

And on top of that, I have a very similar setup on three other breadboards and none of them have that problem. There isn’t anything close that should interfere. It’s a Pro-mini, W25Q flash chip, NRF24L01 and a LCD. Could the LCD backlight pwm cause this? Oh my… (small epiphany here)

The backlight PWM pin is right next to the CE pin… Oh I’m tingling now! Could it be that or I’m again setting myself to be disappointed?! I’m going to try turning off PWM to see (in a bit)… I’ll come back with the results. If you have tip on handling such thing as a pwm next to a sensitive, childish, stubborn, annoying digital output, please enlighten me.

Thanks for making me shake my neurons!

[ian.c]

For clarity, I’m not suggesting RF “output performance” in your case, but RF susceptibility on the CE pin, because you have an intermittent signal-related issue on an RF component which is solved by your finger (likely capacitance, grounding, or the physical connection itself). We’re speculating without a scope… I think we’re assuming that the signal doesn’t stay above the ON threshold for >10us until your finger adds capacitance, helps to ground noise from the board, ‘shorts’ the connection to another pin, completes the pin’s connection, or does something else we’re not considering (without a scope we don’t know). The buffered packet is then sent.

You said you drive it high for 10us and tried longer, you should certainly have it longer because 10us is the spec’s bare minimum. You can tighten this toward 10us after you have stability.

Any signal including a PWM can cause interference, but if a digital line is not stable (1 or 0 solid) its the digital line’s susceptibility or connection I’d focus on. Susceptibility causes could be poor grounding in the circuit, lack of necessary decoupling caps, trace layout, etc. Poor connection causes could be a bad solder joint, bad wiring, bad part… Could also be the ON timing, or insufficient power/voltage to drive the pin. With a scope you could check for digital levels, rise and fall time, and signal frequencies on the pin and we’d know whether it actually goes high when you drive it. A PWM could induce a signal on a digital line but if you account for the stuff above it should be nothing but a tiny ripple in a solid signal, maybe. What is the supply voltage and what is the CE pin voltage? Is it above the turn on threshold if you hold it high? You could check this with a DMM if you can safely hold CE high.

If you have other boards working and this is a one-off, then is the troubleshooting worth the effort or would buying another module be the simplest solution?

[JustinCase]

As expected I’m even more lost than I was. It turns out the pwm pin is not right next to the CE pin. But I tried turning it off anyway. It didn’t work.

The CE pin is an output from an Atmega328p. I would assume it can drive plenty but that’s where my lack of electronic background shines. So I tried all sort of pull-up and down combinations. Driving the pin low as an output and high as an input with the internal weak pull-up turned on. As an input with a stronger 1k external pull-up, as an output with a 1k pull-down (I didn’t like the 3.3mA shunt to ground when driving high but I had to try) and as an output with a strong pull-up (again, I doubt it could drive more than the pin itself but had to try for completeness’s sake). Nothing worked.

What ‘worked’ in the end was having a 1k resistor on the CE pin from the uC followed by a small length of wire and all of that left… floating. I didn’t really try that as a solution but I noticed it was suddenly working for no apparent reason. With just the wire there is a delay but the packet is still sent. With a 10k it isn’t sent. With 1k it’s practically right away. But it’s friggin’ floating!!! So yeah… I’m lost. I put the NRF w/ PA back in the drawer and maybe one day I will again feel like wasting a bit of time on that. Since it happens on only one board and only with the PA models, I will avoid that combination.

A last note, when it’s not working I can fill the FIFO and all three packets will be sent when I touch the wire (I only have to approach it, I don’t even have to touch it). It really is only the CE pin. Everything else is rock solid.

As a last, last note, I can use a PA model powered with only two coin cells in series with a 3.3V linear regulator and a 33uF cap on the NRF’s power pins and it’s working without a single problem.

Anyway, I’ll keep an eye here but I’m mostly done with that problem. On a final board I would not have those wires picking/throwing up all kinds of crap anyway.

[ian.c]

@JustinCase

What ‘worked’ in the end was having a 1k resistor on the CE pin from the uC followed by a small length of wire and all of that left… floating

Hahaha, I'm sure this was frustrating, but it's so interesting. I wish I could see a scope output and a photo of the board.

Ok so, floating as in not connected to the CE on the nRF???? (can't be, right?) or as in hanging off of the connection between the nRF and Atmega, I assume? I know you put it away already, but for completeness... the resistance in the second option should affect the impedance of CE connection. The impedance will impact the coupling of RF noise or signals onto the trace/wire connected to the CE pin, so it makes sense to me that this had an effect, but it's uncontrolled... A decoupling cap (at the right value) mounted close to the CE input should eliminate spurious signals in a more intentional way.

[JustinCase]

Yes, floating as in one end not connected to anything. PinB1 of uC -> 1k resistor -> wire that was supposed to connect to Vcc/Gnd -> Free air! That’s when my left eye started twitching and I decided to stop. I figured I would eventually wake up and laugh about it…

I’m trying to understand everything you said but when I see words like coupling of RF noise and impedance I get cold sweats! By decoupling cap do you mean a 0.1uF between CE pin and ground? I tried that (and 10nF and 1uF too) but then even touching the wire wouldn’t do anything. It just wouldn’t transmit anything. I tried on both the uC and NRF sides. Are you suggesting a resistor and cap as decoupling apparatus when the uC pin is set as Input with a 1k external pull-up? I’m not sure what the connections should be though. I’m thinking signal from uC to resistor and then split from resistor to go to NRF-CE and also to cap->Ground? Taking a mostly wild guess based on low pass filter schematics.

Here’s a picture I took this afternoon. I’ll try to make a short video showing it in action. Floating wire and all!

RemoteX-xx|690x388

The plot thickens. And thanks!

[Backpacker87]

@JustinCase, did you try using one of these? The NRF24L01+ is picky about its power supply. If its not working, usually it is a power issue or it is wired wrong. Also, I don’t know where you got your radio modules, but counterfeits are out there and they can have very erratic behavior.

I don’t know if you are using a library or not, but this one is the best place to start.

I have multiple uno based system that uses the NRF24L01+ module (has FCC cert) in a mesh configuration that supports 20 nodes + talking to a single base on a 2 second interval. Once you get them working they are pretty cool what they can handle including my favorite, which is the ability to assign channels on the fly.

[ian.c]

when I see words like coupling of RF noise and impedance I get cold sweats

Noise gives everyone cold sweats, so you aren't alone!

Yes, the 0.1uF is a decoupling cap. Often an app note will recommend the value but I don't see one in the datasheet. It should be on the nRF CE pin side.
The uC pin should never be an input when you use it to drive the CE pin. That's pretty confusing to me.

Usually either a pull-up OR a decoupling cap on one pin. The pull-up stabilizes your HIGH supply so that the uC output pin doesn't have to send all of the energy. With a pull-up, you allow power to come from the supply and the pin just shunts to GND when you send it LOW, make sure the pull-up resistor is large enough that you don't shunt too much power (check datasheets). This fixes a situation where your pin lacks the power to drive the line, it does nothing for noise.

If the supply is noisy, like @Backpacker87 suggests, then it's not more power, it's a clean signal you need. The cap smooths the voltage, like a damper in a car's suspension, so that it doesn't bounce around. If you use them together you start to filter specific frequencies, a wire plus a cap is just a very low value resistor and a cap so it's works the same but you aren't building a filter so the resistor shouldn't go in-line.

The cap from Vcc to GND is why this sounds predictable:

As a last, last note, I can use a PA model powered with only two coin cells in series with a 3.3V linear regulator and a 33uF cap on the NRF’s power pins and it’s working without a single problem.

The 33uF is a decoupling cap that's filtering noise on the power supply. Why a 0.1uF cap kills your TX when attached to CE is confusing, but the cap causes a dampening, remember, so if you don't allow enough time for the CE voltage to rise from 0 to 3.3V it will never get high enough and before you shut it off. On the CE pin it has to be a lower value, but if you tie the CE pin to Vdd with a pull-up resistor and then put a 33uF cap between Vdd and GND very near to the resistor connection I wonder what will happen?

I think that might look like this sketch if you use a 22uF cap decoupling Vdd, and a 10k pull-up on CE, but check my connections before you trust this and adjust the values as necessary. Maybe @Backpacker87 could comment as he has experience with this IC:

[JustinCase]

@Backpacker87 I saw those modules mentioned often but I never experienced any kind of power problem with NRFs. I have been using those modules for a while and with a lot of different uC. I wrote my own library a couple years ago and it’s pretty solid. I trust my code. That’s my desk atm, brought together for a family picture with 3 more still hidden behind. It’s only the PA/LNA on the large breadboard that exhibits the CE behavior. So I’m thinking you may be right about counterfeits, or maybe I just got a batch of almost duds, or my breadboard hates antennas, I dunno! Nevertheless, I put two of those power modules on my next order. They’re too cheap to not at least give it a try. And if it works I will work my way back to the source of the problem and try solve it without using the module (I will just check how they do it and copy). If only to say GOTCHA!!!

@ian.c Driving the pin with an input+pull-up was confusing to me too but I didn’t know you could pull-up an output. For me pulling was always done on an input. I thought pulling an output would waste power as I would have to use a strong pull to try to beat the pin itself but you kinda covered that up too so now I know better. Thanks for that! The uC pin can drive the pin plenty though. I know it’s not the problem. It’s most likely as you suggested noise, even if it’s only the PA/LNA that suffers from it. I will try again the 0.1uF cap on the NRF’s CE but this time I will prolong the 10us pulse. It could be why it wasn’t working at all with a decoupling cap. I will not tie CE to Vdd with a pull-up and add a 33uF cap though. I’m always going back to “it only happens in this very specific case” so I believe I’m done experimenting. The 0.1uF and longer CE pulse is the last thing I’m going to try. That is until I receive the power modules and go for another round.

[Backpacker87]

@JustinCase
I zoomed in on the PA + LNA module on the big breadboard that you are referencing and I have never worked with that model in the form factor shown. I am use to the PA + LNA looking like this with a duck antenna.

When I have used the above larger unit with a duck antenna with the power module they always seem to work. Having the duck makes a big difference because these radios are sensitive to the ground plane. Another way you can identify this is by taking foil and laying it near/over the module which can have a similar effect as using a finger.

Bottom line, if you want to move on from the frustration, I would suggest trying the larger module with the power module. If this does not work, then I would get into CE timing, etc.