This is old, but I was looking through it today...
According to the datasheets for voltage regulators and the reports of why there are problems with the nRF, the output, or load side capacitors are for keeping the voltage into the nRF as steady as possible. smaller caps are on the front side of the regulators for noise (faster transient voltages than what you'd see on the nRF draw), like those from other electronics, certain lights, radios, etc. and they are ceramic (or other non-polarized) that are great for this filtering in a small package.
The regulators themselves, like the ones in the Arduinos (if you feed RAW pin) take care of the high frequency stuff, but a bigger capacitor is needed for voltage variations, which a ceramic can't do. This is why electrolytics are used. The problem is, electrolytics are much bigger, and so most regulators have you add them to make them work better. But where would you put a component larger than the MCU's chip? And besides, they are getting smaller all the time.
I've never seen anyone say what value cap is overkill, as each person's setup is different. Some don't power their radios from the MCU's rail at all, and some MCUs can be loaded with servos, etc. that would make their draw on transmit different than yours. The bigger the cap (as long as voltage is a tad over what it will see) the better, when it comes to electrolytics. In fact, you can power your MCU with them!
The only way you can know what will work in your unique situation is with an oscilloscope. It is fast enough to capture any dips in voltage on transmit/power-up, and it can show you any noise and ripple on the input. VOMs are just too slow, and not made to measure small changes in a higher voltage at the speeds you will need to see them.
Since I have a pile of 10uf and 100uf, I start with 10uf by default, and if there is any errors that seem like TX dropout, I'll try 100uf, but a cap in this scenario is only a bandaid making up for an under-powered board, IMHO. With battery size/count restrictions, we don't have any choice, but in AC powered systems we should have a PS beefy enough to allow the radio and all peripherals to go nuts without affecting each other.
If you suspect a supply voltage dropout to the nRF, you'll receive fine. So maybe try taking the other peripherals out one by one, maybe measuring overall current draw, and see if the symptom at some point goes away.
And finally, my opinion is that the radio board is the most suspect piece in the chain. Playing musical parts might save you messing with the caps...
@dmonty First question, and I realize it is outside of the scope of your question, why don't you have your message definitions using your IDs (ID_S_MOTION_BACK_GARAGE_1, ID_S_LIGHT_IN, etc...)
MyMessage msg_S_TEMP (0,V_TEMP);
MyMessage msg_S_TIMER (7, V_DIMMER); // Dimmer used to set light countdown timer 1-100%
MyMessage msg_S_MOTION_T (8,V_TRIPPED); // pir motion sensors
MyMessage msg_S_REED_T (11,V_TRIPPED); // door/window sensors
MyMessage msg_S_LIGHTS (14,V_STATUS); // light relay switch
You have 2 motion sensors defined, but only one to report back.
Anyways, looking at your code, I cannot see a reason why the light state would not report back. The only thing that I can see that wouldn't report back would be motion sensor 2.
@ludoarchi said in Problem to compile external mysensor exemple sketches:
i finally arrived to compiled
Would you mind sharing how you solved your problem ? This could help someone having the same problem in the future
As you also suspect I think the gateway is rebooting at a regular interval. In my experience this can be due to two causes. Either due to a bug that was present in an older core arduino firmware version or due to the gateway doesn't get enough power to handle sending of messages. Sending messages requires more power than receiving messages.
How did you program the gateway, ie what software and what version of software did you use? How do you power the gateway? Do you use the recommended capacitor close to the radio?
See this post for info on arduino core versions with the bug:
It was solved in version 1.6.18.
@bluezr1 said in Combining relay and temperature sketch:
Thank you so much rejoe2 for not just giving me the answers but by pushing me to do it myself. You pointed me to where I needed to be and I thank you for that.
Now you got me wanting to learn even more.
Thanks also a lot for your positive feedback - seems there are more and more people interested in quick fixes, but imo, it's by far better to "learn how to fish".
For the next steps, I'd recommend to do some more "combinded sketching", based on the existing build examples - but you'll find that easy once you did the next two of them
One more interesting thing may be working with interrups in non-blocking sketches - please mind the needed type of variable definition to avoid irritating effects
Then you might run into trouble as combining things needs more PINs - then you are forced to have a look on the next level of abstraction: array functions . For a start, you may analyse the multi-button-relay-sketch somwhere around here in the forum.
Then you are at least on my level of knowledge within one week
Looks like we finally have the tools to keep spam out of the forum after upgrade.
This means a little more wait time for new users to get their posts accepted. But I think it's worth it to keep the evil spammers out.
I had the gateway reboot problem since 2.1.1. After initial startup, the gateway would keep rebooting after receiving messages from nodes. After a while it seems to stabilize.
I tried 2.2.0-rc.1 as you suggested and I don't see that problem any more. Thank you!
@Johandelange I didn't look closely enough at the logs, but I think @mfalkvidd may be right. You may need to assign the node IDs manually in your code if you are using MQTT. The 47uf capacitors might be a little high, but may still work fine. On my radio nodes I typically use 4.7uf, but your situation could be different. It does seem to be working for you.
I have installed the mysensors lib from platformio (platformio lib install xx, or something like that)
And my platformio.ini file look like this:
platform = atmelavr
framework = arduino
board = pro8MHzatmega328
I think you could remove the build_flags and the lib_ignore