Does anyone recognize this board, is it a gpsdo?

[alank2]

http://www.ebay.com/itm/10-MHz-Double-Oven-OCXO-Double-sinewave-EPSON-TOYOCOM-TCO-6920N-10MHZ-/111693078549?pt=LH_DefaultDomain_0&hash=item1a016d2015

[Lightages]

It certainly looks like one. Hard to say though without more information or details on the other metal can on the board.

[Deathwish]

the smaller can is a  ublox le Gps receiver, I just purchased one.This one to be precise.

http://www.ebay.co.uk/itm/291140312483?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

[Lightages]

Yes, I just found something like it on the UBlox website.

[edpalmer42]

Didn't you notice that he has pictures of TWO DIFFERENT BOARDS!!!!

So I asked him which one he was selling.  He said he's selling the board in the first picture.  Not the GPSDO.  Just the oscillator that was removed from the GPSDO plus a little support circuitry.

Just a little deceptive, wouldn't you say?

Ed

[alank2]

Yes, I noticed.  Very lame as he has the one with the GPS as the main picture...

[grumpydoc]

Yes, I noticed.  Very lame as he has the one with the GPS as the main picture...

For fun I bought one - I got the board with the GPS receiver.

Might be interesting to figure out how to talk to it.

The large chips on the board are a NEC uPD70F3738 micro-controller, a Xilinx XC3S200A FPGA and a M29W320EB 32M flash.

It is marked NEC NWM-034241-201 on the top silk screen and NEC NWA-057706-001 on the bottom silk screen. There's also a serial No (2641) and date of manufacture (2010)

Photos to follow.

[edpalmer42]

I wish he'd make up his mind what he's selling.

I have no interest in the oscillator, but the GPSDO would be interesting to play with.  But since he told me that the first picture, i.e. just the oscillator, is what he's selling, I'm not willing to deal with him.

[grumpydoc]

I wish he'd make up his mind what he's selling.

I have no interest in the oscillator, but the GPSDO would be interesting to play with.  But since he told me that the first picture, i.e. just the oscillator, is what he's selling, I'm not willing to deal with him.

I confess I bought it as an unknown GPSDO to play with - I was quite prepared to give some negative feedback for misleading photos.

The seller has 2 left sold out - but, I agree, his photos are still ambiguous.

Interestingly the board with just the ocxo is available from another seller (well, could be the same guy using a different ID)

[grumpydoc]

the smaller can is a  ublox le Gps receiver, I just purchased one.This one to be precise.

http://www.ebay.co.uk/itm/291140312483?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

The one on the board is an LEA-5T

[Deathwish]

I think I would like to get one then shove it in a box with the intention of making something only to forget it as i did the one I just bought 

[grumpydoc]

A couple of photos, as promised (click on image for slightly larger version)

Top of board:



The GPS module is a ublox LEA-5T with what looks to be an SNB RF connector, the white connector has traces going to a max3243 (just below/right of Z5) so I presume carries a serial interface. The blue inductor and four caps at the bottom left are DC supply filtering, the three other inductors are part of separate DC-DC converters built around the tps62110 step-down converter and there are a couple of 3.3V regulators top right & top left. There's also a  Xilinx XC3S200A FPGA, presumably for glue logic.

Bottom of board:



This looks interesting, the first thing I noticed was several differential tracks running to the connector at the bottom of the board - these run to two Micrel SY89833 LVDS fanout buffers - these have a 2GHz bandwidth and claim < 190ps rise and fall times so the 10MHz out is going to have sharp edges! The inputs to the fan-out buffers come from a further pair of LVDS buffers, in this case the TI LVDS104M. Actually I'm slightly puzzled here. The datasheet for the LVDS104 says it is a 16 pin part, but there are 8 pin parts on the board. They are clearly marked with the TI logo and LVDS104M but I can't find this part on the TI  web site - does anyone have any pointers?

The OCXO output itself runs through what looks like some LC filtering, then to a 74LCX244 buffer, then presumably into the LVDS104's

As well as the LVDS outputs the bottom connector has DC in - presumably 12V as it runs straight through to the OCXO VCC pin with just a bit of LC decoupling. there are also 15 lines on the opposite side to the LVDS output, most of these have 10k pulls downs attached (the row of SMD resistors below Z5 on the top of the board). It is not possible to trace them visually into the board after that so they could run up to the FPGS or the CPU - no idea whether they are a parallel interface or status lines or what.

Finally there are four TTL level lines running out to the unpopulated connector Z1, not sure what these are - some sort of serial debug interface (not JTAG as not enough pins).

I might power it later today and check that the 3.3V logic gets power with just 12V applied, I can't try it out properly until I get hold of a SNB to BNC adapter to hook it up to the GPS antenna.

UPDATE: Powered up, various LEDs flash & change so the processor is probably OK and 10MHz out of one set of LVDS outputs, so the OCXO is working (and the oven current conforms to the datasheet). The other set is inactive, there is nothing out of one of the LVDS104M's - but I don't know whether that's because of a fault or it's supposed to do that.

Datasheets

OCXO: http://www.wild-pc.co.uk/docs/TCO-6920N.pdf
CPU: http://media.digikey.com/pdf/Data%20Sheets/Renesas/uPD70F3737,38,92,93.pdf
RS232: http://www.ti.com/lit/ds/symlink/max3243.pdf
GPS: http://www.u-blox.com/images/downloads/Product_Docs/LEA-5_NEO-5_TIM-5H_HardwareIntegrationManual%28GPS.G5-MS5-09027%29.pdf
DC-DC: http://www.ti.com/lit/ds/symlink/tps62110.pdf
FPGA: http://www.xilinx.com/support/documentation/data_sheets/ds529.pdf
LVDS: http://www.micrel.com/_PDF/HBW/sy89833al.pdf http://www.ti.com/lit/ds/slls396f/slls396f.pdf

[lukier]

I just got my board as well.

TI LVDS chip is probably this one:
http://www.ti.com/lit/ds/symlink/sn65lvds2.pdf

There is a couple of opamps (OP291, NJM5534), but I didn't spot any DAC (well it may be one of the tiny QFN equivalent SOT-23-5 parts) or precise voltage reference. How they tune the OCXO? PWM generated DAC? There is a fair amount of R/L/C components around these areas so that seems probable.

I have a gut feeling that this might come from some NEC telecom equiment. People usually associate rubidium with base stations, but OCXO based GPSDO is pretty much as good as rubidium one.

On one hand it would be great to reverse engineer this particular board - the MCU might be implementing some clever Kalman filter based tuning and learned the aging parameters of this particular OCXO (hypothesis). On the other hand this MCU is a bit too exotic to me to bother either reverse engineering FW blobs or write FW from scratch, so I'm tempted to salvage the parts and reuse in my own design. 

[grumpydoc]

I just got my board as well.

TI LVDS chip is probably this one:
http://www.ti.com/lit/ds/symlink/sn65lvds2.pdf

Yes, I came across that this morning in an idle minute I had to hit google. Looks as though I should have just read the part No as "LVDS1"

There is a couple of opamps (OP291, NJM5534), but I didn't spot any DAC (well it may be one of the tiny QFN equivalent SOT-23-5 parts) or precise voltage reference. How they tune the OCXO? PWM generated DAC? There is a fair amount of R/L/C components around these areas so that seems probable.

There's a D to A on the CPU - only 8 bits but it has two channels so they could be scaled and added to give more resolution. It should be easy enough to trace the drive back - it comes out of the 5534 op amp.

I have a gut feeling that this might come from some NEC telecom equiment. People usually associate rubidium with base stations, but OCXO based GPSDO is pretty much as good as rubidium one.

I would assume so - not something I know a lot about.

On one hand it would be great to reverse engineer this particular board - the MCU might be implementing some clever Kalman filter based tuning and learned the aging parameters of this particular OCXO (hypothesis). On the other hand this MCU is a bit too exotic to me to bother either reverse engineering FW blobs or write FW from scratch, so I'm tempted to salvage the parts and reuse in my own design. 

I already have a rubidium and GPSDO so this is just idle curiosity, especially as I don't have anything which wants LVDS and the connectors on the board aren't exactly hobbyist friendly. I'll be happy if I can see that the it has locked and maybe see if there's anything sensible on the RS232 interface.

Have ordered a GPS puck with SMB connector - might get chance to play a little more later in the week.

[grumpydoc]

but I didn't spot any .... precise voltage reference.

There doesn't appear to be one - the two analogue V_REF inputs are tied to V_DD, which comes straight from one of the DC-DC converters.

It is going to be slightly more of a challenge to trace the two analogue output pins to see if they are used to drive the control voltage as the traces are not visible on the top of the board and I need at least three hands to hold the board and two meter probes

[lukier]

I'm also looking at this board ATM. It seems very sophisticated. IC6, IC7 and IC8 are all LM71 SPI temperature sensors. Filters on the OCXO output produce nice 3Vpp sine wave, before it enters LCX244 and later LVDS drivers.

I need to figure UARTs, as I didn't saw with the scope any traffic on the pins of the white connector.

With 3 DC-DC converters generating 5/3.3/1.2V I also wonder what is the purpose of IC9/IC10 (3.3V LDO I presume) - cleaner power for the analog stuff?

Also, I wonder, what are these SMD power resistors (2R70) along with unknown SOT-223 devices.

[grumpydoc]

It should be easy enough to trace the pins back to the MAX3243 and then hopefully to the processor to see which are transmit and which receive.

However, the UARTs in the CPU only provide TXD and RXD - no modem control so you only need three pins and there are 9+ground on the connector. It looks as though all 9 connect to something.

I had a go at tracing the DAC outputs from the CPU, so far with no luck.

[Vgkid]

I bought one, so I will start following this thread. At least it has a rather good ocxo, though i wish more drift specs were given.

[grumpydoc]

OK, had an idle 20 minutes between other jobs and travelling between sites

So - with pin 1 top right (arrow on silk screen) and then counting down and then right (so odd numbered pins across the top and even numbered pins on the bottom row) we have

Z5 pin	MAX 3243 Pin	MAX3243 Function
1	GND
2	9	DOUT1 (RS232 TX)
3	4	RIN1 (RS232 RX)
4	GND
5	10	DOUT2
6	5	RIN2
7	?	not connected to MAX3243
8	GND
9	11	DOUT3
10	6	RIN3

TX and RX are from the boards perspective.

I haven't traced these back to the CPU - one problem is that a lot of the CPU output lines run through 100R resistors which means that the meter's continuity buzzer doesn't work and I have run out of time to do any more for the moment. The most obvious is that they map directly to the three UARTA channels.

[grumpydoc]

I'm also looking at this board ATM. It seems very sophisticated. IC6, IC7 and IC8 are all LM71 SPI temperature sensors. Filters on the OCXO output produce nice 3Vpp sine wave, before it enters LCX244 and later LVDS drivers.

It does seem a bit over-engineered in parts. For one thing why a 200K gate FPGA.

I need to figure UARTs, as I didn't saw with the scope any traffic on the pins of the white connector.

See my previous post - still not had chance to trace these back. The 3243 is set up with auto power down enabled which means unless it detects a valid RS-232 voltage on the data in pins the output pins will be high impedance.

However, I've had a look at all of the DIN pins and can't see any activity there either - so it either doesn't announce anything useful over the serial port or, just possibly, the INVALID output from the MAX3243 is hooked to the CPU and used to disable serial output if there's nothing plugged into the port.

With 3 DC-DC converters generating 5/3.3/1.2V I also wonder what is the purpose of IC9/IC10 (3.3V LDO I presume) - cleaner power for the analog stuff?

Also, I wonder, what are these SMD power resistors (2R70) along with unknown SOT-223 devices.

No idea for now.

[lukier]

Thanks for tracing the 10 pin connector. I'll try to do some tests tomorrow.

