[time-nuts] Lucent KS-24361, HP/Symmetricom Z3809A, Z3810A, Z3811A, Z3812...
GandalfG8 at aol.com
GandalfG8 at aol.com
Wed Nov 5 08:01:41 EST 2014
Hi Bob,
Thanks for the information, I've still just been working from the J8
Diagnostic port and it's about time I took a look at the RS422 output.
The "proper" Ref-1 seems to be working as I'd expect, it's accepting a
valid Ref-0 is present and going into standby as a result. Pulling out the
link cable results in the Standby flashing and inserting the faker plug at
this stage switches it straight to "ON", standby light now off, and enables
the outputs.
Unfortunately, persuading the other other Ref-1 that it's really a Ref-0
would seem to involve a little bit more than the minor surgery I've
performed so far:-)
Regards
Nigel
GM8PZR
In a message dated 05/11/2014 12:41:42 GMT Standard Time, kb8tq at n1k.org
writes:
Hi
On a “real” Ref-0 / Ref-1 combo, the Lucent status message (RS-422 / PPS
port) shows which device the string is coming from. This is independent of
their status bits. Previous digging into similar units shows the same thing
on earlier Lucent GPSDO’s. All the details are buried (200 posts back
according to some ..) in one of my previous posts.I do not have anything on the
diag port, so I don’t know what it says.
Looking at the few unknown pins / pairs on the 15 pin connector, I’m
guessing that one of them might be high or low depending on it being a Ref-0 or
Ref-1. I’m also guessing that the pair on pin 15 is serial both ways. At
this point my guessing average is not to good on these parts. I’m not really
expecting that it will improve. Figuring out what the last few pairs do
would be a nice thing.
Bob
> On Nov 5, 2014, at 7:20 AM, GandalfG8--- via time-nuts
<time-nuts at febo.com> wrote:
>
> For what it's worth, here's what happened when I linked two Ref-1 units
> together....
>
> One was fitted with it's GPS module as normal, I'll call this Ref-1.
> The other was as normal other than having it's GPS module removed, I'll
> call this Ref-1-0.
> The link cable was around 15 inches long and wired 1-15, 2-14, etc,
using
> standard 15 way high density plugs.
>
> BTW, whereas shortened pins have been used in the past to ensure safe
power
> up sequences I'm pretty sure that on the Z3809A cable it's perhaps a
> precaution to reduce the risk of bringing down the base station when hot
> swapping.
> I've noticed that removing my "faker" plug once a stand alone Ref-1 is
up
> and running starts to flash the Standby light but doesn't otherwise
inhibit
> operation, the 15MHz and 1PPS outputs remain available. I don't know how
> long this might continue but the system obviously responds differently
once
> fully booted to when it's first powered and I suspect the use of
shortened
> pins could be related.
>
> Anyway, back to the two linked....
>
> At power up both go through the flashing light sequence, then...
> Ref-1-0 -- "No GPS" - Flashing, "Fault" - Solid
> Ref-1 ------"No GPS" - Solid, "Fault" - Solid
>
> After the boot period finishes.....
>
> Ref-1-0 -- "No GPS" - Flashing, "Fault" - Solid
> Ref-1 ------"Standby" - Solid, all other lights off.
>
> Both units will talk via the J8 diagnostics port as soon as powered up
but
> Ref-1-0 behaves just as one would expect if the GPS module is removed,
and
> it doesn't seem to be relaying any data from the Ref-1 unit, whilst
Ref-1
> shows what looks to be a normal acquisition sequence, the onset of
> conditioning, and a self survey
> At no time is there a 15MHz or 1PPS output available from either unit.
>
> Although it's been conjectured that the firmware is identical in the
Z3811A
> and Z3812A, and the Prom markings certainly seem to confirm this, it
would
> also seem that there must be something that tells the unit what it is,
> either by a firmware difference somewhere after all or perhaps a link
on the
> board somewhere.
> This isn't just based on my not very successful experiment, although the
> results are no great surprise:-), but my Ref-1 units always report
> themselves to monitoring software as a "Z3811A Secondary Receiver".
> Based on this am I correct in thinking that a standard Ref-0 would
report
> as a "Z3812A Primary Receiver"?
> If so it has to get this information from somewhere.
>
> Regards
>
> Nigel
> GM8PZR
>
>
>
> In a message dated 04/11/2014 09:38:25 GMT Standard Time,
> stewart.cobb at gmail.com writes:
>
> A wiring diagram of the Z3809A cable interconnect cable was published
> earlier on this list. That information appears to be incorrect. The
> cable is actually wired pin 1 to pin 15, pin 2 to pin 14, etc.
> Another way to describe it is that for each wire in the cable, the pin
> numbers on each end of the cable add up to 16.
>
> A mated pair of these units is running in my lab with a scratch-built
> interconnect cable following the above rules. This scratch-built
> cable allowed access to the interconnect signals while the system was
> operating happily. No lights were lit except the green ON light on
> the Ref-0 unit (Z3812A, no GPS) and the yellow STBY light on the Ref-1
> unit (Z3911A with GPS receiver). The following signals were observed
> on the interconnect (pin numbers given for the J5 interconnect socket
> on the Ref-1 unit):
>
> Pin 1: 9600 baud serial data (described below)
>
> Pin 2: logic low (0.11V)
>
> Pin 3: Ground (0.00V) Presence detect? (see below)
>
> Pin 4: logic high (4.79V)
>
> Pin 5: inverted Motorola PPS, high (5V) for 800ms, low for 200ms
>
> Pin 6: "17 / 23 dBm" signal from Ref-0 unit (see below)
>
> Pin 7: logic high (4.48V)
>
> Pin 8: Ground (0.00V)
>
> Pin 9: logic low (0.11V)
>
> Pin 10: "17 / 23 dBm" signal from Ref-1 unit (see below)
>
> Pin 11: inverted PPS, low 400us, high (5V) otherwise
>
> Pin 12: logic low (0.12V)
>
> Pin 13: Ground (0.00V)
>
> Pin 14: logic low (0.08V)
>
> Pin 15: logic high (4.78V)
>
> Pins 3, 8, and 13 appear to be firmly connected to Ground. (Note that
> these are the three pins which are clipped short on the HP
> interconnect cable.) On an unpowered, disconnected box (either Ref-0
> or Ref-1), pins 8 and 13 are connected to Ground (low resistance) and
> pin 3 is high impedance. Presumably pin 3 on each box (connected to
> the grounded pin 13 on the other box) is used to sense the presence of
> the other box and/or the interconnect cable.
>
> The timing of the PPS signal on pin 11 matches precisely the timing of
> the PPS signal available on pins 1 and 6 of J6 (RS422/PPS) on the
> active Ref-0 unit. Presumably this signal is coming across the cable
> from the Ref-0 unit.
>
> Note: when the system is coming up from a cold start, SatStat on the
> unit with the GPS receiver (Ref-1) will show "[Ext 1PPS valid]" in the
> space where it shows "[GPS 1PPS valid]" after the survey is complete.
> It appears that the Ref-1 unit timing system is locking its oscillator
> to the PPS coming from the Ref-0 unit during this time.
>
> The timing of the PPS signal on pin 5 matches the timing of the PPS
> output described in the Motorola OnCore manual. Presumably this
> signal is sourced by the Ref-1 unit to allow the Ref-0 unit to lock to
> GPS. The edges of this PPS signal look very dirty compared to the
> signal on pin 11. This may be an artifact of the homemade cable used
> for this experiment. The HP cable clearly has an overall shield
> (visible through the cable sheath) and may have internal coax or
> twisted pair for these PPS signals.
>
> When pin 5 and pin 11 are observed together, the usual GPS sawtooth
> pattern is evident.
>
> Someone discovered earlier that the both units will blink their green
> ON lights if the front-panel switch on either unit is set to 23 dBm
> vice the normal 17. Obviously each unit can communicate its switch
> status to the other unit. They use pins 6 and 10 to do that. Pin 10
> (on the Ref-1 unit) is high (~5V) if the switch on the Ref-1 unit is
> in the 17 dBm position, and low in the 23 dBm position. Pin 6 (on the
> Ref-1 unit) gives the same indications for the switch on the Ref-0
> unit.
>
> The serial data on pin 1 is transmitted at 9600 baud, with a burst of
> data every second. The signal idles at logic low (near 0V) and rises
> to logic high (near 5V) during the burst. This may be the standard
> for TTL (not RS-232) transmission of serial data, or it may be
> inverted. The first few characters of one burst were hand-decoded
> from a scope trace as 0x40, 0x40, 0x45, 0x61, 0x0B, or ASCII "@@Ea".
> This appears to be the Motorola Oncore binary data format, although
> "Ea" does not appear to be a valid Motorola command or response.
> Perhaps the hand-decoding was in error.
>
> One can use SatStat, talking to the Ref-0 (non-GPS) box, to issue
> queries and commands to the GPS receiver. The results are
> inconsistent, but it seems that at least some of the queries get
> through and trigger responses. If the Ref-0 box is actually talking
> to the GPS receiver, it must be doing so through the interconnect
> cable. The specific wire in the cable used for this (if any) has not
> yet been identified.
>
> An earlier post speculated that the computer in each unit only had two
> UARTs. This does not seem possible. Clearly each unit uses one UART
> to communicate with the J8 diagnostic port. The Ref-1 unit needs
> another UART to communicate with the GPS receiver. And both units need
> to be able to transmit the legacy Lucent timecode message out the J6
> (RS422/1PPS) port. Perhaps there is a transmit-only UART coded into
> the FPGA, or perhaps one of the UARTs is timeshared with the Lucent
> message, or perhaps there is another UART chip hidden somewhere on the
> board.
>
> It seems unlikely that the two units are sending serial data to each
> other. (No such data was observed on the interconnect.) Instead,
> they appear to communicate their state to each other by means of logic
> levels on various pins of the cable. The logic functions of pins 6
> and 10 have already been identified. Further research is needed.
>
> Cheers!
> --Stu
> _______________________________________________
> 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.
More information about the time-nuts
mailing list