Hi Folks, As much as we all love our HP 5370B's, they are a tad expensive if you want to monitor several PPS sources long term to ensure they are all closely syncronised.
In my case, I have three Austron 2100 LORAN receivers and a HP Z3816A GPS receiver. I wanted to be able to compare each of their PPS outputs with the PPS output of the Z3816A, as well as each other. Clearly, multiple 5370's would have been too expensive, not just for initial outlay, but also ongoing electrical costs would not be helped! However, the Beaglebone (Both White and Black variants) have two PRUs. These are real-time units, with clocks that run at 200 MHz, and most instructions complete in 1 clock cycle (5ns) So, I decided to write a TIC in the PRU Assembler to scratch my particular itch. The current code waits for the "A" clock to go high, and then counts until "B" goes high, resets it's counters, and waits for "A" to go high again. It also keeps track of a "sequence" number for sanity's sake, and onward processing. Since the Beaglebone's have two PRUs, I have written the code to run on both at the same time, and use different GPIO pins, so you can compare up two sets of two clocks, or two clocks with a common reference. Pins are documented in README.txt Now, it's resolution is 20ns. However, it gets confused if the two pulses are less than around 10-11uS apart. I -think- this is when it sends the data back to the host processor via shared RAM. In my case, this is not an issue, as I can just slew the PPS from the Austron's (or even use the Fixed PPS), but if you wanted to compare two GPS receivers, then that would be an issue. I'll have to look if there's a better way to do the shared memory stuff (interrupts, signaling etc), or store multiple intervals and send them all at once, although the current code seems pretty tight. I'd like to have tried it with 1MHz, 5MHz, and even 10 MHz clocks, as 20nS resolution will handle that, but I think I need to fix the <11uS separation issue first. Then again, it was written to compare PPS's from different Austron 2100's and GPS. It also took less than 24 hours from concept to running :) If anyone wants it, the code is here here: http://hal.g7iii.net/bb_tic/ You will need the pasm compiler, and probably the am335x PRU package, although there are (tiny) binaries there as well Setup, Compile, and Running instructions are included in README.txt Oh, Sample output: PRU0: Seq No:848 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.000011700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.000011680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.000011660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.000011660 seconds You can plainly see the Austron has a jitter of around +/-20 ns from the GPS PPS (figures confirmed with the 5370). Slew was around 11.5us. I must wire up the other two Austron's but will need to build a new BB image first :) Hope someone else finds the code useful. Iain _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.