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 <[email protected]> > 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, [email protected] > 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 > <[email protected]> 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, >> [email protected] 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 -- [email protected] >> To unsubscribe, go to >> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
