Then I thought about the emonTx, which do have an RSSI field, and I realized I don’t understand what that is. AIUI the emonTx are transmit-only and the emonBase is receive-only, so what is the emonTx’s RSSI field actually measuring?
Also, it seems the RFM69CW has adjustable output power. I can see a possible desire to minimise power on a battery-operated instance. What level is the output power set to on the emonTx and is it adjustable?
I don’t think so. I don’t have an emonPi running at the moment (so no screenshot), but the received RSSI is the number in brackets at the end of the list of data bytes, or at the bottom of the Inputs page - unless your emonPi is so old that it has a RFM12B, not the RFM69CW (pictures for identification in ‘Learn’, but I don’t think any emonPi’s were ever made with a '12B).
So yes, that is totally wrong. The RSSI field ISN’T something the emonTx is measuring, it’s a field added by the emonPi that gives the strength of the received signal from the emonTx.
It’s +7 dBm by default. JeeLib fixes it, and doesn’t allow you to change it. That doesn’t mean you can’t, but there are caveats: it’s possible to cook and kill your RFM69CW if you turn the power up without an effective aerial to radiate the power away (ask Dan Bates - he found out the hard way), and unless you’re using a 5 V d.c. power supply, then the emonTx might crash if it tries to transmit when the mains voltage is very low - that’s because the original a.c. supply was designed only to support the RFM12B which needs far less peak current to transmit.
If you want to try a higher power, take JeeLib out of the sketch and substitute the rfm.ino file out of the 3-phase sketch, see EmonTx stops sending data - no led activity until reboot - #18 by Robert.Wall
If you have several transmitters all on the same channel, that file doesn’t check for ‘channel busy’ before transmitting, so you might have more collisions. If that seems to be a problem, a version that we’re testing appears to solve that.
RFPWR is what you change. 0x99 is the default (+7 dBm), maximum is 0x9F (+13 dBm).
I guess that means it doesn’t exist, rather than “0 dBm” = the same as the reference level.
The emonPi doesn’t receive itself by radio.
I don’t understand what you’re saying there - is the emonBase forwarding the data via Ethernet to the emonPi? if so, it won’t have a received signal strength because it isn’t being received by the emonPi’s radio front end. But if it’s within range and received by both, then both should show a RSSI.
ARCHIVE: : Introducing emonTx V3.4 says " The emonTx V3.4 uses an edge SMA connector with an SMA antenna included as standard. We have standardised on 433Mhz (see forum post). The emonTx V3.4 supports and will eventually ship with the new RFM69CW module, this module is backwards compatible with RFM12B. However due to sourcing and lead time issues we have had to use RFM12B on the first batch of 500 units of emonTx V3.4 (now in the shop). When the RFM69CW is used a RSSI (Received Signal Strength Indicator) will appear in emoncms giving indication of signal strength."
That seems to imply it is the RFM69CW shipped with the emonTx that is relevant for the RSSI value???
Thanks for the advice about increasing the output power. It all seems a bit scary to me. I view firmware similarly as hardware - I’m not really qualified to mess with it. (I’m still trying to recover from blowing up a pi and apparently a video adapter by trying to attach a UPS to it )
I can see how you’d get that impression. It’s not worded as well as it might be, and as it’s a blog, I’d never seen that before you quoted it. It is correct - but only when used as a receiver. RSSI wouldn’t be available in the emonPi if the emon part was equipped with an RFM12B. The RFM12B had a much more basic method - the software could tell if the signal was above or below an adjustable level - but signal strength did come out on a pin as an analogue voltage, if my memory serves. MartinR used that to make a modified emonGLCD with signal strength indication. The emonTx can receive, it’s just that we don’t use that facility. If you changed the whole of your system over to the LowPowerLabs library, the “transmitter” does receive messages from the “receiver” in order to agree on a minimum power level to operate at.
Fair enough - but there are things you can do to improve the link without touching the power level. Search here for “ground plane” or read up about it, for one easy & cheap way.
In the light of Dave’s confusion, is it possible to edit that information?
Thanks for the advice about the firmware. I may get up the courage one day
Yes, we had a discussion about those kind of topics as a result of which I fitted a dipole to the emonTx which helped a bit but not enough apparently. And I uncoiled the wire on the emonbase from inside the case to stand it up. But I still see a lot of dropouts.
I’d forgotten it was you asking about ground planes. Are there large metal objects in the vicinity will reflect the signal? Because if your aerial happens to be where the signal can arrive via two paths and the two happen to be out of phase so that they cancel, you’ve got no signal.
If your signal strength is good (-70 dBm or higher - i.e. less negative) then you might have a local source of interference that’s blocking the wanted signal from your emonTx.
The receiver (i.e. emonBase) is next to my router, phone, and main wiring panels and CUs (plastic rather than the newfangled metal types) etc. So there are a lot of wires. The nearest large metal objects are a washing machine underneath and a thermal store about a metre away.
Signal strength varies. Last 4 days it was around the -70 dBm mark. Before that and currently it’s -74 to -80 dBm and there are significantly more dropouts. Some last half-an-hour.
The pi I blew up was the one I was setting up to monitor interference with
In addition to that - and actually, much more common - if the two signals are out of phase, but not
to the point where they cancel each other, there’ll still be problems. The receiver will see both signals,
but won’t be able to tell which one is the genuine article, effectively mangling the packet such that it’s
not processable by the signal electronics.