-
More ECOC-2522 results
03/05/2018 at 18:04 • 0 commentsThe 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.
-
I've had it
02/25/2018 at 22:44 • 0 commentsBack 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.
-
5680A watchdog redux
02/10/2018 at 16:54 • 0 commentsWell, I'm glad I checked... It turns out the new watchdog chip was permanently wired disabled.
Fortunately, it has an internal pull-down, so you can leave the enable pin floating and it will be forced-enabled. With that, I verified that it wasn't actually working properly.
One issue is that the default Lfuse value of 0xe0 delays startup for 65 ms, which is way too long. That's been changed to 0xc0, which essentially has no delay. But if startup gets wedged, that's ok, because the watchdog circuit is there to force it to try again. :)
The other issue is that the watchdog seems to impede programming. On AVRs, programming mode is entered by bringing !RESET low, but apparently the start of actual programming has some timing constraints, as it would seem that the watchdog occasionally yanking on the !RESET line during programming is no good. So I'm going to have to spin new boards with a solder jumper to disable the watchdog. You close the jumper for programming and then open it again once programming is complete. It's not ideal, but it will do. The alternative is to not install the chip until programming is complete, but that complicates field firmware updates.
-
Watchdog for 5680A boards
02/03/2018 at 17:22 • 0 commentsI've found sometimes when cold-starting the frequency of a 5680A is unstable enough to sometimes result in the controller locking up.
This was worked-around on the ATTiny841 variant by clocking the controller internally until the oscillator indicated a lock and then switching to external clocking, but when we moved to the ATMega328PB (because of running out of flash) that wasn't an option.
I tried first to delay startup by holding RESET low with a Schmidt trigger buffer on an RC circuit, thinking that was the issue, but it didn't fix things all the way, so I've decided to replace that with a hardware watchdog.
The STWD100NPWY3F is a good choice. It's has an open drain output that it will bring low to reset the controller. It expects to see rising edges at least every 3 ms or so on its input or it will trigger a reset. An unused line on the controller will be configured as an output and every time we used to call wdt_reset(), we'll call a method that does that and toggles that output line. As long as we do that at least once every ms or so, that should be enough. If the controller gets wedged, then the watchdog will reset it. Fortunately, I've not seen a board lock up so hard that briefly shorting RESET to ground on the ISP header doesn't unstick it. The issue in the past has been sometimes it's hard to tell the difference between mode 0 and a locked up controller, so this will make that unnecessary.
As a happy coincidence, when programming the controller, RESET is held low anyway, so the fact that the watchdog won't be being petted during programming won't be an issue.
EDIT: It took a while, but I finally got around to building one of these, and I paired it with a cold 5680A. I was able to observe the controller go bonkers for a moment and - unlike in the past - it got reset and started right back up. Overnight, it made it to mode 3 and all indications are that it works perfectly. -
First ECS results
12/18/2017 at 22:17 • 0 commentsI've built the first unit with the ECS ECOC-2522-10.000-3-F-C. It made it to mode 3 overnight, which is much faster than "first light" for an OH300. At not quite 24 hours in, the average phase error reported by the diagnostic log output is hovering in the low single digits, and the DAC is dancing in a corridor of around 3 units width, perhaps aging upwards fairly slowly.
Interestingly enough, the reference voltage output of this unit was measured at around 2.8V rather than 3.3. That said, the current DAC setting is 0x27A13, which when you scale it is around 1.733 volts. So the reference voltage is lower than expected, but the actual center point is just over the actual Vcc/2 midpoint.
ADEV testing for this variant is pending. I want to wear it in a few days and then run it against my Thunderbolt. In principle, the ADEV claimed by ECS is around what the Thunderbolt itself claims, so I may not really be able to work out the actual quality of this one myself. Not sure where I'll go from there. I rather suspect sending it out to be tested by a proper lab would be more than I could afford.
If it turns out that this unit is equal to the TB, then I will probably retire my TB and start actually eating my own proverbial dog food.
-
Another diagnostic port option
11/28/2017 at 17:52 • 0 commentsIf you need to connect the diagnostic port up to RS-232, there's an adapter board design you can use. You can select whether the transmit pin is the diagnostic output or the GPS NMEA output. Received data is connected to GPS. The PPS output is connected to DCD and is configured so that DCD asserts on-time.
-
Another OCXO option
11/27/2017 at 21:43 • 0 commentsI've been a pretty loyal user of the Connor Winfield OH300, but it's always a good idea to look for other options.
And, sure enough, there is another option that looks compelling: the ECS ECOC-2522-10.000-3-F-C.
The form factor is remarkably similar. The only real difference is on the OH300 the bottom center pin is NC and on the 2522 it's a Vref pin. Using that would save us the need to add a separate regulator for the DAC reference voltage. There are two more pins on the top edge of the OH300, but they're NC.
Electrically, they're quite similar, but the 2522's pullability is ±700 ppb instead of ±400 ppb, and the lifetime aging spec is ±500 ppb instead of ±300 ppb. But on the flip side, the low frequency phase noise is 5 dB lower through 100 Hz on the 2522. They don't list a short term Allan deviation spec (the OH300 claims 1E-11 @ 𝜏 1s, but in my testing I actually see more like 8E-12). Additionally, the OH300 has a "dead band" for the control voltage of the outer 0.3V. The spec for the 2522 is rail-to-rail.
The pullability specs for both suggest that with the 2522 the 18 bit tuning steps would be a bit coarser. What that winds up meaning when the rubber hits the road is, however, an open question.
Lastly, the 2522 is $40 more (Q:1). Whether it's worth $40 more...? We'll have to build one to find out.
-
SkyTraq GPS module firmware issue
09/27/2017 at 12:38 • 0 commentsWord has come to me via the TimeNuts mailing list that certain models of SkyTraq GPS receiver may have firmware issues that prevent them from getting a fix due to recent changes in the GPS almanac. This same note said that modules in survey-and-position-hold mode do not suffer from this problem. All of the SkyTraq modules I have obtained are in this latter category and (so far as I can tell) are continuing to operate normally. I have inquired of SkyTraq if there is any field remediation that should be taken, and I'll update here with anything I get back.
Any GPSDO with a 6 pin diagnostic port can be connected to a TTL level serial interface. Presumably any remediation software that might come from SkyTraq would operate over this interface (if a field remediation is possible at all). A GPSDO with a 4 pin diagnostic port can also be similarly connected, as long as the microcontroller on the board is held in RESET (tie pin 5 of the ISP header to ground).
-
Changing the FE board from one oscillator to another
09/12/2017 at 16:12 • 0 commentsThe FE-5680A board can support the 5680A, the variant of the 5660A with firmware modified by Skip Withrow, and the FE-405B. It just requires different firmware for the FE-405B (and for the 5680A, it requires some adjustment to the solder jumpers).
Replacing the firmware is a bit tricky, though, since sending garbage to an FEI oscillator over its serial port can brick it if you're not lucky. But you can't program the ATMel controller without a clock source, so you can't disconnect the oscillator, load the new firmware, and then connect the new oscillator.
The solution is to erase the firmware while it's connected to the old oscillator (avrdude -c [programmer] -p m328pb -U flash:w:0:m), then move the board to the new oscillator and load the new firmware.
While the flash is erased, the controller won't even configure, much less transmit on the serial ports, so there's no chance it will send garbage. In actual fact, there's little chance it would anyway, since when you switch from the 56x0A to the 405B you change from 10 MHz to 15 MHz, and the serial port clock generator will have the wrong constants, meaning it won't be able to properly parse the data from the GPS receiver. Without detecting a GPS lock, it shouldn't want to talk to the oscillator at all. But to be extra sure, I recommend following this procedure if you want to switch between the 56x0A and 405B.
-
Changing the buck converter
05/27/2017 at 03:54 • 0 commentsWhen I last ordered a pile of Crazy Clocks to be manufactured, I screwed up and ordered a reel of PAM2305 buck converters (they're used in the GPS clock and the Pi clock projects) by mistake instead of XC9140 boost converters. Since they were ordered as DigiReels, they're not returnable, so I'm sort of stuck with a lifetime supply of them.
Well, they're good chips... could they replace the SC189Z that I've been using in the GPSDO?
Turns out that the answer appears to be yes. I built a board with one (it's pin compatible with the SC189Z) using the part values I've been using for the GPS clock. It seems to have nice low noise and ripple. It's going to take a few days run time for the oscillator to stabilize to get a good picture, but it looks good right at the start.