[time-nuts] Symmetricom TymServe 2100-GPS currently fails with GPS offset
Hi! It seems that there's serious bug in Symmetricom Tymserve 2100 most recent firmware (V4.1). When leap second pending flag was added to GPS transmission (according to data shown by Lady Heather) the Tymserve's time started to be exactly 1 second late from UTC! Currently it claims that current UTC offset is 17 seconds, while Lady Heather shows 16 seconds. Also if I compare the NTP time with another NTP servers it is really 1 seconds late. Playing with telnet: ? utcoffset GPS -- UTC Offset = 17 (And of course there's no way to set this manually) However in the utcinfo data the dTLs value received from GPS is correct (16) but it seems that Tymserver firmware uses wrong value dTLsf, which is the future value of UTC offset after leap second event: ? utcinfo A0:0.000 A1:0.000 dTLs:16 ToT:61440.000 WNt:1829 WNLsf:1851 DN:3 dTLsf:17 It seems that there's no way to fix this. There's also leap second command available, having no efffect on this. Everyone who owns this device please check what's going on with it... To me this is somehow suprising, assumed this to be professional grade, reliable and trouble free instrument, but obviously it's not. No wonder why these are sold so cheap on Ebay (where I got mine). Maybe only way is to run this with 1PPS from Thunderbolt until the leap second period is over. -- 73s! Esa OH4KJU ___ 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] FYI: 2x HP-5370B in San Diego area on GovernmentLiquidation.com
Stumbled on these a day ago, and for logistics reasons it makes no sense for me to bid on them. There may be those of you in southern CA (San Diego area) that may wish to do so however, and 5370Bs are popular on the list so I thought I would mention it. They appear to be in decent physical condition. http://www.govliquidation.com/auction/view?auctionId=8924630 This message requires no reply -I know nothing about these units or the procurement process through governmentliquidation.com, etc. It's just a 'hey, in case you're interested' message. It would be better that these get snapped up by someone who will use them than they go to scrap. ___ 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] R: Re: Racal Dana 1992 universal counter
I have an NI GPIB board ( $ 29.00 on Ebay ) with an ISA connector. The computer I use has Win 98SE with one ISA and several PCI. NI has two short programs ( ULI and Ibconf ) that will allow QB45 to interface with the ISA board. I have interfaced with several instruments with no trouble ( HP 3325A, HP 3478A, Fluke 6080A/AN and Wayne Kerr PSG2400L ) . I capture the amplitude and phase of an HP 8405A with an RS232 DI-194S A/D. All work great with QB45. -Original Message- From: Bryan _ Sent: Thursday, January 22, 2015 8:00 PM To: TIme Nuts Subject: Re: [time-nuts] R: Re: Racal Dana 1992 universal counter Off topic somewhat, but an interesting project . http://www.dalton.ax/hpdisk/ -=Bryan=- Date: Thu, 22 Jan 2015 23:06:53 +0100 From: iov...@inwind.it To: time-nuts@febo.com Subject: [time-nuts] R: Re: Racal Dana 1992 universal counter I' ve used for a while a National Instruments RS232-GPIB converter with my two 1992s using the military language. I wrote my programs myself in QuickBasic under MS-DOS on a laptop. The whole thing worked quite well. Indeed I had a vague info that the counter could be switched to standard GPIB but I was never able to do the maneuver, neither did I ever have confirmation from this list that someone actually succeeded doing this. Antonio I8IOV Da: c...@omen.com Data: 22/01/2015 20.13 A: time-nuts@febo.com Ogg: Re: [time-nuts] Racal Dana 1992 universal counter I forgot to mention -- the 1992 has a jumper that selects between vanilla GPIB and a special Air Force ATE standard. Mine came with the Air Force setting. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ 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. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.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] Ublox 6T receiver, noisy PPS.
Now I suggest to wait for the next noisy event and try to force the position hold mode using the CFG-NAV5 message, dynModel= 2. Actually the UBX protocol description is not very clear about how to set (that is force) the position hold mode. The GPS has a static hold (see 2.4 page 3 of the G6-SW-10018-C manual) that says until there is evidence of movement again, so it is possible to jump out of position hold if something strange is seen by the navigation input and output filters (see 2.2 and 2.3 on page 2 and the staticHoldThresh parameter in the CFG-NAV5 message). Maybe that playing with the staticHoldThresh parameter (increasing it) can solve the issue. The default setting of the parameter is 0.00m/s (see appendix A.3 page 196). On Fri, Jan 23, 2015 at 4:10 AM, d...@irtelemetrics.com wrote: Azelio, Tom and Bob, A test with hold mode turned off was/is a good idea. I tried that for a few hours afternoon, See attached image. By eye it looks a little more erratic than the 'noisy' data, but the errors were pulling the EFC up and down a bit here too. My guess is that the wander is exaggerated a bit by the control loop. For this data the EFC moves around about two or three times worse than what HVAC cycles would do, but at noticeably shorter periods. I would tend to think the guess is correct that the GPS dropped out of position hold mode. It's very curious that is was not reported back to the u-center application upon polling the fields. It would be nice to have more GPS related data in the log file. The possibility of adding more data is not out of the realm of reason. As for Bob's suggestion to log more stuff, currently a bunch of data is being recorded. I just omitted most of it here. No reason to expose everyone to the results of data dysentery! ;) Things like OCXO oven monitor volts, OCXO case temp, system supply voltage, EFC DAC volts, room temp are being logged to uV levels every 20 seconds with a 24bit DAQ card. The GPSDO is also logging it's own on board temp sensor, phase comparisons, GPS saw tooth, UTC, and EFC DAC value, and a few other internal goodies every second. It sounds like more GPS related stuff needs to be added to this list somehow... The bottom line is, it looks like something happened to the GPS. Unless any of you have suggestions on improving the GPS configuration/settings, the plan is to continue to run as is. If anything else weird shows up at least I know what to start looking at. Thanks all, Dan OK, my opinion is that the GPS was not in position hold mode during the noisy period. Maybe due to an internal error or whatever, the GPS quitted the position hold mode. Try to add to the software the ability to log the GPS actual status so that if this error will return you are able to see what happened to the GPS. In order to confirm (or not) my opinion, you can try to run a test where the GPS operates in the standard navigation mode and see if the wander is the same as the noisy period. I echo what Azelio is saying. During the time when you are evaluating a GPS receiver it is important to collect as much data as possible, just in case you need to go back and correlate unusual events. I tend to turn on all possible binary messages and collect tens or hundreds of MB. You never know what you will uncover hidden in the data. But even collecting as little info as date, time, number of SV visible and locked, signal strengths, and solution mode (3D, 2D, 0D) once a second is a good enough summary for most purposes. I also log lat/lon/alt because if that varies then you know you're no longer in position hold mode. You can confirm Azelio's prediction below by manually forcing it to 3D for a while and see if that suddenly matches your noisy data. /tvb Hi I think I would add a few things to the logging list as well: 1) Filter state in the the controller (if it’s multi state). 2) EFC voltage, either directly with a DVM , or as a DAC setting. 3) Temperature, even as an once a minute output from a cheap USB temperature gizmo. That’s not to say that any of the above is likely to be a big issue in solving the current problem. You never know what will come up next … 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] Racal Dana 1992 universal counter
I presume this jumper is located on the separate GPIB circuit board. How is the jumper identified and what are the positions for the options? Larry On 1/22/2015 11:13 AM, Chuck Forsberg WA7KGX wrote: I forgot to mention -- the 1992 has a jumper that selects between vanilla GPIB and a special Air Force ATE standard. Mine came with the Air Force setting. -- Best wishes, Larry McDavid W6FUB Anaheim, California (SE of Los Angeles, near Disneyland) ___ 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] Ublox 6T receiver, noisy PPS.
Hi Any / all of these gizmos will go out of position hold mode if they decide that the survey position is not close enough to the current position. Who knows what the level of close enough” is used to make this decision. There are a lot of things about these devices that are poorly documented. The most common work around is to disable as many automatic features as possible. In this case that would mean turning off the self survey, feeding it a known locating, and locking it in position hold mode. In that mode, a position error will nuke the time quality metrics. When they are “bad” you set the output to turn off. That way you *know* when there is a problem. Bob On Jan 22, 2015, at 10:10 PM, d...@irtelemetrics.com wrote: Azelio, Tom and Bob, A test with hold mode turned off was/is a good idea. I tried that for a few hours afternoon, See attached image. By eye it looks a little more erratic than the 'noisy' data, but the errors were pulling the EFC up and down a bit here too. My guess is that the wander is exaggerated a bit by the control loop. For this data the EFC moves around about two or three times worse than what HVAC cycles would do, but at noticeably shorter periods. I would tend to think the guess is correct that the GPS dropped out of position hold mode. It's very curious that is was not reported back to the u-center application upon polling the fields. It would be nice to have more GPS related data in the log file. The possibility of adding more data is not out of the realm of reason. As for Bob's suggestion to log more stuff, currently a bunch of data is being recorded. I just omitted most of it here. No reason to expose everyone to the results of data dysentery! ;) Things like OCXO oven monitor volts, OCXO case temp, system supply voltage, EFC DAC volts, room temp are being logged to uV levels every 20 seconds with a 24bit DAQ card. The GPSDO is also logging it's own on board temp sensor, phase comparisons, GPS saw tooth, UTC, and EFC DAC value, and a few other internal goodies every second. It sounds like more GPS related stuff needs to be added to this list somehow... The bottom line is, it looks like something happened to the GPS. Unless any of you have suggestions on improving the GPS configuration/settings, the plan is to continue to run as is. If anything else weird shows up at least I know what to start looking at. Thanks all, Dan OK, my opinion is that the GPS was not in position hold mode during the noisy period. Maybe due to an internal error or whatever, the GPS quitted the position hold mode. Try to add to the software the ability to log the GPS actual status so that if this error will return you are able to see what happened to the GPS. In order to confirm (or not) my opinion, you can try to run a test where the GPS operates in the standard navigation mode and see if the wander is the same as the noisy period. I echo what Azelio is saying. During the time when you are evaluating a GPS receiver it is important to collect as much data as possible, just in case you need to go back and correlate unusual events. I tend to turn on all possible binary messages and collect tens or hundreds of MB. You never know what you will uncover hidden in the data. But even collecting as little info as date, time, number of SV visible and locked, signal strengths, and solution mode (3D, 2D, 0D) once a second is a good enough summary for most purposes. I also log lat/lon/alt because if that varies then you know you're no longer in position hold mode. You can confirm Azelio's prediction below by manually forcing it to 3D for a while and see if that suddenly matches your noisy data. /tvb Hi I think I would add a few things to the logging list as well: 1) Filter state in the the controller (if it’s multi state). 2) EFC voltage, either directly with a DVM , or as a DAC setting. 3) Temperature, even as an once a minute output from a cheap USB temperature gizmo. That’s not to say that any of the above is likely to be a big issue in solving the current problem. You never know what will come up next … Bob GPSPosHoldOff.jpg___ 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] Racal Dana 1992 universal counter
Chuck, I'm going to send you off list the 1992-02M manual which contains the MATE/CIIL military commands. I don't remember where I got this manual from. Anybody else interested please ask. Antonio I8IOV I take it you have documentation on the Air Force commands used with the 1992. Where did you find them? ___ 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] Racal Dana 1992 universal counter
There is a 4 pin header, SK4, on the edge of the board. The standard setting is to short the top two pins. See also https://www.febo.com/pipermail/time-nuts/2009-August/040381.html -Original Message- From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Larry McDavid Sent: Thursday, January 22, 2015 11:58 PM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Racal Dana 1992 universal counter I presume this jumper is located on the separate GPIB circuit board. How is the jumper identified and what are the positions for the options? Larry On 1/22/2015 11:13 AM, Chuck Forsberg WA7KGX wrote: I forgot to mention -- the 1992 has a jumper that selects between vanilla GPIB and a special Air Force ATE standard. Mine came with the Air Force setting. ___ 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] R: Re: Racal Dana 1992 universal counter
I take it you have documentation on the Air Force commands used with the 1992. Where did you find them? On 01/22/2015 02:06 PM, iov...@inwind.it wrote: I' ve used for a while a National Instruments RS232-GPIB converter with my two 1992s using the military language. I wrote my programs myself in QuickBasic under MS-DOS on a laptop. The whole thing worked quite well. Indeed I had a vague info that the counter could be switched to standard GPIB but I was never able to do the maneuver, neither did I ever have confirmation from this list that someone actually succeeded doing this. Antonio I8IOV Da: c...@omen.com Data: 22/01/2015 20.13 A: time-nuts@febo.com Ogg: Re: [time-nuts] Racal Dana 1992 universal counter I forgot to mention -- the 1992 has a jumper that selects between vanilla GPIB and a special Air Force ATE standard. Mine came with the Air Force setting. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ 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. -- Chuck Forsberg WA7KGX c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 ___ 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.
