I'm trying to set up a basic MySensors network. I have a NodeMCU hooked up to a NRF24L01+ with attena. It looks like it boots up normally. I also have an Arduino Nano hooked up to another NRF24 of the same type, but it has !TSM:FPAR:NO REPLY messages in the Serial console.
79 MCO:BGN:INIT GW,CP=RNNGE---,FQ=80,REL=255,VER=2.3.2 136 TSF:LRT:OK 152 TSM:INIT 165 TSF:WUR:MS=0 189 TSM:INIT:TSP OK scandone state: 0 -> 2 (b0) state: 2 -> 3 (0) state: 3 -> 5 (10) add 0 aid 10 cnt connected with REDACTED, channel 10 dhcp client start... ip:192.168.178.84,mask:255.255.255.0,gw:192.168.178.1 426 TSM:INIT:GW MODE 449 TSM:READY:ID=0,PAR=0,DIS=0 481 MCO:REG:NOT NEEDED 1580 GWT:TIN:CONNECTING... 2608 GWT:TIN:CONNECTING... scandone 3636 GWT:TIN:CONNECTING... 3665 GWT:TIN:IP: 192.168.178.84 3699 MCO:BGN:STP 3717 MCO:BGN:INIT OK,TSP=1 3745 TSM:READY:NWD REQ 3772 ?TSF:MSG:SEND,0-0-255-255,s=255,c=3,t=20,pt=0,l=0,sg=0,ft=0,st=OK: pm open,type:2 0
It does not output any more messages after that.
__ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.2 16 MCO:BGN:INIT NODE,CP=RNNNA---,FQ=16,REL=255,VER=2.3.2 26 TSM:INIT 28 TSF:WUR:MS=0 34 TSM:INIT:TSP OK 36 TSM:INIT:STATID=10 38 TSF:SID:OK,ID=10 39 TSM:FPAR 1855 ?TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 3863 !TSM:FPAR:NO REPLY 3865 TSM:FPAR 5681 ?TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 7688 !TSM:FPAR:NO REPLY 7690 TSM:FPAR 9505 ?TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 11512 !TSM:FPAR:NO REPLY 11514 TSM:FPAR 13330 ?TSF:MSG:SEND,10-10-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 15338 !TSM:FPAR:FAIL 15339 TSM:FAIL:CNT=1 15341 TSM:FAIL:DIS 15343 TSF:TDI:TSL
This continues for a bit but it's just the same messages again.
A few notes:
- Both radios have 100uF capacitors
- I'm 99% they aren't fakes, they don't have the blob thingies
- I have not set up a controller yet, but the node has a static ID defined
- The gateway's NRF24 is at about 3.1v, the node's is at exactly 3.3v
- I have tried setting both of them to RF24_PA_MIN, this did not make a difference
- I have tried switching out the NodeMCU, but this did not make a difference
Any suggestions? Is this a hardware issue? I salvaged both NRF's from a previous project, and I couldn't get them to work then either. They might just not work.
mhkid last edited by
Is the NodeMCU an ESP8266 or an ESP32? I've had trouble with the ESP32 and getting the communication to work but have no idea why. I did what you did and swapped out the NRF24's and it didn't help. Then I swapped out the microcontrollers and that's when I swapped the ESP32 (gateway in my case) with an ESP8266 and everything worked fine.
Sometimes what I'll do to troubleshoot is replace the gateway with an UNO just to eliminate issues and go with a known working piece of hardware. Sounds like you may have done some of that already. You could try moving them a little farther apart and see if that works.
It's a ESP8266. How far apart should I move them? I've tried up to 10m, which I think should be more than enough. I'll order new NRF's, if that doesn't fix it I guess I will just have some extras.
TRS-80 last edited by TRS-80
I have had weird things happen that were solved simply by pressing the reset button on the microcontroller. Maybe the radio and/or uC get powered in wrong order, I don't really know. I only discovered this on an otherwise already known working setup that all of a sudden couldn't find the parent for some weird reason. And you seem to already have done all the other basic trobleshooting stuff.
If you are unsure about hardware, before throwing it away, perhaps run some of your units through ping pong sketch before even loading MySensors. I made a detailed post about evidence based testing here. It can eliminate some doubt, at least it did for me.
EDIT: As an alternative / in addition to "moving them apart" you can also set the
LOWif you are testing close to the gateway. I have done this and sometimes it actually improves communication. Remember it is set to
HIGHby default. Do so by putting following near top of your sketch:
#define MY_RF24_PA_LEVEL RF24_PA_LOW
DuPont wires can also be bad, or have bad connections...
If you are using breadboard and/or multiple power supplies, make sure all grounds are tied together...
I think that covers most of basic stuff?
BearWithBeard last edited by
I also have an Arduino Nano hooked up to another NRF24 of the same type, but it has !TSM:FPAR:NO REPLY messages in the Serial console
Are you powering the NRF24 PA-LNA module directly from the 3V3 pin of the Nano? The Nano doesn't have a dedicated voltage regulator for 3.3V on board. 3.3V are provided through an LDO integrated into the USB-UART controller. If it's a genuine FTDI, it can provide up to 50 mA, but if your Nano is a Chinese clone, it's more likely that they are using a CH340 or something like that. This chip may be able to deliver 25 mA or so and might not be able to regulate larger loads properly, which could cause a lot of noise on the 3.3V line - something that NRF24 transceivers don't like at all. Besides that, those black PA-LNA modules may draw up to 150 mA during transmission, which would be far out of spec on higher PA levels and may permanently damage the USB-UART controller.
That could be the or a reason why your Nano node doesn't seem to be able to reach the GW. Try hooking up a regulated 3.3V power source to the radio in this case.
The Nano doesn't have a dedicated voltage regulator for 3.3V on board. 3.3V are provided through an LDO integrated into the USB-UART controller.
I had to do a double take when I read this. Then I had to pull one of mine out, because I was sure I thought I saw a regulator on there. And sure enough, I have an AMS1117 right on the bottom side of the board, along with the CH340. And mine are cheap Chinese clones. I can take a pic if you like? So, does this mean that:
Mine are different from the norm? Or,
The Bear is perhaps mistaken?
I am often impressed by your knowledge and attention to detail, @BearWithBeard, so I'm not sure which case would surprise me more.
BearWithBeard last edited by
@TRS-80 Well, thanks for the kind words - right or wrongly.
No, you're not wrong here. There is a voltage regulator - but you'll notice "5.0" written on it. The Nano (schematics of rev 3.2) will use it to get regulated 5V if you power it with 6 - 12V directly from the VIN pin.
Aha! You are right! I never looked closely at the regulator before, but sure enough it says "5.0" on it!
I learned something today...
OK, I had always heard stuff along these lines (in vague terms) but never explained so explicitly and clearly:
The Nano doesn't have a dedicated voltage regulator for 3.3V on board. 3.3V are provided through an LDO integrated into the USB-UART controller. If it's a genuine FTDI, it can provide up to 50 mA, but if your Nano is a Chinese clone, it's more likely that they are using a CH340 or something like that. This chip may be able to deliver 25 mA or so and might not be able to regulate larger loads properly, which could cause a lot of noise on the 3.3V line - something that NRF24 transceivers don't like at all.
So, sorry for going offtopic a bit, but I couldn't help but wonder how much "regular" nRF24L01+ draw (especially since I sometimes power them directly from 3.3V on Nano). I guess I could look on the datasheet... Maximum I see there in section 5.1 Power Consumption (p. 14) is 13.5 mA (typical) for receiving at 2 Mbpsl however for the 250kbps that (I think?) MySensors is set at, it says 12.6 mA (typical). Of course clones could differ, but I still think I should be well within acceptable range, especially with supply caps that I always add to the radio... Anyway, something to be aware of for sure...
MisterMel last edited by MisterMel
@BearWithBeard Yep, the Arduino is a cheap Chinese clone. It definitely uses a CH340. I just ordered some 3.3v regulators as well. Both the new NRF's and the regulators should be arriving tomorrow.
The new NRF's are the version without external antenna, so I guess they would probably also work without the regulator, but I'm going to try if I can get the ones with external antenna working with the regulator.
I also ordered another Arduino Nano (still a clone though), so I'll try that if the regulator doesn't work.
The new NRF's are the version without external antenna, so I guess they would probably also work without the regulator
This is how I do my gateway with a Nano, and it has been flawless. Do note however that I am using a combination of capacitors which testing revealed were optimal for my setup. Prior to doing that, I did not have nearly as much success / reliability (as can be read in the thread)!
@TRS-80 if you wonder how much your nrf consumes, why don't you just measure it? https://forum.mysensors.org/topic/9178/nrf24doctor
TRS-80 last edited by TRS-80
Stop adding on to my list!
Nice piece of kit! I am sure I will build one sooner or later. It's like a much more portable, easier to use, and more feature filled implementation of my evidence based radio testing method. I even think I have all parts needed on hand (or on the way) already, except for the PCB.
Speaking of which, I saw some talk in that thread about PCB design over at GitHub, hopefully that is still available, as I did not see any page on Hardware section about nRF24doctor...?
It works now! I'm now using the NRF's without external antenna and I've added a AMS1117 3.3v regulator module to the node. The ones with external antenna still don't work, but the it will probably be fine without them.
The ones with external antenna still don't work, but the it will probably be fine without them
I run all "regular" nRF24 radios, including the gateway, and it works well enough for me. My place is pretty small, but there are masonry walls and walls with metal studs that seem to cut down on range. I found putting the nodes up high on my walls helps a lot.
Glad to hear you got it working.
One more thing I wanted to re-iterate, for people coming along searching this topic later. I mentioned before, but keep experiencing this as I am working on some nodes the last couple days. Seems to me that fairly often actually, right after (re-)flashing and node boot up for first time on new software, I often get a lot of FPAR errors, which the node does not seem to come out of on it's own. But one or two resets (via on-board button) and then it starts working. Not sure what that is all about, or if others have experienced same, but I thought I would mention it again before people go nuts with other troubleshooting steps, and pulling their hair out.