Archived Forum

Jerome has thought quite a lot about this problem. I'm not sure if he found a perfect solution, but you could try searching through his posts to see what he has written.

Indeed, I configured my TX to send the pulses the same way your gasmeter does.

This is ongoing work, and I'm currently stuck with range issues, so I haven't been working on it lately.

I'll propose it for integration when it's all validated. In the meantime, you may want to have a look to:

• The sketch I'm using in the TX. (Actually you don't need this, but someone who's interested in this thread could.)
• The modifications I made to emoncms.

Current issues:

• emoncms needs to discriminate between counter being reset and counter wrapping around. In the general case, this takes the knowledge of the max counting rate. Since I don't know how to pass this as a parameter to the pulse_diff function, there is a hardcoded 1 here.
• When the received counter value is similar to last value, emoncms computes a power of 0. Then, if the counter is incremented and received just a second later, the power calculated is huge and wrong, because the energy was not actually consumed only in the last second, but also before.

For this particular issue, I modified emoncms so that when the counter is received with a value equal to the last one, the processing is stopped and the power not calculated. Therefore, when the value is actually increased, the power is computed on a time interval that goes back to the last increment. This is the best we can do with the meter precision.

The issue is with the graphical representation. In practice, you get power profiles (in kW) roughly like this:

12 13 12                              1 12 13 12                                     1

This is for a boiler that goes on for a few minutes every 20 minutes. You get more or less flat peaks, almost like a square wave. And before each peak, you have a low power value that accounts for the energy consumed during the interval between the peaks. This can be real energy (little gas consumption, for cooking or hot water) or an artefact due to the meter precision. In any case, there's nothing we can do about it.

To graphically represent this, I'd like to see a square wave, with a value close to but not 0 between the peaks. (In fact it can never be a perfect 0.) With the current emoncms graphical visualisation, the power points are linked linearly: draw each point, then add a line between them, so as to get a continuous function. But we need a step function: each value is the value of the power for the time passed since last sample. There is no interpolation to make. And if there was, it would be between the points that are at the middle of each segment.

We don't want the visualization to make the graph continuous.

I suppose this would take a new visualization type. I had a quick peek in the code and it wasn't obvious to me how to create one.

Am I making myself clear ? I hope so because this is also a call for help, regarding the visualization need.

I tried to trick the visualization: each time a new power value is computed, before entering it in the database, add another sample with the same value and the time of the last sample, to force the curve to appear as a step function. Obviously, this is a dirty hack. I just wanted to see what it would look like. I couldn't test because of another issue on my setup. This is not pushed on my github branch anyway.

Related threads:

http://openenergymonitor.org/emon/node/3183

http://openenergymonitor.org/emon/node/1585

http://openenergymonitor.org/emon/node/2850

Jerome,

I am reading your stuff with great interest, as I will soon be coming across these issues. My next step is to see if I can get a magnetic pulse reading from my meter, so a few steps behind you!

I am hoping that I will be able to power my EmonTx from a mains adapter rather than battery, so I'm not so bothered about saving power.

You may have already thought this through, but instead of using emoncms to calculate power from the number of pulses received (if I understand the sketch correctly), why not calculate the rate of power on the emonTX and send this value?

So transmit from the emonTX every 60 seconds, counting the number of pulses each time, and therefore the kW over this 1 minute period. At low gas consumption figures this will give slightly odd results though?

Chris

Some questions on your emonTX sketch (I'm pretty new to coding Arduino sketches);

Line 30: doesn't this code get run first if it is located before the setup? Shouldn't this go after the void loop section?

Line 78: detachInterrupt(1)- doesn't this turn off the interrupt? What is this used for?

Line 85: if(digitalRead(3)==LOW)- what is this if statement for?

Line 91: is the watch dog timer there to count the time between pulses?

Chris

Line 30: No. This is the handler interrupt. It is called when a falling edge is received on the interrupt in, thanks to line 69:

attachInterrupt(1, Pulse, FALLING);

(See, "Pulse" is the name of the handler function.)

Line 78: The interrupt is detached for a short amount of time (10ms + computation and RF send) to debounce the signal, otherwise, the Reed switch would generate several interrupts for the same wheel turn. it is then reattached after that, at the beginning of the next loop iteration.

Line 85: This checks that after the 10 ms debounce period, the signal is still low. If not, it was just noise.

Line 91: No. See next paragraph.

I'm using deep sleep mode. If you're on grid, most of the complications in my sketch are useless to you.

In this mode, only the watchdog and the interrupt can wake the TX up. The TX awakes only if a falling edge is received (wheel turn) or the watchdog reaches its end (8s in my case, which is the maximum, but this is not precise, it is rather a minimum).

Because of this, there is no way to compute the power on the TX, because it does not know how much time elapsed since last interrupt: while sleeping, it loses the notion of time. Because of the watchdog precision, and because when the interrupt triggers, we don't know how much time was left in the watchdog (I think, I'm not 100% sure).

You can do the calculations in the TX if you use a lighter sleep mode where you can use a counter. Perhaps is this a better idea. I mean, even on battery, if it does not consume much more, it could be a good idea. I didn't investigate this, thinking if a post-processing is possible, we might as well allow the TX to sleep.

Another option we did not explore is the power computation in the base...

Jerome,

Thanks for the detailed reply and explanation. I think it mostly makes sense to me now.

You mention in another thread that you are concerned about the reliability of the wireless transmission of pulses (from the emonTX to the Pi), which is why you are using a counter to send the total number of pulses achieved, then post processing to get the kW over that period. Have I understood correctly?

If I have, I would assume that even if using a power supply for the emonTX, I would have the same issue that occasionally the transmission of a pulse might fail to get to the RPi (wireless transmissions I assume are occasionally a bit dodgy just like my internet at home!)

This isn't a problem with the electrical monitoring using a CT clamp, as if the wireless cuts out for a few seconds it makes no difference, as the TX is broadcasting all the time. But if trying to capture pulses, at low pulse rates this could make a bit more difference. If there was only one pulse per minute, and the wireless transmission failed for some reason, I would get no reading.

Chris

You mention in another thread that you are concerned about the reliability of the wireless transmission of pulses (from the emonTX to the Pi), which is why you are using a counter to send the total number of pulses achieved, then post processing to get the kW over that period. Have I understood correctly?

Right.

If I have, I would assume that even if using a power supply for the emonTX, I would have the same issue that occasionally the transmission of a pulse might fail to get to the RPi (wireless transmissions I assume are occasionally a bit dodgy just like my internet at home!)

True.

This isn't a problem with the electrical monitoring using a CT clamp, as if the wireless cuts out for a few seconds it makes no difference, as the TX is broadcasting all the time. But if trying to capture pulses, at low pulse rates this could make a bit more difference. If there was only one pulse per minute, and the wireless transmission failed for some reason, I would get no reading.

Using the TX on power supply, you could take a different approach, use time knowledge to compute the power in the TX and send the power. In this case, if you miss a frame, it can't be repeated, the value is interpolated, which is generally fine but not great with a low pulse rate. You may be better off using the counter approach as well.