nrf24L01+ range and some software issues
-
Hi all,
i'm starting to use MySensors and have some issues.
First i describe what is my setup. The gateway is raspberry pi 3 with nrf24L01+ (pcb antenna) wired based on this: https://www.mysensors.org/build/raspberry. the mysGateway configured with this options:
./configure --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mygateway1 --my-transport=nrf24 --my-rf24-irq-pin=15One test node made of my custom made atmega328p board with internal 8MHz clock, powered with li-ion battery through the 3v/300mA voltage regulator. the board has 3 components, atmega, hc-05 bluetooth module and nrf24L01+ module.
Software on the node: arduino ide 1.6.2 and mysensors library installed through arduino library manager (v2.0.0) and test sketch is BinarySwithSleepSensor. this is configuration:
// Enable debug prints to serial monitor
#define MY_DEBUG// Enable and select radio type attached
#define MY_RADIO_NRF24
#define MY_RF24_CE_PIN 9
#define MY_RF24_CS_PIN 8
#define MY_DEFAULT_TX_LED_PIN A5
#define MY_WITH_LEDS_BLINKING_INVERSE
//#define MY_RADIO_RFM69#define MY_NODE_ID 1
as you can see i had to set node id statically because i don't know why node id is not getting one dynamically, this is my first issue.
the biggest issue (or not) is the radio range. the range is maximum 7 meters, when wall or a person is in the middle it gets even shorter. When i cover the node with my body the range is less that 2 METERS ! So what range should i expect from this setup ? is this normal ? should i buy a nrf module with external antenna or there is something i can do to extend the range ?
I also wonder if the bluetooth module could interfere with nrf so i changed the channel to 100 but the result was the same. i have also arduino uno board and tested range with this board and get the same result. so probably bluetooth is not the issue.lastly i have two software issues, first as You can see i setup MY_DEFAULT_TX_LED_PIN because i have one available led on my board, but this led is behaving very wierd, because it is not blinking when transmitting, instead it just turns on sometimes (for a long time) and sometimes turns of.
the other sw issue is that when i go far from the gateway and errors start occurring after couple of fails the communication stops entirely and does not recover when i get close to the gateway. this is the debug output from the node:
TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:0
TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=ok:1 <-- this two were ok
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=0,st=fail:0 <-- here start fails
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=1,st=fail:1
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=2,st=fail:0
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=3,st=fail:1
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=4,st=fail:0
!TSP:MSG:SEND 1-1-0-0 s=3,c=1,t=16,pt=2,l=2,sg=0,ft=5,st=fail:1
!TSM:UPL FAIL, SNP TSM:FPAR TSP:MSG:SEND 1-1-255-255 s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=bc:!TSP:SEND:TNR <-- from here the communication will not recover
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNR
!TSP:SEND:TNRI will be very grateful for any tips regarding these issues.
-
Very welcome to the MySensors community @rozpruwacz !
Automatic node assignment is handled by the controller (see https://www.mysensors.org/about/network for information about the different components in a MySensors network)
Is a controller connected to the gateway? If so, what does the log file from that controller say?Range is often not more than 10-50m but you should get more than 2m. How is the nrf powered? What caps are connected? Many range issues are power issues in disguise. See
https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help for a flowchart on how to troubleshoot range and power problems. If you are powering the nrf from the Arduino, try powering it separately instead. The voltage regulator on the Arduino is often not able to deliver good quality power to the nrf. Without good quality power, all sorts of strange things happen.
-
Hi @mfalkvidd, thanks for quick response.
the info in the link you provided is not clear to me. on the pi side i launch the mysGeteway as a mqtt client that connects to mosquitto server, and have also openHab 1.8.3 with mqtt binding, all this works without a problem. so i don't realy know which of these components is a controller and should assign the node ids.
regarding the powering the nrf, on the pi side the nrf module is connected with about 10cm cables directly to the pi header (3.3v pin #17 for the power). and there is also 10uF ceramic smd capacitor soldered directly between vcc and gnd pins on the nrf module pcb. On the atmega side the nrf module is almost directly soldered into the atmega board with maybe 1.5cm wires for the gnd and vcc (and also the 10uF ceramic smd capacitor between gnd and vcc pin on the nrf module pcb).
So on the atmega side the power shouldn't be any issue, for the pi I will try to power the nrf module with separate 3.3v regulator to check if this will change anything.
From the nrf datasheet the power consumption should be max 13.5mA so pi and atmega should easily deliver this amount of power, so maybe 10uF capacitor is not enough for the filtering ? As a side note the nrf modules are getting quite hot, considering power consumption of only 13.5 mA this is very wierd ...
-
@rozpruwacz as mentioned on the list linked from the page I mentioned, OpenHab is a controller.
However, I think I read somewhere that it is not possible to hand out node IDs through mqtt, so you'll need to either use a different type of gateway or continue assigning node IDs manually. Either way is fine.
As for the power, the capacitor on the nrf module has proven, over and over again, to be insufficient. That is why the radio connection instructions and the troubleshooting instructions mention adding an extra capacitor. It is not about the amount of power, it is about the stability of the power. You are of course free to ignore the collective experience of the community, but why are you asking in the forum if you don't want to use the answers?
The heat sounds strange. I haven't seen that in any of my modules. Maybe the vendor sent defect modules?
-
@mfalkvidd said:
@rozpruwacz as mentioned on the list linked from the page I mentioned, OpenHab is a controller.
However, I think I read somewhere that it is not possible to hand out node IDs through mqtt, so you'll need to either use a different type of gateway or continue assigning node IDs manually. Either way is fine.
ok, understand, i can assign node id's staticaly, no problem.
As for the power, the capacitor on the nrf module has proven, over and over again, to be insufficient. That is why the radio connection instructions and the troubleshooting instructions mention adding an extra capacitor. It is not about the amount of power, it is about the
stability of the power.so the additional 10uF should be sufficient, so what else could degrade the range ?
btw. a did this trick (https://www.youtube.com/watch?v=NpMnauHeR7Y) and it helped a lot, but it gets a little big
The heat sounds strange. I haven't seen that in any of my modules. Maybe the vendor sent defect modules?
i will try to measure the current.and what about the issue with the communication not recovering from the blackout, e.g. if the mysGateway goes down the node would never recover unless i will recycle the power.
-
@rozpruwacz not sure why it is not recovering. It should, but as your log shows it doesn't
. Perhaps the trobleshooting recommendations in https://forum.mysensors.org/topic/5174/solved-non-healing-tsm-msg-len-error-hours-into-run/4 can help - enable the sanity check and see if the debug output says anything useful.
-
i found the solution for not connection not recovering from the blackout (https://forum.mysensors.org/topic/4593/battery-sensor-and-re-connecting-to-gateway/2)
the sketch i'm using is "sleeping" between button presses and the transport layer have no time to reestablish connection. adding the wait statement to the sketch solves the problem.
-
@rozpruwacz great find!
-
with wierd leds blinking is the same problem
the sleeping causes them to sometimes turn on but not turn of and sometimes turn of but not turn on, without sleeping they work ok
-
i measured the current drown by the nrf module connected to the pi, it is above 100mA ! no wonder it gets so hot ... i ordered new ones and one with external antenna.
-
@rozpruwacz said:
with wierd leds blinking is the same problem
the sleeping causes them to sometimes turn on but not turn of and sometimes turn of but not turn on, without sleeping they work ok The blinking leds feature was originally created for gateways, which need to have power all the time to receive messages. The feature was recently extended to make it possible to enable on repeaters, which also need to have power all the time to receive messages.
Sleeping nodes generally want to minimize power consumption, so blinking leds is generally not something a sleeping node wants to do. Using remote debug might be better if troubleshooting is the goal.
So I am not surprised that the feature doesn't work for sleeping nodes, it was not designed with that in mind. But if you (or someone else) wants it, it should be possible to adjust the code to handle sleeping nodes as well.
-
yeah, now it makes perfect sense. i saw how to configure leds in "Advanced Gateway Options" section and somehow assumed that this is the same for nodes ...
so now my problems are solved accept for the radio range which i hope will be solved when i get my new fresh radios
thank you very much for helping me !
-
great news
with the new nrf modules there is no more range problem for the gatewane i use nrf24l01+pa+lna and for the sensor node nrf24l01+. now from every place in my small flat the connection is perfect
