Thanks to everyone for the pointers on getting my Z3801A/58503A working correctly. The pointer to the realhamradio.com really helped. I was looking for a schematic but the info on the realhamradio pages with pin outs and voltages was almost as good. I have finally decided that everything is working except the outer oven. There is no 14 volts on the heater and no current is being drawn. An curious thing is that there are 2 DC to DC converters the main power converter is 24 volts in and +12, -12, and 5 volts out and the input and output voltage is plainly marked on the side of the converter. The power supply supplied with the unit is 24 volts DC and the that converter is working fine. The second DC to DC converter is labeled UMR-5/4000-D48 which according to the data sheets that I found is a 48 volt DC in and a 5 volt DC at 4 amps out unit. I dont understand why the 2 DC to DC converters would have a different input voltage with only the 1 power supply If anyone has any thoughts about this I would like to hear about them. Again my symptoms are that the unit seems to work but it is moving all over the place and moves in and out of spec which then takes it out of lock until it comes back into spec. I have sent the vendor a request but he is in Hong Kong and I havent heard back from him yet.
Thanks, Jerry W5RCQ On Wed, Dec 1, 2010 at 1:07 AM, <time-nuts-requ...@febo.com> wrote: > Send time-nuts mailing list submissions to > time-n...@febo.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > or, via email, send a message with subject or body 'help' to > time-nuts-requ...@febo.com > > You can reach the person managing the list at > time-nuts-ow...@febo.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of time-nuts digest..." > > > Today's Topics: > > 1. Re: OT: NTP server questions (Robert Darlington) > 2. Re: OT: NTP server questions (Hal Murray) > 3. Re: OT: NTP server questions (Robert Darlington) > 4. Re: OT: NTP server questions (scmcgr...@gmail.com) > 5. Re: Z3801A/58503A Help (scmcgr...@gmail.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 30 Nov 2010 23:50:45 -0700 > From: Robert Darlington <rdarling...@gmail.com> > Subject: Re: [time-nuts] OT: NTP server questions > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Message-ID: > <aanlktinrosn_pj85zhc7h3nunom8otwf04a-vdolf...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > That won't work in my application. I can't run anything on any server but > one I provide specifically for time, which is why I'm looking at dedicated > time servers. Believe me when I say this crossed my mind and was crossed > off the list. Just about every system is MS Windows based which means > one server to sync against unless I add complexity (add NTP) and that won't > work in my application since I only control a few of the systems and we > don't want anything else running but our custom software. I can't dictate > to the other participants in the project that they run software and even if > I did they'd all end up doing it differently and I'd be back to one guy > using UTC, another TAI..... > > Guys, I appreciate the comments and now it's just a matter of deciding what > hardware to buy. I like my existing Symmetricom box but don't want to > re-purpose it for this project so it means buying a 2nd one. They're all > roughly $4k starting so it's coming down to what color I like best ;-) > > -Bob > > On Tue, Nov 30, 2010 at 11:32 PM, Chris Albertson <albertson.ch...@gmail.com >> wrote: > >> I had suggested the same thing. In fact I'd argue not having an NTP box is >> more reliable than having one. A non-esistant box can't fail. >> >> But don't run just one NTP server, run one on every non-overloaded >> server. You clients will automatically sync with whichever server >> is "best" >> >> On Tue, Nov 30, 2010 at 6:09 PM, Hal Murray <hmur...@megapathdsl.net> >> wrote: >> > >> >> > 100 systems is falling off a log. >> > >> > If you have some other server that isn't overloaded, it may be better >> overall >> > to run NTP on that system. The idea is to avoid adding another box just >> for >> > NTP. If you do something like that, you may still need a GPS unit. >> -- >> ===== >> 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. >> > > > ------------------------------ > > Message: 2 > Date: Tue, 30 Nov 2010 23:08:30 -0800 > From: Hal Murray <hmur...@megapathdsl.net> > Subject: Re: [time-nuts] OT: NTP server questions > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Message-ID: > <20101201070830.ca992800...@ip-64-139-1-69.sjc.megapath.net> > Content-Type: text/plain; charset=us-ascii > > > rdarling...@gmail.com said: >> That's exactly what we've done in the past (setting it when on the network >> and letting the clock do what it wants) and that's fine. The actual time >> isn't as important as the agreement on what time it is. This is certainly >> the cheaper way to go and is becoming a viable option. > > How long does it take for data to get from way out in the field to your > system? > > Earlier, you said that you only needed time to within a second. That's a > long time for networking. > > If it's only 100 ms (pulled out of the air) for the data to get from the > sensor to your system, then forget all the timestamps as the local system and > just use the arrival time at your system. > > If a significant part of the delay is things like RS-232 baud rates, you can > correct for that constant offset. (or semi-constant if the length of a > message varies, but maybe you can record the length of the message and do the > right correction) > > > > -- > These are my opinions, not necessarily my employer's. I hate spam. > > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 1 Dec 2010 00:34:00 -0700 > From: Robert Darlington <rdarling...@gmail.com> > Subject: Re: [time-nuts] OT: NTP server questions > To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Message-ID: > <aanlktik+8+7dwja6kiranpl6sfm_jnw3bdm8pfy=y...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > There are sometimes delays up to 30 minutes or so due to processing of > sensor data till it makes it into my system which is also way out in the > field. Imagine a shipping pallet full of equipment that gets air dropped > into the middle of nowhere. That IS my network, and it has no connection to > anything but the sensors deployed with it. Maybe on a good day I'll have a > wireless or satellite connection back to another network that may or may not > have a time server on it. I can't ever assume this will be the case. I > will, however, be rotating hard disks full of collected sensor data for > off-line analysis (forensic stuff) at a less remote location. I will have > spare parts (including NTP servers) at this location that will be visited > daily. > > I really only need time to one second. Most file systems don't have any > finer granularity and we're not making scientific measurements. We have a > system to display transient events inside of a time window that can be > arbitrarily set, but typically no wider than 15 minutes. If the data is 15 > minutes old, it's not important anymore. If the data is 40,000 years in the > future due to a bad time stamp like when it's marked in miliseconds since > the epoch (unix time) instead of seconds, we won't ever see it since it too > is outside of my window. If it's 4 seconds old, that's okay. I'll see it > inside of my time window. > > The problem with arrival times is that things I'm looking for don't happen > the instant I get alerted. I may want to go back and look at when events > happened and compare that with when I was notified so I can see where the > bottle necks are. If I have a 5 second delay and 5 seconds of clock drift > in the same direction, I don't see any bottleneck which is why I need to > know roughly what time it is at each sensor, computer, and server at least > to one second. It's rare when something I'm looking for comes directly into > one of my systems. Almost always there is some processing going on by other > teams on the project that are working independently from my team trying to > make use of some of the data in different ways. They would then generate > the alert message into my system. One of these teams that created data used > a TAI reference clock and the folks using this data used UTC (as do I) and > it really caused problems since one set of sensors is saying some event > happened at a particular time and yet, there was nothing there at that time > according to other sensors. I think in this case it was cars driving down > a street (I have no idea how they actually determine this since I just > ingest data) and another group took video data to generate tracks for > vehicles that were not there at the time the vehicle detectors said they > were. 34 second delay (TAI vs UTC) means I'm more than a half mile away > from the sensor if I'm going about 60mph. If I'm trying to predict when a > car will be near another sensor based on bad data, we'll never be looking at > the right time. > > -Bob > > On Wed, Dec 1, 2010 at 12:08 AM, Hal Murray <hmur...@megapathdsl.net> wrote: > >> >> rdarling...@gmail.com said: >> > That's exactly what we've done in the past (setting it when on the >> network >> > and letting the clock do what it wants) and that's fine. The actual time >> > isn't as important as the agreement on what time it is. This is >> certainly >> > the cheaper way to go and is becoming a viable option. >> >> How long does it take for data to get from way out in the field to your >> system? >> >> Earlier, you said that you only needed time to within a second. That's a >> long time for networking. >> >> If it's only 100 ms (pulled out of the air) for the data to get from the >> sensor to your system, then forget all the timestamps as the local system >> and >> just use the arrival time at your system. >> >> If a significant part of the delay is things like RS-232 baud rates, you >> can >> correct for that constant offset. (or semi-constant if the length of a >> message varies, but maybe you can record the length of the message and do >> the >> right correction) >> >> >> >> -- >> 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. >> > > > ------------------------------ > > Message: 4 > Date: Wed, 1 Dec 2010 07:58:18 +0000 > From: scmcgr...@gmail.com > Subject: Re: [time-nuts] OT: NTP server questions > To: "Discussion of precise time and frequency measurement" > <time-nuts@febo.com> > Message-ID: > > <781384083-1291190299-cardhu_decombobulator_blackberry.rim.net-12415173...@bda716.bisx.prod.on.blackberry> > > Content-Type: text/plain > > I think we are getting precision and accuracy confused, > > And they are quite different, In the time-nut world we use them as > synonyms, In reality its possible to have a precise measurement which is not > accurate (think instrument with bad timebase it's repeatable and reads out to > a high degree of precision but it's INACCURATE). > > We can also have a accurate measurement in with resolution in gross units > like minutes or seconds but be highly ACCURATE but have a low degree of > PRECISION. > > What's needed is ACCURATE time referenced to a external standard to within > milliseconds with a resolution of 1 second as application does not understand > any unit smaller than 1 second. > > Scott > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Robert Darlington <rdarling...@gmail.com> > Sender: time-nuts-boun...@febo.com > Date: Wed, 1 Dec 2010 00:34:00 > To: Discussion of precise time and frequency measurement<time-nuts@febo.com> > Reply-To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: Re: [time-nuts] OT: NTP server questions > > There are sometimes delays up to 30 minutes or so due to processing of > sensor data till it makes it into my system which is also way out in the > field. Imagine a shipping pallet full of equipment that gets air dropped > into the middle of nowhere. That IS my network, and it has no connection to > anything but the sensors deployed with it. Maybe on a good day I'll have a > wireless or satellite connection back to another network that may or may not > have a time server on it. I can't ever assume this will be the case. I > will, however, be rotating hard disks full of collected sensor data for > off-line analysis (forensic stuff) at a less remote location. I will have > spare parts (including NTP servers) at this location that will be visited > daily. > > I really only need time to one second. Most file systems don't have any > finer granularity and we're not making scientific measurements. We have a > system to display transient events inside of a time window that can be > arbitrarily set, but typically no wider than 15 minutes. If the data is 15 > minutes old, it's not important anymore. If the data is 40,000 years in the > future due to a bad time stamp like when it's marked in miliseconds since > the epoch (unix time) instead of seconds, we won't ever see it since it too > is outside of my window. If it's 4 seconds old, that's okay. I'll see it > inside of my time window. > > The problem with arrival times is that things I'm looking for don't happen > the instant I get alerted. I may want to go back and look at when events > happened and compare that with when I was notified so I can see where the > bottle necks are. If I have a 5 second delay and 5 seconds of clock drift > in the same direction, I don't see any bottleneck which is why I need to > know roughly what time it is at each sensor, computer, and server at least > to one second. It's rare when something I'm looking for comes directly into > one of my systems. Almost always there is some processing going on by other > teams on the project that are working independently from my team trying to > make use of some of the data in different ways. They would then generate > the alert message into my system. One of these teams that created data used > a TAI reference clock and the folks using this data used UTC (as do I) and > it really caused problems since one set of sensors is saying some event > happened at a particular time and yet, there was nothing there at that time > according to other sensors. I think in this case it was cars driving down > a street (I have no idea how they actually determine this since I just > ingest data) and another group took video data to generate tracks for > vehicles that were not there at the time the vehicle detectors said they > were. 34 second delay (TAI vs UTC) means I'm more than a half mile away > from the sensor if I'm going about 60mph. If I'm trying to predict when a > car will be near another sensor based on bad data, we'll never be looking at > the right time. > > -Bob > > On Wed, Dec 1, 2010 at 12:08 AM, Hal Murray <hmur...@megapathdsl.net> wrote: > >> >> rdarling...@gmail.com said: >> > That's exactly what we've done in the past (setting it when on the >> network >> > and letting the clock do what it wants) and that's fine. The actual time >> > isn't as important as the agreement on what time it is. This is >> certainly >> > the cheaper way to go and is becoming a viable option. >> >> How long does it take for data to get from way out in the field to your >> system? >> >> Earlier, you said that you only needed time to within a second. That's a >> long time for networking. >> >> If it's only 100 ms (pulled out of the air) for the data to get from the >> sensor to your system, then forget all the timestamps as the local system >> and >> just use the arrival time at your system. >> >> If a significant part of the delay is things like RS-232 baud rates, you >> can >> correct for that constant offset. (or semi-constant if the length of a >> message varies, but maybe you can record the length of the message and do >> the >> right correction) >> >> >> >> -- >> 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. >> > _______________________________________________ > 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. > > ------------------------------ > > Message: 5 > Date: Wed, 1 Dec 2010 08:07:34 +0000 > From: scmcgr...@gmail.com > Subject: Re: [time-nuts] Z3801A/58503A Help > To: "Discussion of precise time and frequency measurement" > <time-nuts@febo.com> > Message-ID: > > <1784409955-1291190855-cardhu_decombobulator_blackberry.rim.net-13040165...@bda716.bisx.prod.on.blackberry> > > Content-Type: text/plain > > Btw the telco 48 volt supply is in reality -48 ie positive ground system. So > be careful with grounding esp in common with other gear > > Scott > Sent from my Verizon Wireless BlackBerry > > -----Original Message----- > From: Hal Murray <hmur...@megapathdsl.net> > Sender: time-nuts-boun...@febo.com > Date: Tue, 30 Nov 2010 22:38:18 > To: Discussion of precise time and frequency measurement<time-nuts@febo.com> > Reply-To: Discussion of precise time and frequency measurement > <time-nuts@febo.com> > Subject: Re: [time-nuts] Z3801A/58503A Help > > >> I have run the Z38XX software but I dont really understand yet what the >> charts are telling me, outside of the sat signal strength and pattern. > > There is lots and lots of info on the Z3801A out on the web. (Time sink > warning.) Here is a good place to start: > http://www.realhamradio.com/GPS_Frequency_Standard.htm > > google will find lots more. > > I suggest getting a copy of the User's Guide and reading through it. Here is > one. > www.leapsecond.com/museum/z3801a/097-z3801-01-iss-1.pdf > > > >> My biggest concern is that the power supply that came with the package is 24 >> volts and the back of the box indicates that it requires a 36 to 60 volt >> power supply. > > There are two versions of the Z3801A, one for 48V and one for 24V. I assume > 48 is telco and 24 is cell phone. 48 volts from lead acid batteries is > really 54 if they are fully charged. (13.6 for your 12 V car) > > Take the cover off and look inside to see what you really have. (If you > haven't already taken the cover off, this is a good excuse.) There is a > power supply board. It's on top where you can see it without taking anything > else apart. It's got a couple of DC-DC converter "bricks". Maybe you can > find some input voltage ratings. > > Most of those bricks will work over a wide input range, probably wider than > spec if you aren't pulling full rated output current. > > Or ask the seller. > > > -- > 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. > > ------------------------------ > > _______________________________________________ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > End of time-nuts Digest, Vol 77, Issue 4 > **************************************** > _______________________________________________ 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.
