07/17/2020 at 03:33 •
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.
07/06/2020 at 16:44 •
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.
08/05/2018 at 17:46 •
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.
06/11/2018 at 15:54 •
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.
06/10/2018 at 22:00 •
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.
05/14/2018 at 00:03 •
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).
03/22/2018 at 17:03 •
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).
03/19/2018 at 14:29 •
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.
03/05/2018 at 18:04 •
The first unit I built with the ECOC-2522 did not work very well. The low-tau ADEV was above 10^-11, but it's supposed to be down in the low -12s. I found a lot of noise on the reference voltage output line. I'm not sure what's going on there.
I built a second one with the same circuit that I use for the OH300. For that one, the resulting ADEV is much better - in the mid -12s. It's not as good as ECS' test data says it should be, but it's possible that either my test set up or the circuit is contributing enough noise to take the result from the low to the mid -12s.
It's somewhat concerning that the reference output from this oscillator seems to have too much noise to use. Of course, the sample size is 1, so it may just be that I got a dud.
In the end, however, the ECS isn't so much better than the Connor Winfield unit that I'm going to switch to it. And while the ADEV curve is slightly better at tau 2-10 seconds or so, I'm not convinced it's better enough to justify the extra cost.
02/25/2018 at 22:44 •
Back when the controller for the 5680/5660 board variant was the ATTiny841 the fact that the oscillator output could glitch when the !READY output wasn't on was not a problem - the ATTiny841 can alter its clock source programmatically, so you can run it from the 8 MHz internal oscillator until the oscillator comes ready, then switch.
The ATMega328PB can't do that. And I've tried a bunch of things to try and prevent glitching from affecting the controller, but it's just not working out to my satisfaction.
The next step forward is to try a variant with the ATXmega32E5. This has some positive ramifications, but some negative ones.
One big change is that the controller needs 3.3 volt power instead of 5 volt. To some extent, this makes interfacing with the GPS receiver a little easier, since it's 3.3 volts too. The 3.3 volt LDO powering the GPS receiver has plenty of capacity to power the controller as well.
One big benefit we gain is that there's no longer a need to share the programming pins with any other functional pins. This means we can get rid of the NAND gates that would disconnect the oscillator from its serial pins when !RESET was low (during programming). This is because both of the serial ports (the port C one has GPS input and diagnostic output, and the port D one has the oscillator I/O) can be dedicated to their sole task.
The downside is that two of the inputs into the controller need to be level shifted down from 5 volts. The oscillator TX output from the MAX232 can be level shifted with a simple diode+pull-up circuit, but the other signal that needs to be shifted is the 10 MHz clock from the NB3N551. Down-shifting a 10 MHz clock requires a bit more care. I'm going to try using a low value resistor divider (1kΩ/500Ω) or a low value resistor and zener pair (not yet sure which).
Another benefit we gain from this arrangement is that the XMega can run at a faster internal clock rate. We still want to clock it from the oscillator, but there's an internal PLL that we can use to triple that to 30 MHz. We can also run the internal 32 MHz oscillator instead at 30 MHz so that we can run at a consistent clock speed both before and after we switch to the external oscillator.
We also get a 12 bit ADC instead of a 10 bit one, so in principle the granularity of the phase discriminator can be 250 ps instead of 1 ns (whether it's going to be that accurate or not is questionable). For the first cut of the firmware, however, it's likely we'll just throw away the extra two bits to try and get everything running properly. There's a DAC as well, but it doesn't do us any good since the FE oscillators are serial-controlled. It won't do us any good on the OCXO/TCXO variants because 12 bits isn't enough for them.
Lastly, we no longer have to insist that programming only take place with the oscillator connected. Unfortunately, we need to use PDI to do the programming, but at least we can do that whether the oscillator is connected or not (and PDI is very fast).
The last downside, of course, is that the XMega is double the price ($2.80 vs $1.40 Q:1), but we do get to say goodbye to a couple of ICs (we do gain a couple of inexpensive diodes), which softens the blow a little. At least it's the same package as the 328PB we were using before.
Rewriting the firmware is going to be a painful operation, but I said that before doing the same thing for the GPS clock, so yeah.