Data dropouts

Getting Started
1

This weekend I got round to putting the EmonTx / base / EmonTh (x6) equipment that i purchased into service. Had a few challenges along the way, but now have everything up and running, showings as nodes, and feeds setup based on selected inputs. Thumbs up all round.

Almost, but Not quite.

So when i get to look at the logged data in detail, i notice that i’m getting lots of data dropouts (values show as NAN when i view CSV of graphs) on all my nodes. But there seem to be different reasons depending on on the node.

  1. EmonTx.
    What happens here, is that everything seems to log ok for about 20-30 minutes, and then i get a data gap of about 20-30 mins. When i inspect the debug log it appears that the data is still be received & processed (RFM2Pi shows frame data, timestamp, values etc) and appears to be published (MQTT publishing for all values), however no data appears to being logged and there are gaps in the plotted data sets. Whilst writing this, i went to check and another gap had appeared. I then viewed the log; changed log mode to Error, then back to debug - and when I went back to my graphs, data was being logged again. Any ideas on what is happening or why ?

I have 10 feeds setup to track P1, P2, P3, kWh for the same, Vrms, and daily max / min for Vrms and daily min for P1. Scans are setup for every 5sec.

  1. EmonTh
    The dropouts here seem to be being caused by transmission dropouts. Whereas for the EmonTx i get an rssi of ~ -65, those for the EmonTh are closer to -78 to -85. My thinking here is that the issue is with signal strength more than anything else. Given that the max (linear) distance from the base unit to a 'Th is about 6m I am surprised. Certainly for some of the 'Th units, the lack of data corresponds to there being no RMF2Pi data for that node in the log. Any suggestions on how to improve the signal strenght from the 'Th’s ?

I am logging Temp / humidity from each 'Th at an interval of 30 sec.

Matt

2

Do you mean the Feed is 5s? The emonTX only sends at 10s intervals by default unless you have changed it.

Starting point;

Leave the emonhub log level at debug. Run this command

tail -f /var/log/emonhub/emonhub.log | grep " NEW FRAME :"

This will tell you if the data is being received from the TX. You will see the THs as well. Add in the right node ID to the grep to just get the TX data.

3

Can you send a photo of the emonBase setup. How is the antenna positioned?

4

Note also the emonTH by default only transmits every minute, so if you’ve set your feed to have a 5 s timebase, then (assuming PHPFINA) you’ll have 11 NULL values for every received value.

5

Ok. so it looks like i missed a few things about transmission rates. I’d missed that the feed timebase was different to the node transmission time base - for some reason i thought that timebase settings made in Emoncms were pushed out to nodes. .

@borpin - yes, my feed timebase for the emonTx was 5s. I’ve since recreate my feeds with a timebase that matches the node transmission timebase (10 sec emonTx / 60 sec emonTh) and i’m waiting to see if that improves things over time. certainly seems to have mitigated most of my dropout issues so far.

I’ll take a pic of my emonbase setup & post it hopefully later this evening. As a guide, what sort of values should i be expecting for rssi ? ( and i know that’s a bit like asking how long’s a bit of string as each install is different).

6

Anything above about -90 dBm should get through OK. Above -80 dBm you should have no problems.

7

FWIW, I still get a lot of drop-outs at around -80 so I think -90 is optimistic.

8

You might well have a source of co-channel interference that’s giving you a problem.

As I write, I’m testing an emonPi using the RFM69CW’s native message format (as distinct from the classic JeeLib format), and I’ve five points where the signal dipped severely, with signals of -101 dBm, -95 dBm, -102 dBm, -98 dBm & -95 dBm, all of which have a valid checksum.

I don’t think -90 dBm is overly optimistic, it’s still giving me a 5 dB margin over the least bad of those.

9