For my purpose (GPSDO) all I really need is to tap 10MHz sine before LCX244 and feed it into a distribution amplifier.

By the way, is there any standard for 10MHz reference signal?

Some people just use multiple 74AHC04 to drive 50 Ohm load with a square wave, some say a nice sine is a must. My Hantek HDG2002B generator probably just has a Shmitt trigger gate at the input and that's it. I need to check my Racal-Dana 1992 counter schematic as well. It's a pity that DS1054Z doesn't have 10MHz input.

There should be 1pps signal somewhere on the board so I could connect that to RaspberryPi's GPIO and run NTP server as well.

It would be nice though to be able to get more internal data from this module, lock status, maybe tap into GPS UART, these temperature sensors etc.

[grumpydoc]

.....maybe tap into GPS UART.....

That, at least, is straightforward - the ublox serial TXD and RXD are connected to UARTA channel 2 on pins 35&36 of the CPU and I can see data on those lines with the 'scope.

I haven't had any luck at all tracing the serial lines from the MAX3243, they don't appear to connect to the CPU UART and I can't find them on the FPGA either.

[grumpydoc]

There should be 1pps signal somewhere on the board so I could connect that to RaspberryPi's GPIO and run NTP server as well.

Appears to be via X7/X8

Now that I have an antenna connected X8 initially flashes once per second missing every 10th second. Then both flash with X8 continuing to miss every 10th beat. I assume that means a basic GPS lock. After a while X8 stopped missing the 10th beats so I presume that means a better quality lock.

After a couple of hours running with a GPS antenna hooked up X7/8 are flashing in tandem at 1PPS and X4 is flashing rapidly - at this point I'd expect the oscillator control to maybe have a coarse lock so we will see if anything changes over the next 24 hours.

......


Well, after another hour or so X4 went steady and X5 starts flashing at 0.25Hz, I guess that means it locked - at least to some degree. At that point I turned the board over to look at the outputs and it looks like IC29 and it's associated fan-out buffer carry the 10MHZ and IC30 has a 1 PPS signal. Sadly turning the board pulled my dodgy power connection off so that's reverse engineering finished for now.

There is also a TTL level serial data burst every second on one of the pins on the top row of the connector - not coming from the CPU UART 

[lukier]

Now that I have an antenna connected X8 initially flashes once per second missing every 10th second. Then both flash with X8 continuing to miss every 10th beat. I assume that means a basic GPS lock. After a while X8 stopped missing the 10th beats so I presume that means a better quality lock.

After a couple of hours running with a GPS antenna hooked up X7/8 are flashing in tandem at 1PPS and X4 is flashing rapidly - at this point I'd expect the oscillator control to maybe have a coarse lock so we will see if anything changes over the next 24 hours.
......
Well, after another hour or so X4 went steady and X5 starts flashing at 0.25Hz, I guess that means it locked - at least to some degree. At that point I turned the board over to look at the outputs and it looks like IC29 and it's associated fan-out buffer carry the 10MHZ and IC30 has a 1 PPS signal. Sadly turning the board pulled my dodgy power connection off so that's reverse engineering finished for now.

There is also a TTL level serial data burst every second on one of the pins on the top row of the connector - not coming from the CPU UART 

Great job. I'm still waiting for my SMB GPS antenna.

Maybe first state is position surveying phase and after that it does the final lock.

I didn't have much time today, but I had a quick look. First I thought that that the power resistors measure OCXO current to detect when the heater has stabilized, but after a quick look it seems that the power resistors and associated opamp seem to have something to do with active antena power, maybe controlling the current or protecting against overcurrent.

It would be great to evaluate this board, i.e. holdover performance. It would take probably a couple of days of measurements to see if the board output drift is just what OCXO specs say or if they implement predictive control.

[Vgkid]

For the gps connector would it be a smb female?

[grumpydoc]

For the gps connector would it be a smb female?

Yes, it's SMB male on the board.

[edpalmer42]

Looks like the seller found some more units.  Since you guys got the GPSDO, I decided to take a small chance and bought one.

If I had to guess why he said that he was selling the small board in the first picture, I'd guess it was more of a language issue than anything.  He might have been saying that the value was for the OCXO and the board with the GPS receiver just happened to be there.

Once this thing has been sorted out and is running good, does anyone have any good equipment to confirm it's performance?

[Vgkid]

Thanks for the reply Grumpy, I will pick up a sma to smb pigtail.

[grumpydoc]

It's quiet here - I hope you guys are having fun with your boards

GPS time of day is available on the main connector (and top of PCB) 4800baud 8N1 LV TTL data levels, one update per second.

Has anyone got anywhere with the RS232 interface?

[grumpydoc]

Gosh it is quiet

It would be great to evaluate this board, i.e. holdover performance. It would take probably a couple of days of measurements to see if the board output drift is just what OCXO specs say or if they implement predictive control.

To an extent the problem is that you need something more stable/accurate to check against - however I have it running against my rubidium unit at the moment.

Currently my Racal counter is showing between 0-1mHz (yes, I do mean small "m") difference in frequency between the FE5680A and the NEC board, very similar to my Rapco 1804. That is 0.1ppb (1 x 10^-10) and is right at the limit of what I can measure directly with the counter.

So all I can say is that the short term variation over the 20second gate time is 1 x 10^-10 or better and the absolute frequency accuracy is also 1 x 10^-10 or better.

Quick update: switching to an indirect measure (observing the relative change in phase over time) gives me a figure of about 3x10^-11 for the absolute difference in frequency between the NEC board and the FE-5680A, again similar to the Rapco - at this point I do not know which device is "out", just that it looks as though all my frequency standards agree within a few parts in 10¹¹.

In any case the short term variance is going to dominated by the OCXO - pretty much anything less than 100 seconds - sadly the datasheet does not seem to give the figures .

[lukier]

Gosh it is quiet
To an extent the problem is that you need something more stable/accurate to check against - however I have it running against my rubidium unit at the moment.

Currently my Racal counter is showing between 0-1mHz (yes, I do mean small "m") difference in frequency between the FE5680A and the NEC board, very similar to my Rapco 1804. That is 0.1ppb (1 x 10^-10) and is right at the limit of what I can measure directly with the counter.

So all I can say is that the short term variation over the 20second gate time is 1 x 10^-10 or better and the absolute frequency accuracy is also 1 x 10^-10 or better.

That's great news. I'll have decent frequency standard on the cheap

I don't know if I had figured that out correctly, but what thought was to see how NEC board without GPS compares to another GPS constantly synchronized reference. This way we would see how MCU+FPGA controls the OCXO when there is no GPS. Then after some time we would see the difference between them (e.g. Figure 12 here http://tf.nist.gov/general/pdf/2297.pdf).  Would that be just OCXO datasheet aging rate or something rather clever.

Thanks for figuring out GPS time of day UART. My experiments with this board are hindered by the fact that in my lab I don't have GPS reception and at my desk I do, but I don't have any tools

[Deathwish]

Someone reads the forum , the price of that ocxo has shot up in price literaly overnight to almost twice what it was before.

http://www.ebay.co.uk/itm/111709755330?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

[grumpydoc]

Someone reads the forum , the price of that ocxo has shot up in price literaly overnight to almost twice what it was before.

http://www.ebay.co.uk/itm/111709755330?_trksid=p2055119.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

Well, 1.5x - he was asking $40, now $60

The number available seems to have gone from 10 -> 5 as well, without selling any on ebay.

[Velund]

Looks like it is a module from some NEC microwave data link or maybe WiMax base station.

Unfortunately, I do not know anyone who service this equipment to ask...

[edpalmer42]

Looks like it is a module from some NEC microwave data link or maybe WiMax base station.

Unfortunately, I do not know anyone who service this equipment to ask...

Yes, it appears to be from their Pasolink line.  That's the only place I found part numbers of the form NWA-05xxxx.  Unfortunately, I wasn't able to find any detailed manuals for that equipment.

[Velund]

Now that I have an antenna connected X8 initially flashes once per second missing every 10th second. Then both flash with X8 continuing to miss every 10th beat. I assume that means a basic GPS lock. After a while X8 stopped missing the 10th beats so I presume that means a better quality lock.

After a couple of hours running with a GPS antenna hooked up X7/8 are flashing in tandem at 1PPS and X4 is flashing rapidly - at this point I'd expect the oscillator control to maybe have a coarse lock so we will see if anything changes over the next 24 hours.
......

Well, after another hour or so X4 went steady and X5 starts flashing at 0.25Hz, I guess that means it locked - at least to some degree. At that point I turned the board over to look at the outputs and it looks like IC29 and it's associated fan-out buffer carry the 10MHZ and IC30 has a 1 PPS signal. Sadly turning the board pulled my dodgy power connection off so that's reverse engineering finished for now.

It would be interesting to determine meaning of LEDs...

I do not see any backup battery on the board, so every time GPS should begin from cold start. So, basic lock and valid time, then self-survey to precisely determine coordinates... If I remember correctly, there should be something like "dashboard" in uBlox software, so it is possible to hook input of RS232 buffer or USB-serial converter to TXD of module and observe process, noting LED state changes.

Then, some LED may reflect T-RAIM status...

[Vgkid]

My module came today i should have ordered that adapter sooner than today.

[Vgkid]

Since I'm waiting on my connector, is there a pin for the 12v input power. Or should i just apply it to the ocxo?

[Vgkid]

Sorry for the double post:::
smb female to sma female came today...
It works

[grumpydoc]

Since I'm waiting on my connector, is there a pin for the 12v input power. Or should i just apply it to the ocxo?

The power  is on the bottom connector, there's a bit of decoupling/LC filtering but it does go straight to the OCXO 12V pin.

[lukier]

I did some more reverse engineering on this board today.

I traced most signals on the main connector.

Pin	Signal	Comment
1	12V
2	12V
3	12V
4	12V
5	GND
6	GND
7	GND
8	GND
9	GND
10	GND
11	MAX3243 DIN1
12	PPS (3.3V)
13	MAX3243 ROUT1
14	GND
15	GND
16	IC28 Q1P	LVDS PPS
17	MAX3243 DIN2
18	IC28 Q1N	LVDS PPS
19	MAX3243 ROUT2
20	GND
21	GND
22	IC28 Q2P	LVDS PPS
23	MAX3243 DIN3
24	IC28 Q2N	LVDS PPS
25	MAX3243 ROUT3
26	GND
27	GND
28	IC28 Q3P	LVDS PPS
29	MCU P31 (RXDA0)	115200 bps 8n1
30	IC28 Q3N	LVDS PPS
31	MCU P30 (TXDA0)	115200 bps 8n1
32	GND
33	TOD UART TX - FPGA pin 50	4800 bps 8N1
34	IC27 Q1P	LVDS 10MHz
35	GND
36	IC27 Q1N	LVDS 10MHz
37	NC?	UNKNOWN
38	GND
39	MCU FLMD0
40	IC27 Q2P	LVDS 10MHz
41	NC?	UNKNOWN
42	IC27 Q2N	LVDS 10MHz
43	MCU pin 28	P33/TIP01/TOP01
44	GND
45	MCU pin 29	P34/TIP10/TOP10
46	IC27 Q3P	LVDS 10MHz
47	MCU pin 30	P35/TIP11/TOP11
48	IC27 Q3N	LVDS 10MHz
49	GND
50	GND

I got my TL866 adapters recently so I've desoldered M29W320 flash memory and dumped the contents but there isn't much there. I could recognize serial/model number and the rest is FPGA bitstream noise. MCU has its own flash and it looks like there are pins on the main header for ISP (UART0 and FLMD0) but I don't have any tools for this arcane architecture (or disassembler)

TOD UART funny enough comes from the FPGA and without GPS (my current condition) it says "TOD_NOT_VALID;" every second.

