Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
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.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 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
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
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.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 seconds You can plainly see the Austron has a jitter of around
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
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
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
Ian Thank you On Fri, Sep 5, 2014 at 3:54 PM, Iain Young i...@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 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
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
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 paulsw...@gmail.com wrote: Ian Thank you On Fri, Sep 5, 2014 at 3:54 PM, Iain Young i...@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 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
[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.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 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.
Re: [time-nuts] Poor Mans TIC (Using Beaglebone onboard PRU)
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.11680 seconds PRU0: Seq No:849 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:850 Interval:11700 ns or 0.11700 seconds PRU0: Seq No:851 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:852 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:853 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:854 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:855 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:856 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:857 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:858 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:859 Interval:11680 ns or 0.11680 seconds PRU0: Seq No:860 Interval:11660 ns or 0.11660 seconds PRU0: Seq No:861 Interval:11660 ns or 0.11660 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
