Update to continuous monitoring, random "-4" power readings?

[spock64 (Jason)]

Hi,

I updated my emonpi to continuous monitoring today, making the required changes to the emonhub config and blowing the firmware.

All seems to be OK until I look in the emonhub log, for example:

2024-06-06 12:38:22,912 DEBUG RFM2Pi 63 NEW FRAME : OK 5 62 0 0 0 222 1 0 0 222 1 55 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 65 0 0 0 0 0 0 0 (-0)
2024-06-06 12:38:22,916 DEBUG RFM2Pi 63 Timestamp : 1717673902.911705
2024-06-06 12:38:22,917 DEBUG RFM2Pi 63 From Node : 5
2024-06-06 12:38:22,918 DEBUG RFM2Pi 63 Values : [62, 478, 0, 478, 0.55, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 0, 0.0]

Then, ten seconds later I see:

2024-06-06 12:38:32,776 DEBUG RFM2Pi 64 NEW FRAME : OK 5 63 0 0 0 252 255 0 0 252 255 56 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 65 0 0 0 0 0 0 0 (-0)
2024-06-06 12:38:32,781 DEBUG RFM2Pi 64 Timestamp : 1717673912.776247
2024-06-06 12:38:32,782 DEBUG RFM2Pi 64 From Node : 5
2024-06-06 12:38:32,782 DEBUG RFM2Pi 64 Values : [63, -4, 0, -4, 0.56, 0, 0, 0, 0, 0, 0, 0, 0, 65, 0, 0, 0.0]

As you can see, I and getting a ‘-4’ reading.

After this message, all continues as normal until I see another ‘-4’ reading.

Could anyone give me some tips please?

[Robert.Wall]

Welcome, Jason, to the OEM forum.

What’s happened to your voltage - why only 0.55 – 0.56 V? Have you forgotten your a.c. adapter, or has it got unplugged or failed?

[spock64 (Jason)]

Hi Robert,

It’s odd isn’t it?

My setup is simple enough an emonpi which had the RF board on it. It has been working for a god few years. The pi is powered from an adapter; no adapter, no comms!

Perhaps I should open it up and check that the board looks OK?

[Robert.Wall]

I didn’t mean the 5 V d.c. power supply, I’m interested in the a.c. adapter from which it gets a sample of the a.c. mains in order to measure it and compute the real (or active) power. It plugs into the socket labelled “9V AC SAMPLE”. You should be seeing a value of about 240 V for the 5th value, not 0.56 V.

My suspicion is there’s not quite enough voltage there when it reads 0.55 V to trigger the voltage detector, so it guesses apparent power based on an assumed 240 V; but when it sees 0.56 V, it reverts to doing as it should and calculates real power, but with a weird phase shift hence the negative value.

Hence my suggestion that your a.c. adapter isn’t giving out the correct 12 V or so (even though it says 9 V on the label).

[spock64 (Jason)]

Ah yes, I had forgotten about the capability to use a PSU to provide a sense value for the a.c. supply voltage.

The thing is, I don’t have that PSU. Perhaps this means that we have a problem with ripple?
But, I’m not sure - I’m looking at EmonLibCM_interrupt where the acPresent flag is set.

I see that there looks to be problematic code in that ISR - the calculation seems to be as follows (omitting all code that does not access acSense) …

  static unsigned int acSense = 0;
  .
  .
  .
      acSense -= acSense >> 2;
      acSense += sampleV_minusDC > 0 ? sampleV_minusDC : -sampleV_minusDC;
      acPresent = acSense > acDetectedThreshold;

This is odd - acSense does not seem to be read anywhere before the calculation is made?
Does’t this make the value of acPresent random ?

The full snip of code is below…

  static unsigned int acSense = 0;
  
#ifdef SAMPPIN
    digitalWrite(SAMPPIN,HIGH);
#endif
  
  rawSample = ADC;
  next = sample_index + 2;
  if (next>no_of_channels)                 // no_of_channels = count of Current channels in use. Voltage channel (0) is always read, so total is no_of_channels + 1
      next -= no_of_channels+1;
  
  ADMUX = ADCRef + ADC_Sequence[next];     // set up the next-but-one conversion
#ifdef SAMPPIN
    digitalWrite(SAMPPIN,LOW);
