GPS Disciplined xCXO

The AP63205 has fallen victim to the supply chain crisis and won't be available until 2023, apparently. 

It turns out that there is another option - the AP62200WU. It's not at all pin compatible and is an adjustable version, so you need a voltage divider to set the output voltage.

I tried a board out, but it didn't work straightaway. It turns out that you can't just tie the EN pin to Vin because the absolute maximum voltage is 6 volts on that pin. You're supposed to use it to do UVLO with a voltage divider. Fortunately, you can just leave it floating and it will be internally pulled up, which is fine. I also managed to connect the wrong PPS pin on the new GPS module. So this board will return to inventory once I get another order from OSHPark.

SkyTraq has EOLed the Venus838LPx-T timing receiver module. Their new replacement is the PX1100T, which has a number of advantages. For one, it's a castellated edge module rather than an LGA-69 package, which is easier to assemble. On the firmware side, the serial baud rate is 115200 rather than 9600. Because the same port is used for transmitting the debug output stream, it too has to follow along to 115200, but that has the side effect of making it consistent with the NMEA pin.

Curiously, the PSTI,00 message quantization error is consistently zero. I have an inquiry in to SkyTraq about that, but according to the datasheet the potential quantization error is much lower anyway. There may still be concern about hanging bridges (white noise quantization error can be averaged away, but when the error is of a consistent magnitude, it can't be), but without a correction message, there's nothing that can be done.

A prototype with the relevant firmware changes is operating no differently than previous models did. I'll run an ADEV acquisition on it after it's been running for a couple of days to insure it's as expected. I don't have any particular reason to think it won't be.

EDIT: SkyTraq says they will have a firmware update later this week for the QE message.

The more I get to know USB-C, the more I like it.

It turns out that I believe both iterations of this project can be successfully powered from USB-C power sources.

The OCXO variant is fairly straightforward. Since it doesn't demand more than 1A @ 5V, there's no need to hook anything up to any of the pins other than the standard CCx pull-down resistors.

The FEI variant is a bit more complex. USB C can supply up to 100W, but negotiating the high voltage power that we would want requires some work. Fortunately, there are some very good solutions available. The best I've found is the Cypress Semi CYPD3177. That chip is a power sink negotiator, but what makes it particularly good for us is that it's desired voltage and current are set with voltage dividers, so there's nothing to program or set up. There's a "fault" LED that gets added that will light up red if the supply is incapable of negotiating the desired power (15 volts, 2.25A). Otherwise, the chip will pull down on a P MOSFET gate to send power to the circuit, once it's properly negotiated.

I've decided to try one more pass at improving the sine wave output. This will involve ganging two of the NB3N551 outputs together to improve the output drive (ditching the square wave output in the process), and using a coaxial output - a U.FL jack on the board and an SMA pigtail to the front panel.

I anticipate that the result of this will be a very, very clean output with reduced load change sensitivity.

This change can't readily be done on the FE56x0 board because it also supports the FE405B, which has an output frequency of 15 MHz. On that board with the 405 oscillator, the LPF suppresses the sine output entirely because the corner frequency of the LPF is too low. In principle, you could alter the components of the LPF to raise its corner frequency, but I'm too lazy.

I've been talking to a recent purchaser of the OH300 GPSDO and he's got some expertise in RF and has made some very helpful suggestions for making the output a little bit cleaner. I'm going to try his suggestions and the result should be cleaner output. Note that by 'cleaner' we're really referring to the waveforms themselves. The frequency stability is unchanged.

• Add additional bulk capacitance near the clock fanout chip
• Add some capacitance to the CMOS output
• Add a common mode choke to the twisted pair output leads

The bulk capacitance adds additional bypassing to the clock chip, which results in improved stability of the voltage on the 5v digital rail. The extra capacitance on the CMOS output increases the rise time slightly, but tames the overshoot that's present, making for a more stable output. The common mode choke reduces ground loop noise that can happen between the two outputs. That common mode noise was the reason for the rising amplitude of the higher order harmonics on the sine output. I haven't duplicated his results just yet, but the other fellow tried all of that and got all of the harmonics on the sine output to under 50 dB down from the fundamental, which is good enough to score.

As soon as I can duplicate these results, look for those additions to become a standard part of the design.

Note that the 56x0 discipline board doesn't actually come with output wiring, so users of those boards will need to do the common mode choke themselves if they wish. Of course, if you just connect one output up to the board, that makes ground loops between the two outputs a non-issue.

From my experiments this morning with the new 5 pole sine filter I've discovered that there is some degree of load sensitivity on the output. I've seen this in the past when disconnecting loads - sometimes the mode will drop one notch while the PLL compensates. But somewhat more disturbing is that if you put a 50 Ω load on both outputs at the same time, you'll see a small glitch in the sine wave at the rising edge of the square wave (the two aren't perfectly in phase because the sine filter adds some delay).

