I did the test again, this time logging serial on the node. At 4277 and 4280 you see how the messages fail the first time. It is expected since the GW is down. Then I start the GW. There is no attempt to connect on the node's side. After one hour you can see how the node fails to send messages, this time the GW is up. The node does not seem to register during this hour. When I restart the node, the connection to the GW is established as it should. Maybe it is a bug?

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=3000
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=2
15 TSF:SID:OK,ID=2
17 TSM:FPAR
53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2060 !TSM:FPAR:NO REPLY
2062 TSM:FPAR
2098 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3006 MCO:BGN:STP
3135 MCO:BGN:INIT OK,TSP=0
4277 !MCO:SND:NODE NOT REG
4280 !MCO:SND:NODE NOT REG
3604282 !TSM:FPAR:NO REPLY
3604285 TSM:FPAR
3604322 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3604328 TSF:MSG:READ,0-0-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
3604334 TSF:MSG:BC
3605475 !MCO:SND:NODE NOT REG
3605477 !MCO:SND:NODE NOT REG
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=3000
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=2
15 TSF:SID:OK,ID=2
17 TSM:FPAR
53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
814 TSF:MSG:READ,0-0-2,s=255,c=3,t=8,pt=1,l=1,sg=0:0
819 TSF:MSG:FPAR OK,ID=0,D=1
2060 TSM:FPAR:OK
2061 TSM:ID
2062 TSM:ID:OK
2064 TSM:UPL
2067 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2076 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2081 TSF:MSG:PONG RECV,HP=1
2084 TSM:UPL:OK
2085 TSM:READY:ID=2,PAR=0,DIS=1
2091 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2097 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2105 TSF:MSG:SEND,2-2-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2113 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2139 TSF:MSG:READ,0-0-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2146 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=OK:GardenMaster
2156 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:2.0
2164 TSF:MSG:SEND,2-2-0-0,s=1,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2171 TSF:MSG:SEND,2-2-0-0,s=2,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
2178 MCO:REG:REQ
2181 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2188 TSF:MSG:READ,0-0-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2193 MCO:PIM:NODE REG=1
2195 MCO:BGN:STP
2323 MCO:BGN:INIT OK,TSP=1
3467 TSF:MSG:SEND,2-2-0-0,s=1,c=1,t=1,pt=2,l=2,sg=0,ft=0,st=OK:96
3475 TSF:MSG:SEND,2-2-0-0,s=2,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=OK:24

I had a (seemingly) similar issue with my NRF24+LNA+PA board. The solution was stupid simple - just get the node further away from the GW. Or remove antenna if you have one. We usually develop the node connected to the same PC, both GW and the node. It is simply too strong a signal.

@gohan said in nRF24 would not transmit when connected to Nano, but works fine with Mega:

voltage regulators usually can not keep up

LP2985 on Mega gives 150mA, which is at least in double excess of the highest nRF24 +LNA+PA can consume. It should do fine without the cap.

On Nano it is not a voltage regulator. FTDI chip converts serial to USB. And for Nano I did use the caps 4, 10 and 20 uF - none helped. Honestly, I haven't noticed any effect of these caps so many on the forum talk about. If it works, it works, if not - bad luck. I can believe in a very rare case the extra charge of a 20uF cap could topple the scale, giving illusion that this is a solution.

When I reduced from RF24_PA_MAX to RF24_PA_HIGH it started to work sometimes. When down to RF24_PA_LOW it works stable. However I transmit 7 bytes only, the payload can be up to 32 bytes. This will further increase power requirements and will further short 3V3 output.

In order to save MySensors lib from ungrounded suspicions (which I had) and simply to act professionally we should admit that on Nano the 3V3 output should not be used. Otherwise the behavior is undefined. Even without PA. The spec for nRF24 says 14mA at transmission. The spec for FTDI says it 15mA typical, 24mA max. It is an unacceptable low margin for expecting stable communication.

@gohan said in nRF24 would not transmit when connected to Nano, but works fine with Mega:

voltage regulators usually can not keep up

LP2985 on Mega gives 150mA, which is at least in double excess of the highest nRF24 +LNA+PA can consume. It should do fine without the cap.

On Nano it is not a voltage regulator. FTDI chip converts serial to USB. And for Nano I did use the caps 4, 10 and 20 uF - none helped. Honestly, I haven't noticed any effect of these caps so many on the forum talk about. If it works, it works, if not - bad luck. I can believe in a very rare case the extra charge of a 20uF cap could topple the scale, giving illusion that this is a solution.

