On 2/27/2015 1:27 PM, Tom Van Baak wrote:

Been doing just that - fascinating!  I'm getting closer to doing some
frequency / phase monitoring here.

From:  http://leapsecond.com/pages/mains-cv/

"A convenient way to monitor power line phase or frequency is to
timestamp every cycle. This generates a lot of data...so for most
purposes we keep just one timestamp per second. This gives about 86400
samples per day."

Using a zero-crossing detector with the picPET and logging the timing of
each zero-crossing, how do you toss out the other 59 samples each second?

Doing this after-the-fact seems do-able with some software.  I seem to
recall doing something like this with FORTRAN or BASIC.  (open log file,
open output file, read log file line by line, tossing out 59 samples and
writing the 60th to the output file, reach EOF, close both log and
output file)

But...is there a clever way to do it up front?  Time to do more reading.
I've seen some folks doing frequency / phase monitoring using an
Arduino, but nothing (yet) that uses a high-precision reference such as
10 MHz from a GPSDO.

On a side note...the Z3801 got a new outdoor GPS antenna yesterday.
Very happy with how well it is working:

http://www.kd5byb.net/kd5bybgpscon/gpsstat.htm

thanks much and 73,
ben, kd5byb

On 3/1/2015 3:10 PM, Ben Hall asked:

I think I figured out a very obvious way.

~60 Hz AC --> zero crossing detector --> divide by 64 ripple counter

THEN feed the output of the div by 64 counter into picPET.  It is
logging a little less than once a minute...but 60 vs 64...

thanks much and 73,
ben, kd5byb

Hi Ben,

1. The PC program that reads the serial port can toss lines it doesn't want.

2. Or you can prune the log file with a C program like this:

   // filter to pass one of every N input lines
   #include <stdio.h>
   #include <stdlib.h>
   int main (int argc, char *argv[])
   {
   long count = 0;
   char line[1000];
   long nth = (argc > 1) ? atol(argv[1]) : 60;
   while (fgets(line, sizeof line, stdin) != NULL) {
   if ((count++ % nth) == 0)
   fputs(line, stdout);
   }
   return 0;
   }

3. The other solution that I often use is a version of the picPET (pP19) that deliberately takes 990 ms to output the timestamp (events are counted in h/w). That way it still counts all cycles but only outputs one timestamp per second. This is sort of like putting a prescaler in front of the picPET, but better. Better because no h/w is needed and because it is more immune to false triggers than a pre-scaler. It also works without changes for both 50 Hz or 60 Hz grids.

Yes, see code above. Same logic in any language, but probably one line of code in awk or perl or python.

If you do it up-front, like a pre-scaler, you have to worry about signal quality to avoid off-by-one glitches. You'll get lots of suggestions here on the mailing list and on the web about how to best detect zero-crossings. The circuits get pretty complex. It may surprise you that I don't do any of that.

The beauty of timestamping (instead of traditional counting) is that signal conditioning is much less important. I put raw 5 VAC into the PIC pin via a 10k resistor. That's it. Any "conditioning" can be done in software. About once a month I see a stray timestamp or an extra pulse. You just delete it. So you can recover from glitches. With counters you can't - which is why signal conditioning is critical in those designs.

/tvb

Hi Ben,

Any microcontroller will allow you to poll for or capture events. Many even have capture/timer capability in h/w. Using a continuously running multi-byte timer you just subtract the current time from the previous time to get time interval (period). The traditional method of starting or resetting a timer after each event is prone to accumulated timing errors. Making periodic snapshots of a continuous timer avoids this.

Note that timer wrap-around is transparent for binary counters, as long as your timer won't wrap twice between events. For example, a 16-bit 1 MHz timer is more than sufficient for measuring 60 Hz events (since 16667 < 65536) with 1 us resolution.

In pseudo-code:

event()
time_now = get_timer()
interval = time_now - time_then
time_then = time_now
serial_output(interval)

Now, there are subtle issues with how interrupts and timers work, depending on the microcontroller, but the basic idea of measuring the precise interval between moderately rapid events (like 50/60 Hz cycles) is simple.

/tvb

Hi Tom and list!

Thank you for the responses.  This has been very educational.

On 3/2/2015 2:55 AM, Tom Van Baak wrote:

I'll publicly expose my silliness here - I never thought about the
program end of things.  I was simply thinking something like an old
terminal program with logging turned on.

Last night in a sleepless moment I got to thinking:  this seems like a
great use of a Raspberry Pi.  It can parse the serial, save the data to
a file, start a new file each day, each week, etc...  Plus, I can set it
up to be a network file location so I can analyze the files elsewhere
easily.  I'm going to pursue this.  I've got two already - one is a
GPS-based NTP server...the other is an ADS-B receiver / reporter.

This would be perfect.  While discarding the unwanted data should not be
hard...not having to do it at all is easier.  ;)

I'll probably end up learning some python in doing the serial logger
above.  It seems to be a language of choice for the Pi.

I wasn't aware of this, so its very good to know.  :)

It is a lot simpler too.  Simple is always good in my book.  (mostly
because I'm too stupid to do much that is complex!)

thanks much and 73,
ben, kd5byb