Fixing this means either lowering the power supply impedance to the output buffer chip or adding more bypass capacitance for it. I'll have to play with it some more, but for now my best advice is  to use one output or the other.

I finally had an opportunity to build the GPSDO with the 5 pole output filter for the sine output instead of the 3 pole. It was also an excuse to dig out my old spectrum analyzer.

Here's the old circuit:

You can see that the first harmonic is only about 35 dB down from the fundamental and the third is not quite 50 dB down.

Here's the new circuit:

Now that second harmonic is knocked right down under 50 dB. I'm not sure what's up with the higher harmonics starting to drift up, but I did have to compromise a little on one of the capacitor values. I'm going to buy a reel of a better fit and maybe that will help a little bit. But even that I think is an improvement. I believe the higher order harmonics are less distressing than the low ones for a 10 MHz reference output.

Of course, on my scope it looks like a sine wave, but the old circuit did too since my scope only has 50 MHz bandwidth.

I've had some feedback from someone who bought a GPSDO that the sine output isn't as clean as I thought, and it turns out that the reason why it seemed cleaner to me was that I neglected to take into account that I have only a 50 MHz scope. Well, 50 MHz is only the 5th overtone of 10 MHz, so my view on the output is a bit myopic.

So I'm going to order a set of boards to try with footprints for a 5 pole filter instead of a 3 pole filter. That ought to improve the filter's performance a bit (hopefully enough).

I've built and tested a prototype of the XMega32E5 controlled OH300, and it works fine. This has allowed me to return to a single firmware source for both boards. In the source code, you include an oscillator include file that has a bunch of macro definitions to tailor the source for that oscillator. In particular, the two board types are differentiated by the SPI_DAC macro. The FEI boards do not define that macro, and the OCXO and TCXO variants (not sure if I will go to the trouble of designing one of those - they don't really sell) do. In addition, if SPI_DAC is defined, you can choose between the AD5680 and AD5061 DACs depending on whether you need 16 or 18 bits of resolution (16 bits is for the TCXO variant). Next, the oscillator control file is where you define the EFC GAIN and (for the FEI board) any BIT_REDUCE value required to bring the gain down to a useful range. Lastly, the file defines the two or three time constants to be used by the modes. Longer time constants trade phase control for frequency stability.

If your oscillator has an inverse EFC slope (higher EFC means lower frequency), then you can change the DAC_SIGN value from 1 to -1. Other than that, there should be nothing in the actual source code to change.

The source repository includes support for the FE-56x0A, FE-405B (using the FEI board), and the OH300, ECOC-2522 (using the OCXO board) and the DOT050V (using a TCXO board, but I may not bother designing one).

The XMega board variant arrived and the prototype built. Converting the firmware over to the XMega architecture was a tedious exercise, but the result seems to work pretty well. At boot the board sets itself up to clock from the 32 MHz RC oscillator brought down to 30 MHz. The DFLL uses the internal 32 kHz RC oscillator to tune it. Once the FE lock pin is asserted, the PLL is set up to triple the 10 MHz input and switch over to using that. This neatly avoids the whole problem of the clock instability causing controller lock-ups and malfunctions prior to physics lock.

A side effect of this is that programming now no longer strictly requires the external oscillator be fed. PDI programming can take place regardless. Of course, that means having to use a PDI programmer, which is marginally less convenient for me than SPI programming.

If there's a real downside it's that I've discovered the chink in the XMega's armor: the ADC is terrible. I've had to configure it for differential mode with the negative pin connected to ground internally. The result is effectively an 11 bit ADC instead of 12 bits, and even then it's so noisy that throwing away another bit to make the output compatible with the ATMega ADC doesn't matter - it still jumps around 2-3 bits worth even then. For our purposes, it isn't too harmful, though, as the phase discriminator output gets averaged over the course of many seconds. It's bad enough, though, that I may wind up adding another conversion to the capture ISR to get a two-sample average each second.

I designed an OH300/ECS2522 board variant with the XMega too. It's not strictly necessary to convert that design, but the benefit would be the possibility of unifying the firmware across both platforms. The only real difference between them would be changing the serial oscillator interface into an SPI interface to drive the external DAC (the XMega has a 12 bit DAC, but that's not nearly enough granularity). Other than that, all that changes are some constant values relating to the EFC slope.