Read this first - it could SAVE YOU A LOT OF TIME
-
@sundberg84: Tks for answering! :)
@pellusfromtellus thanks for noticing. I've updated the connect radio page, hopefully it is a bit clearer now.
@sundberg84 nice profile picture. Great to get a face for you :)
-
I just checked my sensors and I'm using 470µF.
Shows to go you really should check what you grab from a bag of capacitors ;) -
@pellusfromtellus - its a typo... mostly I use a 4.7uF but to be honest im not sure which is the "recommended".
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... :) -
Now that encryption is becoming more common, perhaps there can be some tips/flowchart on how to troubleshoot that?
For example, I just discovered that clearing the eeprom (there is a special sketch for that in the examples folder) helps remove old encryption settings.
-
Now that encryption is becoming more common, perhaps there can be some tips/flowchart on how to troubleshoot that?
For example, I just discovered that clearing the eeprom (there is a special sketch for that in the examples folder) helps remove old encryption settings.
-
Like many, I struggled for literally years getting MySensors to work. Recently I tried (yet again) and this time around I began by focussing on an evidence based radio testing method, which for me was the key to success. I humbly cross-link it from here in the hopes that it is helpful to others, because it makes me sad reading how many people have given up trying to get MySensors to work.
Good luck!
And by all means please do not suffer, struggling along in silence. Make a post and try and get some help before frustration mounts too high, and you give up (as I did, many times).
-
Troubleshoot the debug output
(courtesy of @martinhjelmare from this thread)
From the source code in the dev branch: link
s = sensor id
c = message type 0-4: presentation, set, req, internal or stream. See link
t = value type: S_VALUE during presentation or V_VALUE during set/req
pt = payload type: string, byte int, etc. See link
l = message length
sg = signed or unsigned message: 0 or 1 for false or true0;0;3;0;9 means node 0 , sensor 0, internal message (3), not an ack message (0), log message (9). This means that it's the gateway that prints this info as a log after already having received the message from a node.
At the end you have the payload: 27
Similarly for a sent message: link
@mfalkvidd what if we replace "s" with "sensorId" and so one?
-
@mfalkvidd what if we replace "s" with "sensorId" and so one?