When I reduced from RF24_PA_MAX to RF24_PA_HIGH it started to work sometimes. When down to RF24_PA_LOW it works stable. However I transmit 7 bytes only, the payload can be up to 32 bytes. This will further increase power requirements and will further short 3V3 output.

In order to save MySensors lib from ungrounded suspicions (which I had) and simply to act professionally we should admit that on Nano the 3V3 output should not be used. Otherwise the behavior is undefined. Even without PA. The spec for nRF24 says 14mA at transmission. The spec for FTDI says it 15mA typical, 24mA max. It is an unacceptable low margin for expecting stable communication.

@etxmsol by some magic 5 minutes after I posted the solution dawned on me. I assumed Nano has a voltage regulator for 3V3 like Mega, but in fact it is the FTDI chip that generates 3V3 output. Better they did not have it!!! The typical current acc to spec is 15mA, max 24mA. About as per nRF24 spec for itself, but let alone the PA and LNA. Now when I use my Mega's 3V3 output to feed the nRF connected to Nano, everything is alive.

Strangely, in my quest I used a Fluke to measure consumed current by nRF24 and I saw it is about 20mA for both Mega and Nano. It is likely that the actual moment of transfer is very short and probably just missed in measurements.

Well, what a lesson!

Hi,
after exhaustive troubleshooting, using both logic analyzer and oscilloscope I'm giving up. I have three Arduino Mega boards that all operate nRF24 flawlessly. I have a number of Nanos that would read registers fine, but would not transmit a payload.

The problem is when finding a parent. In the RF24.cpp there is a special treatment for broadcast. Namely, it disables the ACK. In the function RF24_sendMessage a mega would receive RF24_MAX_RT (well, it was trying to send but got no ACK). It flashes the Tx and the communication is established:

// timeout counter to detect HW issues
uint16_t timeout = 0xFFFF;
do {
	RF24_status = RF24_getStatus();
} while  (!(RF24_status & ( _BV(RF24_MAX_RT) | _BV(RF24_TX_DS) )) && timeout--);

My Nanos (some clones) would receive timeout instead. Apparently, it does not try to transmit.

By means of logic analyzer, I could see that the signaling is absolutely equivalent, from Nano to nRF24 as from Mega and nRF24. Mega however does transmit stably, while Nano fails every time. Probably the nRF24 is more discriminative at SPI signaling.

Does any one have any experiences similar to this? Any ideas maybe?

yeah, it should be on the OpenHab side then. I've found an option in the OpenHab service (Karaf) to configure the level of the logging. The message comes actually from the MySensors binding (a part of MySensors infrastructure on the OpenHab side):
23:08:57.306 [WARN ] [rs.internal.gateway.MySensorsGateway] - Presented child is alredy present in gateway
The message type is WARN. I can change the logging level in OpenHab to ERROR. Then the warnings are no more. On the downside, I'll see no warnings at all, even the ones I need to see.
Probably the warning comes from the OpenHab to the binding. Still basically it should be possible to disable this specific warning in the MySensors binding somehow (binding config page?).

also, could you as a moderator move this topic to either Development or Controllers? It looks the discussion is quite specific

