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...
Hi @daniele-frigo, welcome to the MySensors community!
The best way to debug is to get the debug log from the node. Either by connecting a computer and keeping it on until the node acts up, or by using a standalone logger like this https://www.openhardware.io/view/532/The-Logger-Machine-Short-and-long-term-serial-logging
The problem is that the boards.txt is declaring the use of the tool avrdude, in the sketchbook the IDE is not able to find the avrdude, so the error. That's what you get when you mix a Arduino noob with a linux noob
As already meintioned by @kimot and @gohan, the rfm69hcw comes in different versions. From the datasheet, there are four versions:
Each versions support a frequency range. This is also shown in the datasheet:
@Qwe-Qwe you need to buy a version that matches your frequency, and cut/buy an antenna that also matches the frequency.
I fixed it by adding:
#define MY_NODE_ID 11
#define MY_PARENT_NODE_ID 0
I had been noticing that the gateway was overwriting old nodes that hadn't connected for a while. Oddly, I can see the following ID's in Domoticz:
@sushukka i agree with your point. I just wanted to bring light to some aspects that might be out of your view. Before you make any choice about security you better know what the choices are Last advice, google info about your wifi router, if it has any known vulnerabilities that would allow to hack it from outside without much effort.
Not sure if it is the same problem, but looking similar ?
I upgrade my MQTT gateway to 2.2.0 (from 2.1.0), all working ok with my 2.1.0 sensor nodes
I upgrade the first sensor node to 2.2.0, and I get TSM:INIT:TSP FAIL messages on the node.
I downgrade the first sensor node back to 2.1.0 and it works again like a charm ...
Did I miss something ? Is this a bug in 2.2.0 ? Do I need to change config ?
@ben999 Sorry for the delay. Work has been crazy lately. I see there are plenty of answers above and I echo them. I try not to upload with two power sources connected. If everything is 5v you are probably safe but I see you're using batteries and I'd not risk it just to be safe. I have used two power sources in the past but I have since changed my ways. I can't remember what stopped me but I believe I was getting strange results. I don't think I ever fried any hardware but why risk it...?
If you are still having this issue have you tried with another Pro Mini and different code? Is anything coming out of the serial monitor or is it just blank?
The RFM69 is more power hungry than nrf24, so you also need the decoupling capacitor, especially if using the high power rfm69 version.
To be sure, you're using high power version on your node, right? as you're using MY_IS_RFM69HW
RFM69 is not 5v tolerant (mentioned in the build howto). It's not only about rfm69 vcc, but also about its SPI signals pins, irq etc. when using arduino uno, the atmel mcu is 5v powered (the 3v regulator is external). so the atmel is 5v, and send signals to rfm69 with 5v voltage. not good. max voltage recommended by datasheet is 3.9v. so you could fry it or get malfunction.
could you retry with a 3v arduino? if it's still not working then, try with a fresh radio module and check connection.