Sensing 50Hz frequency deviation fast

[ItsCool]

Hi' I'm new here, but otherwise not very young

I need a fast detection of deviation from 50HZ VAC power line frequency.
I know the basic hardware to generate a square either as 50 or 100 Hz, so that is not an issue.

I need to know which approach is the easiest to implement with the Raspberry Pi platform, in order to quickly react to a small drop in frequency.
the detection needs to be able to detect and report deviation within 1-2Hz, with a resolution of 0,1Hz, but fast, so it is not allowed to evaluate over multiple cycles. The result is used to control ballast loads of a limited power resource from a small power plant.

Does any of you smart guy´s and girl´s have a good implementation approach?

I presume it may require some flange detect interrupt handling, but not sure. I'm just affraid if it is not interrupt driven, that it will not be accurate, due to other tasks performed by the system.

br
Steen

[mattmiller]

A Pi running Linux is not the tool for this sort of job due to timing requirements

I think you need to look to use micro-controllers (or even hard-wired electronics might be required for equipment safety reasons)

[ItsCool]

Well unfortunately the Raspberry Pi is the only piece of H/W we have, som suggestions to resolve the timing issues are higly appreciated.

Solution to abandon the Raspberry Pi, is of less interrest, as it is not an option, sorry.

Aren't there anyone with experiance in handling interrupt driven drivers to update a valiable in RAM.
This varialbe can the be monitored by the other software driving the ballasts, as these are controlled over Wifi remote switches.

br
Steen

[joan]

If you can get the signal to pulse a Pi GPIO then pigpio will be able to measure the pulse gap to within 10µs or so.

http://abyz.me.uk/rpi/pigpio/index.html

[ItsCool]

Now we are talking.

Very usefull input indeed. thank you.
This looks exactly like what I'm after.

Thank you again for taking your time to show me this.

[pootle]

You'll definitely need some external circuitry to keep the mains well away from the pi.

I suspect that the best option would be zero crossing detector something like https://www.circuitar.com/nanoshields/m ... ero-cross/. (lots of similar ones pop up on search, but this is nice 'cos you can select 3.3v output and thus connect direct to a pi.

As long as your supply is fairly clean, you should be able to trigger on significant variation in crossing time.

As were only talking about 100 events per second, Python can easily handle this with a callback, with pigpio providing the timestamps (which will be accurate to a few microseconds). You just need to watch out for the timestamp wrapround every hour and a bit

[PiGraham]

For certain you cannot do this with just a Raspberry Pi so saying a Pi is all you have and you can't use anything else doesn't make sense.

A Pi running Ultiboo can do some pretty real-time things. It's worth a look.

You should try to quantify your timing requirements in more detail. What happens if you miss a half cycle or react tens of milliseconds late?

If that doesn't matter a userspace Python program on a Pi should be OK. If that's a problem you should probably look at a more real-time laternative.

A Pi running Ultiboo can do some pretty real-time things. It's worth a look.

Just about any microcontroller could handle this easily.

You could use a hardware counter timer to time the signal and read the result when needed with much less critical timing. Most microcontrollers have such functions built in.

I suggest you start with a zero-crossing detector to produce a logic signal that gives the timing of mains voltage zero crossings. From that you can get a time for a half wave every half wave.

[hippy]

For certain you cannot do this with just a Raspberry Pi

I am not entirely convinced that is the case. To measure to 0.1Hz accuracy requires timing the 50Hz ±2Hz period to about 40us resolution. If pigpio can time a signal to a resolution of 10us or better then it would seem to be possible.

That's an 'if' because I am not familiar with pigpio.

I do however agree that a Pi is probably not the best choice for the job. The Pi's SoC does not appear to have any integrated gated or one-shot timer peripherals which can easily measure a 50Hz signal period to 500ns (0.002Hz) or better resolution whereas most microcontrollers will.

I would probably go with a microcontroller to measure the period which can be reported to the Pi over serial if that microcontroller could not do everything required itself.

[joan]

It only takes a few seconds to see if pigpio can accurately time the pulses.

Download http://abyz.me.uk/rpi/pigpio/examples.h ... monitor_py which is a Python script which just prints GPIO callbacks. (monitor.py).

If you don't have a 50Hz source use the hardware PWM peripheral to generate a 50Hz signal.

sudo pigpiod # start the daemon
pigs hp 13 50 500000 # start 50Hz signal on GPIO 13
./monitor.py # display GPIO activity

Code: Select all

G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10000
G=13 l=1 d=10000
G=13 l=0 d=10001
G=13 l=1 d=10000
G=13 l=0 d=10000

PiGraham's point is that timing the signal is one thing, reacting to the timing is another. pigpio is a userspace program - it might record that a cycle is too short or too long but its reaction time is constrained by the vagaries of Linux.