thanks for your reply. I was not clear on my purpose, my bad. I want a truly self healing network. I have a serial GW, connected to OpenHab2 running on a BeagleBone Black. I use the provided MySensorsSerialGW, connected over FTDI adapter to the USB on the BeagleBone. When on some reason, either GW or the BeagleBone. or both get restarted, the GW loses all information about the connected nodes. This is of course normal, the GW is a simple arduino nano program. The nodes (Arduino Mega), on the other hand are unaware. They send updates, but fail. To solve this issue, I figured out I could call the presentation() function (which is normally only called before Arduino's setup()) every time before sending a message (update status). Just to be sure, the node is registered with the GW. Another solution would be to restart the node, but this is not self healing. In the rare case when the GW was actually restarted, calling presentation() re-does registration. But in all other cases it leads to the warning message as described. I was wondering if I could suppress this message.

Hi,
in order to achieve the self-healing of the network after the GW restart, I call in my nodes the presentation() every time I'm about to send a message. This works perfectly and serves its purpose! One drawback is the openhab2.log file on my BeagleBone is flooded with:
2017-10-01 20:28:11.352 [WARN ] [rs.internal.gateway.MySensorsGateway] - Presented child is alredy present in gateway
Hundreds of kilobytes a day. Is there a way to stop this logging?

I did the test again, this time logging serial on the node. At 4277 and 4280 you see how the messages fail the first time. It is expected since the GW is down. Then I start the GW. There is no attempt to connect on the node's side. After one hour you can see how the node fails to send messages, this time the GW is up. The node does not seem to register during this hour. When I restart the node, the connection to the GW is established as it should. Maybe it is a bug?

0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=3000
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=2
15 TSF:SID:OK,ID=2
17 TSM:FPAR
53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2060 !TSM:FPAR:NO REPLY
2062 TSM:FPAR
2098 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3006 MCO:BGN:STP
3135 MCO:BGN:INIT OK,TSP=0
4277 !MCO:SND:NODE NOT REG
4280 !MCO:SND:NODE NOT REG
3604282 !TSM:FPAR:NO REPLY
3604285 TSM:FPAR
3604322 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
3604328 TSF:MSG:READ,0-0-255,s=255,c=3,t=20,pt=0,l=0,sg=0:
3604334 TSF:MSG:BC
3605475 !MCO:SND:NODE NOT REG
3605477 !MCO:SND:NODE NOT REG
0 MCO:BGN:INIT NODE,CP=RNNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=3000
11 TSM:INIT:TSP OK
13 TSM:INIT:STATID=2
15 TSF:SID:OK,ID=2
17 TSM:FPAR
53 TSF:MSG:SEND,2-2-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
814 TSF:MSG:READ,0-0-2,s=255,c=3,t=8,pt=1,l=1,sg=0:0
819 TSF:MSG:FPAR OK,ID=0,D=1
2060 TSM:FPAR:OK
2061 TSM:ID
2062 TSM:ID:OK
2064 TSM:UPL
2067 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2076 TSF:MSG:READ,0-0-2,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2081 TSF:MSG:PONG RECV,HP=1
2084 TSM:UPL:OK
2085 TSM:READY:ID=2,PAR=0,DIS=1
2091 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2097 TSF:MSG:READ,0-0-2,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2105 TSF:MSG:SEND,2-2-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2113 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2139 TSF:MSG:READ,0-0-2,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2146 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=11,pt=0,l=12,sg=0,ft=0,st=OK:GardenMaster
2156 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:2.0
2164 TSF:MSG:SEND,2-2-0-0,s=1,c=0,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
2171 TSF:MSG:SEND,2-2-0-0,s=2,c=0,t=6,pt=0,l=0,sg=0,ft=0,st=OK:
2178 MCO:REG:REQ
2181 TSF:MSG:SEND,2-2-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2188 TSF:MSG:READ,0-0-2,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2193 MCO:PIM:NODE REG=1
2195 MCO:BGN:STP
2323 MCO:BGN:INIT OK,TSP=1
3467 TSF:MSG:SEND,2-2-0-0,s=1,c=1,t=1,pt=2,l=2,sg=0,ft=0,st=OK:96
3475 TSF:MSG:SEND,2-2-0-0,s=2,c=1,t=0,pt=2,l=2,sg=0,ft=0,st=OK:24

I had a (seemingly) similar issue with my NRF24+LNA+PA board. The solution was stupid simple - just get the node further away from the GW. Or remove antenna if you have one. We usually develop the node connected to the same PC, both GW and the node. It is simply too strong a signal.

thanks, it helped! One downside is that the node seems to abandon connecting attempts completely. It would be great if the connection is established as soon as the GW is up again. Right now it seems I need to restart all the nodes to get them connect to the GW.

Hi,
I have a system since awhile ago. It reads the SHT sensor and controls the solenoid that sets up the water flow. I use the Arduino Mega board. All necessary configs and logs are on the SD card. Basically, it is an autonomous system, that waters my garden. Recently I decided to add the mySensor functionality, mostly because I was curious and had a number of RF24s that were just dusting. I installed OpenHab2 and enjoyed the near real time indication of temp and humidity in the web browser. Everything works reliable, I'm fine with it, but... when I start the system without the serial GW up and running, my Arduino Mega just hangs (actually trying to get in touch with the GW, which I see on Serial). Actually, the MySensors feature for my device is "good to have". I wonder if there is a way to configure the MySesnors library to just set the alarm pin for example, and then continue with the setup()? Just to be more relaxed?
thankful for any tips.
Mikhail