So, having aligned my feed timebases to the node timebases my data dropouts have largely resolved themselves - i still get 1 or 2 per 20 minutes on my emonTh’s but i think i can live with that. rssi values are between -24 dBm for an emonTh currently above the emonbase to -62dBm for one ~ 7m away outside. I had one node that was continuing to give dropouts (even at -62dBm) but power cycling it seemed to fix the issue.

In my setup i was finding that at rssi approaching -80dBm i was getting lots of dropouts, though that was with the erroneous timebases. I’ll rejig things again, see what happens.

@Robert.Wall your comment about co-channel interference interests me. I have a 4G mast not more than 150m away, could that be leaking into the 433MHz band ? some of my remaining dropouts are occuring on the node with an rssi of -24dBm. If i want to view the CRC is that achieved by setting the [RFM2PI] quiet flag in the config to false ? Short of acquiring / building a spectrum analyser are there any simple ways to see what’s happening in the radio space ?

10

Are your “drop-outs” happening in the radio, or later on?

The way emonCMS works (PHPFINA) is when you create a feed, it stores as metadata the creation time and the interval. The database itself is only value data, stored in records. Time is not stored, but calculated from the record number and the start time.

Therefore, each interval can be thought of as a slot into which the incoming data falls. If the slot expires before the next data arrives (as you had it), then the slot remains empty. If the new data arrives before the slot expires, it gets stored, and if the slot was already filled, the previous value is overwritten and lost. Unfortunately, the source timebase and the database timebase aren’t synchronised, and inside emonHub and emonCMS there are variable processing delays that cause jitter in the arrival time of the data. Many years ago, a decision was taken that the data should be sent faster than the emonCMS timebase, because an overwritten sample every now and again was a lesser evil (and less noticeable) than holes in the data. So even though your emonTx should be set to send a couple of hundred milliseconds faster than the database (I’ve just checked and it isn’t, it’s exactly 10 s) jitter may still mean that if the two timebases drift so that the data arrives just either side of a slot boundary, then you will still have holes in your data.

Indeed it is.

@Bill.Thomson is the expert on all things radio, hopefully he’ll chip in with a comment.

11

Software Defined Radio (SDR) is one way. They don’t cost much, (~25 USD) the software is free,
and the learning curve isn’t too steep. Here’s an example:
https://www.amazon.com/RTL-SDR-Blog-RTL2832U-Software-Defined/dp/B0129EBDS2/ref=sr_1_2?crid=3Q8V3ED5NLHWH&dchild=1&keywords=sdr+rtl&qid=1594422991&sprefix=sdr%2Caps%2C211&sr=8-2

1 Like
12

Great. Thanks for all the explanations & help. much appreciated.

I had found something on the (learn?) site that talked about how the database works when i was trying to work out how to / if i could change the feed interval once setup. Once i understood that the log time was not stored with the data point it made sense that the log interval could not be changed - since it would impact the presentation of all data previous to that point.

I’ve not used many lowpower sensors / loggers until now - most the kit i’ve put together until now has been pc based with TB of storage & lots of processing power. I’m going through a bit of a learning curve getting my head around the impact of working at the other end of the computing spectrum - like unsync’d Tx/Rx

13

I’ve checked again, and it’s now set at 9.95 s.

That I think is largely down to history and operation on batteries. Turning on a receiver for maybe a second or two to check that you’re being polled for data will have a big impact on battery life.

14

I wonder what proportion of emonTx are battery powered? Given its major purpose is usually measuring mains currents, I’d guess fairly low.

I wonder if the firmware could be changed to improve transmission reliability in mains-powered situations? Repeated transmission, error-correction codes and so forth.

15

Historically, quite a few more than now. Now - we still get people who have a meter that’s either remote from the house or it’s too hard to get a mains supply to or get a take-off point fitted, and they can order an emonTx with the battery-holder option and use the old discrete-samples sketch to report current or apparent power using the nominal supply voltage. So the shop should be able to tell you the proportion that are ordered with the battery holder option.

