[time-nuts] Lucent KS-24361, HP/Symmetricom Z3809A, Z3810A, Z3811A, Z3812...

Bob Camp kb8tq at n1k.org
Wed Nov 5 20:28:32 EST 2014


Hi

A little more snooping and U18 pops out. It’s an Atmel AT28C64B. Since it is a 64K bit EEPROM, that’s a much more likely place to stuff config items than redoing a flash chip. 64K seems pretty big for simple config variables and it’s a parallel EEPROM rather than a serial part. They may actually have code in there. When I originally looked at the board I assumed it was there to load the FPGA. If that’s what it’s for, the location is a bit odd. U2 seems like a more likely location for the load memory for the FPGA.I would also think that the FPGA memory would come pre-loaded. 

Bob

> On Nov 5, 2014, at 8:01 AM, GandalfG8--- via time-nuts <time-nuts at febo.com> wrote:
> 
> 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.
> 
> _______________________________________________
> 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