Main MCU UART works at 115kbps and at boot prints:

Code: [Select]

OK;
CONFIG_FPGA;
CONFIG_FPGA_OK;
CONFIG_GPS;
CONFIG_GPS_OK;

and nothing more, doesn't respond to random keys.

P33/P34/P35 are timer pins so I suppose they might be used to time external events. I've tried poking them with GND or 3V3, but nothing came up on the main UART.

It seems that MAX3243 hasn't much to do with the GPSDO function, it takes UART signals from the main connector, translates them to RS-232 and they are provided on the white pin header. Maybe some front panel interface?

I bought nice Extron distribution amplifier recently: http://www.ebay.co.uk/itm/201366115087
and both GPSDO and RPi for NTP server should fit nicely:



Distribution amplifier uses OPA3691 for video signals, 74AHCT04 for digital outputs (and NJM360 comparators). Need to replace 75 Ohm resistors

Power supply there provides +5 and -5V. 5V seems to handle 2A without trouble (just a quick test with Agilent 6632B as a load, need to check with thermal camera as well). GPSDO requires 12V so I'll use one of these cheap XL6009 step-up modules. It draws 1A @ 12V when heating the OCXO but later it is < 0.4A, maybe less if I enclose OCXO in styrofoam.
I plan to wire 10 MHz sine to R/G/B inputs, 10 MHz square to H and 1pps square to V. Separate PPS signal and TOD UART will go to RPi for NTP server functionality.

I've desoldered the main connector from GPSDO and the pin pitch is 0.8mm so I thought a SMD SATA connector would fit there, just enough to connect to these nice fast rising 1pps and 1 MHz LVDS and I thought about using SATA cable from GPSDO to my breakout board at the front of the case that would break out from SATA connector into 4 SMA connectors. In theory I could use these fast signals as a pulse generator to test things (I don't have free_electron's Jim Williams Pulse Gen). I'm worried though that I'll loose these nice rise times, not so much in the SATA cable, but when breaking them out into SMA connectors on an etched board (also LVDS impedance control and termination perhaps necessary?). 

[Vgkid]

So my modules been powered up for 50 minutes. X3,4 are blinking rapidly. With x8 blinking at 1pps.

[Vgkid]

I left it powered up all day, no change. Checked the antenna with my 6T module, and 2 sats are above 30dB, with 5 above 20dB.
I wonder if the 5T module on board is bad, it looks to have had either been dropped, or something hit it.

[lukier]

Check what the UARTs say, the main MCU UART (115200 8n1) on power up ("CONFIG_GPS_OK;" message) and Time Of Day UART (4800 8n1) that should output either UTC time (when it has a lock), something like that "$GPZDA,215112,28,07,2015,00,00*47" or "TOD_NOT_VALID;" otherwise.

Also, you could probably tap uBlox 5T UART coming from the MCU and see what is going on there.

[Vgkid]

I think the 5t is fried. Should I contact the seller. I have 3 days.

[Vgkid]

Checked it this morning , still no lock. Or anything else that matter.

[Vgkid]

I emailled the seller a few minutes ago, I really hate to complain.

[grumpydoc]

Remember that these were not sold as GPSDOs but just the OCXO,

[Vgkid]

I will see if I get a favorable response back. Good thing is that the 6T is pin compatable,though I wish the solderpads around the 5t were longer. I would have wired my 6T board to the 5T.

[edpalmer42]

I got my board today.  I'm trying to make it talk to me before I hook up an antenna.  I'd like to see if it has a stored location.  It's interesting to see where these things came from.  No discoveries so far, but I have removed a few possibilities.

I noticed that the communications between the LEA-5T and the micro is at 19200.  Add that to the TOD at 4800 and the MCU UART at 115200 and who knows what speed the RS-232 runs at.  I've confirmed Grumpy's statement that all the RS-232 outputs are turned off until at least one valid input is present.  I've checked the three TX-RX pairs 2-3, 5-6, and 9-10 in the white connector at speeds of 2400 - 115200 N-8-1.  I guessed that the 'language' might be SCPI without the normal command prompt so I sent :SYST:STAT? and SYST:STAT? but didn't even get gibberish for a response.

Things to check - not necessarily by me.  Feel free to jump in at any time!     If you'd like to try something, tell us so we're not all doing the same thing.

1.  There's no particular reason why that TX-RX pairing is correct.  Maybe another combination is correct.
2.  Maybe the language isn't SCPI.  Maybe it's U-blox's native language.  Try their u-center software.
3.  Try NMEA commands - although that seems unlikely.

The Quest continues......

[Vgkid]

What about monitoring the usb interface?

[grumpydoc]

I will see if I get a favorable response back. Good thing is that the 6T is pin compatable,though I wish the solderpads around the 5t were longer. I would have wired my 6T board to the 5T.

Did you ever  get a response?

It looks as though they have now sold out

[Vgkid]

He requested pics,so I sent pics. No response, I will send them again. Then make judgement 

[Velund]

Got my board yesterday.

First checks - dead short on primary (12V) power bus, ohmmeter display zero ohms between power pin of OCXO and ground.

Traced it down to one of DC-DC chips (TPS62110) using current limited lab power supply and DVM on millivolt range.

Have no replacement chip right now, will continue later.

I think I'll just leave negative feedback to a seller for listing obviously failed used items as "New", without spending even more of my time.

[grumpydoc]

It would be interesting to determine meaning of LEDs...

From observation X7 is probably 1PPS from the uBlox
X8 probably reflects 1PPS from the CPU

I haven't traced these or checked against the main 1PPS output

So far I haven't seen X2 lit
X3 is lit after power-up but before lock
X4 flashing rapidly is probably GPS locked and discipline running but timing not locked
X4 steady and X5 flashing likely reflects timing locked.

I think I'll just leave negative feedback to a seller for listing obviously failed used items as "New", without spending even more of my time.

I confess that I didn't notice that the ebay item status was "new", probably because they so obviously weren't. The description said "used" though.

I think leaving negative feedback would be unfair - they were listed as OCXOs not GPSDOs - the fact that some boards actually work is a bonus.

I confess that I quite liked the price so bought a couple more. So I now, like others, have a board where the 5T doesn't work. In my case it was pretty obvious it would not without even powering the board as the screening can was caved in and one of the BGA packages in the 5T cracked in half. The 12V filter inductor was smashed as well.

Does anyone know where to get a LEA 5T or LEA 6T at a sensible price?

[Deathwish]

http://www.aliexpress.com/item/GPS-UBLOX-LEA-6T-industrial-grade-high-precision-timing-module-rawdata-split-board-wrapped-6S/32372178357.html

[grumpydoc]

http://www.aliexpress.com/item/GPS-UBLOX-LEA-6T-industrial-grade-high-precision-timing-module-rawdata-split-board-wrapped-6S/32372178357.html

Ah, thanks - might give that a go.

[Macbeth]

I was going to buy one of these too, I left it 'til morning then the seller pulled them all. Perhaps someone bought them all up outside of ebay, or else he had too many whingers expecting a fully working GPSDO when he was clearly selling it for the OCXO bit alone. So bit of a gamble really. If the OCXO isn't working then you have some come back.

[Velund]

From observation X7 is probably 1PPS from the uBlox
X8 probably reflects 1PPS from the CPU

Received DC-DC chip yesterday and found some time to replace it. Looks like the rest is functional.

Powered it on, and connected antenna after few minutes.. Now X4 is flashing rapidly, X7 and X8 is flashing in unison with 1s period.

By the way, I observed X8 blinking slowly before antenna connection, then X7 and X8 started to flash rapidly, then X7 and X8 started to flash with 1s period but alternately, and finally X7 and X8 started to flash in unison with 1s period.

Supply current was about 0.9 A at start, then rise to 1A, and then gradually decrease to 0.35A.

PS: Left the board powered overnight. Now X4 is steady, X5 briefly blinking each 3 sec (skipping some periods), X7 and X8 blinking every 1 sec.

[edpalmer42]

I've had no luck at all talking to the micro.  I've tried all combinations of 2400 - 115200 bps, 7 or 8 bits, N-O-E parity, 1 or 2 stop bits.  I poked it with a question mark and listened for an answer.  I tried all the xmit-rcv pairings between the pins in the white connector.  Nothing.  All of this was done without hooking up an antenna.

I then went ahead and hooked up an antenna and used u-center to eavesdrop on the chatter from the LEA-5T to the micro.  It only took the 5T a few seconds to grab a bunch of satellites.  It quickly settled down to a 3D/DGPS fix with a 2D accuracy of less than 1 meter and 10 or so satellites locked with signal levels as high as 51 db.  So far, it's not reporting a 3D accuracy value.

U-center has a statistics view that's absolutely wild!  It's reporting a time accuracy of 0.002346 us with a deviation of 0.000477 us.  The Timepulse Quantization Error averages -0.031 ns (yes, ns) with a deviation of 2.983 ns.  This is 6371 seconds after powerup.  I like this module!

Meanwhile, the micro hasn't started disciplining the OCXO yet.  Hopefully it just hasn't been running long enough.  It's currently running at 10 MHz + 150-200 Hz.  I'll leave it running overnight and see what happens.

Ed

[edpalmer42]

Aw, Crap!   

This morning, the LEA-5T is still happy.  It's now reporting a TIME/DGPS fix.  Timing parameters are similar to last night.

But, the OCXO is still 150-200 Hz off frequency.  It doesn't appear that the disciplining is working at all.

I wonder if this is why the seller was just selling these as working OCXOs.  All these boards are defective in some way - either obvious physical damage or failed testing.  So he tested the OCXOs and sold them as working OCXOs with some junk still attached.

Ed

[grumpydoc]

Aw, Crap!   

This morning, the LEA-5T is still happy.  It's now reporting a TIME/DGPS fix.  Timing parameters are similar to last night.

But, the OCXO is still 150-200 Hz off frequency.  It doesn't appear that the disciplining is working at all.

I wonder if this is why the seller was just selling these as working OCXOs.  All these boards are defective in some way - either obvious physical damage or failed testing.  So he tested the OCXOs and sold them as working OCXOs with some junk still attached.

Ed

How sure are you that the output frequency is off by 150-200Hz?

If so you probably have a duff OCXO as the data sheet says the control range is +/- 3x10^-7 - i.e +/- 3Hz so it should not be possible for it to be as much as 150-200Hz out if it is working properly. What is the control voltage pin set at?

What do X2/3/4/5 do from power up? The sequence should be something like X5 briefly, then X3 steady, then X4 flashing rapidly then X4 solid and X5 flashing at 0.3Hz or so,

X4 flashing rapidly is presumably running the discipline algorithm but not yet within spec - it lasts a few tens of minutes on my board(s).

As to the seller's motivation, dunno but it's probably as simple as some have obvious mechanical damage to the LEA module on some cards and not being bothered to spend time testing them. It is certainly not true that all of the boards fail as GPDSOs because I have more than one which works.

[edpalmer42]

Aw, Crap!   

This morning, the LEA-5T is still happy.  It's now reporting a TIME/DGPS fix.  Timing parameters are similar to last night.

But, the OCXO is still 150-200 Hz off frequency.  It doesn't appear that the disciplining is working at all.

I wonder if this is why the seller was just selling these as working OCXOs.  All these boards are defective in some way - either obvious physical damage or failed testing.  So he tested the OCXOs and sold them as working OCXOs with some junk still attached.

Ed

How sure are you that the output frequency is off by 150-200Hz?

If so you probably have a duff OCXO as the data sheet says the control range is +/- 3x10^-7 - i.e +/- 3Hz so it should not be possible for it to be as much as 150-200Hz out if it is working properly. What is the control voltage pin set at?

