433 MHz
So your wire whip is ~ 83 mm? That is the length for 868 MHz. I’d suggest you replace it - and while you’re at it, just check that you have the correct RFM69 - check the appearance here.
Never mind. Red herring. It is 165 mm when it’s actually stretched out.
A ground plane will work at either end, or both ends. If one Tx is weak, that’s the candidate for a ground plane.
That whip is one quarter wavelength, so moving something by that distance represents a long way, if there’s some cancellation going on due to reflections.
Coiling the antenna is a compromise at best. Coiled up, the antenna is far from the desired
quarter-wavelength. The placement of the ground plane isn’t overly critical, but its dimensions must be
a quarter-wavelength or more. Shape isn’t critical, circular or square perform the same. It does need to
be located quite close to the whip.
Did you view the video clip in the thread?
Using a ground plane at the transmitter is more difficult, since it’s wall-mounted.
I looked at the video and believe I understand what it’s showing. I suspect in my case the isolated ‘ground’ plane (i.e. sheet of foil) is also coupling to my nearby Wi-Fi router and increasing the noise seen by the emonBase. But perhaps it’s just the precise positioning of the antenna that matters. Difficult to tell.
I think a better solution might be to connect a remote antenna instead of a piece of wire straight on the receiver. That would give me better control over position and perhaps an antenna with more gain.
An RSSI of -33 is good. Very good, actually. That being the case, you should be good to go, as is.
The receiver sensitivity extends well past an RSSI of -90. At -33, you’re in good shape.
-33 is the value for my first emonTx, which is about a metre from the emonBase. My problem is with my second emonTx, which is 40 m or so away, and that’s what the discussion has been about.
I’m getting a lot of dropouts (unusably many) at around -80 indicated. Though it seems to be mostly working at around that level at the moment.
But I don’t want a system that depends on exactly where my emonBase happens to sit or exactly which way a piece of wire is bent. I’d like to achieve a system that is reliable and that I believe would be reliable if I took it away and then put it back in roughly the same places again.
In that case, forget the ground plane at the emonBase, and look to having a ground plane, or if that’s not possible, a dipole (I think that was mentioned in the thread about ground planes) at the problematical transmitter.
The dipoles just arrived and I fitted one to the remote emonTx. The RSSI has gone from -71 ~ -75 to -62 ~ -64 so that’s a very good result. I probably won’t fit a dipole to the emonBase at present, since that involves soldering and hopefully the signal is now reliable.
I raised a bug about the data errors incorrect data recorded in feeds · Issue #1137 · emoncms/emoncms · GitHub but there’s no response yet.
-64 to -62 is a good solid RSSI, given the radio has an MDS level well under -100 dBm. If signal strength was the cause of your problem, you should see a significant improvement in operation.
(MDS = Minimum Discernable Signal)
Given that the received signal from the other device is quite high, you probably should not fit a dipole to the emonBase anyway. (@Bill.Thomson ?)
He’s got plenty of margin, so addng a dipole to both ends of the link should be OK.
As I understand it, signal levels as high as -30 0 dBm present no issues.
from post No.17.
I wouldn’t necessarily expect a 10 dB improvement, but if so, isn’t it in danger of overloading the front end?
The spec for max signal level is 0 dBm if memory serves, but I’ll look it up to be certain.
Max input is indeed 0 dBm.
MDS is -115 dBm.
My system is now working RF-wise, so thanks for everybody who helped. I now realize that putting my questions about data spikes into the same thread was a bad idea (really, I knew it was a bad idea, but I hoped for a quick resolution). Is it possible to split the bits about spikes in the data to another thread?
I believe the problem occurs as a result of NaN data, but I haven’t got to the bottom of it yet. (and apologies but the lack of comments in the code or overview documentation is one of the main things in slowing me down diagnosing the problem, IMHO)
Good Idea. I moved them to a new thread.
The link is just above post 19 in this thread.
Thanks, Bill.