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

Jason Ball jason at ball.net
Fri Sep 5 17:48:55 EDT 2014


This is interesting.   Im in the process of building my first GPSDO, it
would be interesting to use the PRU to monitor and validate that device,
obviously to the limit of the PRU's accuracy.

I have several BBB's sitting here waiting for a project.


On Sat, Sep 6, 2014 at 7:14 AM, paul swed <paulswedb at gmail.com> wrote:

> Ian
> Thank you
>
>
> On Fri, Sep 5, 2014 at 3:54 PM, Iain Young <iain at g7iii.net> wrote:
>
> > Hey Paul,
> >
> > Grab the tarball, it contains each of the other files in that directory.
> >
> > And yes, the README tells you what you need to do. Note you will need
> > the PRUSS compiler end probably the AM335x PRU Package to compile.
> >
> > Google for it, or grab this one via git:
> >
> > https://github.com/rjw245/am335x_pru_package/
> >
> > [Not mine, but used the inputtest example as a base]. Dump the
> > files in the inputtest directory (or create a new one at the
> > same level), then do the pasm and make stuff.
> >
> > To get started quickly, tic_ab_dualpru, tic_ab_pru0.bin, and
> > tic_ab_pru1.bin, and just run tic_ab_dualpru.
> >
> > This will work on a BBW. I am currently playing with it on the BBB,
> > and have discovered I can go to 10ns resolution, but the code needs
> > adjusting (seems the PRUs might be running at a different speed to
> > the BBW, I need to investigate!)
> >
> > I also still have the 10-11uS issue mentioned below, but I am
> > unconvinced I have the pin-mux settings quite right yet (I think
> > they are being passed back through the SOC-fabric, thus slowing
> > things down!)
> >
> > I'll probably post an update over the weekend (not had chance to
> > play all week due to work commitments)
> >
> >
> > Iain
> >
> >
> > On 05/09/14 20:09, paul swed wrote:
> >
> >> 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.
> >>>>
> >>>>
> >>>
> >>>  _______________________________________________
> >> 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.
> >
> _______________________________________________
> 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.
>



-- 
--
Teach your kids Science, or somebody else will :/

jason at ball.net
vk2vjb at google.com <vk2flnx at google.com>
callsign: vk2vjb


More information about the time-nuts mailing list