What do X2/3/4/5 do from power up? The sequence should be something like X5 briefly, then X3 steady, then X4 flashing rapidly then X4 solid and X5 flashing at 0.3Hz or so,

X4 flashing rapidly is presumably running the discipline algorithm but not yet within spec - it lasts a few tens of minutes on my board(s).

As to the seller's motivation, dunno but it's probably as simple as some have obvious mechanical damage to the LEA module on some cards and not being bothered to spend time testing them. It is certainly not true that all of the boards fail as GPDSOs because I have more than one which works.

I agree that there's something very strange going on here and I'm still trying to get to the bottom of it.  The EFC voltage is 5V36.  Not good.  But the op-amp that's driving that voltage seems to be working.  At least, the inputs are at the same voltage.  My HP 5372A Time Interval Analyzer shows that the signal is pretty badly smeared.  Instead of a period of 100 ns, I'm seeing results from about 97 to 104 ns.  I shouldn't see anything but 100 +- 0.2 ns.  But when I look at the EFC lead with my scope, there's no noise on it.  No wonder my frequency counter was having trouble giving me a stable reading!  I think I'm going to have to unsolder the OCXO and see how it performs on its own.

I didn't track the state of the LEDs after powerup, but right now X7 and X8 are flashing together at ~ 1 PPS, X4 is on solid and X5 is flashing about every 2.5 sec. - the same as yours.

Very odd.

Ed

[grumpydoc]

The EFC voltage is 5V36.  Not good.  But the op-amp that's driving that voltage seems to be working.  At least, the inputs are at the same voltage.  My HP 5372A Time Interval Analyzer shows that the signal is pretty badly smeared.  Instead of a period of 100 ns, I'm seeing results from about 97 to 104 ns.  I shouldn't see anything but 100 +- 0.2 ns.  But when I look at the EFC lead with my scope, there's no noise on it.  No wonder my frequency counter was having trouble giving me a stable reading!  I think I'm going to have to unsolder the OCXO and see how it performs on its own.

I'm not sure why 5.36V on the control pin would be "not good" - the range is 0-10V so that's roughly in the middle and it looks like the software thinks the thing is locked.

That jitter is way out, I don't have anything as fancy as a 5372A but you would see that on a 'scope unless it's only a small %age of cycles that are off.

Of course the disciplining algorithm probably isn't aware of the jitter at the cycle-to-cycle level, it probably just looks at a bulk count of oscillator cycles over an interval defined by the 1pps signal from the timing module.

Sounds like the OCXO is failing. 

[edpalmer42]

The EFC voltage is 5V36.  Not good.  But the op-amp that's driving that voltage seems to be working.  At least, the inputs are at the same voltage.  My HP 5372A Time Interval Analyzer shows that the signal is pretty badly smeared.  Instead of a period of 100 ns, I'm seeing results from about 97 to 104 ns.  I shouldn't see anything but 100 +- 0.2 ns.  But when I look at the EFC lead with my scope, there's no noise on it.  No wonder my frequency counter was having trouble giving me a stable reading!  I think I'm going to have to unsolder the OCXO and see how it performs on its own.

I'm not sure why 5.36V on the control pin would be "not good" - the range is 0-10V so that's roughly in the middle and it looks like the software thinks the thing is locked.

That jitter is way out, I don't have anything as fancy as a 5372A but you would see that on a 'scope unless it's only a small %age of cycles that are off.

Of course the disciplining algorithm probably isn't aware of the jitter at the cycle-to-cycle level, it probably just looks at a bulk count of oscillator cycles over an interval defined by the 1pps signal from the timing module.

Sounds like the OCXO is failing. 

Thanks Grumpy.  I misread the spec sheet for the OCXO as being just +-5V.   

The jitter is massive.  I measured 10M cycles and there were hundreds of thousands of hits in each 200ps bin and outliers beyond.  But for most of them, the jitter was only a few % of the period so it didn't really stand out on the scope.  One other thing I noticed is that even on the analog current meter on my power supply, I could see that the current is continuously jittering just a bit.

Ed

[grumpydoc]

Thanks Grumpy.  I misread the spec sheet for the OCXO as being just +-5V.   

The jitter is massive.  I measured 10M cycles and there were hundreds of thousands of hits in each 200ps bin and outliers beyond.  But for most of them, the jitter was only a few % of the period so it didn't really stand out on the scope.  One other thing I noticed is that even on the analog current meter on my power supply, I could see that the current is continuously jittering just a bit.

Hmmm, I am now curious as to whether my unit would have the same fault as I don't think I have a way of measuring it.

The only thing I can say is that my frequency counter (a Racal 1992) has no problem showing a steady frequency from the OCXO output.

[edpalmer42]

Thanks Grumpy.  I misread the spec sheet for the OCXO as being just +-5V.   

The jitter is massive.  I measured 10M cycles and there were hundreds of thousands of hits in each 200ps bin and outliers beyond.  But for most of them, the jitter was only a few % of the period so it didn't really stand out on the scope.  One other thing I noticed is that even on the analog current meter on my power supply, I could see that the current is continuously jittering just a bit.

Hmmm, I am now curious as to whether my unit would have the same fault as I don't think I have a way of measuring it.

The only thing I can say is that my frequency counter (a Racal 1992) has no problem showing a steady frequency from the OCXO output.

Your 1992 is good enough to show the problem, depending on what else you've got available.  Do you have GPIB capability?  Without that, there's nothing you can do.  Basically, you measure the time interval from the rising edge of the NEC 10 MHz on Channel A to the rising edge of another reference (i.e. an Rb, good Quartz, or good GPSDO) on Channel B.  This is a *much* more sensitive measurement than frequency because frequency averages out all the jitter over the gate time.  You store the data on a PC and analyze it with something like Timelab, Plotter, or Alavar - all freeware.

When I did this type of measurement on my unit, I found that although it was being disciplined to the GPS signal, the oscillator was so poor that it wasn't providing any improvement over GPS itself.  I might as well throw it away and just keep the LEA-5T!

Be warned, this junk is addictive.   

Ed

[grumpydoc]

Your 1992 is good enough to show the problem, depending on what else you've got available.  Do you have GPIB capability?  Without that, there's nothing you can do.  Basically, you measure the time interval from the rising edge of the NEC 10 MHz on Channel A to the rising edge of another reference (i.e. an Rb, good Quartz, or good GPSDO) on Channel B.  This is a *much* more sensitive measurement than frequency because frequency averages out all the jitter over the gate time.  You store the data on a PC and analyze it with something like Timelab, Plotter, or Alavar - all freeware.

When I did this type of measurement on my unit, I found that although it was being disciplined to the GPS signal, the oscillator was so poor that it wasn't providing any improvement over GPS itself.  I might as well throw it away and just keep the LEA-5T!

Be warned, this junk is addictive.   

GPIB is on the to-do list but I don't have anything working at the moment.

If I did have GPIB do you know how I get the 1992 set-up for the measurement.

If I use the 1992 to compare the phase of the OCXO output with my Rb standare (5680A) I get a few degrees of variance from reading to reading, as well as the longer term drift from the slight freqency difference, but was never sure whether this was real jitter or measurement error. Even if it is real jitter I would have no way of separating jitter in the 5680 output from jitter in the OCXO output.

The question, of course, is whether the OCXO is performing as expected or whether it is faulty - perhaps it is significant that there are no phase noise figures in the data sheet - it just says "Low phase noise".

[edpalmer42]

Your 1992 is good enough to show the problem, depending on what else you've got available.  Do you have GPIB capability?  Without that, there's nothing you can do.  Basically, you measure the time interval from the rising edge of the NEC 10 MHz on Channel A to the rising edge of another reference (i.e. an Rb, good Quartz, or good GPSDO) on Channel B.  This is a *much* more sensitive measurement than frequency because frequency averages out all the jitter over the gate time.  You store the data on a PC and analyze it with something like Timelab, Plotter, or Alavar - all freeware.

When I did this type of measurement on my unit, I found that although it was being disciplined to the GPS signal, the oscillator was so poor that it wasn't providing any improvement over GPS itself.  I might as well throw it away and just keep the LEA-5T!

Be warned, this junk is addictive.   

GPIB is on the to-do list but I don't have anything working at the moment.

If I did have GPIB do you know how I get the 1992 set-up for the measurement.

If I use the 1992 to compare the phase of the OCXO output with my Rb standare (5680A) I get a few degrees of variance from reading to reading, as well as the longer term drift from the slight freqency difference, but was never sure whether this was real jitter or measurement error. Even if it is real jitter I would have no way of separating jitter in the 5680 output from jitter in the OCXO output.

The question, of course, is whether the OCXO is performing as expected or whether it is faulty - perhaps it is significant that there are no phase noise figures in the data sheet - it just says "Low phase noise".

