[time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)

[Iain Young]

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