Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Pulse counting RFM69PI direct connect to emonpi base

Tags: #<Tag:0x00007f681c7f7d40>

Hi ,

Total noob to Emoncms, I have followed the

https://blog.openenergymonitor.org/2015/09/pulse-counting-with-rfm69pi-and/#disqus_thread

and finished all the connections and inf file settings. but now I have no idea how to gather the
data or check if is reading. If someone could point me in the right direction it would be great.

regards

Morgan

Nice work :+1:

Are you using an emonSD pre-built SD card image?

If so just browse to local Emoncms, you should see data on the inputs. If not then please post your emonhub.log file. See setup guide:

This will help the next guy who wants to do this from blog tutorial.

Pull in latest changes to RFM2PI git directory:
$ cd RFM2PI (should be RFM2Pi) capital I wont work.
git pull (sudo git pull)

avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex

(this ends up like this)

avrdude-original: erasing chip
avrdude-original: reading input file "/home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex"
avrdude-original: error opening /home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex: No such file or directory
avrdude-original: input file /home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex auto detected as invalid format
avrdude-original: can't open input file /home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex: No such file or directory
avrdude-original: read from file '/home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex' failed

(the problem is there is no folder or file create with these Pulse names below from (git pull)

RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex' failed

I cant go any further without the correct firmware flashed to the RFM69Pi correct?

prebuilt image and emonpi and optical from your store.

regards

Morgan

Hi,

Does anyone know why the git directory for RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex
not correct?

Regards

Morgan

Every now and then the repos get moved around.

It seems the file you seek is now located at RFM2Pi/firmware/dev/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex

So changing that command line to

sudo avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/dev/RFM69CW_RF12_Demo_ATmega328_Pulse/RFM69CW_RF12_Demo_ATmega328_Pulse.cpp.hex 

should work for you. (fingers crossed)

You’re right, that is a typo and should be RFM2Pi (hopefully @glyn.hudson or @Gwil will pick this up and correct the typo and also the path used in the guide)

Sounds like there is a permission issue, the repo should not be owned by root, it should be owned by pi, You are not the first to see this, it is also the reason the RFM2Pi updates do not get automatically pulled in by the emonpi update routine,

You could use

sudo chown -R pi:pi /home/pi/RFM2Pi

to correct the permissions.

1 Like

Thanks, I’ve now amended the typo and the path.

1 Like

Thanks that worked,

I have run into an unforeseen problem the the meter I intend to read has a large glass
cover and it seems that it is too thick and to far for the optical sensor to read the pulses.

I have access to the digital pulse wiring if there is any way to read input these into
emonpi?

https://www.mouser.com/ProductDetail/GHI-Electronics/PULSE-GM-465/?qs=pum4Fo%2bw6dhJ%2FGiSKvNyWA==

Or any other ideas?

Regards

Morgan

Are you referring to volt free S0 pulse type output on the meter?

If so the OEM pulsecounting SW might be able to read those pulses if you can wire it to the RFM69Pi in place of the optical pulse reader.

I’m not familiar with the module you linked to.

Are you confident with low voltage electrics/electronics? There are many threads on these forums about pulse counting so I would say there is a good chance it can be done, but what exactly needs doing and how easy that might be depends on what meter setup you’ve got.

Paul,
I have attached a picture of the meter rear inputs . when I tested the RA / RB leads (パルス入力) which means pulse input, I get a momentary 10.00V pulse in various time increments.

Any ideas how to get this into my EmonPI?

Cheers Morgan

I see wires on those (RA, RB) terminals. Where do they go? Unless they are unused, you can’t use those directly because anything inside the emonPi/emonBase needs to be referenced to the internal 0 V rail.

But if you say there’s a 10 V pulse, can it light a LED? If it can, you can - as Paul said, if you’re confident with low voltage electronics - use that to drive an opto-isolator and feed the isolated output of that into the GPIO pins of your Pi, then run a script to read that input.

I’m afraid I think Paul was mistaken when he wrote

There is a pulse input on the emonPi, but not on the RFM69Pi module you plug onto a Raspberry Pi to make an emonBase. Hence you must use the Pi’s GPIO.
[If you do really have an emonPi, then you could use a LED and the optical pulse reader from the shop, plugged straight into the pulse input on your emonPi.]

No, Actually Paul wasn’t mistaken. Morgan is using the “pulse counting” firmware for his RFM69Pi and following the associated blog/guide, see the opening post. It can be done with a RFM69Pi rather than direct to the Pi GPIO, either can work although neither have the physical rj45 (not entirely a bad thing sometimes).

Still a really good idea, I think this is the way Morgan should probably go (even without the emonPi). He already has an optical pulse connected to the rfm69pi and this would offer a great level of isolation and no concerns over matching voltage levels.

Finished the hardware attached a picture (it’s not pretty, but it works) now I have questions.

  1. The pulses are about ten to fifteen seconds in length, so basically the light is on, with momentary off to separate the pulses.

  2. The documentation says that “50000 pulses = 2.4 kw” but

  3. Numbers from our bills and logs are as follows
    Daily usage approximately : 4300 kwH
    Monthly usage approximately: 196.665 kwH

We are thinking the length of the pulse is the key to the formula ,
Looking forward to your thoughts and suggestions.

Cheers Morgan

Is that “momentary” pulse the same one that is lighting the LED for about ten to fifteen seconds?
Can we have a proper circuit diagram of what’s on that breadboard?
Can you explain (2) & (3):

  • Is (2) from your meter’s data sheet, and you must mean "50000 pulses = 2.4 kWh "?
  • Is (3) Monthly usage from your supplier’s bill, and is “Daily usage” derived from your pulse count?

Have you applied the calibration from (2) ? (i.e. you divide the number of pulses by 20833 to get kWh)

Is that “momentary” pulse the same one that is lighting the LED for about ten to fifteen seconds?
Yes connected the RA/RB pulse input of this meter.


<a class=“attachment” href="/uploads/default/original/2X/e/e5005f8cc699a84670a87067fa524a

Here is the diagram PDF of the breadboard.
pulseleddiag.pdf (27.4 KB)

Is (2) from your meter’s data sheet, and you must mean "50000 pulses = 2.4 kWh "?
Yes

Is (3) Monthly usage from your supplier’s bill, and is “Daily usage” derived from your pulse count?
Yes and Yes

Have you applied the calibration from (2) ? (i.e. you divide the number of pulses by 20833 to get kWh)

Does this look correct?

Question on power pulse length, if I graph from raw pulse data it is extremely close to the power demand I see on analogue meters in control room, coincidence ?

What does the pulse number represent? my numbers coincide with power demand from low 100’s in the lowest demand times in the early morning, to high 500`s in the afternoon.

Thanks for all the assistance,

Cheers,
Morgan

It seems somewhat unusual that the meter is emitting a pulse - normally, the pulse is less than one second, usually 100 - 200 ms, in length. The pulse length should make no difference to the operation of the sketch, because it works on the falling edge of the pulse.

That calibration in emoncms looks OK to me, but I’m not an emonCMS expert.

Most meters emit a pulse when a quantity of energy has been consumed. In that case, the pulse rate is proportional to power, the pulse count over an interval is proportional to the energy over that same interval.
On that basis, “Keizan Power Pulse” should be a number that continually increases, like this:
Selection_280
The slope is power, the absolute value is energy.

I’m struggling to read the text on that screenshot of the graphs, but that’s not what you have,

so it would appear that what your meter is sending is not what you think (and not what the pulse counting firmware is expecting). And what you originally wrote “50000 pulses = 2.4 kW” actually looks correct - the pulse count is proportional to power. This is most unusual. In the light of this, I think you need to go back to the meter’s data sheet and check exactly what it says.

[EDIT]
I think you might need to redesign your LED drive circuit. I’ve just realised that it’s probably counting mains cycles while the LED is on, because the LED and diode in parallel imply it’s fed from a.c. and the LED is flashing at mains frequency!
You need to provide the LED with a smoothed d.c. supply.
(There is in the software a delay to ignore contact bounce, but it’s ineffective if the LED is flashing at 50 / 60 Hz for several seconds. What will actually happen is when the LED goes off, it counts a pulse and a 110 ms timer starts. It will then ignore the falling edges when the LED goes off 20 ms later (assuming 50 Hz), 40 ms later, etc up to 100 ms later, then it resets and counts the next falling edge at 120 ms as a pulse and starts again. So it is counting 1 pulse for every 6 mains cycles while the LED is apparently on continuously.)

Robert,
Thanks for the input.

The circuit shown is a inverse parallel with a IN4007 silicon diode to prevent the LED from being reverse-biased (flicker), the LED power is fed half-wave current this way.

When I connect the multimeter to RA/RB I get the same type of pattern as with the LED breadboard.

The RA/RB power supply at 10v is coming from a pulse meter at the WHM2 directly to the Ozaki meter
shown, I don`t about the “You need to provide the LED with a smoothed d.c. supply. theory” but I am a networking engineer not an electrical so…

Here is mine WH accumulator

Thanks for the input
Morgan

Ok new twist are you ready?

Using my raw pulse count data in daily graph setting, for last 5 days I have had my emoncms running compared to manual logs take from meter there is only a less than +/- 3% deviation!

Can someone tell me how this can be?

Cheers Morgan

I’ve been reading along with this discussion and had been thinking that maybe the LED activity you are seeing is just the inverse of what we’re used to.

Essentially all pulse counting determines the rate of consumption from the length duration between the pulses (or in this case duration of the pulses) as each, pulse on (or alternatively, off) signifies that a pre-determined amount of energy has passed, therefore the speed that pre-determined amount passes indicates the “rate” of flow.

Without knowing exactly what the meter pulse terms do and/or what the existing wiring is hooked into we cannot be sure what you have, perhaps the contacts are volt=free and the existing equipment is working with a switched ground, which you are now using the floating “high” voltage to power your circuit rather than counting the “0v” pulses?

As long as you have a change of state that matches the pulse output of the contacts, I do not think it matters if it’s a pulse off or pulse on. So my interest would turn to the 3% and whether there is a potential reason for there being a 3% error, eg restarts or ambient light etc as counting pulses should ideally be exact.

How many pulses does 3% represent?
Is your sensor assembly installed in a light tight box?
Have you been restarting the device during your tests?

I would be tempted to let the tests run longer (noting the current error or resetting the counter).

If the counting is accurate it should’t matter much if you are counting on pulses or off pulses, but if needed you could alter the sketch to work on the opposite edge/direction of the pulse.

I’m totally confused now. Morgan, you’ve shown a picture of a [s]upermax Mini meter - I presume the back view of that is the picture in post. no. 9, your screenshots show “Kaizan power pulse” and now you mention WHM2 and an Ozaki meter.

Can you clarify just what is what, and where you think the 10 V comes from, and is it a.c. or d.c.?

I think I discounted that early on, because the pulse counting interrupt is edge-driven. Whether the falling edge of the pulse is the start of the pulse or the end of the pulse will make no difference.

Indeed. I’m presently running a test on emonLibCM. My energy meter displays units of 1 kWh. After 1 week, the pulse count was 0.6% in error, after 5 weeks it has dropped to 0.02%, and that’s solely due to the uncertainty in the meter reading.

Help!! pulled bonehead move. apparently deleted feed now no new daily kWh totals after June 26 09:00 so apparently deleting “Power to kWh” process from “pulse power” feed was not a good idea?

Is there a way to view logs to find out what exact process and argument I deleted from logs?

I am not sure I completely understand what feed to apply the “Power to kWh” argument to,
since my it seems my raw pulse count data is correct do I add argument to that feed?

Morgan