All you have to do is cable the 1992 and the controller together (you do have the GPIB controller board for the 1992, don't you?) and then write a program to collect the data.  I don't know of any pre-built programs for the 1992.

You're absolutely correct that you can't seperate the jitter in the 5680 from the OCXO.  That's something you always have to remember.  In fact, the 1992 also adds to the mix.  Welcome to the real world!    All you can do is set up the test so that you can get the results you need without interference from the other equipment.  In this case, the 5680 is known to be stable and to have a 'low enough' jitter value that we won't worry about it.  The 1992 has a resolution of 1 ns, so we'll have to run the test long enough to see a solid trend that's significantly greater than the 1992's resolution.  You can also do a noise floor test as I suggested here .  If you run the tests and find out that you're bumping into the limits of the 1992 or the 5680, then you shrug and say "I guess the OCXO is too good to measure with this equipment".

Ed

[grumpydoc]

All you have to do is cable the 1992 and the controller together (you do have the GPIB controller board for the 1992, don't you?) and then write a program to collect the data.  I don't know of any pre-built programs for the 1992.

Yes I have a GPIB card in the 1992, I even have cables and a GPIB card to go in a PC.

However it's an old ISA card which means digging through my old motherboard collection to find something with an ISA bus, hoping that I still have a CPU and RAM to go in it (quite likely, in fact quite likely that they are still in the M/B) and hoping that I can find a hard disk that will talk to it (IDE because I'm fairly sure I have nothing with an ISA bus and SATA even if such a beast ever existed) and a version of Linux which is light enough to go on the ancient processor that it will have.

I think it could be time to pick up one of the Agilent USB<->GPIB interfaces that are kicking around ebay at the moment

If you run the tests and find out that you're bumping into the limits of the 1992 or the 5680, then you shrug and say "I guess the OCXO is too good to measure with this equipment".

That seems as though it will be likely - the resolution given in the manual is 2ns rather than 1 (plus other sources of timing error) which would fit with the variability in the phase difference of a few degrees between readings. I also have to account for the gradual phase drift between the two signals (which was about  2000 seconds for a 360^o shift).

If the FE-5680A is good enough to act as a reference I'll try to get something set up to play with.

[edpalmer42]

All you have to do is cable the 1992 and the controller together (you do have the GPIB controller board for the 1992, don't you?) and then write a program to collect the data.  I don't know of any pre-built programs for the 1992.

Yes I have a GPIB card in the 1992, I even have cables and a GPIB card to go in a PC.

However it's an old ISA card which means digging through my old motherboard collection to find something with an ISA bus, hoping that I still have a CPU and RAM to go in it (quite likely, in fact quite likely that they are still in the M/B) and hoping that I can find a hard disk that will talk to it (IDE because I'm fairly sure I have nothing with an ISA bus and SATA even if such a beast ever existed) and a version of Linux which is light enough to go on the ancient processor that it will have.

I think it could be time to pick up one of the Agilent USB<->GPIB interfaces that are kicking around ebay at the moment

If you run the tests and find out that you're bumping into the limits of the 1992 or the 5680, then you shrug and say "I guess the OCXO is too good to measure with this equipment".

That seems as though it will be likely - the resolution given in the manual is 2ns rather than 1 (plus other sources of timing error) which would fit with the variability in the phase difference of a few degrees between readings. I also have to account for the gradual phase drift between the two signals (which was about  2000 seconds for a 360^o shift).

If the FE-5680A is good enough to act as a reference I'll try to get something set up to play with.

ISA - Ouch!  Yes, I would recommend something a bit more modern.  PCI or USB - either the Agilent one (although I understand from another thread that they're fakes) or a Prologix (sp?) model.

Don't be so quick to dismiss the 1992.  Take a look at the attached graph.  It's some old data that I collected comparing an HP Z3801A GPSDO to an Oscilloquartz 8601 quartz oscillator with the Racal 1992.  The diagonal line on the left is due to the 1992.  Looks like mine is a bit better than spec because at 1 second, it comes in at about 500 ps.  The flat bottom section is the combined noise from the 8601 and the Z3801A.  The rising part on the right is due to aging of the 8601.  Sure, it would be nicer if the counter's line was further down and to the left, but there's still useful data here.  I've also added the 'GPS line'.  That's what I call it.  It shows the approximate performance of GPS.  If you were measuring your NEC against your 5680, you would see the flat part of the line curve down and to the right and follow the GPS line.  That doesn't show up in my data because the aging of the 8601 was too high (yeah, right!  4e-11 per day is too high  ).

Ed

[grumpydoc]

ISA - Ouch!  Yes, I would recommend something a bit more modern.  PCI or USB - either the Agilent one (although I understand from another thread that they're fakes) or a Prologix (sp?) model.

I've ordered one of the "Agilent" USB/GPIB adapters available on ebay. There are a lot of clones knocking around so it could be an adventure in itself.

Don't be so quick to dismiss the 1992. 

OK, after knocking up a 50ohm splitter I tried a little experiment with my sig gen.

With equal length cables the 1992 shows 0ns delay between the two input channels (good start, I thought). With the "B" input having 50cm more of RG58 it shows 2-3ns delay and with 100cm it shows 5-6ns. there doesn't seem to be any way of getting better resolution than 1ns.

RG58 is supposed to be 1.54ns/ft so 50cm should have a propagation delay of 2.52ns and 1m should be 5.05ns so that does all look fairly plausible. With this setup I could improve resolution with some averaging but that won't be any use if we're looking for timing jitter.

So it looks like it might be worth trying to measure the jitter. I will have to compensate for the fact that there will be a slow drift anyway due to the inevitable slight frequency difference (about 5 in 10^-11 when last measured) between the rubidium and the GPSDO and I can't see the resolution being better than 1ns - but if your measurements showing some intervals being as much as 3ns out I should be able to get an idea if the OCXO in mine is similar to yours.

I just have to wait for the GPIB adapter to turn up and fingers crossed I can talk to it in Linux.

[edpalmer42]

Don't be so quick to dismiss the 1992. 

OK, after knocking up a 50ohm splitter I tried a little experiment with my sig gen.

With equal length cables the 1992 shows 0ns delay between the two input channels (good start, I thought). With the "B" input having 50cm more of RG58 it shows 2-3ns delay and with 100cm it shows 5-6ns. there doesn't seem to be any way of getting better resolution than 1ns.

RG58 is supposed to be 1.54ns/ft so 50cm should have a propagation delay of 2.52ns and 1m should be 5.05ns so that does all look fairly plausible. With this setup I could improve resolution with some averaging but that won't be any use if we're looking for timing jitter.

So it looks like it might be worth trying to measure the jitter. I will have to compensate for the fact that there will be a slow drift anyway due to the inevitable slight frequency difference (about 5 in 10^-11 when last measured) between the rubidium and the GPSDO and I can't see the resolution being better than 1ns - but if your measurements showing some intervals being as much as 3ns out I should be able to get an idea if the OCXO in mine is similar to yours.

I just have to wait for the GPIB adapter to turn up and fingers crossed I can talk to it in Linux.

Yes, the frequency drift will cause phase wraps which are a nuisance.  There is software that can deal with them, but the only ones that I know of are Windows based (Plotter, Timelab, and, I think, Alavar).

Ed

[grumpydoc]

Expanding on this a little

Having once again run up my board to the point that it is locked (X4 steady, X5 flashing) I have had chance to play with the time interval measurements on the 1992. I'm not able to log the data until I can talk GPIB to it but have spent a few minutes observing the display.

The easiest to gauge is the drift between the two oscillators - the time interval between the two is drifting by just approx 0.8ns per minute which corresponds to an absolute frequency difference of 133uHz or 1.3x10^-11

The display does not appear to move more than ± 1ns from the "average" point, and most of the time just oscillates between one count and the next. Switching to phase angle allows more precision (since 1^o equates to 277ps) but I'm not sure this is really accessing any more accuracy from the TEC or just noise. Anyway the this will show up to  ±2^o from a central point; readings appear to be displayed to 1^o of precision though..

Now I have looked at very few data points and by eye so hardly conclusive. You said that you had analysed "10M cycles and there were hundreds of thousands of hits in each 200ps bin and outliers beyond" and also mentioned seeing periods from about 97 to 104ns - do you have any histograms to share or are you able to look at it on a SA to give some idea of the phase noise? I get the impression that we are talking 1% or fewer cycles that far out (which is still huge in phase noise terms).

It will take me a fair while to get 10M readings - the 1992 only does about 6 per second!

[edpalmer42]

I won't be able to get to this until the middle of next week, but what I'll do is repeat my tests and then do the tests that you can do to see if anything is visible with just the 1992.

I should have thought of this long ago.

Ed

[grumpydoc]

I won't be able to get to this until the middle of next week, but what I'll do is repeat my tests and then do the tests that you can do to see if anything is visible with just the 1992.

I should have thought of this long ago.

That would be useful. I might even dig the ISA NEC card out and see if it will play.

But the more I think about this the more I think that the OCXO would have to be fairly broken to demonstrate anything except measurement noise with a 1992. I found a fairly nice document discussing OCXO phase noise and jitter here http://sss-mag.com/pdf/vcxophasejitter.pdf and also a couple of OCXO data sheets eg http://www.wild-pc.co.uk/docs/OCXOVT.pdf (or just Google a few) to get an idea of typical phase noise specs (since the data sheet for the TCO-6920A doesn't give us details).

For the OCXO's I've looked at the largest deviation is generally 10kHz (± 100ps), a couple give values at 100kHz (± 1ns). So if we assume something like -120dB/Hz from 1-10kHz that's maybe -80dB in that band or 1/1E8 cycles with periods in the range ±10ps to 100ps which means (I guess) that the other 99,999,999 samples per 100M should be better than that (I think, I struggle a bit with  maths at this level).

Looking at the signal with a time domain instrument with a resolution in the order 100ps to 1ns should really only show measurement noise - it's too blunt an instrument. If it genuinely shows cycles more than 100ps out the phase noise/jitter is going to be hugely out of spec.

It would, I think, be better to look in the frequency domain - a decent SA should be able to show the phase noise directly, as long as the RBW can go down to the 10's of Hz.

I don't have an SA, decent or otherwise so the only way I can look at the frequency domain is to run an FFT on my 'scope - which is not the fastest or most modern instrument (a Lecroy 9354). The best I can do is a FFT over 1M points captured at 1Gs/s. That shows the 2nd harmonic at about 30dB down which seems about right and a bandwidth for the fundamental of 2-3kHz with no particular "shoulder" - translating ±1.5kHz into jitter means ±15ps. Plausible but given the sampling interval of 1ns I'm not sure whether it's a real measurement or fantasy.

[edpalmer42]

Okay, now I've got a third test to do  . I've got an Advantest R3465 SA, but it only has RBW settings down to 300 Hz so I don't know what I'll see.  Timelab can drive it so it's a trivial test - two or three mouse clicks, sit back and watch.

Ed

[grumpydoc]

Okay, now I've got a third test to do  . I've got an Advantest R3465 SA, but it only has RBW settings down to 300 Hz so I don't know what I'll see.  Timelab can drive it so it's a trivial test - two or three mouse clicks, sit back and watch.

If you are really getting jitter of ±3ns then it should show up as a lot of spectral content up to a couple of hundred kHz away from the nominal 10MHz signal so 300Hz RBW should be OK.

If it is working properly and you wanted to measure the phase noise it might be a bit limited.

One thought - with your original measurements did you look at the OCXO output directly or the LVDS? It would be worth repeating all measurements with both signals.

Disclaimer: I'm making this up as I go along (but hopefully learning as I do so - I certainly understand the FFT on the 'scope a whole lot better).

[edpalmer42]

My original measurements were made directly off the oscillator via a x10 probe.  I haven't looked at the LVDS signals at all.

Making things up is a great way to figure things out.  I do it all the time! 

Ed

[grumpydoc]

My original measurements were made directly off the oscillator via a x10 probe.  I haven't looked at the LVDS signals at all.

In which case it might be worth considering trigger jitter as a source of error, especially as the signal isn't especially high after a 1:10 attenuation so noise will affect the triggering more.

If there is a significant difference between the sine and square wave outputs then that might be the cause of some of the error.

That said the Lecroy is hopeless at triggering cleanly but even it only reports about ± 0.5ns variability in period.

[edpalmer42]

My original measurements were made directly off the oscillator via a x10 probe.  I haven't looked at the LVDS signals at all.

In which case it might be worth considering trigger jitter as a source of error, especially as the signal isn't especially high after a 1:10 attenuation so noise will affect the triggering more.

If there is a significant difference between the sine and square wave outputs then that might be the cause of some of the error.

That said the Lecroy is hopeless at triggering cleanly but even it only reports about ± 0.5ns variability in period.

Although trigger jitter is a consideration, the results were so bad that it's unlikely that it was a significant factor.  I also made measurements on a couple of really high quality oscillators.  Now those results might have been degraded by trigger jitter but they were much, much better than the results for the Epson OCXO.  I'll include the high quality oscillators when I post in a day or two.

Be warned, it'll be a long post! 

Ed

[grumpydoc]

Although trigger jitter is a consideration, the results were so bad that it's unlikely that it was a significant factor.  I also made measurements on a couple of really high quality oscillators.  Now those results might have been degraded by trigger jitter but they were much, much better than the results for the Epson OCXO.  I'll include the high quality oscillators when I post in a day or two.

Ah, that gives a lot more confidence that measurements are valid.

[grumpydoc]

Be warned, it'll be a long post! 

Looking forward to it.

In the meantime I pulled a few FFT pics off the LeCroy

Spectrum for the OCXO output (click on the picture for full size) - span here is 0-100Mhz and 10dBm per division. 10MHz fundamental with 1st harmonic approx 30dB down


Zoomed in on the fundamental, centre 10Mhz and span just 9.990Mhz to 10.01Mhz (10MHz ±10kHz)


Rather crude but if we take it at face value we have ±1kHz at 10dB down and anything more than ±2kHz more than 70dB down. It should really be a narrower trace but the effective RBW is 1kHz so it's a pretty blunt tool.

[Vgkid]

Looking forward to edpalmers update.

[grumpydoc]

Looking forward to edpalmers update.

Likewise - it's a pity I can't make the same measurements as Ed or that I don't have some more appropriate test equipment

I'm fairly sure that whatever the 'scope FFT shows it is not phase noise with a 1ns sampling period. Possibly a bit of AM due to noise.

I'm not even that sure about that 2nd harmonic, given that I will only get 100 points per cycle.

There doesn't seem to be anything which would correspond to 3ns of jitter though.

[edpalmer42]

I've got some measurements!

I compared my NEC GPSDO, which I suspect has a bad OCXO, to my HP Z3801A GPSDO and my Efratom FRT Rubidium Standard.  I used both the Racal-Dana 1992 and the HP 5372A to show the capabilities of both.  During the measurements, the NEC was monitored with u-center by eavesdropping on the LEA-5T output to the micro.  The Z3801A was monitored by Z38xx.  Both units were properly locked to GPS.

The 1992 measurements were Time Interval measurements.  Input A was a 'scope probe set to x1 to give a larger signal and reduce trigger jitter.  It was connected directly to the OCXO output on the NEC or via a BNC probe adapter to the terminated output of the FRT.  Input B was connected to the Z3801A.

The first picture shows the results.  Both graphs are together for time intervals below 100 sec.  This is the result of the resolution of the 1992.  Note that at one second, it's just under 1e-9 which is the resolution of the 1992.  After the 100 second point on the graph, the blue line turns and flattens.  This shows the two GPSDOs being disciplined and tracking each other as they should.  The level that they're at (~6e-12) shows the composite noise for both of them.  It could be one or the other or both.  You can't tell.  The black line shows the same test for the Z3801A vs. the FRT.  Since it continues down further than the blue line, you can conclude that this combination has lower noise than the NEC.  Therefore, the 6e-12 noise is due to the NEC.  If I had run the test longer, the black line would have turned and followed the 'GPS line' which is the approximate performance limit of GPS.

The remaining pictures show my 5372A tests.  This particular test does very fast measurements of the signal's period and increments whichever counter is valid for that measurement.  Each of these tests consisted of 10 million measurements.  The first picture shows the Z3801A.  Out of 10M measurements, 9.2M were in the 100 ns bin.  Next is the FRT.  Even better at 9.7M measurements.  Finally, we have the NEC.  Well....  I think you can see the problem.  I didn't bother to add these up.  There were a screen above and below with the outliers.

One disadvantage to using something like the 1992 is that you have to trade resolution for time.  It takes longer for the graph to dig down to the low levels you want to look at and that gives more time for things to go wrong.  Temperature changes, GPS changes, and noisy connectors will have you cursing.  It took me two runs to get the Z3801A-FRT graph because a connection went noisy and spoiled the data.

To be honest, I expected the 1992 results to be more pronounced than they were.  The 5372A results were so obvious that the relatively good results of the 1992 tests was a bit of a surprise.  But it still shows that the 1992 is capable of showing the difference between my NEC and the other units.  The question for Grumpy is whether his 5680 is quiet enough to show the difference.

This message is big enough.  I'll post the Spectrum Analyzer pictures in a new message.  I have to get set up to take those measurements so it'll be later today.

Ed

[grumpydoc]

I'm looking forward to the SA data as confirmation but the OCXO does, indeed, look as though it is completely broken.

To the precision that I can measure I'm not seeing the same for mine - but Ed has an instrument with 5x the time domain resolution, and I don't have any instrument to look directly at the frequency domain.

I'm still waiting for the GPIB adapter which might be a while.

I might see if I can use the 'scope as a glorified data logger, especially with the interleaved sampling as that potentially gets me down to 100ps resolution (though I'm not sure whether the act of interleaving samples will destroy the data I'm trying to see).

[edpalmer42]

Here are the spectrum plots, but they don't show anything obvious (to me at least).  The levels for the NEC are low because I used a low-impedance, high-bandwidth x10 probe to prevent loading the OCXO down in case it's internally terminated in 50 ohms.  The probe looks like 500 ohms so it should be okay.  The other plots were a direct 50 ohm connection.

The phase noise plots are giving me a bit of trouble.  The mention of FFT reminded me that my 5372A has an FFT option that lets me make phase noise measurements within the unit's 150 ps resolution.  If I'm willing to wait long enough, I can make measurements 1 Hz from the carrier.  Whether the numbers are valid is another matter!  I'm trying to get some consistency between the HP 5372A and the Advantest R3465 spectrum analyzer.  Give me a day or two to work through it and make sure that the measurements make sense.

Ed

Edit:  The plot labelled 'FRK' is the FRT Rb Standard.  FRT is the name of the unit.  FRK is the Rb Standard inside the unit.

I also tried zooming in on the carrier to look for any difference between the NEC and the others.  At RBW=300 Hz and VBW=1 Hz they looked the same.

[grumpydoc]

The phase noise plots are giving me a bit of trouble.  The mention of FFT reminded me that my 5372A has an FFT option that lets me make phase noise measurements within the unit's 150 ps resolution.  If I'm willing to wait long enough, I can make measurements 1 Hz from the carrier.  Whether the numbers are valid is another matter!  I'm trying to get some consistency between the HP 5372A and the Advantest R3465 spectrum analyzer.  Give me a day or two to work through it and make sure that the measurements make sense.

You can probably resolve AM 1Hz from the carrier if you get enough samples. I don't see how you can resolve phase noise/modulation that close with 100ps of time resolution because the difference in period between 10Mhz and 10.000001MhH is only 10 femtoseconds 

You'd need to be looking at 10kHz deviation before the difference in period was > 100ps.

Thinks I have a Marconi 2305 modulation meter somewhere that I picked up at a rally for peanuts. I wonder if that is any use in looking at the phase noise.

[edpalmer42]

I think you're probably right.  I haven't attempted to sort through the math to see what I could expect in terms of offset frequency and dBc/Hz values.  But here's a couple of things I noticed.

Device      'Alleged' phase noise @ 1 Hz offset via the HP 5372A
Z3801A      -56 dBc/Hz
FRT            -55
NEC           +52  Plus?  Really?  Is that even possible??

So I figured that this was some kind of noise floor in the mid -50s.  Fair enough.  The Z3801A and the FRT are rated better than this.  Then I measured a Datum FTS-1200B OCXO which has specs that are much better than the Z3801A or the FRT.  I got a value of -64 dBc/Hz which is also much worse than the spec.  Now I don't know what I'm measuring.

Ed

[edpalmer42]

Well, the phase noise tests were pretty much a bust.

As you can see in the first picture, below 3 KHz, all I'm seeing is the resolution limit of the R3465.  Above 3 KHz, the NEC, Z3801A, and FRT all measure about -105 dBc/Hz, in other words, the noise floor of the R3465.  Above about 40 KHz, the NEC noise floor is high enough to measure while the others are good enough that I'm just measuring the R3465 again.

The HP 5372A noise floor was around -90 to -95 dBc/Hz so it didn't show anything.

And now, after all this screwing around, it looks like the NEC isn't as bad as I thought.  It turns out that there's a relatively strong (-30 dBc) 20 MHz component on the OCXO output.  This was confusing the 5372A and making the OCXO look much worse than it really is.  When I filter that out, the results in the second picture look fairly good.  It didn't affect the phase noise measurements because they're so close to the 10 MHz carrier that they didn't see the other signal.

Note to self:  Always look at the bloody signal first!!

 

Ed

[edpalmer42]

In an attempt to redeem myself after wasting everyone's time, I've had a bit of a breakthrough in talking to the unit and getting it to respond.  Connect to the MCU port on the main connector at 115200,8,N,1.  I used a MAX232 equivalent to do the interfacing.  Remember that it's only 3V3 so don't use a 5V chip.

It looks like it's speaking TL1 https://en.wikipedia.org/wiki/Transaction_Language_1.  Lukier's post that showed the output during bootup gave me the clue.  Those semicolons at the end of each line gave it away.  Unfortunately, that means that it's going to be very difficult to figure out what the commands are and what the responses mean because each company can do whatever they want. 

The only command I've found so far is 'status;'.  It accepts upper or lower case.  All commands must end with a semicolon.  The response was 'STATUS=2,A,W;' with no antenna attached, 'STATUS=4,A,W;' a few minutes after connecting the antenna and 'STATUS=3,O,T;' after about 30 minutes.

Another valid command might be 'restart;'.  It results in a 'SYNTAX_ERROR;' response instead of 'UNKNOWN_CMD;' so maybe there's something missing.

It looks like the command interface times out after 5 or 10 minutes with no input.  Disconnect and reconnect to reestablish communications.

Ed

[grumpydoc]

Good discovery regarding the TL1.

I don't think that the measurements etc were a waste of time, you probably now know your test equipment better now at the very least.

The phase noise plot is reassuring and, as you say the harmonic content is easily filtered - in fact it looks like there is a filter on the board which I've always assumed is a low pass filter to clean up the output from the OCXO before converting to logic levels.

But -30dBc harmonic content is not unusual for an OCXO - nor indeed for a signal generator which are usually something like -25dBc to -30dBc, and the Z8301 is not all that much better if you looks at the spectrums  on the SA but gave a much tighter spread of timings on the 5372A - basically everything was +/- the precision of the instrument which is what you'd expect. Even with some filtering the NEC .was not as tight.

Still something slightly odd here I think.

Did you look at the square wave LVDS output on the 5372A?

[edpalmer42]

More testing showed that the problem wasn't really the 20 MHz harmonic after all.  I wasn't being careful enough when I was probing the signal.  External noise (mainly local FM broadcast signals) was visible on the signal.  When I used my low impedance probe and better grounding on the probe, those signals disappeared and the numbers reported by the 5372A improved to the point where there's no significant difference between the NEC when probing at the oscillator and the FRT or the Z3801A.

As for the LVDS, it was a fussy, finicky, PITA measurement that required 3 hands, but I did it.  If you can use that output, it's definitely the way to go.  I looked at the + signal on one of the 10 MHz outputs with my low impedance, 700 MHz probe.  The rise and fall times are too fast for my poor 100 MHz scope - all I saw was the scope's limit of ~ 3.5 ns.  The signal was 0.4 Vp-p with a DC offset of ~1V2.  I don't have a picture, because that would have required yet another hand!  It was a nice, clean square wave with minimal overshoot or other aberrations.  But I was able to get the 5372A measurement.  See below.

Ed

[Velund]

The only command I've found so far is 'status;'.  It accepts upper or lower case.  All commands must end with a semicolon.  The response was 'STATUS=2,A,W;' with no antenna attached, 'STATUS=4,A,W;' a few minutes after connecting the antenna and 'STATUS=3,O,T;' after about 30 minutes.

Good find. Maybe it will be possible to make a simple and meaningful front panel status indication using some PIC and few LEDs...

[jpb]

I see someone is looking to make a good profit on one of these - though to be fair, the price is reasonable if it works ok - it is just more than 4 times the original sellers price:

http://www.ebay.co.uk/itm/10MHz-GPS-Disciplined-Oscillator-GPSDO-/151847766917?hash=item235ad50b85:g:7WQAAOSwLqFV9Zp8

[Velund]

The only command I've found so far is 'status;'.  It accepts upper or lower case.  All commands must end with a semicolon.  The response was 'STATUS=2,A,W;' with no antenna attached, 'STATUS=4,A,W;' a few minutes after connecting the antenna and 'STATUS=3,O,T;' after about 30 minutes.

Another valid command might be 'restart;'.  It results in a 'SYNTAX_ERROR;' response instead of 'UNKNOWN_CMD;' so maybe there's something missing.

It looks like the command interface times out after 5 or 10 minutes with no input.  Disconnect and reconnect to reestablish communications.

Ed

I suspected that some of fields in responce to status command actually related to OCXO, and left my unit without GPS antenna for a few hours (just to see if W means Warmup), but no, it still was 'STATUS=2,A,W;' after 3 hours. BTW, I do not see any timeouts, left terminal open for 20 mins without input and it was still responsive

Playing with commands, I found another one... It is 'debug'...

If entered without parameters, it returns two 16-bit hex values alternately

debug;

0000;
debug;

00A9;
debug;

0000;
debug;

00A9;
debug;

0000;

Tried to enter some parameter and got some 'stable' responce...

debug 0;

00A9;
debug 0;

00A9;

Looks like it accept any hex value as a parameter...

debug 0000;

00A9;
debug 0001;

3373;
debug 0002;

3235;
debug 0003;

FFFF;
debug 0004;

412F;
debug 0005;

0432;
debug 0006;

0150;
debug 0007;

0000;
debug 0008;

0000;
debug ffff;

FFFF;
debug fffe;

FFFF;
debug 8000;

FFFF;
debug 012A;

1000;
debug 012b;

8A80;
debug dead;

FFFF;
debug deadbeef;

FFFF;

If it is simply a dump of words from MCU address space, maybe there is a chance to 'milk' flash contents and look for the rest of commands?

[Velund]

Experimented with status command little bit. Started with unit that stayed power on for about 6 hours without GPS antenna connected. Programmed 'status;<cr><lf>' to a hotkey to send command by one keypress...

Before connection of antenna , X3 and X4 blinked and status returnng  'STATUS=2,A,W;'.
about 20 sec after antenna connection LEDS changed to steady X3 and status started to return  'STATUS=4,A,W;'
Observed brief blink of X3 and pressed a key immediately, got  'STATUS=4,A,I;'... In a second another keypress returned "A.W" again.
Started here to poll it every second or even faster. In a few minutes seen once more switch to "A,I" but again momentarily, just a single reply between "4,A,W"'s...
Got a phone call and was forced to switch my attention to more important things for a 20 min or so.
When returned to this stuff, observed blinking X4 and status switched to 'STATUS=3,O,T;'.
Tried to disconnect antenna. Status almost immediately switched to 'STATUS=2,O,H;'. X3 and X4 started to blink.
Reconnected antenna. Status in a few moments switched to 'STATUS=1,O,H;' for a few seconds, then returned to 'STATUS=3,O,T;'.
Disconnected antenna again. Status almost immediately switched to 'STATUS=2,O,H;'. X3 and X4 started to blink.
Connected another antenna that was indoors and wrapped by aluminium foil (no GPS signal, but normal antenna current). Status almost immediately switched to 'STATUS=1,O,H;'. X3 and X4 continue to blink.
Now it stays in '1,O,H' for about 10 minutes, will look what will happen later.

So, for now I observed following values:
First field - 1,2,3,4... Yet to figure out what it really mean, but seems 1 is for no lock at all, 2 for antenna problems, 3 for timing lock and 4 for position-only lock or maybe position survey mode?
Second field - characters "A" and "O". Can someone imagine that "O" means "Operational"?
Third field - characters "W", "I", "T", "H". Maybe "W" is for "Warmup" or "Waiting", "T" for "Timing", and "H" is for "Holdover"? What may momentary "I" mean then?

[PA0PBZ]

Dit you see this?

https://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/msg741902/#msg741902

Same STATUS=3,O,T so what about the other commands there like inv; ?

[Velund]

Dit you see this?

https://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/msg741902/#msg741902

Same STATUS=3,O,T so what about the other commands there like inv; ?

Thank you for reference. Yes, it is the same command set... Below is responces of unit in holdover for 1.5 hours, seening no sats but with antenna (in foil) connected...


inv;

INV=NECGPS,057706,003xxx,00,057706,0172,,,6920N02442,0169;

Based on information from another thread:
INV=a,b,c,d,e,f,g,h,i;<cr><lf>
a: Name of the module (Max 12 char.) : NECGPS
b: Article number (Max. 6 characters) : 057706
c: Serial Number (Max: 6 characters) : 003xxx (last digits removed here)
d: Hardware version (Max. 2 characters): 00
e: Firmware article number (6 characters) : 057706
f: Firmware version (4 characters) : 0172
g: Date of test (format : DD/MM/YYYY) : <missing>
h: Version of test system (Max. 4 characters) : <missing>
i : Oscillator's type ( Max. 10 characters) : 6920N02442
j: FPGA version (4 characters) : 0169

conf;

CONF=0,0,A,+00:00,+0;
alarm;

ALARM=2;
gps_time;

GPS_TIME=1880,139398,01.07.15,00:00:00,00,17;
info_track_sat;

INFO_TRACK_SAT=0;
status;

STATUS=1,O,H;
temperature;

TEMPERATURE=+39.67;
type;

TYPE=4500,OEM_01;
atdc_status;

ATDC_STATUS=0,0;
hold_perf_status;

HOLD_PERF_STATUS=0;
info_vis_sat;

INFO_VIS_SAT=0;

[Velund]

Programmed another command to other hotkey and removed foil from antenna... Polled it alternately  for status and number of sats with about 2 sec interval...

status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=0;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=1,
1,30;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=2,
1,8,
2,30;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=2,
1,8,
2,30;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=2,
1,8,
2,30;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=2,
1,8,
2,30;
status;

STATUS=1,O,H;
info_track_sat;

INFO_TRACK_SAT=4,
1,7,
2,8,
3,27,
4,30;
status;

STATUS=3,O,T;
info_track_sat;

INFO_TRACK_SAT=5,
1,7,
2,8,
3,27,
4,28,
5,30;
status;

STATUS=3,O,T;
info_track_sat;

INFO_TRACK_SAT=5,
1,7,
2,8,
3,27,
4,28,
5,30;
status;

STATUS=3,O,T;

[Velund]

Just for reference for someone who'll dare to make a fancy front panel status display for this module (or for a oscilloquartz board, or for both)... If I didn't start doing it myself using those $3 STM32 module and $3 1.8" SPI TFT LCD from eBay...

Responces from unit seening sats, in operational mode.

inv;

INV=NECGPS,057706,003xxx,00,057706,0172,,,6920N02442,0169;
conf;

CONF=0,0,A,+00:00,+0;
alarm;

ALARM=N;
gps_time;

GPS_TIME=1880,145528,01.07.15,00:00:00,00,17;
info_track_sat;

INFO_TRACK_SAT=6,
1,8,
2,11,
3,13,
4,15,
5,18,
6,19;
status;

STATUS=3,O,T;
temperature;

TEMPERATURE=+39.78;
type;

TYPE=4500,OEM_01;
atdc_status;

ATDC_STATUS=0,0;
hold_perf_status;

HOLD_PERF_STATUS=0;
info_vis_sat;

INFO_VIS_SAT=13,
1,5,12,228,18,2,
2,7,26,97,29,2,
3,8,21,40,42,2,
4,11,12,83,28,2,
5,13,65,268,16,2,
6,15,32,303,38,2,
7,17,13,159,21,2,
8,18,9,336,37,2,
9,19,9,160,20,2,
10,20,22,276,25,2,
11,27,1,18,15,2,
12,28,74,172,23,2,
13,30,57,98,26,2;

[Velund]

Tried all commands described in Oscilloquartz document in the following post:

https://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/msg740339/#msg740339

NEC board recognized all commands except one - 'tod_state;'

Not tried to set some parameters but checked that keywords is accepted (syntax error instead of unknown command response).

Manual switch to holdover mode works, may be useful to turn off disciplining during precise measurements.

Funny response to warm restart command:

restart(w);

OK(BUT NOT IMPLEMENTED);



Right after power-up seen status 'STATUS=0,A,I;' that quickly changed to 'STATUS=4,A,I;' and in a few minutes to 'STATUS=4,A,W;'...

From the abovementioned document:

STATUS=l,g,rm;<cr><lf>

l: LED's status:
l = 0 => OFF
l = 1 => Red
l = 2 => Red, blinking
l = 3 => Green
l = 4 => Green, blinking
l = 5 => Red-Green, alternate
l = 6 => Orange
l = 7 => Orange blinking

g: GPS status
g = A => GPS is in alarm
g = O => GPS is OK

rm: Real mode (I: Init, W: Warm-up, F: Fast, T: Tracked,
H: Holdover, S: Squelched)

[Velund]

Let it run for about 48 hours without interruptions - but response of 'hold_perf_status' command remained the same.

atdc_status;

ATDC_STATUS=0,0;
hold_perf_status;

HOLD_PERF_STATUS=0;

Looks like this commands is only for compatibility, and there is no real ATDC support.

[NivagSwerdna]

This thread seems to have gone quiet... I notice that some of these units have come onto ebay eBay auction: #182145209432 although the price seems to be 4x higher than before.

I'm quite interested by this device, particularly as the uBlox receiver has good performance.

How are you lucky (at a low price) owners doing?

[lukier]

This thread seems to have gone quiet... I notice that some of these units have come onto ebay eBay auction: #182145209432 although the price seems to be 4x higher than before.

Whoa, the seller copied my and grumpydoc posts verbatim (pinouts etc) in the description. No reference to either this thread or the respective authors. Not cool.

TBH the price is crazy for a spare, used, part from a base station. One can get Symmetricom GPSDO or BG7TBL for much less.

How are you lucky (at a low price) owners doing?

I haven't finished my Extron distribution amplifier + GPSDO + NTP server yet  I have all the parts, I've modded Extron to 50 ohms, but I still need to etch some accessory PCB and wire everything up. Maybe I'll finish that project this summer.

[NivagSwerdna]

TBH the price is crazy for a spare, used, part from a base station. One can get Symmetricom GPSDO or BG7TBL for much less.

I have a Symmetricom but this looks better, the spec of the PPS from the GPS receiver is certainly much better.  Shame about the price.

[grumpydoc]

Whoa, the seller copied my and grumpydoc posts verbatim (pinouts etc) in the description. No reference to either this thread or the respective authors. Not cool.

Indeed. Much more annoying from my point of view is the fact that he just scraped the list of links from my post which means that he's using my bandwidth for the OCXO datasheet. Lazily he could not even be bothered to check that the linked-to documents are still there.

TBH the price is crazy for a spare, used, part from a base station. One can get Symmetricom GPSDO or BG7TBL for much less.

While the Symmetricom units are around it is rather steep. However once those have dried up - and there are some suggestions that this is happening - it will be more achievable.

Look at what happened to the price of Rubidium units, dirt cheap for a while then the supply dried up and they quadrupled in price. Actually it looks like those have dropped a bit again and there are more on sale than the ast time I looked.

Almost tempted to pick up a spare.

[NivagSwerdna]

Almost tempted to pick up a spare.

I think US$199 is too much for me. I will keep an eye out in case more become available and the price goes down.  At around US$120 I would probably part with some cash.
I never intended to get a GPSDO and here I am looking at another one  It was a thread on this blog that got me started on this frequency nuts stuff 

[DimitriP]

199.00  Ha!   I needed a good laugh

[edpalmer42]

Almost tempted to pick up a spare.

I think US$199 is too much for me. I will keep an eye out in case more become available and the price goes down.  At around US$120 I would probably part with some cash.
I never intended to get a GPSDO and here I am looking at another one  It was a thread on this blog that got me started on this frequency nuts stuff 

Yeah, this stuff is addictive.  Guess how I know!     

Ed

[texaspyro]

There's another seller on Ebay for $129+$15 shipping.  I just ordered one:

http://www.ebay.com/itm/10MHz-GPS-Disciplined-Oscillator-GPSDO-/252610556561?hash=item3ad0c33291:g:ZLwAAOSw44BYFIlb

The commands that these speak are compatible with the Oscilloquartz Star-4 GPSDO (except at 115200 baud,  Star-4 is 9600 baud).   I now have Lady Heather working with the Star-4. hopefully it will also work with these...  that version (complete with New and Improved Documentation (tm)) should be out in a couple of weeks.

[texaspyro]

Lady Heather version 5.0 is now available for download from:
   http://www.ke5fx.com/heather/readme.htm

Many thanks to John Miles for hosting the distribution and his work on the Windows installer, PDF documentation file, readme file, and bring an all-around good guy.

Heather now has some proper user documentation.  Check the heather.pdf file and/or the comments in the first 3500+ lines of the heather.cpp file.  Heather can be compiled for Linux (including the Raspberry Pi) and macOS.  Download the heatherx11.zip file and check the readme.txt file for compilation instructions.

There are MANY new features in Heather.  One of the main ones is support for many new receiver types.  When Heather is started it defaults to attempting to automatically determine the receiver type.   You can bypass this and force the receiver type using the new "/rx..." command line options.  Some receiver types cannot be auto-detected.  Also many receivers power up speaking NMEA and you can enable their native binary language using the /rx commands.  Native binary mode gives better information and allows controlling the receiver configuration and settings.

Currently-supported receivers include:
Trimble Thunderbolt and Thunderbolt-E
Acron Zeit WWVB receiver
UCCM - Trimble / Symmetricom GPSDOs
DATUM STARLOC II GPSDO
NEC GPSDO (STAR-4 compatible)
GPSD interface
Jupiter-T (aka Zodiac)
Lucent KS24361 REF0/Z3811A (19200:8:N:1)
Motorola binary format
Generic NMEA receiver
Trimble Resolution T family with odd parity
Sirf binary
Generic Trimble TSIP binary
Ublox UBX binary
Venus mixed binary / NMEA
Nortel SCPI-compatible GPSDOs (NTWB, NTPX, etc.)
Z3801A and compatible SCPI GPSDOs
HP 5xxxx-style SCPI
Oscilloquartz STAR-4 (via the management interface)
NVS binary
PC system clock (no receiver)

After installing Heather, you should edit the heather.cfg file (or the PROPERTIES setting for the desktop icon) for your desired configuration.  Everybody should change the "/tz" option for their time zone... it comes set up for the US central time zone.  International uses should add a "/b..." command to set their daylight savings time information.   On Windows, you can press the "n" key and that will bring up NOTEPAD to edit the file.  For the changes to take effect you will need to re-start Heather (or do a "r heather.cfg" keyboard command).

[texaspyro]

There's another seller on Ebay for $129+$15 shipping.  I just ordered one:

http://www.ebay.com/itm/10MHz-GPS-Disciplined-Oscillator-GPSDO-/252610556561?hash=item3ad0c33291:g:ZLwAAOSw44BYFIlb

The commands that these speak are compatible with the Oscilloquartz Star-4 GPSDO (except at 115200 baud,  Star-4 is 9600 baud).   I now have Lady Heather working with the Star-4. hopefully it will also work with these...  that version (complete with New and Improved Documentation (tm)) should be out in a couple of weeks.

The first GPSDO that I got in was reporting a bad oscillator.  I sent him some information and links on how to talk to the device.  He sent a replacement unit (he actually sent two replacement units) and it is working properly. 

Lady Heather version 5 that can work with the NEC (and Oscilloquartz Star-4) GPSDOs has been released and is available on ke5fx.com  John has a Windows installer version and the X11 version for Linux or macOS. 

[texaspyro]

I had the NEC GPSDO running with Lady Heather to capture the leap second... the NEC didn't handle it well.  It reported the date as 30 Nov 2016 a couple of times and went into holdover mode.  I wonder if any WiMax systems in Japan crashed?

Log snipped attached...

[Ernie]

I just got my board, and powered up running very nicely also figure out the X2,X3,X4, and X5 LED. After about 3hrs the X5 LED blinking every 3rd sec. and X4 LED is ON.Seems to me that there is a long warming up period as mentioned before.
Nex week I am going to make an ADEV measurement to see the quality of the OCXO.
The X2 LED is still a question-mark....?
Any additional help appreciated.

[Pifke]

whats to do - to connect this board, to a pc with running lady heather soft. have got one for 46 €

is any shematic available

greetings 


@ Ernie same here - waiting for LED X5 at monent

[Pifke]

with the TI Datasheet i was confused .. Maxims Datasheet  shows me the right way , the max3243 is a ""newer"" max232.

[ilexprikle]

Help, I've just discovered this thread and hope somebody may be able to solve my problem.  I bought one of these NEC GPSDO PCBs when they were first put onto Ebay, when it arrived I didn't have time to get it going and when I looked at it recently it appears that there is a surface mount device missing near the 2R7 resistors see the photo below.  It looks like it may have dropped off in transit but I carefully looked through all the packing and couldn't find it. Does anyone know what this device is or can tell me the marking code on it?

The oscillator module appears to be ok and I'm really hoping I can get this board going.

Thanks
John

[Loddestuen]

On my board the part is marked "S G"

[ilexprikle]

Hi, Loddesteun, that's very helpful, thank you.  Initial info from the web suggests it might be a Toshiba PNP 2SA1162-GR which isn't difficult to replace.  I'll do a bit more checking and if nothing contradictory comes up, I'll replace it and do the big switch on.
Thanks again.
John

[SrS]

Does anyone know the type of connector used for Z2 & Z5? and maybe even where to get it in single quantities?
Or is everyone just soldering wires somewhere on the board to tap of signals?

They're still being sold on Ebay usually for more acceptable prices compared to the past.
Like: https://www.ebay.com/itm/NEC-EPSON-TOYOCOM-TCO-6920N-10MHz-GPS-Disciplined-Oscillator-GPSDO/254344933612
Or with different OCXO: https://www.ebay.com/itm/NEC-10MHz-GPS-Disciplined-Oscillator-GPSDO-GPS/263985049514

[eevjohn]

.
Many thanks to all the contributors in this thread who have helped with valuable information about the NEC board.
It has enabled my making up a successful GPSDO project.

I used that very same board ex China via eBay, added a box, two RS232 ports, and an RF amp to give 10 MHz “almost sine” output at +7dBm50.
It has a clear plastic top box so I could read the LEDs.

I have checked my GPSDO against another two GPS references and it works well.

Like any project of this type, and without an NEC board circuit, going from prototype to final with constant design change as you go, my GPSDO project is a little scattered and a bit messy inside.
I also broke quite a few design and construction rules, but the outcome is a working unit.

The RF Amp is an LNA PCB ex eBay with SPF51 MMIC type amp, with input and output coupling caps changed to 1000 pfd, and collector inductor changed to 1 mH approx.
This to modify the response “start” down from 50 MHz to below 1 MHz.
The caps are just soldered in parallel with the existing SMDs.

The RF Amp has the 400 mV PP LVDS 10 MHz differential signal as an input, after a 10 MHz LC filter, and produces an unbalanced 50 ohm output at a nominal level.
The Amp output level is set by slightly mis-tuning the filter output tuned circuit.

To take NEC PCB signals “off board” I just “isolated” them with 0.1 MF caps and sometimes with 100R resistors, or both C and R.
The MAX232 signals lines have 100R resistors as isolators to protect the NEC board drivers.
I didn’t use any board connectors on the NEC PCB, I just soldered directly to PCB or components.

Caution that the roughie circuits may not be exactly correct, and is more of a working conceptual record just for myself, but you will get the general idea.

My GPSDO 10 MHz powers up from cold at approx  -3 Hz and settles at 10 MHz after six hours, and best left for two days.
It shows “no alarms” after about three hours.

I use an eBay GPS antenna with +25 dB gain, and placed on my workshop inside window ledge.
The connection from NEC board SMB antenna socket to GPS Ant BNC is in RG316, and is DC connected for the GPS antenna amp.
My SMB “plug” is one “insert” from a 14 pin DIL IC socket.

The project requires 12 V DC at about 1.5 amps at power up, dropping to approx 300 mA after a while.
The unit may not start up correctly with a 1.0 A supply.

This NEC Board has no memory, so if there are any interruptions to DC supply, it goes through a whole power up sequence, and a whole 3 hour period before clearing any alarms (ie ALARM = N).

LEDs after 5 mins – X3 ON, X7 and X8 flash every 1 second.
LEDs after 3 hrs – X4 ON, X5 flashes every 5 secs, X7 and X8 flash together every 0.5 second.

The Terminal Dialog is similar to the Oscilloquartz STAR4+ Doc Spec, and attached is my collection of sample commands and actual replies via the “Service Port” on my NEC board.
The “Time Of Day” port outputs TOD data every second; no keyboard entry required.

A lot of the above has already been described in previous posts, but collated here.

Attached are some photos, Terminal Port Dialog, roughie interconnect circuits.

[Loddestuen]

Hi all,

I have had this board for some time now.. But I can not seem to get it to talk to my PC..

I'm a mechanical engineer, so bare with me.. I can read tech stuff, I have my own electronics hobby lab and i collect and repair vintage test equipment - mostly HP :-) So not all lost..

I have read this thread through 10 times, but I still cant figure out how to get the NEC board to talk to my PC (U-center or Lady Heather)

My PC has a real COM-port - soldered in.

But..
1) Where on the board do I connect which wires?
2) Do I need anything in between the board and the COM cable?
3) Do I need to change the COM port config in Windows (7) or in U-center / Lady Heather?

