[time-nuts] Oncore question
Hi Fellow Nuts, I've been following the thread on parsing the Motorola receiver code with great interest. I have written AVR code to do this but have not gone to great trouble making it bullet proof as it was a non critical application in a Nixie clock. I programmed the receiver to send only one message, and then looked for the @@Ba string before I started counting bytes. I used the number of SVs byte to decide whether the data was good. Worked fine for me! I'm about to start another project with an Oncore so maybe I'll experiment with a more complex program this time. My question relates to the older Oncore VP receivers. I have one which had a dead memory battery. The receiver has an on-board battery charger for a rechargable Li cell but they are very hard to find down here. In the past I've used a conventional Li cell with a schottky diode to prevent the charger from forcing current down it's throat. I was wondering if there's any reason not to use a super cap. I only need it to support the memory for very short periods during power burps. Will the on-board charger be OK for a 1F super cap? Any help or opinons much appreciated Thanks, Morris ___ 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] The Trimble NTPX26AB-06 / Z3801A
> On the Z3801a, if you want to use the 1-PPS or 10MHz signals that are > on the DB-25 you will need to convert the PECL outputs. If you are willing to lift a pin and cut a trace, you can get the PPS on RS-232 without any external level conversion. The fine print is in here: http://support.ntp.org/bin/view/Support/Z3801AReceiverModifications I used a non-standard pin on the DB-25 in order to avoid cutting a trace, but I was building my own 25 to 9 pin adapter so that was easy fix. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] M12+T more confusion
> I hear SiRF's ZDA message is supposed to be sync'd with the top of the > second. The manual says something like that. I've been searching for inexpensive GPS units that work well with ntp. The SiRF sets are inexpensive, but the timing on their NMEA messages sucks. There is a lot of jitter and wander. By wander I mean offset that changes slowly so you can't filter it out, hanging bridges. http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif They also have a leap second bug that makes the answer off by a second some of the time in some strange pattern over a week. I assume that's what caused it. It was working OK until the GPS satellites started announcing the next leap second. http://www.megapathdsl.net/~hmurray/ntp/leap-gps2.gif (I'll bet there is a good story behind that one.) The NMEA driver in ntpd defaults to expecting RMC, so that's what I normally use. A while ago, somebody mentioned that ZDA should be better, so I tried it. I couldn't see any difference. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] TBolt in the house -- MSFT mouse bug
On Nov 21, 2008, at 4:00 AM, [EMAIL PROTECTED] wrote: > Message: 2 > Date: Fri, 21 Nov 2008 01:25:38 -0500 > From: Norman J McSweyn <[EMAIL PROTECTED]> > Subject: Re: [time-nuts] TBolt in the house! > To: Discussion of precise time and frequency measurement > > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Give this a try! > http://www.synergy-gps.com/images/stories/ShopTalk/disabling% > 20detection%20of%20microsoft%20ballpoint%20mouse.pdf > The serial mouse issue drove me nuts for a while. > Norm Norm, You Da Man!!! The regedit did the trick. Thanks also to Randy at Synergy, and Big Thanks to that unnamed customer who figured it out. Boy, was I tired of having to constantly disable that BallPoint driver. Just another reason to love time-nuts. Dick ___ 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] M12+T more confusion
Chris Kuethe wrote: > On Fri, Nov 21, 2008 at 3:06 PM, Tom Van Baak <[EMAIL PROTECTED]> wrote: >> You are enabling output messages, right? Sounds like the >> order in which you individually *enable* one or more messages >> is unrelated to the order in which, once a second(*), all selected >> messages are *output*. I've never confirmed if they are output >> alphabetically or by size or priority or what. Does someone know >> for sure? Or does it matter? > > i've not seen a gps yet that doesn't act like there's a big, > fixed-order list against which the enabled output messages are checked > once per reporting cycle. it's not impossible to dynamically schedule > a specific order of messages at a certain rate by building an array of > function calls, but that sounds like more work... the first way can be > done with a single char comparison per message. Chris, I'm not much of a programmer **YET**. The approach you suggest is one that I would need to take if I was creating a bulletproof app. Using the simple method that I've employed definitely isn't. Don't get much time to play with this stuff. When I do, I try to get something to work. It's like anything else. The more you play with it, the less intimidating and more familiar it is, hence, more comfortable. > > some messages are certainly more expensive to generate (GSV vs GLL) > and are probably less interesting - so long has there is a good fix > and a navigation solution the average user probably won't care too > much about satellite locations. And the fix data will be more relevant > if you can output location immediately after it's calculated, rather > than delaying it 200ms for a satellite status report. Some receivers > do have certain message types triggered at set time - I hear SiRF's > ZDA message is supposed to be sync'd with the top of the second. > > ___ 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] Wavetek 3010
On Nov 21, 2008, at 12:42 PM, [EMAIL PROTECTED] wrote: > Message: 2 > Date: Sat, 22 Nov 2008 01:21:16 +1300 > From: "Steve Rooke" <[EMAIL PROTECTED]> > Subject: [time-nuts] Off-Topic: On Wavetek 3010 lever thumbwheel > switchesand manual > To: "Discussion of precise time and frequency measurement" > > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > snip > I've also trawled the Net to find a freely downloadable manual (user > and servicing) but to no avail. If anyone has a copy or could point me > in the right direction, I would be most grateful. > > 73, Steve > -- > Steve Rooke - ZL3TUV & G8KVD > Omnium finis imminet > Steve, I've got a Wavetek 3001/3002 manual that may get you near to where you need to go. Contact me at richiem at hughes.net, and let me know if that's something you can use. I'd be happy to loan it to you for copying. Best, Dick Moore ___ 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] M12+T more confusion
Tom Van Baak wrote: >> Gentlemen: >> Why would the M12+T swap the order of messages? >> >> I write @@Hn and @@Eq in that order to the board and it gives it back to >> me in reverse order. > > What parameter(s) are you passing the @@Hn and @@Eq > and how quickly are you sending them? Page 31 talks about > this. Tom, Each message is written so as to get the board to output once per second. The program is structured such that it writes once, then drops down and loops , reading the buffer (I've disabled the termination character) when XX bytes have accumulated. > >> Tried @@Cf then resending the messages. Still the same. Then did it AND >> swapped the order of the messages. Still the same. > > You are enabling output messages, right? Sounds like the > order in which you individually *enable* one or more messages > is unrelated to the order in which, once a second(*), all selected > messages are *output*. I've never confirmed if they are output > alphabetically or by size or priority or what. Does someone know > for sure? Or does it matter? I'm suspecting this is the case. Need to power off the board to confirm that there's nothing being stored Just did that. Then reset the board with @@Cf. Then wrote @@Hn and @@Ha to the board in that order. Came back @@Ha then @@ Hn. If I use @@Hn and @@Eq (ascii position/time message) the same behaviour exists. > >> The manual says it's first in, first out regarding the serial buffer. > > Right, but the commands you are sending are merely enabling > commands. Send as many as you want in any order. You don't > see responses until the top of the next second. Just a guess, > though, since my M12+T is not available to confirm this. > I've played with an 8051. Do know a little about micros. Love trying to guess what's going on inside the little black box. >> I'm using Labview 8. >> >> Norm n3ykf > > > > ___ > 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] M12+T more confusion
On Fri, Nov 21, 2008 at 3:06 PM, Tom Van Baak <[EMAIL PROTECTED]> wrote: > You are enabling output messages, right? Sounds like the > order in which you individually *enable* one or more messages > is unrelated to the order in which, once a second(*), all selected > messages are *output*. I've never confirmed if they are output > alphabetically or by size or priority or what. Does someone know > for sure? Or does it matter? i've not seen a gps yet that doesn't act like there's a big, fixed-order list against which the enabled output messages are checked once per reporting cycle. it's not impossible to dynamically schedule a specific order of messages at a certain rate by building an array of function calls, but that sounds like more work... the first way can be done with a single char comparison per message. some messages are certainly more expensive to generate (GSV vs GLL) and are probably less interesting - so long has there is a good fix and a navigation solution the average user probably won't care too much about satellite locations. And the fix data will be more relevant if you can output location immediately after it's calculated, rather than delaying it 200ms for a satellite status report. Some receivers do have certain message types triggered at set time - I hear SiRF's ZDA message is supposed to be sync'd with the top of the second. -- GDB has a 'break' feature; why doesn't it have 'fix' too? ___ 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] M12+T more confusion
> Gentlemen: > Why would the M12+T swap the order of messages? > > I write @@Hn and @@Eq in that order to the board and it gives it back to > me in reverse order. What parameter(s) are you passing the @@Hn and @@Eq and how quickly are you sending them? Page 31 talks about this. > Tried @@Cf then resending the messages. Still the same. Then did it AND > swapped the order of the messages. Still the same. You are enabling output messages, right? Sounds like the order in which you individually *enable* one or more messages is unrelated to the order in which, once a second(*), all selected messages are *output*. I've never confirmed if they are output alphabetically or by size or priority or what. Does someone know for sure? Or does it matter? > The manual says it's first in, first out regarding the serial buffer. Right, but the commands you are sending are merely enabling commands. Send as many as you want in any order. You don't see responses until the top of the next second. Just a guess, though, since my M12+T is not available to confirm this. > > I'm using Labview 8. > > Norm n3ykf ___ 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] M12+T more confusion
Hi Norman: Can you save the LV program to run with version 7 and email it program to me? Have Fun, Brooke Clarke http://www.prc68.com Norman J McSweyn wrote: > Matt Osborn wrote: >> I'm not a Labview expert, but I've seen Labview do that with messages >> from other devices. Labview (or more likely, its programmer) has >> issues dealing with threading issues. >> >> On Fri, 21 Nov 2008 00:58:36 -0500, Norman J McSweyn >> <[EMAIL PROTECTED]> wrote: >> >>> Gentlemen: >>> Why would the M12+T swap the order of messages? >>> >>> I write @@Hn and @@Eq in that order to the board and it gives it back to >>> me in reverse order. >>> >>> Tried @@Cf then resending the messages. Still the same. Then did it AND >>> swapped the order of the messages. Still the same. >>> >>> The manual says it's first in, first out regarding the serial buffer. >>> >>> I'm using Labview 8. >>> >>> Norm n3ykf >>> >>> >>> ___ >>> 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. >> -- kc0ukk at msosborn dot com >> >> ___ >> 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. >> > Matt, > Could be a loose nut issue. However, using different messages as a test > reveals that "first in first out" in different circumstances is the > behaviour. > > The first part of this .vi just writes a string to the device. > The second reads the buffer (and loops). > After reading the buffer, I flush it. Just to make sure that I will get > a clean read next iteration. > > Any pointers to troubleshooting will be greatly appreciated. > > Why would threading have anything to do with it? > > Just for giggles, I'll try not closing the Visa session until the .vi > completes. > 73 de Norm n3ykf > > ___ > 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] To improve a Tbolt?
> What power supply did the TAPR Thunderbolt use? The green, orange, and red traces used the supply module that came with the TAPR order. You can see the characteristic hump around 3 kHz that appears in many of Tom's plots with this supply as well. The blue trace was the old-style packaged Thunderbolt with the integrated switching supply. > Have you considered using a variant of the Wenzel supply filters to > cleanup the spurs in the 1-10kHz region. It couldn't hurt. However, I don't tend to take spurs below -120 dBc very seriously, because they can come from so many different sources outside my control. The HP 3048A system components were scattered all over the room at the time these graphs were taken, and I had a strong cellular/pager transmitter on the building immediately next door. In any event the 3048A's own spur-level specification is about -115 dBc. I try not to lose sleep over low-level spurs unless/until they interfere with an actual application, then I look into the specific one(s) that are causing trouble. Sloppy, perhaps, but ars longa, vita brevis and all that good stuff... > This is trivial with the low current -12V supply but would require some > design effort for the +12V and +5V supplies. > Using a more modern opamp (simplifies biasing) to augment the > performance of such a filter for the higher current supplies would be > worthwhile. > Even dropping the spur level by 20dB is probably worthwhile. I think the best way to deal with wideband noise and spurs is at the architectural level. Wall off the GPS clock and its supplies entirely, and use its 10 MHz output to phase lock the clock you're actually using to drive critical stuff. That clock would be fed with a clean supply and tightly integrated with its application, as opposed to mounted 20 feet away on another rack. With that philosophy, the GPS clock's performance at 10 Hz and below is worth sweating out, but phase noise and spurs at wider offsets may not be. -- john, KE5FX ___ 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] M12+T more confusion
Matt Osborn wrote: > I'm not a Labview expert, but I've seen Labview do that with messages > from other devices. Labview (or more likely, its programmer) has > issues dealing with threading issues. > > On Fri, 21 Nov 2008 00:58:36 -0500, Norman J McSweyn > <[EMAIL PROTECTED]> wrote: > >> Gentlemen: >> Why would the M12+T swap the order of messages? >> >> I write @@Hn and @@Eq in that order to the board and it gives it back to >> me in reverse order. >> >> Tried @@Cf then resending the messages. Still the same. Then did it AND >> swapped the order of the messages. Still the same. >> >> The manual says it's first in, first out regarding the serial buffer. >> >> I'm using Labview 8. >> >> Norm n3ykf >> >> >> ___ >> 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. > > -- kc0ukk at msosborn dot com > > ___ > 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. > Matt, Could be a loose nut issue. However, using different messages as a test reveals that "first in first out" in different circumstances is the behaviour. The first part of this .vi just writes a string to the device. The second reads the buffer (and loops). After reading the buffer, I flush it. Just to make sure that I will get a clean read next iteration. Any pointers to troubleshooting will be greatly appreciated. Why would threading have anything to do with it? Just for giggles, I'll try not closing the Visa session until the .vi completes. 73 de Norm n3ykf ___ 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] To improve a Tbolt?
John Miles wrote: > I've upgraded the graph on the http://www.ke5fx.com/tbolt.htm page to show > the performance of my Thunderbolt from the TAPR group buy (in orange) next > to the traces for my older unit before and after the 10811 upgrade. > > There is no upside to tinkering with the OCXO on the TAPR units, unless you > have something that can beat a 10811. You could replace it with a rubidium > source and get better short-term stability, but I don't think swapping one > quartz OCXO for another would be a useful thing to do. > > -- john, KE5FX > John What power supply did the TAPR Thunderbolt use? Have you considered using a variant of the Wenzel supply filters to cleanup the spurs in the 1-10kHz region. This is trivial with the low current -12V supply but would require some design effort for the +12V and +5V supplies. Using a more modern opamp (simplifies biasing) to augment the performance of such a filter for the higher current supplies would be worthwhile. Even dropping the spur level by 20dB is probably worthwhile. Bruce ___ 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] To improve a Tbolt?
> On your rubidium comment, one needs to be a little careful about > expectations. For short tau (say 0.1 to 10 seconds) your average > cheap eBay surplus telecom Rb will have far less performance > than a good OCXO. Yet mid-term (say 10 to 10^4 seconds), a > Rb-GPSDO will win. However, long-term the LO makes much less > difference since GPS always wins. And GPS aside, clearly the > holdover performance of Rb will blow away OCXO. > Good point, there's a big piece of the curve where simply upgrading a quartz-based GPS standard to drive an Rb would not be a win. Two pieces, actually, since Efratom (at least) doesn't seem to care much about phase noise. > So it all depends on ones need. I guess my main point is that a > typical rubidium-based TBolt is not necessarily, just because it's > "atomic", automatically better than a stock TBolt at every point. > > If you'd like to test an FRS or LPRO version of a TBolt for me let > me know. I'd rather see your plots than my words. I could graft a rubidium source onto the original Thunderbolt platform I used for the OCXO tests, but I currently don't have a good way to look at Allan deviation compared to the TSC/maser setup you've got. I can measure the phase noise easily enough but it'd be better to get it back to you for longer-term tests, especially if the loop parameters need to be adjusted iteratively. That would be a heat-death-of-the-Universe process on a 3048A... -- john, KE5FX ___ 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] M12+T more confusion
I'm not a Labview expert, but I've seen Labview do that with messages from other devices. Labview (or more likely, its programmer) has issues dealing with threading issues. On Fri, 21 Nov 2008 00:58:36 -0500, Norman J McSweyn <[EMAIL PROTECTED]> wrote: >Gentlemen: >Why would the M12+T swap the order of messages? > >I write @@Hn and @@Eq in that order to the board and it gives it back to > me in reverse order. > >Tried @@Cf then resending the messages. Still the same. Then did it AND >swapped the order of the messages. Still the same. > >The manual says it's first in, first out regarding the serial buffer. > >I'm using Labview 8. > >Norm n3ykf > > >___ >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. -- kc0ukk at msosborn dot com ___ 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] The Trimble NTPX26AB-06 / Z3801A
On the Z3801a, if you want to use the 1-PPS or 10MHz signals that are on the DB-25 you will need to convert the PECL outputs. I build a little converter based on the on-semi MC100ELT23 dual PECL to TTL translator. I also built a simple RS422 to RS232 converter using a DS275 and 75179 All of these were done on 16SOIC surfboards that fit inside a DB25-DB25 shell. I wanted to keep my z3801a boxes completely unmodified. Scott Roy Phillips wrote: > Dear Members > > I have the Trimble NTPX26AB-06 and I have established that the I/O port (25 > way D connector) has the same pin-outs as the Z3801A. Can any owners/users of > these units advise me on a suitable (proved to work) interface adaptor from > the RS-422 to RS-232. The unit works fine and is producing its 10 MHz output > with very good accuracy, but I am looking forward to "seeing it" through its > interface with TBolt Mon. > Thanks > > Roy Phillips > ___ > 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] To improve a Tbolt?
I have a 10811 floating around here somewhere. What about marrying up one of your reject TAPR's to it ? 73, Dick, W1KSZ -Original Message- >From: Tom Van Baak <[EMAIL PROTECTED]> >Sent: Nov 21, 2008 2:33 PM >To: Discussion of precise time and frequency measurement >Subject: Re: [time-nuts] To improve a Tbolt? > >> I've upgraded the graph on the http://www.ke5fx.com/tbolt.htm page to show >> the performance of my Thunderbolt from the TAPR group buy (in orange) next >> to the traces for my older unit before and after the 10811 upgrade. >> >> There is no upside to tinkering with the OCXO on the TAPR units, unless you >> have something that can beat a 10811. You could replace it with a rubidium >> source and get better short-term stability, but I don't think swapping one >> quartz OCXO for another would be a useful thing to do. >> >> -- john, KE5FX > >Hi John, > >Very nice work and I mostly agree with your conclusions. The >OCXO inside the TAPR TBolts is really quite good. And those >that aren't that good are not sent to TAPR for sale (my pile of >TBolt rejects is growing; more on that later). > >So, yes, the typical TBolt OCXO is in the same ballpark as many >10811, which is why replacing one with the other may be futile. > >A problem here is that 10811 are all over the map. There are >variants of 10811; and even those with the same part number or >part number suffix will vary. Some 10811 get way down in the >-13's and are thus much better than any TBolt I've seen (which >is also one reason that some HP 58503* or Z38* series GPSDO >command such a price). Also, some 10811 have much better >phase noise specs than other. Some people are after better PN >rather than better ADEV. > >So if you have the ability to measure each 10811, or measure >an assortment of good OCXO, clearly you can pick a superior >one and thus improve your TBolt performance. > >On your rubidium comment, one needs to be a little careful about >expectations. For short tau (say 0.1 to 10 seconds) your average >cheap eBay surplus telecom Rb will have far less performance >than a good OCXO. Yet mid-term (say 10 to 10^4 seconds), a >Rb-GPSDO will win. However, long-term the LO makes much less >difference since GPS always wins. And GPS aside, clearly the >holdover performance of Rb will blow away OCXO. > >So it all depends on ones need. I guess my main point is that a >typical rubidium-based TBolt is not necessarily, just because it's >"atomic", automatically better than a stock TBolt at every point. > >If you'd like to test an FRS or LPRO version of a TBolt for me let >me know. I'd rather see your plots than my words. > >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] To improve a Tbolt?
> I've upgraded the graph on the http://www.ke5fx.com/tbolt.htm page to show > the performance of my Thunderbolt from the TAPR group buy (in orange) next > to the traces for my older unit before and after the 10811 upgrade. > > There is no upside to tinkering with the OCXO on the TAPR units, unless you > have something that can beat a 10811. You could replace it with a rubidium > source and get better short-term stability, but I don't think swapping one > quartz OCXO for another would be a useful thing to do. > > -- john, KE5FX Hi John, Very nice work and I mostly agree with your conclusions. The OCXO inside the TAPR TBolts is really quite good. And those that aren't that good are not sent to TAPR for sale (my pile of TBolt rejects is growing; more on that later). So, yes, the typical TBolt OCXO is in the same ballpark as many 10811, which is why replacing one with the other may be futile. A problem here is that 10811 are all over the map. There are variants of 10811; and even those with the same part number or part number suffix will vary. Some 10811 get way down in the -13's and are thus much better than any TBolt I've seen (which is also one reason that some HP 58503* or Z38* series GPSDO command such a price). Also, some 10811 have much better phase noise specs than other. Some people are after better PN rather than better ADEV. So if you have the ability to measure each 10811, or measure an assortment of good OCXO, clearly you can pick a superior one and thus improve your TBolt performance. On your rubidium comment, one needs to be a little careful about expectations. For short tau (say 0.1 to 10 seconds) your average cheap eBay surplus telecom Rb will have far less performance than a good OCXO. Yet mid-term (say 10 to 10^4 seconds), a Rb-GPSDO will win. However, long-term the LO makes much less difference since GPS always wins. And GPS aside, clearly the holdover performance of Rb will blow away OCXO. So it all depends on ones need. I guess my main point is that a typical rubidium-based TBolt is not necessarily, just because it's "atomic", automatically better than a stock TBolt at every point. If you'd like to test an FRS or LPRO version of a TBolt for me let me know. I'd rather see your plots than my words. 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] The Trimble NTPX26AB-06 / Z3801A
> I have the Trimble NTPX26AB-06 and I have established that the I/O > port (25 way D connector) has the same pin-outs as the Z3801A. Can any > owners/users of these units advise me on a suitable (proved to work) > interface adaptor from the RS-422 to RS-232. The unit works fine and > is producing its 10 MHz output with very good accuracy, but I am > looking forward to "seeing it" through its interface with TBolt Mon. The Z3801A has both RS-422 and RS-232 level conversion chips inside. What gets routed to to the connector is determined by either some jumpers on a header or some zero ohm resistors. So it's easy to modify the unit to directly speak RS-232. I don't know what's in the NTPX26AB, but looking to see if there is an RS-232 chip seems like a good excuse to open it up and look around. :) (If you haven't done it already.) If you want to build an external converter box, I have schematics I found on the web many years ago. They use LTC1318 or MAX3162. I'm sure there are many other chips, but those are probably a reasonable place to start. -- These are my opinions, not necessarily my employer's. I hate spam. ___ 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] To improve a Tbolt?
John Miles wrote: > I've upgraded the graph on the http://www.ke5fx.com/tbolt.htm page to show > the performance of my Thunderbolt from the TAPR group buy (in orange) next > to the traces for my older unit before and after the 10811 upgrade. > Thanks John, it looks like the Tapr ones have a very good oven fitted already, and thus I will leave well alone. There must be something else I can use the 10811 for :^) Dan ___ 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] To improve a Tbolt?
I've upgraded the graph on the http://www.ke5fx.com/tbolt.htm page to show the performance of my Thunderbolt from the TAPR group buy (in orange) next to the traces for my older unit before and after the 10811 upgrade. There is no upside to tinkering with the OCXO on the TAPR units, unless you have something that can beat a 10811. You could replace it with a rubidium source and get better short-term stability, but I don't think swapping one quartz OCXO for another would be a useful thing to do. -- john, KE5FX > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Ulrich Bangert > Sent: Friday, November 21, 2008 2:58 AM > To: Time nuts > Subject: Re: [time-nuts] To improve a Tbolt? > > > I would be interested in this information as well! > > Best regards > Ulrich Bangert > > > -Ursprungliche Nachricht- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag von Dan Rae > > Gesendet: Donnerstag, 20. November 2008 18:58 > > An: time-nuts@febo.com > > Betreff: [time-nuts] To improve a Tbolt? > > > > > > I have been reading with interest John Miles' page about his Tbolt > > 'upgrade'. > > > http://www.thegleam.com/ke5fx/tbolt.htm > > I have a newly acquired Tbolt here, and also have lying around an almost > > identical 10811-60111 OCXO which I am considering using with it, exactly > > as John describes. However my Tbolt is of a later vintage than John's > (2005 date code) and I wonder if that would show as big an improvement > as John reports. The on board OCXO on this one has a Trimble sticker on > > it, but otherwise looks similar to the one pictured on John's page. The > > GPS receiver area of my board also looks very different, but I don't > think this would have any effect. > > Not having the sort of phase noise measuring facilities here to be able > to test it, I am wondering if anyone else has done this with a similar > vintage Tbolt, and could say if it is likely to show as big an > improvement as John seems to be getting. > > I was a little surprised at the amount of short term variation, of the > order of minutes duration, that I was seeing on another Tbolt when using > > it to set a Rb standard. > > The obvious answer to my question is to try it and see, but I'd > appreciate hearing from anyone who has tried it! > > Dan > > ___ 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] Do any regulations or laws require time tobeaccurate within 'x' seconds?
http://www.nerc.com/files/BAL-005-0.pdf http://www.nerc.com/files/BAL-005-1.pdf It would appear these documents are just talking about annual calibration requirements of the *transducer* (the control room test equipment used to measure line frequency) and do not imply a specification of line frequency itself. Does anyone know which NERC document specifies power line phase or frequency? (and note that a frequency measurement implies an averaging time). See http://leapsecond.com/pages/mains/ for the ADEV of power line frequency. It's ~2e-5 at one day. So does NERC owe me a million bucks or not? /tvb - Original Message - From: "Bill Hawkins" <[EMAIL PROTECTED]> To: "'Discussion of precise time and frequency measurement'" Sent: Friday, November 21, 2008 12:16 PM Subject: Re: [time-nuts] Do any regulations or laws require time tobeaccurate within 'x' seconds? > That's an interesting reference. Google finds it. > > Assuming that the digital frequency transducer measures the 60 Hz line > frequency, the required accuracy is somewhat less than 2 parts in 10E-5. > > Analog transducers, like Watts, Volts, and VARs, require 0.25% of scale > accuracy. Calibration is annual. > > This is nothing like the 10E-15 sought by time nuts. > > Bill Hawkins > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mike Clapp > Sent: Friday, November 21, 2008 1:04 PM > To: Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Do any regulations or laws require time to > beaccurate within 'x' seconds? > > The North American Electric Reliability Corporation (NERC) under federal > law can fine of up to $1 million a day. > > Standard BAL-005-0 - Automatic Generation Control Requirement 17. Each > Balancing Authority shall at least annually check and calibrate its time > error and frequency devices against a common reference. The Balancing > Authority shall adhere to the minimum values for measuring devices as > listed below: > > Device Accuracy > > Digital frequency transducer ? 0.001 Hz ___ 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] Do any regulations or laws require time to beaccurate within 'x' seconds?
That's an interesting reference. Google finds it. Assuming that the digital frequency transducer measures the 60 Hz line frequency, the required accuracy is somewhat less than 2 parts in 10E-5. Analog transducers, like Watts, Volts, and VARs, require 0.25% of scale accuracy. Calibration is annual. This is nothing like the 10E-15 sought by time nuts. Bill Hawkins -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Clapp Sent: Friday, November 21, 2008 1:04 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Do any regulations or laws require time to beaccurate within 'x' seconds? The North American Electric Reliability Corporation (NERC) under federal law can fine of up to $1 million a day. Standard BAL-005-0 - Automatic Generation Control Requirement 17. Each Balancing Authority shall at least annually check and calibrate its time error and frequency devices against a common reference. The Balancing Authority shall adhere to the minimum values for measuring devices as listed below: Device Accuracy Digital frequency transducer ? 0.001 Hz ___ 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] Do any regulations or laws require time to be accurate within 'x' seconds?
The North American Electric Reliability Corporation (NERC) under federal law can fine of up to $1 million a day. Standard BAL-005-0 ― Automatic Generation Control Requirement 17. Each Balancing Authority shall at least annually check and calibrate its time error and frequency devices against a common reference. The Balancing Authority shall adhere to the minimum values for measuring devices as listed below: Device Accuracy Digital frequency transducer ≤ 0.001 Hz ___ 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] Finding a good antenna location?
Hello, Alan. Friday, November 21, 2008, 18:11:47, you wrote: A> I recently picked up a Thunderbolt on eBay. For the present, I will be A> using it with the antenna inside, and have been experimenting with various A> window locations for the best signals. Even small changes in position make A> a significant difference in the individual satellite signals, though A> fortunately there are several locations which are qualitatively good in A> terms of the number with acceptable signal strengths. A> My question is whether there is a general "goodness of reception" parameter, A> or process, which would allow me to at least semi-quantitatively find the A> "best" antenna location? The constant motion of the satellites seems to A> preclude the normal "tune for maximum" approach. A> Apologies if I missed this, and thanks for the great info I did find in the A> archives. A> Alan A> WA4SCA Rule of thumb for GPS antenna location - more unobstructed sky view is better. Less reflective objects around antenna is better. Sometimes nearby transmiting antennas may represent problem, if there is oxidized compression joints that may act as "frequency multiplier" (non-linearity). Height is not so critical, unobstructed sky view is much more important... -- Best regards, Yuri UA3ATQ/KI7XJmailto:[EMAIL PROTECTED] ___ 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] Finding a good antenna location?
I recently picked up a Thunderbolt on eBay. For the present, I will be using it with the antenna inside, and have been experimenting with various window locations for the best signals. Even small changes in position make a significant difference in the individual satellite signals, though fortunately there are several locations which are qualitatively good in terms of the number with acceptable signal strengths. My question is whether there is a general "goodness of reception" parameter, or process, which would allow me to at least semi-quantitatively find the "best" antenna location? The constant motion of the satellites seems to preclude the normal "tune for maximum" approach. Apologies if I missed this, and thanks for the great info I did find in the archives. Alan WA4SCA ___ 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] Fwd: M12+T ASCII interface - I'm confused?
Hi, Thanks all - I think I've got a pretty good grasp of the protocol now. Ulrich thanks for the rule set. I'm quite sure the remaining issues are just us speaking past one another. Maybe the [time-nuts] could get a white board for block diagrams? :) One more thing: The M12+ automatically throws out faulty messages - does it remove those messages from the input buffer to make space for valid ones? Or, are the faulty messages kept in the buffer but not processed? The reason I'm asking: If the former is true I will be able to have the M12+ share the RX part of the RS232 link with another device. Messages destined for the other device will be discarded. Same goes for the other device. If the latter is true the M12+ buffer would probably always be full with garbage destined for the other device. Does anyone know the answer to this? Regards, Stephan On 21/11/2008, Ulrich Bangert <[EMAIL PROTECTED]> wrote: > > Stephan, > > for me the following rules have turned to be optimal for M12+ decoding: > > 1) Program the M12+ to auto-send all information that you are interested > in at a one second update rate. > > 2) During serial reception do nothing else than to put the received data > into a buffer of sufficient length. > > 3) Wait for the PPS to appear. After the positive slope of the PPS you > can be sure that EVERYTHING that relates to the second which's start is > indicated by the PPS is in your buffer. > > 4) Start a counter that addresses bytes in your buffer and search for > "@@". Don't look for "@@", that would make it necessary that the > end of the messages of the LAST second is still in the buffer in order > to detect the first first new packet, what you do not want. Note: Since > you will reset the pointer that indicates where in the buffer the next > received byte will be written to the start of the buffer after having > decoded all packets it is very likely that your buffer starts with "@@" > and no lengthy search is necessary. > > 5) If a "@@" is detected read the next two charcters and using a table > decide whether they make a correct packet header and find out the length > of the according packet. > > 6) Use the packet length information to find out whether the > sequence is to be found at a matching location of your buffer. If that > is the case then perform the crc calculation. If this is ok too you have > found a valid packet and may decode it's contents. > > 7) Set your "@@" search counter to the end of this packet and goto 4) > > 8) Repeat this until all packets of interest have been found or until > you have reached the end of your buffer. > > 9) Reset the pointer which indicates where the next received byte shall > be written in the buffer to the start of the buffer. Also important: Set > all bytes in your buffer to an known initial state, otherwise artefacs > of the LAST transmission could pretend a succesfull reception for the > current second. Then goto 3) > > For the whole action you have abt. 30 ms time (an eternity for today > technology) because abt. 30 ms after the positive slope of the PPS the > M12+ starts to transmit packets belonging to the NEXT PPS. If one of the > conditions for a valid packet is NOT given simply disregard it and > increment the counter until the next "@@". > > In my GPSDO I use a log mechanism that logs errors in packet detection & > decoding. Sometimes there ARE errors. It does not need a pulled cable or > a direct lighning stroke. Any sufficient big spike on your power lines > will do. For that reason you should not rely on the idea that the serial > reception is practically error-free. However, errors of that kind are > very seldom. For me they appear once every few months. > > Best regards > Ulrich > > > > -Ursprungliche Nachricht- > > Von: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Im Auftrag von Stephan Sandenbergh > > > Gesendet: Donnerstag, 20. November 2008 16:17 > > An: Discussion of precise time and frequency measurement > > Betreff: [time-nuts] Fwd: M12+T ASCII interface - I'm confused? > > > > > > > Hi, > > > > Now I'm slightly confused: > > > > > > > > > My gut tells me that <@><@> would be > > believable > > > > more than say 95% (if not 99%) of the time. I've got the > > following > > > > observations: > > > > In the above I assumed no data length checking is employed. > > > > > > > > > > - 95% is a bad number in accurate timing applications. > > > > > > You misunderstand. You can get as close to 100% as you > > > want. Some of us have logged data from M12+ receivers without error > > > for weeks or months -- gigabytes, error-free. > > > > Sure, I assume you refer to the case when you check the data > > length as well? I meant that the <@><@> > > byte string could also potentially exist in the data itself, > > but only in very rare cases (from there the 95% thumb suck). > > > > > > > > > - the checksum is one of the few things that are easy to > > do in VHDL. > > > > > > > > - one would always miss the first most data strea
[time-nuts] Off-Topic: On Wavetek 3010 lever thumbwheel switches and manual
I have bought one of these but all (yes ALL) the frequency selection lever thumbwheel switches are broken. I've been looking around for them but with no luck as yet. Ideally I'd like to pick up used to save money but I'll look at anything. They are labeld L20-36AD, L20-37AD and L20-17AJ and the unit uses various quantities of each to form a switch bank. Can anyone let me know if they can be obtained somewhere or substituted with another more available type? I've also trawled the Net to find a freely downloadable manual (user and servicing) but to no avail. If anyone has a copy or could point me in the right direction, I would be most grateful. 73, Steve -- Steve Rooke - ZL3TUV & G8KVD Omnium finis imminet ___ 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] Lucent Rb/GPS
Gentlemen Is there a member out there that recognizes the LUCENT unit that is currently being offered. This is the dual RTFG-m-RB and RTFG-m-XO. The only number that appears is L105B. This appears to be part of an AT&T system. The question is - - can the interface software be obtained easily ? Any other information on this item would be useful to know. Roy ___ 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] The Trimble NTPX26AB-06 / Z3801A
Dear Members I have the Trimble NTPX26AB-06 and I have established that the I/O port (25 way D connector) has the same pin-outs as the Z3801A. Can any owners/users of these units advise me on a suitable (proved to work) interface adaptor from the RS-422 to RS-232. The unit works fine and is producing its 10 MHz output with very good accuracy, but I am looking forward to "seeing it" through its interface with TBolt Mon. Thanks Roy Phillips ___ 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] To improve a Tbolt?
I would be interested in this information as well! Best regards Ulrich Bangert > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Dan Rae > Gesendet: Donnerstag, 20. November 2008 18:58 > An: time-nuts@febo.com > Betreff: [time-nuts] To improve a Tbolt? > > > I have been reading with interest John Miles' page about his Tbolt > 'upgrade'. > http://www.thegleam.com/ke5fx/tbolt.htm I have a newly acquired Tbolt here, and also have lying around an almost identical 10811-60111 OCXO which I am considering using with it, exactly as John describes. However my Tbolt is of a later vintage than John's (2005 date code) and I wonder if that would show as big an improvement as John reports. The on board OCXO on this one has a Trimble sticker on it, but otherwise looks similar to the one pictured on John's page. The GPS receiver area of my board also looks very different, but I don't think this would have any effect. Not having the sort of phase noise measuring facilities here to be able to test it, I am wondering if anyone else has done this with a similar vintage Tbolt, and could say if it is likely to show as big an improvement as John seems to be getting. I was a little surprised at the amount of short term variation, of the order of minutes duration, that I was seeing on another Tbolt when using it to set a Rb standard. The obvious answer to my question is to try it and see, but I'd appreciate hearing from anyone who has tried it! Dan ___ 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] Fwd: M12+T ASCII interface - I'm confused?
Stephan, for me the following rules have turned to be optimal for M12+ decoding: 1) Program the M12+ to auto-send all information that you are interested in at a one second update rate. 2) During serial reception do nothing else than to put the received data into a buffer of sufficient length. 3) Wait for the PPS to appear. After the positive slope of the PPS you can be sure that EVERYTHING that relates to the second which's start is indicated by the PPS is in your buffer. 4) Start a counter that addresses bytes in your buffer and search for "@@". Don't look for "@@", that would make it necessary that the end of the messages of the LAST second is still in the buffer in order to detect the first first new packet, what you do not want. Note: Since you will reset the pointer that indicates where in the buffer the next received byte will be written to the start of the buffer after having decoded all packets it is very likely that your buffer starts with "@@" and no lengthy search is necessary. 5) If a "@@" is detected read the next two charcters and using a table decide whether they make a correct packet header and find out the length of the according packet. 6) Use the packet length information to find out whether the sequence is to be found at a matching location of your buffer. If that is the case then perform the crc calculation. If this is ok too you have found a valid packet and may decode it's contents. 7) Set your "@@" search counter to the end of this packet and goto 4) 8) Repeat this until all packets of interest have been found or until you have reached the end of your buffer. 9) Reset the pointer which indicates where the next received byte shall be written in the buffer to the start of the buffer. Also important: Set all bytes in your buffer to an known initial state, otherwise artefacs of the LAST transmission could pretend a succesfull reception for the current second. Then goto 3) For the whole action you have abt. 30 ms time (an eternity for today technology) because abt. 30 ms after the positive slope of the PPS the M12+ starts to transmit packets belonging to the NEXT PPS. If one of the conditions for a valid packet is NOT given simply disregard it and increment the counter until the next "@@". In my GPSDO I use a log mechanism that logs errors in packet detection & decoding. Sometimes there ARE errors. It does not need a pulled cable or a direct lighning stroke. Any sufficient big spike on your power lines will do. For that reason you should not rely on the idea that the serial reception is practically error-free. However, errors of that kind are very seldom. For me they appear once every few months. Best regards Ulrich > -Ursprungliche Nachricht- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Stephan Sandenbergh > Gesendet: Donnerstag, 20. November 2008 16:17 > An: Discussion of precise time and frequency measurement > Betreff: [time-nuts] Fwd: M12+T ASCII interface - I'm confused? > > > Hi, > > Now I'm slightly confused: > > > > > > My gut tells me that <@><@> would be > believable > > > more than say 95% (if not 99%) of the time. I've got the > following > > > observations: > > In the above I assumed no data length checking is employed. > > > > > > > - 95% is a bad number in accurate timing applications. > > > > You misunderstand. You can get as close to 100% as you > > want. Some of us have logged data from M12+ receivers without error > > for weeks or months -- gigabytes, error-free. > > Sure, I assume you refer to the case when you check the data > length as well? I meant that the <@><@> > byte string could also potentially exist in the data itself, > but only in very rare cases (from there the 95% thumb suck). > > > > > > - the checksum is one of the few things that are easy to > do in VHDL. > > > > > > - one would always miss the first most data stream at > startup (not a > > > problem). > > > > Correct, not a problem. Note NMEA, TSIP, and any other > > GPS protocol has the same feature, right? > > > > > - the last message in the data stream will always only be > decoded on > > > the next second when the new streams are coming through > (a potential > > > problem) > > > > Not true. You can process the entire message as soon as > > the checksum matches. Do you see why? > > > > If you're brave you can process the message, byte by byte, field by > > field, as it arrives in real time and use the checksum as a commit. > > Again, the checksum could be part of the data string - so > without checking the data length you'll be waiting for the @@ > (less probable to exist in data). > > > > > > Thus, I agree: The only real reliable way is to have a lookup of > > > header bytes and data length. Disappointing protocol I must add. > > > > Stephan > > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/tim
