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 <paulsw...@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 <t...@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" <i...@g7iii.net>
To: "Discussion of precise time and frequency measurement" <
time-nuts@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@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