Please lent me a hand here..

Thanks,

Cheers from Denmark..

[Loddestuen]

In addition to the above out cry for help, I could add some info that might benefit other owners..

Its about the SINE OUT from the OCXO box..

OCXO direct output is only 1,25 V p-p

But the sine OUT at solder pad by mounting hole with respect to GND: 

2V p-p @1M ohm load with my scope.

Loading this OUTPUT with 50 Ohms results in 1V p-p - so I guess this output (if avalible at your PCB) is a 50 Ohms output..

The output (solderpads) are the ones with the yellow wires attached. 

[eevjohn]

Hello Denmark


But..
1) Where on the board do I connect which wires?

The “terminal” signals on the NEC board are TTL levels and must be converted to RS232 voltage levels.
I used a dual bi-directional driver MAX232N.
Be sure to add the 0.1 capacitors C1 – C4 as per datasheet.
Connect the MAX232 TTL inputs and outputs to the NEC board signals near connector Z5.
Connector Z2 is on the other side of the board, but solder points near Z5 were easier for me.

Z2 connector pin 33 is TOD TX Data; no handshake required.  TXD every second.
Z2 connector pin 29 is RX Data from the user terminal
Z2 connector pin 31 is TX Data from the NEC.

I used tiny “wire wrap” wire and just tack soldered to the pin side of the small SMD components which connect to Z2.
The connector that I have at NEC board connector position Z1 is just a tie point. My connector does not connect with any Z1 signals.
Be very quick with your soldering.

