Does anyone recognize this board, is it a gpsdo?

[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