This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF24L01+ seems very sensitive to electric noise

Hi

I am working on a design using an nRF24L01+ in a circuit also consisting of an ATMEGA microcontroller and a H-bridge motor driver driving a brushed DC motor. The whole circuit will be battery powered.

Now, the nRF24L01+ seems very sensitive to electric noise produced by the motor.

As a consequence the nRF24L01+ seems to crash and needs a reset by cutting the power and switching it back on. The ATMEGA microcontroller of the circuit seems to be far less sensitive and takes this noise well without crashing.

As for the noise from the sparks produced by the commutator of the brushed DC-motor, I have found that it can be successfully filtered away using three 100nF capacitors on the motor, one between the terminals of the motor, and one between each terminal and the motor casing, as well as a reasonably large capasitor, 100µF, on the 3.3 V power supplied to the nRF24L01+.

But I have another problem also. I mentioned that the circuit will be battery powered. Everything works fine when the batteries are fully charged.

But, the nRF24L01+ does not seem to like it much when the batteries are starting to run a little low and the motor is switched on. Because the change in voltage due to running the motor is also something that sometimes seem to crash the nRF24L01+

Contrary to what I expected when measuring the supply voltage to the nRF24L01+ when running the motor on a battery that is a little out of charge, the voltage across the power terminals of the nRF24L01+ does not drop, but actually jump up a little. I assume this is due to the 3.3 V linear voltage regulator that I am currently using, overcompensates for the drop in battery voltage.

When I run the system on batteries that are fully charged the voltage from the regulator stays constant when the motor runs.

So, I guess that a clue here is to find another 3.3V voltage regulator that does a better job suppling the nRF24L01+ with a more stable voltage even in the situation that the batteries are a little low on charge and a larger load is switched on.

Question 1: Do any of you, from experience, have any voltage regulators, that would do a good job doing so, to recommend

Question 2: It would be nice, for an added degree of robustness, if the microcontroller could wake up the nRF24L01+ in the event that the latter has crashed. Does anyone have a word of advice as to how that might be accomplished?

  • Some ideas:

    1. Use a watchdog timer.
    2. Output a square wave from the nRF and detect it from the Atmega to check for liveness.
    3. Add a larger smoothing capacitor for the motor. 300 nF is not very much for a motor.
    4. Add another capacitor for the nRF after the regulator (do you have one)?
    5. Run the nRF from a separate battery to see what causes the problem exactly.

    I've used Sparkfun's 3.3V step-up regulator for powering an nRF51822 from 2xAA batteries and it works fine.

  • @Tim

    Thank you answering

    1 I have that already, but I am not sure how to restart the nRF24L01+ from the MCU when a timeout occurs.

    3 It is a fairly small 6V DC motor, so 3x 100 nF seems to have done the trick regarding just that problem. But sure, I can opt for some with a larger capacitance.

    4 Yes I do have a 100µF electrolyte capacitor after the regulator, and a 100nF ceramic capacitor in parallel with it also, to filter noise with frequencies that the electrolyte is not so good at.

    5 I am not quite sure as to how that would help me diagnose the problem. Running it from a separate battery would probably make it even more difficult, if not impossible, to reproduce the error. And the error is pretty hard to reproduce as it is. Its one of those pesky ones, that come and go, actually it comes on rare occasions. So, it is a matter of testing, testing and testing until it occurs.

  • Hey @Vidar, did you find a suitable method to restart the nRF24L01+ from the MCU when a timeout occurs yet? I am facing a similar issue, and it would be great if you could share how you managed to tackle the issue.

  • EMI issues should be resolved at the schematic/layout level of the PCB. Software can only do so much in that case.

Related