TOD output goes to pin 11 of MAX232
TXD goes to pin 10 of MAX232
RXD goes to pin 9 of MAX232.
I used 100R resistors in series with each signal to add a degree of isolation with each connection.

See photo.


2) Do I need anything in between the board and the COM cable?

Yes – add RS232 signal conversion as above.

3) Do I need to change the COM port config in Windows (7) or in U-center / Lady Heather?

Depends on particular PC and Terminal Software.
TOD signal is 4800 baud 8N1
Service Port is 115200 baud 8N1
I used both COM 1 and COM 4 on my ASUS WIN10 Laptop with Terminal Program “Termite 3.4”.
You will probably have to experiment a little.

You can only “talk” to the NEC Board software, not to the uBlox receiver module.
That would require a separate terminal connection on the uBlox module.
I have no experience with this, and it was not required for me, as to a degree, the NEC board interprets and reports the signal levels etc.

Good luck.

[ShadowLight]

Hello guys,

I know this subject has come silent, so let me know if I should post my own subject. But thing is, I think there is only this subject about this NEC GPSDO here...

I recently bought a board from eBay, it came without the OCXO. I powered the board, it works (there is a PPS signal at the LEA-5T). So I'm now looking for an oscillator. The Epson Toycon looks to have a control voltage ranging between 0-10v, centered at 5v. I was looking at some MV-180, but they are expecting a control voltage between 0-5v. Would the board be able to "learn" the control voltage, would it be safe for the MV-180? Or is there another reference I should be looking at?

Remi.

EDIT 2023.07.14: The answer is yes. I bought a FEI FE-180 OCXO on eBay, the control voltage starts a bit high but stabilizes around 2.8 volts. Lady Heather reports everything good after a while.