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

[paul swed]

Ian what files are needed?
Forgive me if its in the read me.
Thanks


On Fri, Sep 5, 2014 at 2:56 PM, paul swed <paulswedb at gmail.com> wrote:

> Ian
> Have not downloaded the info yet.
> But I was surprised by the fact you were using LORAN sooo you must be in
> Europe. Lucky you to have such a fine signal.
> Great job on the tic. Now to go download the bits.
> Thanks again.
> Regards
> Paul.
>
>
> On Sun, Aug 31, 2014 at 10:26 PM, Tom Van Baak <tvb at leapsecond.com> wrote:
>
>> Hi Iain,
>>
>> Thanks very much for posting, and for sharing the code. I know many of us
>> are interested in how well modern CPU's or SBC's can be used as time
>> interval, time stamping, and frequency counting instruments. I know the BB
>> PRU's have been mentioned before on the list but it's really nice to see
>> actual code and test results.
>>
>> About the hp 5370 -- realize that these are still 1000x more precise (on
>> the order of tens of ps) than what a BB/PRU is capable of (on the order of
>> tens of ns). But as you observe, they key point is -- for mid- to long-term
>> measurement of free-running time/frequency standards you do not necessarily
>> need ps-level measurement capability. Nanosecond, or even microsecond time
>> resolution is more than enough to create comprehensive plots of time and
>> frequency drift over the long-term.
>>
>> Again, thanks.
>>
>> /tvb
>>
>> ----- Original Message -----
>> From: "Iain Young" <iain at g7iii.net>
>> To: "Discussion of precise time and frequency measurement" <
>> time-nuts at febo.com>
>> Sent: Sunday, August 31, 2014 1:24 PM
>> Subject: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
>>
>>
>> > 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 at febo.com
>> > To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> > and follow the instructions there.
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
>