Re: [time-nuts] Hanging bridge question
In message , "Tom Van Baak" writes: >That's only true for time scales less than the cross-over point. >Beyond that, the 1 PPS from the GPS receiver is actually better >(more accurate). That's why the LO is disciplined by GPS, not the >other way around. I would also like to add that the jitter on the 1PPS from the GPS (aka: The hanging bridge) actually helps measurement precision in exactly the same way systematic jitter makes life better a lot of other places, from tape recording (bias = jitter) to machine tools. The best way to use the sawtooth correction is to apply it in software after all the hardware measurements had their errors smoothed out by it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] TSIP protocol for T-Bolt
Am 25.03.2014 22:43, : Today I spent good part of my time to figure out that my version of Thunderbolt has some issue with the TSIP protocol definition. I am using following document: "ThunderBolt GPS Disciplined Clock User Guide, Version 5.0, Part Number: 35326-30, November 2003" but beware, no single document related to Thunderbolt from Trimbles website is complete nor fully correct. As a reference you may use my code of a simple Tbolt-Monitor you will here: http://www.romahn.info/tbolt2lcd/ regards Götz ___ 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] Hanging bridge question
Hi Take a look at the PIC-TIC stuff. They have the HP circuit in the middle of it. Bob Stewart posted a circuit with a pair of tri-state gates in it within the last month or so. They all pretty much: 1) Measure the “coarse time” with a counter Today that’s just about always a counter in an MCU. 2) Based on the clock to the counter (say 25 ns), you have a roundoff / truncation error. (say 0 to 25 ns) 3) You use a gate or two and your capture flip flop to convert the truncation to a pulse. (normally 25 to 50 ns) 4) You pick an R/C time constant to be “useful” (say 50 ns, could be less). 5) You charge the RC with the pulse 6) After the pulse is done, you open circuit the R/C so charge / discharge stops. 7) When you get around to it, you measure the voltage on the cap with an ADC Starting from the 50 ns example, an 8 bit converter likely gives you 500 ps resolution. 10 bits gets you to 250 ps and 12 bits to 125 ps. More bits or a faster clock would do even better. Since the R/C charge voltage vs time is pretty well known, you can do the first part of the math fairly easily. You have a clock and flip flops are pretty cheap. If you want to shoot cal pulses at it, send it a 25 and 50 ns wide pules. The delta between the two should be pretty good. If you have the range, go to 75 ns and get 3 points to fit. The basic R/C is about 5 cents. The one tri-state gate you need is about 16 cents. A quad nand is about the same these days. You already need a pair of flip flops to capture the pps edge (two to a package …). If you want to do the whole calibration thing, one of Bert’s $2 CPLD’s has way more parts in it than you will ever need. The ADC can be what you get with your MCU. In that case 12 bits may be stretching it. There are very nice 12 bit parts from TI that run about $3 or so. 16 bits is still under $10. Bob On Mar 25, 2014, at 11:08 PM, Jim Miller wrote: > Bob > > I'm not sure who you're responding to but I have a couple of questions: > > TDC = Time Delay Correlator? > > Could you point me to one of these 50 cent threads? I've read a ton of this > list from 2007 forward but must have missed that. > > Thanks > > jim ab3cv (much to learn) > > Hi > > There have been multiple posts about analog TDC's of various designs > that get you into the sub 100 ps range without costing very much > money. I believe the cheapest posted so far adds < 50 cents to a basic > PIC based design. > > Bob > ___ > 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.
Re: [time-nuts] TSIP protocol for T-Bolt
You can play with my Thunderbolt Simulator:
http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php
(Windows only, sorry...)
It lets you create arbitrary packets (including setting fault conditions
and arbitrary GPS time or coordinates) and properly escapes the embedded
DLEs. The actual string that is sent is displayed in Hex at the bottom of
the screen.
(Warning: It is work in progress, so not all menu selections actually work)
On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r wrote:
>
> Much thanks Tom and Mike ! I missed that point. In another word, T-Bolt
> sending DLE data "wrapped" by another byte ! Now I know !
>
>
> On 2014-03-25 19:55, mike cook wrote:
>
>> Le 25 mars 2014 à 22:43, d0ct0r a écrit :
>>
>> Today I spent good part of my time to figure out that my version of
>>> Thunderbolt has some issue with the TSIP protocol definition. I am
>>> using following document: "ThunderBolt GPS Disciplined Clock User
>>> Guide, Version 5.0, Part Number: 35326-30, November 2003"
>>>
>>> In that particular PDF file, there is definition for 0x8F-AB TSIP
>>> packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
>>> Packet].
>>>
>>> Here is the structure of 8F-AB, translated to plain C-code:
>>>
>>> typedef struct tb_8f_ab {
>>> uint8_t sub; //0 : 1
>>> uint32_t tow; //1-4 : 4
>>> uint16_t wn; //5-6 : 2
>>> int16_t ls; //7-8 : 2
>>> uint8_t tflag; //9 : 1
>>> uint8_t sec; //10 : 1
>>> uint8_t min; //11 : 1
>>> uint8_t hr; //12 : 1
>>> uint8_t day; //13 : 1
>>> uint8_t month; //14 : 1
>>> uint16_t year; //15-16 : 2
>>> } mytb_8f_ab;
>>>
>>> Here is the dump I get from my MCU:
>>>
>>> //0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
>>> 0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
>>> //0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
>>> 0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
>>>
>>
>> how are you dumping this?
>> you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
>> second is to be ignored.
>>
>> Which is conform to TSIP standard packet definition:
>>>
>>> TSIP packet structure is the same for both commands and reports. The
>>> packet format is:
>>>
>>> Where:
>>> * is the byte 0x10
>>> * is the byte 0x03
>>> * is a packet identifier byte, which can have any value
>>> excepting
>>> and .
>>>
>>
>> Ex: In the tsip developer tool kit , from TsipParser.c
>>
>> case TSIP_IN_PARTIAL:
>> // The parser is in this state if a previous character was
>> // a part of the TSIP data. As noted above, a DLE character
>> // can be a part of the TSIP data in which case another DLE
>> // character is present in the data stream. So, here we look
>> // at the next character in the stream (currently loaded in
>> // ucByte). If it is a DLE character, we just encountered
>> // a stuffed DLE byte. In that case, we ignore this byte
>> // and go back to the TSIP_DLE state. That way, we will log
>> // only one DLE byte which was a part of the TSIP data.
>> //
>> // All other non-DLE characters are placed in the TSIP packet
>> // buffere.
>> if (ucByte == DLE)
>> {
>> nParseState = TSIP_DLE;
>>
>> }
>> else
>> {
>> ucPkt[nPktLen++] = ucByte;
>> }
>> break;
>>
>> However, its appeared that my T-Bolt throwing one "extra" byte for
>>> the so-called "Timing Flags".
>>> There is 19 bytes coming from my T-Bolt, instead of expected 18. I
>>> found that actual length of TFLAG is 16 bit - not 8. Interesting
>>> enough, that Lady Heather works perfectly fine with that T-Bolt !
>>>
>>> Can somebody confirm that there is different version of T-Bolt on
>>> the market ? If so, where I need to look for the documentation for
>>> my version ?
>>>
>>> --
>>> WBW,
>>>
>>> V.P.
>>> ___
>>> time-nuts mailing list -- time-nuts@febo.com
>>> To unsubscribe, go to
>>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts [1]
>>>
>>> and follow the instructions there.
>>>
>>
>>
>>
>> Links:
>> --
>> [1] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>>
>
> --
> WBW,
>
> V.P.
> ___
> 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.
Re: [time-nuts] Hanging bridge question
Hi, Just a quick question from a novice. Sometimes I see abbreviations here and don't know, but usually I can make a good guess. Your first paragraph, "HP" is perhaps high precision? Just want to make sure I am not missing some other meaning. Thanks, learning a lot from reading this group! Matt Martin On Wed, 3/26/14, Bob Camp wrote: Subject: Re: [time-nuts] Hanging bridge question To: "Discussion of precise time and frequency measurement" Date: Wednesday, March 26, 2014, 4:45 AM Hi Take a look at the PIC-TIC stuff. They have the HP circuit in the middle of it. Bob Stewart posted a circuit with a pair of tri-state gates in it within the last month or so. They all pretty much: 1) Measure the “coarse time” with a counter Today that’s just about always a counter in an MCU. 2) Based on the clock to the counter (say 25 ns), you have a roundoff / truncation error. (say 0 to 25 ns) 3) You use a gate or two and your capture flip flop to convert the truncation to a pulse. (normally 25 to 50 ns) 4) You pick an R/C time constant to be “useful” (say 50 ns, could be less). 5) You charge the RC with the pulse 6) After the pulse is done, you open circuit the R/C so charge / discharge stops. 7) When you get around to it, you measure the voltage on the cap with an ADC Starting from the 50 ns example, an 8 bit converter likely gives you 500 ps resolution. 10 bits gets you to 250 ps and 12 bits to 125 ps. More bits or a faster clock would do even better. Since the R/C charge voltage vs time is pretty well known, you can do the first part of the math fairly easily. You have a clock and flip flops are pretty cheap. If you want to shoot cal pulses at it, send it a 25 and 50 ns wide pules. The delta between the two should be pretty good. If you have the range, go to 75 ns and get 3 points to fit. The basic R/C is about 5 cents. The one tri-state gate you need is about 16 cents. A quad nand is about the same these days. You already need a pair of flip flops to capture the pps edge (two to a package …). If you want to do the whole calibration thing, one of Bert’s $2 CPLD’s has way more parts in it than you will ever need. The ADC can be what you get with your MCU. In that case 12 bits may be stretching it. There are very nice 12 bit parts from TI that run about $3 or so. 16 bits is still under $10. Bob On Mar 25, 2014, at 11:08 PM, Jim Miller wrote: > Bob > > I'm not sure who you're responding to but I have a couple of questions: > > TDC = Time Delay Correlator? > > Could you point me to one of these 50 cent threads? I've read a ton of this > list from 2007 forward but must have missed that. > > Thanks > > jim ab3cv (much to learn) > > Hi > > There have been multiple posts about analog TDC's of various designs > that get you into the sub 100 ps range without costing very much > money. I believe the cheapest posted so far adds < 50 cents to a basic > PIC based design. > > Bob > ___ > 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.
Re: [time-nuts] TSIP protocol for T-Bolt
Thanks ! As soon as I figured out about "double" DLE bytes - everything is back to right track. Regards, V.P. On 2014-03-26 04:46, Götz Romahn wrote: Am 25.03.2014 22:43, : Today I spent good part of my time to figure out that my version of Thunderbolt has some issue with the TSIP protocol definition. I am using following document: "ThunderBolt GPS Disciplined Clock User Guide, Version 5.0, Part Number: 35326-30, November 2003" but beware, no single document related to Thunderbolt from Trimbles website is complete nor fully correct. As a reference you may use my code of a simple Tbolt-Monitor you will here: http://www.romahn.info/tbolt2lcd/ regards Götz ___ 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. -- WBW, V.P. ___ 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] TSIP protocol for T-Bolt
Speaking about legacy T-Bolt devices and modern development: Here is
paragraph from Trimble Thunderbolt User guide:
Week Number: This field represents the current GPS week number. GPS week
number 0
started on January 6, 1980. Unfortunately, the GPS system has allotted
only 10-bits of
information to carry the GPS week number and therefore it rolls-over to
0 in just 1024
weeks (19.6 years,) and there is no mechanism built into GPS to tell the
user to which
1024 week epoch the week number refers. The first week number roll-over
will occur as
August 21, 1999 (GPS) transitions to August 22, 1999 (GPS). The
ThunderBolt adjusts for
this week rollover by adding 1024 to any week number reported by GPS
which is less that
week number 936 which began on December 14, 1997. With this technique,
the
ThunderBolt will provide an accurate translation of GPS week number and
TOW to time
and date until July 30, 2017.
How that "week number" will affect the functionality of whole device ?
Its probably time to think to put some workaround to the code or even
eliminate to use that time information received from T-Bolt. I already
met that challenge when I was working with BC637PCI card. The work
around was quite simple then - just to add 619315200 seconds to the
current value [1024*7*24*60*60]. I would like to be little proactive
here. ;-)
Also, does anybody knows if new Trimble Thunderbolt "E" is backward
compatible with legacy HW ? I mean the replacement will still works on
most of existed setups. For example, I did compare the packet definition
for 8F-AC and looks like Thunderbolt "E" has some extensions, but its
backward compatible.
Regards,
V.P.
On 2014-03-26 08:38, Didier Juges wrote:
You can play with my Thunderbolt Simulator:
http://www.ko4bb.com/Timing/GPSMonitor/TBoltSim.php [2]
(Windows only, sorry...)
It lets you create arbitrary packets (including setting fault
conditions and arbitrary GPS time or coordinates) and properly escapes
the embedded DLEs. The actual string that is sent is displayed in Hex
at the bottom of the screen.
(Warning: It is work in progress, so not all menu selections actually
work)
On Tue, Mar 25, 2014 at 7:11 PM, d0ct0r wrote:
Much thanks Tom and Mike ! I missed that point. In another word,
T-Bolt sending DLE data "wrapped" by another byte ! Now I know !
On 2014-03-25 19:55, mike cook wrote:
Le 25 mars 2014 à 22:43, d0ct0r a écrit :
Today I spent good part of my time to figure out that my version of
Thunderbolt has some issue with the TSIP protocol definition. I am
using following document: "ThunderBolt GPS Disciplined Clock User
Guide, Version 5.0, Part Number: 35326-30, November 2003"
In that particular PDF file, there is definition for 0x8F-AB TSIP
packet [section A.10.30 Report Packet 0x8F-AB Primary Timing
Packet].
Here is the structure of 8F-AB, translated to plain C-code:
typedef struct tb_8f_ab {
uint8_t sub; //0 : 1
uint32_t tow; //1-4 : 4
uint16_t wn; //5-6 : 2
int16_t ls; //7-8 : 2
uint8_t tflag; //9 : 1
uint8_t sec; //10 : 1
uint8_t min; //11 : 1
uint8_t hr; //12 : 1
uint8_t day; //13 : 1
uint8_t month; //14 : 1
uint16_t year; //15-16 : 2
} mytb_8f_ab;
Here is the dump I get from my MCU:
//0x10 0x8F 0xAB 0x0 0x3 0x92 0x88 0x6 0xF9 0x0 0x10 0x10 0x3 0x2C
0x1 0x11 0x19 0x3 0x7 0xDE 0x10 0x3
//0x10 0x8F 0xAB 0x0 0x3 0xCC 0x16 0x6 0xF9 0x0 0x10 0x10 0x3 0x12
0x7 0x15 0x19 0x3 0x7 0xDE 0x10 0x3
how are you dumping this?
you have an imbedded (stuffed)DLE, which is sent as DLE/DLE but the
second is to be ignored.
Which is conform to TSIP standard packet definition:
TSIP packet structure is the same for both commands and reports.
The
packet format is:
Where:
* is the byte 0x10
* is the byte 0x03
* is a packet identifier byte, which can have any value
excepting
and .
Ex: In the tsip developer tool kit , from TsipParser.c
case TSIP_IN_PARTIAL:
// The parser is in this state if a previous character was
// a part of the TSIP data. As noted above, a DLE character
// can be a part of the TSIP data in which case another DLE
// character is present in the data stream. So, here we look
// at the next character in the stream (currently loaded in
// ucByte). If it is a DLE character, we just encountered
// a stuffed DLE byte. In that case, we ignore this byte
// and go back to the TSIP_DLE state. That way, we will log
// only one DLE byte which was a part of the TSIP data.
//
// All other non-DLE characters are placed in the TSIP packet
// buffere.
if (ucByte == DLE)
{
nParseState = TSIP_DLE;
}
else
{
ucPkt[nPktLen++] = ucByte;
}
break;
However, its appeared that my T-Bolt throwing one "extra" byte for
the so-called "Timing Flags".
There is 19 bytes coming from my T-Bolt, instead of expected 18. I
found that actual length of TFLAG is 16 bit - not 8. Interesting
enough, that Lady Heather works perfectly fine with that T-Bolt !
Can somebody confirm that there is different version of T-Bolt on
the market ? If so, where I nee
Re: [time-nuts] RC TIC linearity correction?
Thanks Charles. That makes sense, but at the expense of adding unwanted complexity. As I've been moving the setpoint around this morning, I think I see a way to characterize what it's doing. Maybe I can come up with a small correction table or formula that's good enough for my purposes. Bob > > From: Charles Steinmetz >To: Discussion of precise time and frequency measurement >Sent: Wednesday, March 26, 2014 12:27 AM >Subject: Re: [time-nuts] RC TIC linearity correction? > > >Bob wrote: > >>I hadn't given any thought to correcting the linearity of the TIC I >>built, but my PLL plots tell me I should do it now. > >You are using a resistor to charge the integrating capacitance, so it >charges with the classic exponential curve and you get a nonlinear >time-to-voltage conversion. You need to charge the integrating >capacitance with a constant current if you want a linear >time-to-voltage function. The current source will probably need to >be connected to a supply that is higher than 5v, because it needs >some headroom. > >There may be secondary errors, as well, due to the leakage of the >tri-state buffers in their hi-Z state and/or nonlinearity in the >ADC's internal capacitors. Often you can improve things by using >sufficient external capacitance to swamp the ADC's internal >capacitance and increasing the charging current. > >Best regards, > >Charles > > ___ 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] RC TIC linearity correction?
I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. One method would be to calibrate with a series of buckets that you fill by sampling a random source, the more samples in a bucket the more range in phase for that bucket. For example 1 1 1 2 2 2 3 2 2 1 0 samples sum equal 17 so each unit equal 17/(total range of TIC) and the bucket with 3 samples would be 3 * 17/(total range of TIC). Stanley ___ 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] TSIP protocol for T-Bolt
hi all, as is my commentent to /tvb's question. Hope it helps, Götz Tom, i've found 3 pdf Thunderbolt-Manuals identified as: -V3 from 2000 -V3 from 2003 and -V1 from 2012 Differences are in the Report Packet 0x8F-AC Data Format pp A62,A62 and 81. If you compare, there are differences among Byte 1 (Receiver Mode) Bits 5 and6, Byte 13 (Disciplining Activity) Bits 8 and 9 Bytes 8,9 (Critical Alarms) Bits 1,2,3 Bytes 10,11 (Minor Alarms) Bits 9 and 11 (and yes, Bit 11 is set from my Tbolt (Firmware V3.00) if I remember correctly). Use of Bit 10 (EEPROM invalid) is not decribed. I have not it tested though :-) A rather reliable reference are Messages from Thunderbolt Monitor V2.60. regards Götz Am 26.03.2014 15:05, : but beware, no single document related to Thunderbolt from Trimbles website is complete nor fully correct. Can you give me an example of some TBolt command that is not in the TBolt document? As a reference you may use my code of a simple Tbolt-Monitor you will here: http://www.romahn.info/tbolt2lcd/ regards Götz Nice. Thanks for posting that. Thanks, /tvb ___ 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] RC TIC linearity correction?
On Wed, Mar 26, 2014 at 8:41 AM, Bob Stewart wrote: > Thanks Charles. That makes sense, but at the expense of adding unwanted > complexity. As I've been moving the setpoint around this morning, I think > I see a way to characterize what it's doing. Maybe I can come up with a > small correction table or formula that's good enough for my purposes. > Yes a lookup table would be easy. But how to create the table? I've been thinking about a way to do self calibration. The controller purposely runs the DAC and of course the OCXO through some range and watches the phase. This gives you a rough DAC vs. Phase function. Re-running the calibration could make up for some component aging. It would take some time (hours) to wait for everything to warm up and then you'd have to move the EFV voltage slowly -- Chris Albertson Redondo Beach, California ___ 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] RC TIC linearity correction?
If I were to try to do this automatically, I think I'd move the PLL set point in "n" steps from near the bottom to near the top and look at the width of the PPS signal at each step; perhaps using the bucket scheme that Stanley mentioned and using some count per bucket to decide "how wide is wide". I don't have any sort of phase wrapping code, though, so I have to be careful how close to a phase point I get. Bob > > From: Chris Albertson >To: Bob Stewart ; Discussion of precise time and frequency >measurement >Sent: Wednesday, March 26, 2014 11:25 AM >Subject: Re: [time-nuts] RC TIC linearity correction? > > > > > > > > >On Wed, Mar 26, 2014 at 8:41 AM, Bob Stewart wrote: > >Thanks Charles. That makes sense, but at the expense of adding unwanted >complexity. As I've been moving the setpoint around this morning, I think I >see a way to characterize what it's doing. Maybe I can come up with a small >correction table or formula that's good enough for my purposes. >> > > >Yes a lookup table would be easy. But how to create the table? I've been >thinking about a way to do self calibration. The controller purposely runs >the DAC and of course the OCXO through some range and watches the phase. This >gives you a rough DAC vs. Phase function. Re-running the calibration could >make up for some component aging. It would take some time (hours) to wait >for everything to warm up and then you'd have to move the EFV voltage slowly > > > > > >-- > >Chris Albertson >Redondo Beach, California > > ___ 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] RC TIC linearity correction?
A random source will need a lot more samples in each bucket to reduce the noise to an acceptable level. To determine the relative bucket width with a 10% error requires at least 100 samples per bucket. For 1% error at least 10,000 samples per bucket. All thats really required is a sufficiently noisy oscillator that isn't phase locked to your clock. Bruce Stanley wrote: I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. One method would be to calibrate with a series of buckets that you fill by sampling a random source, the more samples in a bucket the more range in phase for that bucket. For example 1 1 1 2 2 2 3 2 2 1 0 samples sum equal 17 so each unit equal 17/(total range of TIC) and the bucket with 3 samples would be 3 * 17/(total range of TIC). Stanley ___ 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] TSIP protocol for T-Bolt
For those of you who collect documentation, now here are 4 versions: http://leapsecond.com/pages/tbolt/Thunderbolt-2000-09.pdf http://leapsecond.com/pages/tbolt/Thunderbolt-2003-11.pdf http://leapsecond.com/pages/tbolt/Thunderbolt-2012-02.pdf http://leapsecond.com/pages/tbolt/Thunderbolt-2012-03.pdf Web source: ThunderBolt™ GPS Disciplined Clock Manual VERSION 3.0 Part Number: 35326-30 September 2000 http://nice.kaze.com/thunderbolt_03.pdf ??? ThunderBolt™ GPS Disciplined Clock User Guide Version 5.0 Part Number: 35326-30 November 2003 http://trl.trimble.com/docushare/dsweb/Get/Document-10001/ThunderBoltBook2003.pdf Trimble® ThunderBolt® E GPS Disciplined Clock Version 1.0 Revision C Part Number 64057-00-ENG February 2012 http://trl.trimble.com/docushare/dsweb/Get/Document-388613/ThunderboltE_UG_1B.pdf Trimble® ThunderBolt® E GPS Disciplined Clock Version 1.0 Revision D Part Number 64057-00-ENG March 2012 http://trl.trimble.com/dscgi/ds.py/Get/File-601842/ThunderboltE_UG_1D.pdf If you have a copy of yet another version, or official Trimble URL, please let Götz or I know. Thanks, /tvb ___ 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] GPSDO simulation tool
On 24/03/14 07:12, Hal Murray wrote: mag...@rubidium.dyndns.org said: I did a temporary hack on the PID code to convert the D-term into I^2 term, by integrating the integrator output. First attempt was indeed quite resonant just to show that I was in the unsafe region. Backing down on the strength of the component sure did remove much of the resonance, but I did not see any appreciable improvement in filtering performance, so quick and dirty hacking isn't sufficient, darn. Maybe it isn't sufficient to make a great GPSDO, but it's more than sufficient to point out the advantages of Tom's simulation setup. Thanks Tom. Did some home-work on third-degree PLL parameters, so now I know why I failed, as I never tried to do it right. One thing that Tom's simulator isn't doing is calculating the parameters for the PID for you, or backwards what characteristics you will get. Cheers, Magnus ___ 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] TSIP protocol for T-Bolt
Tom, You are missing the 2002 version I have on my web site :) I already had the 2003, I will add the others Thanks for the links Didier KO4BB On Wed, Mar 26, 2014 at 2:31 PM, Tom Van Baak wrote: > For those of you who collect documentation, now here are 4 versions: > > http://leapsecond.com/pages/tbolt/Thunderbolt-2000-09.pdf > http://leapsecond.com/pages/tbolt/Thunderbolt-2003-11.pdf > http://leapsecond.com/pages/tbolt/Thunderbolt-2012-02.pdf > http://leapsecond.com/pages/tbolt/Thunderbolt-2012-03.pdf > > Web source: > > ThunderBolt(tm) GPS Disciplined Clock Manual > VERSION 3.0 Part Number: 35326-30 September 2000 > http://nice.kaze.com/thunderbolt_03.pdf ??? > > ThunderBolt(tm) GPS Disciplined Clock User Guide > Version 5.0 Part Number: 35326-30 November 2003 > > http://trl.trimble.com/docushare/dsweb/Get/Document-10001/ThunderBoltBook2003.pdf > > Trimble(R) ThunderBolt(R) E GPS Disciplined Clock > Version 1.0 Revision C Part Number 64057-00-ENG February 2012 > > http://trl.trimble.com/docushare/dsweb/Get/Document-388613/ThunderboltE_UG_1B.pdf > > > > Trimble(R) ThunderBolt(R) E GPS Disciplined Clock > Version 1.0 Revision D Part Number 64057-00-ENG March 2012 > http://trl.trimble.com/dscgi/ds.py/Get/File-601842/ThunderboltE_UG_1D.pdf > > > If you have a copy of yet another version, or official Trimble URL, please > let Götz or I know. > > Thanks, > /tvb > > > ___ > 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.
Re: [time-nuts] GPSDO simulation tool
> Did some home-work on third-degree PLL parameters, so now I know why I > failed, as I never tried to do it right. > > One thing that Tom's simulator isn't doing is calculating the parameters > for the PID for you, or backwards what characteristics you will get. > > Cheers, > Magnus Magnus, et al, Still hoping some of you process control & PID experts will contribute a couple lines of C code to the simulator. The gpsim1 ver=N parameter will select any one of many different algorithms. I believe no one algorithm is "correct"; the goal is simply to include as many as you can contribute so we can all play with them. /tvb ___ 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] RC TIC linearity correction?
Hi Having done this - it gets really boring to sit there for 10,000 seconds and collect data. Best to automate the process. In reality you want to run three groups of 10,000 samples and see how they relate to each other. With some approaches you can find some disturbing things going on. Bob On Mar 26, 2014, at 1:22 PM, Bruce Griffiths wrote: > A random source will need a lot more samples in each bucket to reduce the > noise to an acceptable level. > To determine the relative bucket width with a 10% error requires at least 100 > samples per bucket. > For 1% error at least 10,000 samples per bucket. > > All thats really required is a sufficiently noisy oscillator that isn't phase > locked to your clock. > > Bruce > > Stanley wrote: >> I hadn't given any thought to correcting the linearity of the TIC I built, but my PLL plots tell me I should do it now. >>> >> One method would be to calibrate with a series of buckets that you fill by >> sampling a random source, the more samples in a bucket the more range in >> phase for that bucket. For example 1 1 1 2 2 2 3 2 2 1 0 samples sum equal >> 17 so each unit equal 17/(total range of TIC) and the bucket with 3 samples >> would be 3 * 17/(total range of TIC). >> >> Stanley > > ___ > 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.
Re: [time-nuts] Hanging bridge question
Hi HP = Hewlett Packard Bob On Mar 26, 2014, at 10:31 AM, Matthew Martin wrote: > Hi, > > Just a quick question from a novice. Sometimes I see abbreviations here and > don't know, but usually I > can make a good guess. Your first paragraph, "HP" is perhaps high precision? > Just want to make sure > I am not missing some other meaning. > > Thanks, learning a lot from reading this group! > > Matt Martin > > > On Wed, 3/26/14, Bob Camp wrote: > > Subject: Re: [time-nuts] Hanging bridge question > To: "Discussion of precise time and frequency measurement" > > Date: Wednesday, March 26, 2014, 4:45 AM > > Hi > > Take a look at the PIC-TIC stuff. They have the HP circuit > in the middle of it. Bob Stewart posted a circuit with a > pair of tri-state gates in it within the last month or so. > > They all pretty much: > > 1) Measure the “coarse time” with a counter Today > that’s just about always a counter in an MCU. > 2) Based on the clock to the counter (say 25 ns), you have a > roundoff / truncation error. (say 0 to 25 ns) > 3) You use a gate or two and your capture flip flop to > convert the truncation to a pulse. (normally 25 to 50 ns) > 4) You pick an R/C time constant to be “useful” (say 50 > ns, could be less). > 5) You charge the RC with the pulse > 6) After the pulse is done, you open circuit the R/C so > charge / discharge stops. > 7) When you get around to it, you measure the voltage on the > cap with an ADC > > Starting from the 50 ns example, an 8 bit converter likely > gives you 500 ps resolution. 10 bits gets you to 250 ps and > 12 bits to 125 ps. More bits or a faster clock would do even > better. > > Since the R/C charge voltage vs time is pretty well known, > you can do the first part of the math fairly easily. > > You have a clock and flip flops are pretty cheap. If you > want to shoot cal pulses at it, send it a 25 and 50 ns wide > pules. The delta between the two should be pretty good. If > you have the range, go to 75 ns and get 3 points to fit. > > The basic R/C is about 5 cents. The one tri-state gate you > need is about 16 cents. A quad nand is about the same these > days. You already need a pair of flip flops to capture the > pps edge (two to a package …). If you want to do the whole > calibration thing, one of Bert’s $2 CPLD’s has way more > parts in it than you will ever need. > > The ADC can be what you get with your MCU. In that case 12 > bits may be stretching it. There are very nice 12 bit parts > from TI that run about $3 or so. 16 bits is still under $10. > > > Bob > > > > > On Mar 25, 2014, at 11:08 PM, Jim Miller > wrote: > >> Bob >> >> I'm not sure who you're responding to but I have a > couple of questions: >> >> TDC = Time Delay Correlator? >> >> Could you point me to one of these 50 cent threads? > I've read a ton of this >> list from 2007 forward but must have missed that. >> >> Thanks >> >> jim ab3cv (much to learn) >> >> Hi >> >> There have been multiple posts about analog TDC's of > various designs >> that get you into the sub 100 ps range without costing > very much >> money. I believe the cheapest posted so far adds < > 50 cents to a basic >> PIC based design. >> >> Bob >> ___ >> 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.
Re: [time-nuts] Beaglebone NTP server
Hi Gabs, I have a Z3805A and a Beaglebone, and would like to set up an NTP server for the lab. Any kernel drivers and/or setup hints would be appreciated :) Cheers, Henry On Thu, Jun 20, 2013 at 7:37 PM, Gabs Ricalde wrote: > On Thu, Jun 20, 2013 at 3:39 AM, Chris Howard wrote: >> >> Are you using the original BeagleBone or the new BeagleBone Black? >> > I'm using the original BeagleBone. it should work on the BeagleBone Black. > >> Will you have any details available about what parts are needed to set it up? >> > If your GPS receiver is using 3.3V logic, wiring it up is > straightforward, similar to the Raspberry Pi NTP server. I will probably > setup a page describing this. > ___ > 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.
Re: [time-nuts] Beaglebone NTP server
Hi The quick / dirty / easy way for any of the NTP stuff with a GPSDO is to simply run the PPS in. PPS into serial is one way, pps into a GPIO is another way. Bob On Mar 26, 2014, at 5:51 PM, Henry Hallam wrote: > Hi Gabs, > > I have a Z3805A and a Beaglebone, and would like to set up an NTP > server for the lab. Any kernel drivers and/or setup hints would be > appreciated :) > > Cheers, > Henry > > On Thu, Jun 20, 2013 at 7:37 PM, Gabs Ricalde wrote: >> On Thu, Jun 20, 2013 at 3:39 AM, Chris Howard wrote: >>> >>> Are you using the original BeagleBone or the new BeagleBone Black? >>> >> I'm using the original BeagleBone. it should work on the BeagleBone Black. >> >>> Will you have any details available about what parts are needed to set it >>> up? >>> >> If your GPS receiver is using 3.3V logic, wiring it up is >> straightforward, similar to the Raspberry Pi NTP server. I will probably >> setup a page describing this. >> ___ >> 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.
Re: [time-nuts] Hanging bridge question
Bob, Thanks. That was too obvious, but having not looked at HP's similar circuits I ruled it out. Many thanks. Still lots to learn here….. Matt On Wed, 3/26/14, Bob Camp wrote: Subject: Re: [time-nuts] Hanging bridge question To: "Discussion of precise time and frequency measurement" Date: Wednesday, March 26, 2014, 2:47 PM Hi HP = Hewlett Packard Bob On Mar 26, 2014, at 10:31 AM, Matthew Martin wrote: > Hi, > > Just a quick question from a novice. Sometimes I see abbreviations here and don't know, but usually I > can make a good guess. Your first paragraph, "HP" is perhaps high precision? Just want to make sure > I am not missing some other meaning. > > Thanks, learning a lot from reading this group! > > Matt Martin > > > On Wed, 3/26/14, Bob Camp wrote: > > Subject: Re: [time-nuts] Hanging bridge question > To: "Discussion of precise time and frequency measurement" > Date: Wednesday, March 26, 2014, 4:45 AM > > Hi > > Take a look at the PIC-TIC stuff. They have the HP circuit > in the middle of it. Bob Stewart posted a circuit with a > pair of tri-state gates in it within the last month or so. > > They all pretty much: > > 1) Measure the “coarse time” with a counter Today > that’s just about always a counter in an MCU. > 2) Based on the clock to the counter (say 25 ns), you have a > roundoff / truncation error. (say 0 to 25 ns) > 3) You use a gate or two and your capture flip flop to > convert the truncation to a pulse. (normally 25 to 50 ns) > 4) You pick an R/C time constant to be “useful” (say 50 > ns, could be less). > 5) You charge the RC with the pulse > 6) After the pulse is done, you open circuit the R/C so > charge / discharge stops. > 7) When you get around to it, you measure the voltage on the > cap with an ADC > > Starting from the 50 ns example, an 8 bit converter likely > gives you 500 ps resolution. 10 bits gets you to 250 ps and > 12 bits to 125 ps. More bits or a faster clock would do even > better. > > Since the R/C charge voltage vs time is pretty well known, > you can do the first part of the math fairly easily. > > You have a clock and flip flops are pretty cheap. If you > want to shoot cal pulses at it, send it a 25 and 50 ns wide > pules. The delta between the two should be pretty good. If > you have the range, go to 75 ns and get 3 points to fit. > > The basic R/C is about 5 cents. The one tri-state gate you > need is about 16 cents. A quad nand is about the same these > days. You already need a pair of flip flops to capture the > pps edge (two to a package …). If you want to do the whole > calibration thing, one of Bert’s $2 CPLD’s has way more > parts in it than you will ever need. > > The ADC can be what you get with your MCU. In that case 12 > bits may be stretching it. There are very nice 12 bit parts > from TI that run about $3 or so. 16 bits is still under $10. > > > Bob > > > > > On Mar 25, 2014, at 11:08 PM, Jim Miller > wrote: > >> Bob >> >> I'm not sure who you're responding to but I have a > couple of questions: >> >> TDC = Time Delay Correlator? >> >> Could you point me to one of these 50 cent threads? > I've read a ton of this >> list from 2007 forward but must have missed that. >> >> Thanks >> >> jim ab3cv (much to learn) >> >> Hi >> >> There have been multiple posts about analog TDC's of > various designs >> that get you into the sub 100 ps range without costing > very much >> money. I believe the cheapest posted so far adds < > 50 cents to a basic >> PIC based design. >> >> Bob >> ___ >> 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. ___ 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] Beaglebone NTP server
On Wed, Mar 26, 2014 at 4:51 PM, Henry Hallam wrote: > Hi Gabs, > > I have a Z3805A and a Beaglebone, and would like to set up an NTP > server for the lab. Any kernel drivers and/or setup hints would be > appreciated :) > Actually, I was thinking of doing exactly the same thing. I am interested in any answers for this too. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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] TSIP protocol for T-Bolt
Thanks to today's contributions from Götz, Hal, Nigel, and Didier we now have all(?) 7 versions: http://www.leapsecond.com/pages/tbolt/manual.htm /tvb - Original Message - From: Didier Juges To: Tom Van Baak ; Discussion of precise time and frequency measurement Sent: Wednesday, March 26, 2014 2:01 PM Subject: Re: [time-nuts] TSIP protocol for T-Bolt Tom, You are missing the 2002 version I have on my web site :) I already had the 2003, I will add the others Thanks for the links Didier KO4BB ___ 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] GPSDO simulation tool
In message <514d.5090...@rubidium.dyndns.org>, Magnus Danielson writes: >Did some home-work on third-degree PLL parameters, so now I know why I >failed, as I never tried to do it right. Once you get to third-order PLLs you need to start paying serious attention to rounding errors. In most cases using a "double" floating point format will do, but you have to make sure you don't loose precision to normalisation in your additions. I've had varying degress of success myself, and overall I'm not sure it really makes sense to fight the battles, unless you need really long hold-over times. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Beaglebone NTP server
On Wed, Mar 26, 2014 at 5:05 PM, Bob Camp wrote: > Hi > > The quick / dirty / easy way for any of the NTP stuff with a GPSDO is to > simply run the PPS in. PPS into serial is one way, pps into a GPIO is > another way. > Well, yeah. I figured that I would run the 1pps from my T-bolt to a GPIO line with appropriate clamping to 3.3V. But if anyone has done this before and run into anything of note, that would be nice to know ahead of time. -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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] GPSDO simulation tool
Hi 64 bit int’s with 128 bit intermediate results can do a pretty good job for most of this. Bob On Mar 26, 2014, at 6:47 PM, Poul-Henning Kamp wrote: > In message <514d.5090...@rubidium.dyndns.org>, Magnus Danielson writes: > >> Did some home-work on third-degree PLL parameters, so now I know why I >> failed, as I never tried to do it right. > > Once you get to third-order PLLs you need to start paying serious > attention to rounding errors. > > In most cases using a "double" floating point format will do, but you > have to make sure you don't loose precision to normalisation in > your additions. > > I've had varying degress of success myself, and overall I'm not > sure it really makes sense to fight the battles, unless you need > really long hold-over times. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > 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.
Re: [time-nuts] Beaglebone NTP server
Hi With a GPIO pulse width should not be an issue. With RS-232 you might have needed a pulse stretcher. Bob On Mar 26, 2014, at 7:18 PM, Brian Lloyd wrote: > On Wed, Mar 26, 2014 at 5:05 PM, Bob Camp wrote: > >> Hi >> >> The quick / dirty / easy way for any of the NTP stuff with a GPSDO is to >> simply run the PPS in. PPS into serial is one way, pps into a GPIO is >> another way. >> > > Well, yeah. I figured that I would run the 1pps from my T-bolt to a GPIO > line with appropriate clamping to 3.3V. > > But if anyone has done this before and run into anything of note, that > would be nice to know ahead of time. > > -- > Brian Lloyd, WB6RQN/J79BPL > 706 Flightline Drive > Spring Branch, TX 78070 > br...@lloyd.com > +1.916.877.5067 > ___ > 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.
Re: [time-nuts] Beaglebone NTP server
On Wed, Mar 26, 2014 at 2:51 PM, Henry Hallam wrote: > Hi Gabs, > > I have a Z3805A and a Beaglebone, and would like to set up an NTP > server for the lab. Any kernel drivers and/or setup hints would be > appreciated :) > > It's best to go in steps. Resist the temptation to simply connect everything, turn it on and see it is works. The first step is to get NTP installed and running using Internet pool servers for reference clocks. Make sure this is working reliably. NTP may already be mostly configured. I don't know. Next make sure the kernel level PPS diver is working. To test PPS there is a user-land test program you can run that simply prints the time of each pulse to the console. Besure to watch both the voltage levels (the Beagle is 3.3 volts) and the polarity of the pulse. If you get the polarity wrong it will appear t work but the timing will lag by the pulse width (because the falling edge is now the raising edge.) Be sure and match up the levels for both serial and PPS. After both of the above, adding a GPS based reference clock to NTP is easy. All you do is edit the config file. Obviously I've left out much detail but the biggest thing is to follow the step by step process -- Chris Albertson Redondo Beach, California ___ 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] RC TIC linearity correction?
I finally got my PLL running today, and I think I can manage with just a small table of 10 values to be used as the width of my PPS jitter corrector. That takes care of it for this project, but obviously not for the general case. Bob > > From: Chris Albertson >To: Bob Stewart ; Discussion of precise time and frequency >measurement >Sent: Wednesday, March 26, 2014 11:25 AM >Subject: Re: [time-nuts] RC TIC linearity correction? > > > >Yes a lookup table would be easy. But how to create the table? I've been >thinking about a way to do self calibration. The controller purposely runs >the DAC and of course the OCXO through some range and watches the phase. This >gives you a rough DAC vs. Phase function. Re-running the calibration could >make up for some component aging. It would take some time (hours) to wait >for everything to warm up and then you'd have to move the EFV voltage slowly > > > > ___ 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] Beaglebone NTP server
On Wed, 26 Mar 2014 17:40:07 -0700 Chris Albertson wrote: > On Wed, Mar 26, 2014 at 2:51 PM, Henry Hallam > wrote: > > > Hi Gabs, > > > > I have a Z3805A and a Beaglebone, and would like to set up an NTP > > server for the lab. Any kernel drivers and/or setup hints would be > > appreciated :) > > > > It's best to go in steps. Resist the temptation to simply connect > everything, turn it on and see it is works. > > The first step is to get NTP installed and running using Internet pool > servers for reference clocks. Make sure this is working reliably. > NTP may already be mostly configured. I don't know. > > Next make sure the kernel level PPS diver is working. To test PPS > there is a user-land test program you can run that simply prints the > time of each pulse to the console. Besure to watch both the voltage > levels (the Beagle is 3.3 volts) and the polarity of the pulse. If > you get the polarity wrong it will appear t work but the timing will > lag by the pulse width (because the falling edge is now the raising > edge.) Be sure and match up the levels for both serial and PPS. > > After both of the above, adding a GPS based reference clock to NTP is > easy. All you do is edit the config file. Obviously I've left out > much detail but the biggest thing is to follow the step by step > process Job number one on the Beaglebone Black (and I assume the regular version) is to install NTP. Otherwise it doesn't even know the date. It has no battery for RTC. Beyond that, I haven't found a very clear way to get the gpio-pps going. ___ 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] Beaglebone NTP server
On Wed, Mar 26, 2014 at 7:17 PM, Bob Camp > wrote: > Hi > > With a GPIO pulse width should not be an issue. With RS-232 you might have > needed a pulse stretcher. > That is what I was thinking as well. Any suggestions on software issues in getting this running? -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 -- Brian Lloyd, WB6RQN/J79BPL 706 Flightline Drive Spring Branch, TX 78070 br...@lloyd.com +1.916.877.5067 ___ 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] Beaglebone NTP server
On Wed, Mar 26, 2014 at 5:51 PM, Henry Hallam wrote: > I have a Z3805A and a Beaglebone, and would like to set up an NTP > server for the lab. > Here's an example for the Black. I believe the same ideas apply to the Beaglebone (White). http://the8thlayerof.net/2013/12/08/adafruit-ultimate-gps-cape-creating-custom-beaglebone-black-device-tree-overlay-file/ I prefer the Beaglebone to the Pi because of the silly USB glitch but out of three BBBs only one will run for more than a month without wedging. This may be because I run Debian but as with the Pi USB bug it's not much comfort when the box fails. The Pi I use as an NTP server ran for 4 months and developed a filesystem error. It's been up two months post-repair. If I depended on a server built around a dev board I'd be careful to make the SDcard/eMMC read-only and build more than one. ___ 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] Beaglebone NTP server
Much appreciated. I have that GPS. It didn't occur to me to build my own cape. Had I known, I would have ordered that board had I seen this webspage. I can probably cut some out of perf board. On Wed, 26 Mar 2014 21:37:43 -0400 Paul wrote: > On Wed, Mar 26, 2014 at 5:51 PM, Henry Hallam > wrote: > > > I have a Z3805A and a Beaglebone, and would like to set up an NTP > > server for the lab. > > > > Here's an example for the Black. I believe the same ideas apply to > the Beaglebone (White). > > http://the8thlayerof.net/2013/12/08/adafruit-ultimate-gps-cape-creating-custom-beaglebone-black-device-tree-overlay-file/ > > I prefer the Beaglebone to the Pi because of the silly USB glitch but > out of three BBBs only one will run for more than a month without > wedging. This may be because I run Debian but as with the Pi USB bug > it's not much comfort when the box fails. The Pi I use as an NTP > server ran for 4 months and developed a filesystem error. It's been > up two months post-repair. If I depended on a server built around a > dev board I'd be careful to make the SDcard/eMMC read-only and build > more than one. ___ > 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.
