Node can send I_FIND_PARENT_REQUEST but cannot receive I_FIND_PARENT_RESPONSE



  • I recently designed and fabricated a new PCB utilizing the NRF24 with an ATMEGA168P (12MHz, 3.3V) and as usual, I ran into problems immediately. This time, it seems that the node is able to broadcast the I_FIND_PARENT_REQUEST to the gateway which receives it, but somehow is unable to itself receive the I_FIND_PARENT_RESPONSE from the gateway.

    Here is the simple sketch (LightSensor example) that I used. I added the #define MY_NODE_ID 15 line to force the node to broadcast a preset ID as not including this line led to the controller not logging any record of receiving the I_FIND_PARENT_REQUEST.

    // Enable debug prints to serial monitor
    #define MY_DEBUG
    #define MY_RF24_PA_LEVEL RF24_PA_MAX
    #define MY_NODE_ID 15
    
    // Enable and select radio type attached
    #define MY_RADIO_NRF24
    //#define MY_RADIO_NRF5_ESB
    //#define MY_RADIO_RFM69
    //#define MY_RADIO_RFM95
    
    #include <MySensors.h>
    
    #define CHILD_ID_LIGHT 25
    #define LIGHT_SENSOR_ANALOG_PIN 0
    
    //uint32_t SLEEP_TIME = 30000; // Sleep time between reads (in milliseconds)
    
    MyMessage msg(CHILD_ID_LIGHT, V_LIGHT_LEVEL);
    int lastLightLevel;
    
    
    void presentation()
    {
    	// Send the sketch version information to the gateway and Controller
    	sendSketchInfo("Light Sensor", "1.0");
    
    	// Register all sensors to gateway (they will be created as child devices)
    	present(CHILD_ID_LIGHT, S_LIGHT_LEVEL);
    }
    
    void loop()
    {
    	int16_t lightLevel = (1023-analogRead(LIGHT_SENSOR_ANALOG_PIN))/10.23;
    	Serial.println(lightLevel);
    	if (lightLevel != lastLightLevel) {
    		send(msg.set(lightLevel));
    		lastLightLevel = lightLevel;
    	}
    }
    

    Here are the logs from the node:

     __  __       ____
    |  \/  |_   _/ ___|  ___ _ __  ___  ___  _ __ ___
    | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __|
    | |  | | |_| |___| |  __/ | | \__ \  _  | |  \__ \
    |_|  |_|\__, |____/ \___|_| |_|___/\___/|_|  |___/
            |___/                      2.3.2
    
    16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=12,REL=255,VER=2.3.2
    27 TSM:INIT
    28 TSF:WUR:MS=0
    35 TSM:INIT:TSP OK
    38 TSM:FPAR
    3353 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    5363 !TSM:FPAR:NO REPLY
    5364 TSM:FPAR
    8680 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    10689 !TSM:FPAR:NO REPLY
    10690 TSM:FPAR
    14006 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    16016 !TSM:FPAR:NO REPLY
    16018 TSM:FPAR
    19334 ?TSF:MSG:SEND,255-255-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
    21344 !TSM:FPAR:FAIL
    21345 TSM:FAIL:CNT=1
    21348 TSM:FAIL:DIS
    21349 TSF:TDI:TSL
    

    and !TSM:FPAR:NO REPLY repeats over and over... But strangely these are the logs from the controller (Raspi running HA):

    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20391 TSF:MSG:READ,15-15-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20391 TSF:MSG:READ,15-15-255,s=255,c=3,t=7,pt=0,l=0,sg=0:
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20398 TSF:MSG:BC
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20398 TSF:MSG:BC
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20401 TSF:MSG:FPAR REQ,ID=15
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20401 TSF:MSG:FPAR REQ,ID=15
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20404 TSF:PNG:SEND,TO=0
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20404 TSF:PNG:SEND,TO=0
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20407 TSF:CKU:OK
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20407 TSF:CKU:OK
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;20410 TSF:MSG:GWL OK
    2022-06-04 17:14:43 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:20410 TSF:MSG:GWL OK
    2022-06-04 17:14:44 DEBUG (MainThread) [mysensors.transport] Receiving 0;255;3;0;9;21404 !TSF:MSG:SEND,0-0-15-15,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
    2022-06-04 17:14:44 DEBUG (MainThread) [mysensors.handler] n:0 c:255 t:3 s:9 p:21404 !TSF:MSG:SEND,0-0-15-15,s=255,c=3,t=8,pt=1,l=1,sg=0,ft=0,st=NACK:0
    

    From the st=NACK:0, it seems that the node is not acknowledging the I_FIND_PARENT_RESPONSE.

    I have already tried soldering a 100uF cap across the RF24 supply pins as well as powering the entire circuit using a lab bench power supply at 3.3V.
    I find this extremely puzzling as the node can clearly establish a one-way communication line with the controller but not vice versa. Any help as to why this is happening would be greatly appreciated. Thanks.



  • Are you sure the INT pin is connected?
    Sending will work, but it will never get an interrupt on recieving a message



  • @electrik it is connected to INT0 (D2). I went through all my RF24 modules and finally got one to work. As such I think the problem was with the RF24 module.

    I am going to migrate to RFM69 as RF24 modules are too inconsistent and low quality for reliable home automation.



  • If you have the wrong modules, it could give you problems yes. Check out the buying guide, there are recommendations for the modules to pick, for example the ebyte ones. The will work very reliable. Big advantage of NRF24 to RFM69 is the throughput and response time.


Log in to reply
 

Suggested Topics

77
Online

10.6k
Users

10.9k
Topics

111.3k
Posts