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

[paul swed]

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.
>