2

I have a Raspberry Zero connected to the SO pulse output of an energy meter (ABB C13) using a direct connection to GND and GPIO13 configured as input with pull-up resistor, and a Python program with the standard setup of GPIO-event callback on a falling edge. I have an inkyPHAT as display which is updated in a separate thread. The main program just waits around. I.e. like

GPIO.setmode(GPIO.BCM)
GPIO.setup(PULSE_GPIO, GPIO.IN, pull_up_down=GPIO.PUD_UP)
GPIO.add_event_detect(PULSE_GPIO, GPIO.FALLING, callback=getpower, bouncetime=200)

try:
  while running:
    time.sleep(10)

except KeyboardInterrupt:
  running = False

In the callback I have

  newtime=time.time()
  deltime=newtime-oldtime
  oldtime = newtime

and some data calculation and dumping to a file.

I measure the power use of my EV car charger (and I am not charging...), which in standby uses about 1.7 W. The meter gives 1000 pulses/kWh, so the interval is about 35 minutes.

It works fine for some 12-15 hours, but then the GPIO events become erratic. A log-scale plot looks like this: Log power versus time

This may stop after some hours, but sometimes I just loose patience and reboot and restart.

Do I need to/could do something in the callback to ensure the integrity of GPIO-event or whatever?

Should I skip the internal pull-up and use external parts instead? I haven't tried to "reverse" the circuit (connect to 3.3 V and GPIO and use pull-down, because the voltage outputs are used/blocked by the display)

I notice the erratic behaviour starts after 18:00, but I do not know of any events in the power usage in my home that changes dramatically at that time. The connection to the SO output is simple twisted pair, no shielding or otherwise.

Any ideas?

Edit:

Trying @joan suggestion, I added pigpiod and monitor.py and got this result which I read as a nice and steady signal:

monitor.py output

(I suppose its ticks in microseconds, and the interval is about 2400 s with a 100 ms pulse.)

However, I see several callbacks between each 2400 s period for about three hours after which it settles again !?

So if the pulse is OK what else can trigger the callback?

2 Answers 2

4

Perhaps it is EMF from something switched on at around 18:00.

I suggest you run monitor.py in the background and check its view of the situation.

sudo pigpiod

python monitor.py 13

If you see spurious pulses try using debounce to filter the inputs.

To set a debounce filter use the following command from another terminal.

pigs fg 13 1000

http://abyz.me.uk/rpi/pigpio/pigs.html#FG

That sets a 1000 microsecond (1 miilisecond) debounce. Increase/decrease the 1000 figure until the pulses are reliable again without EMF.

If the erratic pulses stop (in the view of monitor.py) you need to debounce the input within your script.

1
  • Thanks. Will try next time it occurs. This evening is quiet so far (sunday?) ...
    – HJensen
    Commented Mar 6, 2022 at 19:46
0

As @joan's suggestion of monitoring via pigpiod showed that the GPIO events were in fact clean, but for some reason spurious callbacks are generated, I simply added a primitive "debounce" in the callback procedure.

Since the pulses from the SO are 100 ms wide, I insert a wait for 40 ms and check if the GPIO is still high. If so, skip the callback.

  newtime=time.time()

  time.sleep(0.04)
  if GPIO.input(PULSE_GPIO)==1:
    return

  deltime=newtime-oldtime

It seems to work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.