#endif
  // Count ADC samples for timing when voltage is unavailable
  missing_VoltageSamples++;

  
  if (sample_index==0)                                               // ADC_Sample 0 is always the voltage channel.
  {
#ifdef SAMPPIN
    digitalWrite(SAMPPIN,HIGH);
#endif
      // Removing the d.c. offset - new method:
      // Rather than use a filter, which takes time to settle and will always contain a residual ripple, and which can lock
      // up under start-up conditions, it is possible to remove the effect of the offset at the final stage of measurement.
      // First take off the theoretical (constant) offset to reduce the size of the numbers (as Robin's original method).
      // Then accumulate the sum of the resulting values so as to be able at the end of the measurement period to 
      // recalculate the true rms based on the rms with the offset and the average remaining offset. The remaining offset 
      // should be only a few counts.
      //
      lastSampleV_minusDC = sampleV_minusDC;                         // required for phaseCal algorithm
      sampleV_minusDC = rawSample - (ADC_Counts >> 1);               // remove nominal offset (a small offset will remain)
      // Detect the ac input voltage. This is a 'rough&ready" rectifier/filter. It only needs to be good enough to detect
      //  sufficient voltage to provide assurance that the crossing detector will function properly
      acSense -= acSense >> 2;
      acSense += sampleV_minusDC > 0 ? sampleV_minusDC : -sampleV_minusDC;
      acPresent = acSense > acDetectedThreshold;

[Robert.Wall]

I don’t understand your thinking.

      // Detect the ac input voltage. This is a 'rough&ready" rectifier/filter. It only needs to be good enough to detect
      //  sufficient voltage to provide assurance that the crossing detector will function properly

What you have in the lines following that explanation is a variable that gets the peak value and then decays with each sample set. It’s not expected nor intended to do anything other than what it says. Bear in mind too that without the mains voltage reference, all you are able to measure is current, it won’t and can’t give you an accurate value of the quantity you pay for, which is energy, the time integral of real (active) power, because you can’t calculate power without knowing the instantaneous relationship between current and voltage.

If you don’t intend to use the voltage, then your easiest change is in line 215 - just raise the threshold, say:
unsigned int acDetectedThreshold = ADC_Counts >> 3;
which if it’s triggering on pickup spikes with an rms value of 0.56 V, should raise that to over 2 V, yet low enough to still work with an a.c. adapter.

If this is indeed the problem, you’re only the second person to report it, the emonPiCM has been available for nearly 3 years, and emonLibCM has been used in the emonTx V3 (with effectively the same hardware) for over 5 years, so it’s not exactly a common problem.

[Bill.Thomson]

@spock64

a PSU to provide a sense value for the a.c. supply voltage.

It’s not really a PSU, just a “wall wart.”
(just in case you or - other users - were thinking that it’s an actual power supply)

[spock64 (Jason)]

Well, it’s a transformer isn’t it? A kind of power supply …

[Robert.Wall]

But it’s not supplying any significant power, all the power comes from the 5 V d.c. psu.

[spock64 (Jason)]

Sorry Robert, I had missed the ‘static’ storage classifier - I was rushing out when I send the last post.

I’m fully aware of how to calculate power in systems - in my case, I’m more interested in the pattern of current draw rather than any absolute accuracy though - this allows me to spot what is happening in our home.

Perhaps to actually solve the problem I had though, it might be better to ensure that only sensible values are returned from the library? Returning a negative value, for example, is clearly not a good idea. Alternatively, a configuration flag would allow for the problem to be obviated once and for all? I’ll ponder and send you a pull request when I get to it.

When I’m back from holidays in a couple of weeks, I’ll pop the scope on to see what is happening on the ADC input - it could be that I am suffering from some unexpected noise.

Meanwhile I’ll make the change you suggest to see if that resolves my short-term problem.

I’ll update when I know a bit more - but many thanks for now.

[spock64 (Jason)]

Yes, it’s used to sense voltage here, but the device is a PSU … that’s what the data sheet says!

[Robert.Wall]

@spock64

Returning a negative value, for example, is clearly not a good idea.

Really? What if you have PV and want to know how much electricity you’re exporting?

[Robert.Wall]

I’ve done/repeated some tests:
unsigned int acDetectedThreshold = ADC_Counts >> 5; show AC detected around 9.6 V
ADC_Counts >> 4 moves it to around 19 V,
ADC_Counts >> 3 moves it to around 39 V.

With the a.c. adapter unplugged, it reads between 0.06 and 0.12 V.

All this was done with an emonTx V3.4 out of its case. I don’t think I can justify changing emonLibCM on the evidence so far, especially as no more emonTx’s or emonPis will be sold with software that uses emonLibCM.

[spock64 (Jason)]

Ah yes, as my main use for the past number of years has been measuring usage rather than managing feed in, I had missed that point.

Perhaps emonhub should so something about that … it can understand the context and can be easily configured.

[spock64 (Jason)]

I’m going to look a little deeper - what is interesting is that the power value being returned is plausible yet with an obviously incorrect VRMS.

The ‘-4’ is also consistent - also odd.

I’ll take a look over the next few days.

[Bill.Thomson]

@spock64

Perhaps emonhub should so something about that

[spock64 (Jason)]

It would make sense for emonhub to discard data that is invalid in the context of a feed.

A simple flag or feed type that indicated that a feed was import only, export only or both would make sense wouldn’t it?

Otherwise, how is junk data spotted and discarded?

BTW, I don’t think It is appropriate for the firmware to understand the context of a feed - although it might discard data that is clearly junk.

[Greebo]

You can already discard “junk” input data before adding it to a feed, why duplicate that capability in emonHub?

For example, here’s input processing I use to set any values from my Solar of “less than 5” to zero before logging them to the feed. Any value greater than 5W is logged as normal.

My solar inverter shows a few W of power generation during the night that I wanted to filter out.

[Robert.Wall]

@spock64

and send you a pull request when I get to it.

If that relates to Github, don’t bother, I don’t use it so I’ll never see it. The procedure is to post in the support topic related to the post from where you download emonLibCM (there’s a link on that page) for consistency, but I’ll probably see it anywhere else on this forum.