Radio problems
-
- Yes, I read that in the troubleshooting section http://www.mysensors.org/build/debug
- I read about another guy in thread http://forum.mysensors.org/topic/309/1-4b-radio-transmission-problem-not-present-in-1-3b/16 where he tested 22uF without success but 47 uF worked, so I did the same today. No success but then I restarted the gateway and it started to send/receive. Yes, I am using electrolytic capacitor. Is ceramic better?
- Sure the quality can be questioned sometimes but it seems to work. I have just ordered two additional NRF24L01+PA+LNA just in case :-)
- It's not very good if the reception is a lot different based on radio orientation, especially if NRF24L01+PA+LNA is used (~1000m distance) in this short distance
- I have pretty short cables. Everything mounted on universal PCB with header pin connector and short cables. The cables are maybe not the best; used a stripped cat5e
- Can be something to investigate if no success in other labs
The current setup have not yet been operated for that long time but it looks better:
Messages received in interval (sensor sends every 20 sec so 2 sec tolerance) 0-22 sec 181 91,4% 23-40 sec 16 8,1% 41-100 sec 1 0,5% 101-100000 sec 0 0,0% Total messages 198 100,0%Maybe I should increase the capacitor on gateway to 47uF as well....
@jocke4u said:
Everything mounted on universal PCB with header pin connector and short cables.-What is the universal PCB you mention?
I had a problem where a NRF24L01+PA+LNA would not work on a breadboard setup whereas a basic NRF24 would. I thought it was a dud... then when i built the iBoard Ethernet gateway, i thought i would give it another go and it worked straight away!
Good luck!
-
@jocke4u said:
Everything mounted on universal PCB with header pin connector and short cables.-What is the universal PCB you mention?
I had a problem where a NRF24L01+PA+LNA would not work on a breadboard setup whereas a basic NRF24 would. I thought it was a dud... then when i built the iBoard Ethernet gateway, i thought i would give it another go and it worked straight away!
Good luck!
@gregl said:
-What is the universal PCB you mention?
It is like this http://www.kjell.com/sortiment/el/elektronik/monsterkort/experimentkort/experimentkort-lankar-p89417
Then I have soldered female header socket pins so I can replace Arduino and radio and also have screw terminals for the sensor.
http://www.ebay.co.uk/itm/2x6pin-4x8pin-2x10pin-Single-Row-Header-Socket-Connector-Kit-for-Arduino-DIY-/151372711839?pt=UK_BOI_Industrial_Automation_Control_ET&hash=item233e84479f -
Ok, so a bigger capacitors seemed to have helped. I don't know for sure if ceramic would be better. It would at least be more expensive and harder to find when you want capacitance in uF values. If you can't pick them up locally and cheaply, don't bother.
I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?
-
Ok, so a bigger capacitors seemed to have helped. I don't know for sure if ceramic would be better. It would at least be more expensive and harder to find when you want capacitance in uF values. If you can't pick them up locally and cheaply, don't bother.
I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?
@ServiceXp
How are you powering the sensor? Is there a step-up regulator involved?
See below. The Arduino board is Nano.
@bjornhallberg said:
I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?
I am using a USB charger and have tested some different ones (Samsung's SGS2, iPhone, aftermarket) but I have to admit that those tests have not been very scientific. Now I am doing one change at time and let the device run for a couple of hours.
The statistics I have pulled is from dataMine in Vera3 which logs this variable change and therefore I allow extra 2 sec for OK result. Most of OK tests happens on 20 sec (as the sensor sends every 20 sec) but many is 40 sec which means that the previous send failed. The statistics this morning was worse (over 10% failed) that previously posted so I am not sure whether the large capacitor helped.
I also increased the capacitor on gateway to 47uF
-
@ServiceXp
How are you powering the sensor? Is there a step-up regulator involved?
See below. The Arduino board is Nano.
@bjornhallberg said:
I'd also like to know how you power your sensor node ... if it is some regulator from batteries or some wall wart?
I am using a USB charger and have tested some different ones (Samsung's SGS2, iPhone, aftermarket) but I have to admit that those tests have not been very scientific. Now I am doing one change at time and let the device run for a couple of hours.
The statistics I have pulled is from dataMine in Vera3 which logs this variable change and therefore I allow extra 2 sec for OK result. Most of OK tests happens on 20 sec (as the sensor sends every 20 sec) but many is 40 sec which means that the previous send failed. The statistics this morning was worse (over 10% failed) that previously posted so I am not sure whether the large capacitor helped.
I also increased the capacitor on gateway to 47uF
@jocke4u Say what you will of iphones but those chargers are pretty solid, if they don't work, no wall wart will. It's too bad you can't give the radio another source of 3.3V though. I assume the Nano follows specs and derives its 3.3V output from the FTDI. Just to rule out that the Nano or the FTDI is the the culprit. An external step down module for instance.
I agree that the setup should cover the distance you mention just fine if it were working at peak efficiency, but even so it might be interesting to change the orientation or move the sensor closer just for troubleshooting purposes.
-
Over and over I have read that daisy chaining the radio or giving it power from the Arduino is a source of problems.
I found that out the hard way with a board where I put the radio at the end of a chain.
My next iteration of my board will give it power direct from the source which will hopefully solve the short-range-issue... -
Arduino nano makes its 3,3V from the ft232RL chip. According to its specs it can give 50 ma maximum current.
http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf
NRF24L01+PA+LNA can use up to 115 ma in tx. http://www.electrokit.com/tradlos-nrf24l01-2-4g-modul-med-pa-och-lna.49982.
I think that to use a NRF24L01+PA+LNA on a nano requires a separate LDO 5->3,3V regulator. -
Thank you for all your answers.
I think I have a couple of "AMS1117 5V-3.3V Step Down Module" (or similar) that I can connect to a USB charger. Need to verify though.
http://www.ebay.com/itm/261172232237 says "output: 3.3 V, 800 mA"Some hacks to do :)
-
Hi again,
First I would like to thank you all for the support/ideas etc and I really want to get sensors stable and reliable. Sure this EnergyMeterPulseSensor is not the most critical one and sure the sketch can be improved not to loose KWH readings/accumulations (Watts is a snapshot) when send fails. But with more critical sensors where something else is triggered.
Anyway, since I have problem with the EnergyMeterPulseSensor sending data (not counting pulses) I need to get that working and set the "foundation" for future sensors. Sure I have some other test sensors...Yesterday I took the following actions.
EnergyMeterPulseSensor- Reverted back to NRF24L01+ due to lower power consumtion
- Still using 47 uF capacitor to radio power
- Reverted back to the standard code with gw.begin(incomingMessage); (not using RF24_PA_LOW)
Gateway
- Still using NRF24L01+PA+LNA
- Still using 47 uF capacitor to radio power
- Added AMS1117 5V-3.3V Step Down Module connected to a separate USB charger feeding the radio
- Reverted back to the standard code with gw.begin(); not using RF24_PA_LOW
But unfortunately no success.
So I wonder what you have as hardware reference architecture;
- Do you have a verified and reliable solution?
- What components do you use?
- What working distance do you have between gateway-sensors ?
Regards
Joacim -
Hi again,
First I would like to thank you all for the support/ideas etc and I really want to get sensors stable and reliable. Sure this EnergyMeterPulseSensor is not the most critical one and sure the sketch can be improved not to loose KWH readings/accumulations (Watts is a snapshot) when send fails. But with more critical sensors where something else is triggered.
Anyway, since I have problem with the EnergyMeterPulseSensor sending data (not counting pulses) I need to get that working and set the "foundation" for future sensors. Sure I have some other test sensors...Yesterday I took the following actions.
EnergyMeterPulseSensor- Reverted back to NRF24L01+ due to lower power consumtion
- Still using 47 uF capacitor to radio power
- Reverted back to the standard code with gw.begin(incomingMessage); (not using RF24_PA_LOW)
Gateway
- Still using NRF24L01+PA+LNA
- Still using 47 uF capacitor to radio power
- Added AMS1117 5V-3.3V Step Down Module connected to a separate USB charger feeding the radio
- Reverted back to the standard code with gw.begin(); not using RF24_PA_LOW
But unfortunately no success.
So I wonder what you have as hardware reference architecture;
- Do you have a verified and reliable solution?
- What components do you use?
- What working distance do you have between gateway-sensors ?
Regards
Joacim -
@ServiceXp
I have had 1.3b before but without capacitor etc.
Maybe time to go back to 1.3b3, to see if that works better. -
@jocke4u
At least In my environment, I had zero communication problems with v1.3. Can't say that about 1.4. -
DAMN :( :(
I think dataMine played a prank on me and the statistic is probably not correct (not logging everything). Will hook in my MQTT monitor to extract statistics in a way I control it.
Currently I am running 1.3b3 and will run a test sensor for a while to see how it's works and then eventually go for 1.4 again.
Thanks for your support and I have learnt more about power and capacitors :) -
@ServiceXp said:
Can't say that about 1.4.
Do you mean you're having problems with 1.4 then or did you just not have any experience with it yet?
-
-
@ServiceXp I'm not aware of any major issues with 1.4 at the moment and @hek is about to tag it. If you are really having (radio) issues related to 1.4 we should fix them asap.
At this point I think I found the solution, but have not built up another test bed to make sure the solution worked. The temp conversion problem is persistent,
http://forum.mysensors.org/topic/309/1-4b-radio-transmission-problem-not-present-in-1-3b
RJ_Make
-
At this point I think I found the solution, but have not built up another test bed to make sure the solution worked. The temp conversion problem is persistent,
http://forum.mysensors.org/topic/309/1-4b-radio-transmission-problem-not-present-in-1-3b
@ServiceXp you said in this post:
That was it!!!!! I tried 22uF, was still doggie, so I thought why not move up to 47uF wink and what do you know, that seems to be the winning value. I have some more testing, but looking pretty good so far.
This sounds to me that the issue is solved...
I can imagine that 1.4 requires a bigger cap while 1.3 doesn't. 1.4 uses auto acknowledge which can send burst packets. This could put a bigger load on your power supply.
