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)
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,
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.
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.
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:
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.
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.)
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…
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.