[time-nuts] time-nuts Digest, Vol 77, Issue 4

Jerry jreed123 at cox.net
Fri Dec 3 01:10:26 UTC 2010


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-request at febo.com> wrote:
> Send time-nuts mailing list submissions to
>        time-nuts at 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-request at febo.com
>
> You can reach the person managing the list at
>        time-nuts-owner at 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 (scmcgrath at gmail.com)
>   5. Re: Z3801A/58503A Help (scmcgrath at gmail.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 30 Nov 2010 23:50:45 -0700
> From: Robert Darlington <rdarlington at gmail.com>
> Subject: Re: [time-nuts] OT: NTP server questions
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID:
>        <AANLkTinROSN_Pj85zHC7h3NunoM8OtWf04A-vdOLFhpQ at 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.chris at 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 <hmurray at 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 at 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 <hmurray at megapathdsl.net>
> Subject: Re: [time-nuts] OT: NTP server questions
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID:
>        <20101201070830.CA99280003B at ip-64-139-1-69.sjc.megapath.net>
> Content-Type: text/plain; charset=us-ascii
>
>
> rdarlington at 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 <rdarlington at gmail.com>
> Subject: Re: [time-nuts] OT: NTP server questions
> To: Discussion of precise time and frequency measurement
>        <time-nuts at febo.com>
> Message-ID:
>        <AANLkTik+8+7DWJA6KiRANPL6sFm_JnW3BdM8pfY=YJVv at 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 <hmurray at megapathdsl.net> wrote:
>
>>
>> rdarlington at 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 at 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: scmcgrath at gmail.com
> Subject: Re: [time-nuts] OT: NTP server questions
> To: "Discussion of precise time and frequency measurement"
>        <time-nuts at febo.com>
> Message-ID:
>        <781384083-1291190299-cardhu_decombobulator_blackberry.rim.net-1241517341- at 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 <rdarlington at gmail.com>
> Sender: time-nuts-bounces at febo.com
> Date: Wed, 1 Dec 2010 00:34:00
> To: Discussion of precise time and frequency measurement<time-nuts at febo.com>
> Reply-To: Discussion of precise time and frequency measurement
>        <time-nuts at 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 <hmurray at megapathdsl.net> wrote:
>
>>
>> rdarlington at 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 at 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 at 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: scmcgrath at gmail.com
> Subject: Re: [time-nuts] Z3801A/58503A Help
> To: "Discussion of precise time and frequency measurement"
>        <time-nuts at febo.com>
> Message-ID:
>        <1784409955-1291190855-cardhu_decombobulator_blackberry.rim.net-1304016505- at 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 <hmurray at megapathdsl.net>
> Sender: time-nuts-bounces at febo.com
> Date: Tue, 30 Nov 2010 22:38:18
> To: Discussion of precise time and frequency measurement<time-nuts at febo.com>
> Reply-To: Discussion of precise time and frequency measurement
>        <time-nuts at 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 at 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 at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>
> End of time-nuts Digest, Vol 77, Issue 4
> ****************************************
>



More information about the time-nuts mailing list