My feeling is most aren’t really drop-outs at all, not in the way that I understand the term, but data that arrives late in emonCMS and thus misses its slot. And that’s a totally different problem.

But don’t forget the emonTH. Whatever you propose for the emonTx must work for, or not interfere with, the emonTH. And battery life for that is of paramount importance, because it was never intended to be powered any other way.

16

Well my meter is remote from the house, but I don’t understand how it could be hard to get a mains supply. The output from the meter is via your own tails to a consumer unit and tails are normally quite short?

Surely that would result in individual missing readings at fairly regular intervals, which is nothing like the symptoms I (and I suppose others) see?

Why does the sketch in the emonTH have to be identical to that in the emonTx? In fact, I don’t think it is, is it?

17

I get the impression that you don’t understand the principles of protection and the requirements of BS 7671 and Building Regulations.

That depends on the other processes that might be happening in the RPi at the same time. Even with only emonCMS running I’ve yet to be able to recognise a pattern.

Who mentioned the SKETCH in the emonTH? This is what I wrote

I can’t see the word “sketch” anywhere in there.

You cannot - or rather, it gets excessively complicated if you do - have one system for the emonTH and another for the emonTx that operates on totally different principles.

18

Well as somebody who built his own house, I probably have a better than avaerage understanding :slight_smile: Anyway, I don’t understand the point of your comment?

Sorry, maybe I’ve misunderstand what you’re saying (perhaps because you weren’t explicit enough to deal with the low bandwidth of Internet-text-based communication?) You think the problem occurs at the receiving end?

Why is there so much attention paid to the radio communication then? Why does only one of my emonTx have a problem - the one that is a long way from the emonBase versus the totally reliable one that is right next to it?

Sorry but I don’t understand your point there. Are we talking about the software in the originating devices or the software in the receiving device? In the second case, as a software developer, I don’t agree.

19

It’s too hard, or perceived to be too hard, because users don’t want the trouble or expense of calling in a registered electrician to break the seals on the meter, put in Henley Blocks and a 1-way consumer unit to feed a socket outlet - and install a second weatherproof box to put it all in if there isn’t room in the original meter box, and all that if they can’t get a protected cable back from the consumer unit to the meter box if it’s on an outside wall, without destroying the interior decoration.

I’ve answered the questions when users say it’s too hard to fit a socket at the meter position. It’s they who decide it’s too hard, not me. Your situation isn’t common (neither is it all that unusual), but I don’t think you considered other peoples’ situations when you wrote what you did.

Yes - as well as in the air, and probably more than in the air in most situations.

Probably because people assume it is the radio channel that is failing.

Most probably it’s the inverse square law coming into play.

As an aside to that, have you checked for channel occupancy not coming from your transmitters? Is there an interfering transmitter that presents a stronger signal at your receiver? How far above the receiver’s noise floor is the wanted signal from the distant emonTx?

I am talking about the whole system, specifically not software nor one device nor one medium. And as a retired Chartered Electrical Engineer who spent most of his working life on projects and systems, I’m darned sure it not all that hard for people who understand what they’re doing. But reality is we have a user base here whose knowledge of the subject and competence in the English language spreads all the way between both extremes in both, and you must bear the whole range of users in mind when deciding what it’s reasonable for them to do and understand.

If you’re a commercial producer with closed and controlled intellectual property, it’s simple to implement a system of the sort I think you have in mind. OEM isn’t like that.

What I have in mind as a solution is to poll the emonPi front end, and all mains-powered emonTx’s, from emonCMS. That would immediately solve the on-air collisions and the missed slots problem. On its own, it still leaves the emonTH’s potentially clashing with the the rest. But, the base should be able to predict when an emonTH is due to transmit, and leave the channel open for it. That solves the problem if you have one emonTH. It still doesn’t prevent on-air clashes when you have more than one emonTH, and you can’t turn on the receiver in the emonTH because it costs too much in battery life (or it’s perceived to cost too much). That’s what I meant with “it gets excessively complicated”.