[hippy]

[deleted]

[PiGraham]

For certain you cannot do this with just a Raspberry Pi

I am not entirely convinced that is the case.

I just mean you can't wire a Pi to mains and not fry everything. Some other circuitry is required, such as a zero crossing detecto opto-isolator

[Moe]

I know the basic hardware to generate a square either as 50 or 100 Hz, so that is not an issue.

Looks like a few posters missed this bit and immediately assumed ItsCool was planning to plug his Pi directly into the mains .

[Z80 Refugee]

The problem here (as I see it) is that the standard OS for the RPi is not what we call "real time". That means you can never rely on program execution to look at some input at or even near exactly the right time, because you cannot guarantee execution won't have been interrupted off somewhere to do some housekeeping.

If this were coded on a micro-controller, you would have absolute control over every clock cycle in the program execution. If you want to do it purely in code with an RPi (assuming the mains signal has been converted to a floating 3V square wave by some additional electronics), you had probably better look at bare-metal programming (ie no OS, just the code running from boot), or at the very least a real-time OS.

As the requirement is so clear and unlikely to need tweaking, I would (personally) much rather design some very simple hardware which compares the input frequency to a reference 50Hz and provides an error signal of some kind. The RPi could easily be programmed to provide the 50Hz reference using its hardware timers, but of course there are many ways to do that without an RPi.

Then, if the error signal is supposed to provide real-time feedback to a power converter, you would be better off doing that directly than going through program code (which has its own delays, and suffers the real time problem...).

Programming makes complex things possible. Hardware does simple things better than software, much faster than software. Most operational systems are a combination of programming with some specialised hardware to do the bits that hardware is good at.

[PiGraham]

I know the basic hardware to generate a square either as 50 or 100 Hz, so that is not an issue.

Looks like a few posters missed this bit and immediately assumed ItsCool was planning to plug his Pi directly into the mains .

It looks like you missed this bit:

I need a fast detection of deviation from 50HZ VAC power line frequency.

[RichardRussell]

The problem here (as I see it) is that the standard OS for the RPi is not what we call "real time". That means you can never rely on program execution to look at some input at or even near exactly the right time, because you cannot guarantee execution won't have been interrupted off somewhere to do some housekeeping.

That is a very good general point to make, but the pigpio library claims to be able to sample and time-stamp the GPIO inputs to a resolution of about 5 microseconds. Taking that claim at face value, which would imply that it is using a high-priority interrupt to circumvent the latency you describe, it should be capable of the task required by the OP. However in a critical application I would want some assurance that the "accurate to a few microseconds" claim by pigpio really is a worst case figure rather than a typical value.

[Z80 Refugee]

I agree... at face value. There would still remain a problem guaranteeing the subsequent processing of the pigpio output to produce a useful effect. As far as I can tell, the pigpio library uses hardware interrupts to capture GPIO state and put it on a queue. That's not much help if the OP then wants to take the output of the queue, work out what it means, and feed the reaction back to the power converter in time for the next switching cycle.

All that would have to be protected from interrupt, with known timings. Other OS functions would have to be locked out until the critical process (triggered by each power cycle) was finished, but then you could not let the OS back in because it might decide not to let you back in when you need it (or if it did, the "other stuff" such as Ethernet servicing might not get enough attention).

Don't get me wrong, I'm not against experimenting as a learning exercise. However, you can waste an awful lot of time pursuing an idea which may or may not work and turns out not to.

[RichardRussell]

That's not much help if the OP then wants to take the output of the queue, work out what it means, and feed the reaction back to the power converter in time for the next switching cycle.

Indeed not, but I would be surprised if a few milliseconds latency was significant when switching ballast loads into or out of circuit, which is the required function as I understand it. Mechanical inertia places a limit on how fast the generator set itself can respond to a change of load. There's a description of what the OP is presumably wanting to achieve here.

[hippy]

I don't know how pigpio does its thing; I was assuming it interrupts, grabs the system timer value, subtracts the last it had sampled, calls that the last pulse width, returns.

Knowing the guranteed maximum latency in that is important, but more so for the userland program using it and what the latency requirements are for the application.

I am not sure a mains cycle measurement lost here or there would be too much of a problem with slow changes of frequency but only the OP can tell us what his actual requirements are.

[joan]

@hippy

pigpio samples the GPIO by using DMA to copy the GPIO register to a userland memory cyclic buffer. The DMA can be paced to do those transfers at precise intervals (every 5µs by default for pigpio). The cyclic buffer is big enough for 120 milliseconds of samples by default. The cyclic buffer is processed at a nominal rate of once per millisecond.