Radio stop emitting after a few hours...

  • Hi,

    I replaced the thermostat of my old fridge by an sensor made of arduino nano + nrf24l01+ DS18B20 temp sensor + relay.
    And it works great. Except that after a few hours, and although the temperature control works ok, the sensor stops emitting to the controller.

    If I reset the arduino the radio communication is good again, and then a few hours later, same thing, it does't send anything (no messages appear in the log of the controller).

    In the meantime I added a 47µF capacitor on the radio, but it didn't help.
    The arduino is not on battery..

    Today when I saw the radio didn't send data anymore I plugged the serial, and here's what I read (the T:X.XX comp:1 are the temperature and the boolean indicating if the compressor is on or off):

    T:6.70 comp:1
    T:6.70 comp:1
    T:6.70 comp:1
    T:6.70 comp:1
    T:6.60 comp:1
    T:6.60 comp:1
    T:6.60 comp:1
    T:6.50 comp:1
    TSP:MSG:SEND 142-142-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:
    T:6.50 comp:1

    Reading a bit of the MySensors source code I understood that TNR means "Transport Not Ready", but... why ?

    In any case, here's the sketch I'm using:

    // Enable debug prints to serial monitor
    #define MY_DEBUG 
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    //#define MY_RADIO_RFM69
    #include <SPI.h>
    #include <MySensors.h>  
    #include <DallasTemperature.h>
    #include <OneWire.h>
    #include "FridgeThermostat.h"
    #define ONE_WIRE_BUS 3 // Pin where dallase sensor is connected
    #define MAX_ATTACHED_DS18B20 16
    #define SLEEP_TIME 30000 // Sleep time between reads (in milliseconds)
    #define GPIO_THERMOSTAT 8
    #define TEMP_LOW 5.0
    #define TEMP_HIGH 6.0
    #define NB_HOT_READS_NO_ACTION 1
    OneWire oneWire(ONE_WIRE_BUS); // Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
    DallasTemperature sensors(&oneWire); // Pass the oneWire reference to Dallas Temperature.
    // Initialize temperature message
    MyMessage msg(0, V_TEMP);
    MyMessage msgCompressorStatus(1, V_STATUS);
    // query conversion time and sleep until conversion completed
    int16_t conversionTime;
    void presentation()  {
      // Send the sketch version information to the gateway and Controller
      sendSketchInfo("Fridge thermostat", "0.4");
      // Register all sensors to gateway (they will be created as child devices)
      present(0, S_TEMP, "Temperature");
      present(1, S_BINARY, "Compressor on/off");
    void setup() {
      // Startup up the OneWire library
      // query conversion time
      conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
      // requestTemperatures() will not block current thread
    void loop()      
      // Fetch temperatures from Dallas sensors
      // sleep until conversion completed
      // sleep() call can be replaced by wait() call if node need to process incoming messages (or if node is repeater)
      // Read temperatures and send them to controller
      // Fetch and round temperature to one decimal
      float temperature = static_cast<float>(static_cast<int>((getConfig().isMetric?sensors.getTempCByIndex(0):sensors.getTempFByIndex(0)) * 10.)) / 10.;
      // Send in the temperature to the controller even if error, to have a clue
      // something goes wrong:
      boolean compressorIsOn;
      // Only tell the thermostat if no error:
      if (temperature != -127.00 && temperature != 85.00) {
        compressorIsOn = thermostat.act(temperature);
      Serial.print(" comp:");

    Any help appreciated !



  • Contest Winner

    @ybycode I'll see if I can find strange things in your sketch later on. But most of these problems are power related. And I know that sounds fuzzy ;-). At least for me in the beginning. But in the end, it's 90% of the cause.

    1. How do you power the radio? Directly from the radio?
    2. Did you try an other radio? Radio might be defect

    edit. I don't see anything strange in your code.

  • The whole is powered with a 5V 1A power supply from an old phone, connected to the USB port of the arduino nano. The radio module is powered by the VCC port of teh arduino.

    I'll change the power supply this evening, see what happens. I'll try another radio module tomorrow if needed.

    I'll keep you posted.

    Thanks !

  • Mod

    @ybycode said:

    The radio module is powered by the VCC port of teh arduino.

    nRF24 is only rated at 3.6V maximum. You should not run it at VCC of the Nano, which is at 5V!

  • Contest Winner

    @ybycode If nothing else is being powered directly from the Arduino you should be okay.

    But it is always better to power everything you attach to the Arduino by an adapter. You could use a cheap LE33 power regulator between the adapter and the gnd and vcc of the radio. If you're lazy like me a buck converter is always your friend.

  • @Yveaux sorry, correction: it's connected to 3V3

  • Changing the power supply didn't change anything. I'll try changing the radio today.

    In the meantime, I have a question. Everytime the problem has happened, the last temperature that was sent is always either the limit low, or the limit high temperature defined in my sketch, meaning when the relay is passed from close to open or from open to close, when the fridge compressor is turned on or off.
    This makes me think: could my problem be du to an inductive spike, like described in this thread ?

  • Contest Winner

    @ybycode could be. I once had a MySensors project which used a speaker. The speaker was very close to the radio and that Node behaved just like yours. When I move the speaker away from the node it became stable. Not sure if an inductive speak could be the cause, when you use the break-out relays. But that's a good question for someone with more electronics knowledge.

    I've found a tutorial about watch dogs. It is a last resort, but adding a watchdog will reset your arduino if it stalls. It doesn't resolve the cause though. But I'm thinking about adding a watchdog to all of my sensors. Just to make sure they can't stall in case hardware related issues.

Log in to reply

Suggested Topics

  • 5
  • 25
  • 2
  • 9
  • 2
  • 5
  • 3
  • 13