EmonPi losing connection to EmonTX (again)

You won’t have any gain. For you, the question is, is your cable loss is less than the loss through the wall? It should be, in which case you should see an improvement.

This Don't Be Intimidated By Low-Power RF System Design | Electronic Design says “If obstructions are involved, some corrective figures must be added in. Average loss figures are 3 dB for walls, 2 dB for windows, and 10 dB for exterior structure walls.” which is pretty wide range. A decent RF cable should have losses around 0.5 dB/m or better.

You didn’t mention what type of feedline you’re using, so I’ll go with a worst case calculation based on RG174 which has 17.3 dB loss per hundred feet at 400 MHz.

At 434 MHz and a length of 1 meter, the the feedline loss is ~0.66 dB.
Bear in mind the loss reduces transmitted and received signals.

If your feedline extension enables you to effectively eliminate one wall from the signal path, depending on the construction of said wall, you might wind up with a net increase in signal strength from what you have now. The chances for a net gain increase with each wall and/or RF obstruction you eliminate from the signal path.

How is your emonTx powered? The mention of a non-existent Node 0 made me wonder whether the power to that is marginal, and what is happening is the power supply is falling over - if it’s powered by the ac adapter and the supply voltage is low, that’s a possibility.

0.5 dB/m is actually quite lossy. i.e. not much better than RG174 which is some of the lossiest coaxial RF cable available. An example of another lossy cable type is RG58. OK at HF (3-30 MHz), it’s loss of 0.429 dB/m at 434 MHz makes it unsuitable for more than a short run, at that frequency.

Better quality cable, e.g. RG6A - typically used in satellite TV receiver installations - has a loss of ~0.1 dB/m at 434 MHz.

Ref: Coax Calculator

I too chose a bad-ish cable, hence the ‘or better’. And not forgetting the additional 2 half connectors.

But 0.5 dB looks as if it is better than a (presumably single) brick wall, and we don’t know whether the path is straight through or skiffing through at a shallow angle.

Agreed. Especially if multiple walls are in the signal path. Eliminating one of them surely couldn’t hurt. :wink:

Thanks for all the helpful comments. The cable is RG174 and the wall is a block and brick cavity: looks like it is worth a try, so that is the weekend booked!

The EmonTX is powered by the AC adaptor and I have not been writing the VRMS to a feed (I am now). VRMS is around 238-242V.

I recall that the VRMS on the EmonPi changed after a firmware upgrade and the change resulted in a much better agreement between the indicated solar invertor power and that produced by EmonCMS. It may be that the EmonTX VRMS firmware needs a change to be consistent: at present the VRMS on the supply (EmonTX) is 5v higher than on the EmonPi which is way higher than the minimal voltage drop expected on the cable between the two (16mm armoured, about 30w on the cable judging by EmonCMS)

Ouch! I think the extended aerial is definitely worth a try.

Another update following getting the antenna through the wall. The RSSI range reported at the emonPi in the garage dropped from 75-84 to 65-76, so the signal strength has improved (signal strength is better overnight and in clear atmospheric conditions). Connection stability is better, with drop outs once a day on average, rather than several times a day. Next step is to take the EmonPi apart and check for bad connections: I saw an RSSI increase just by fiddling with the antenna before moving it.

After a reboot the false Node 0 disappeared, but a Node 4 has appeared. Do I take it that the EmonPi receiver is getting a corrupted set of bytes that make it think these nodes are present?

Hi, just curious.
What is the distance between the two devices?

About 10m as the crow flies.

I should have reported back that updating to the version of firmware available in June 2017 and low-write 9.8.7 EmonCMS resulted in no further drops of signal. Emonhub log shows a lot of discarded packets, but enough are getting through to produce a good enough set of feeds. There is still usually a phantom node, presumably as some of the deformed packets are apparently equivalent to what would be expected from another node. However, as everything is working, I have left well alone.