Saturday, May 20, 2017
Welcome Bay Area Maker Faire 2017 visitors!
It's a little embarrassing that the last post I've made on this blog was last year's Maker Faire post, but I am a bit more active on Hackaday. You can find my store on Tindie, but we are doing specials for Maker Faire. You can find our booth in the Southeast corner of Zone 2.
Sunday, May 22, 2016
Welcome Bay Area MakerFaire 2016 visitors!
I was showing Crazy Clocks this year and GPS disciplined oscillators. You can find the firmware over at GitHub and project info over at Hackaday.
Sunday, December 20, 2015
Home-brew J1772 EVSEs
I've spent some time this morning and looked at some of the videos on YouTube of people showing off their home-brew J1772 charging stations. I have some concerns about a lot of them.
Now, my criticism doesn't apply to all of them. Quite a few of them are based on OpenEVSE, which does include all of the checks. In fact, an OpenEVSE based design recently obtained full UL approval. That said, there are some things I would change about OpenEVSE's design, and those things wound up being the design for OpenEVSE II.
The most frequent deficiency I see is a lack of a ground-fault interruptor (GFI). A GFI is particularly important in EVSEs for two reasons. One, the business end of the EVSE is intended to be used in all weather conditions. Two, the car itself sits on four rubber tires, which prevent the frame from being grounded other than via the ground connection of the J1772 cable. A ground fault in the vehicle potentially could energize the entire chassis.
The second deficiency I see often is a lack of ground continuity monitoring (GCM). In the above case, where a ground fault energizes the chassis of the vehicle, a proper ground connection would overload the circuit breaker feeding the EVSE if the GFI didn't stop the current flow first. If the ground fault in the vehicle existed and the ground connection was poor (and the GCM didn't detect that), then there would be no ground fault current for the GFI to detect until a circuit to ground was established - likely through the next human to touch the vehicle. Now, the GFI will trip, but that takes some time, so the human will still get a brief shock, which could have been prevented.
Lastly, the specification requires a stuck-relay test. This test insures that when the relay or contactor is switched off that there is no voltage present on the hot lines of the J1772 cable. If the relay fails in a manner where it's stuck closed, then all of the other safety systems are completely moot. A proper EVSE should at least produce a warning so that power can be removed and the unit repaired.
There is also the pilot diode test. The diode test allows the EVSE to tell the difference between a vehicle and a bucket of salt water. Obviously, turning the power on when the handle is "plugged in" to one of the latter would be a bad thing. This is accomplished by testing for both the maximum and minimum voltage seen on the pilot line while the pilot is oscillating. The maximum voltage is used to detect J1772 state transitions, but the minimum voltage should be (close to) -12 volts.
So, yes, you can just charge a car by making a 1 kHz square wave with variable duty cycle and turning a contactor on and off, but there's more to it than that. You don't have to go get your home-brew J1772 EVSE UL approved, but you need to at least be aware of what UL wants to see and why before you play with 7.2 kW or more of power.
Now, my criticism doesn't apply to all of them. Quite a few of them are based on OpenEVSE, which does include all of the checks. In fact, an OpenEVSE based design recently obtained full UL approval. That said, there are some things I would change about OpenEVSE's design, and those things wound up being the design for OpenEVSE II.
The most frequent deficiency I see is a lack of a ground-fault interruptor (GFI). A GFI is particularly important in EVSEs for two reasons. One, the business end of the EVSE is intended to be used in all weather conditions. Two, the car itself sits on four rubber tires, which prevent the frame from being grounded other than via the ground connection of the J1772 cable. A ground fault in the vehicle potentially could energize the entire chassis.
The second deficiency I see often is a lack of ground continuity monitoring (GCM). In the above case, where a ground fault energizes the chassis of the vehicle, a proper ground connection would overload the circuit breaker feeding the EVSE if the GFI didn't stop the current flow first. If the ground fault in the vehicle existed and the ground connection was poor (and the GCM didn't detect that), then there would be no ground fault current for the GFI to detect until a circuit to ground was established - likely through the next human to touch the vehicle. Now, the GFI will trip, but that takes some time, so the human will still get a brief shock, which could have been prevented.
Lastly, the specification requires a stuck-relay test. This test insures that when the relay or contactor is switched off that there is no voltage present on the hot lines of the J1772 cable. If the relay fails in a manner where it's stuck closed, then all of the other safety systems are completely moot. A proper EVSE should at least produce a warning so that power can be removed and the unit repaired.
There is also the pilot diode test. The diode test allows the EVSE to tell the difference between a vehicle and a bucket of salt water. Obviously, turning the power on when the handle is "plugged in" to one of the latter would be a bad thing. This is accomplished by testing for both the maximum and minimum voltage seen on the pilot line while the pilot is oscillating. The maximum voltage is used to detect J1772 state transitions, but the minimum voltage should be (close to) -12 volts.
So, yes, you can just charge a car by making a 1 kHz square wave with variable duty cycle and turning a contactor on and off, but there's more to it than that. You don't have to go get your home-brew J1772 EVSE UL approved, but you need to at least be aware of what UL wants to see and why before you play with 7.2 kW or more of power.
Saturday, October 17, 2015
Making clocks - accuracy counts
Because of the widely publicized incident of the young Texan clock maker being arrested for bringing his creation to school, there has been a surge of interest in designing and making clocks. And that's awesome. Clocks are well known, and it's particularly easy to make them with microcontrollers (far easier than with discrete logic, but something can be said for the awesomeness of doing something the hard way). But clockmaking is deceptive. It's easy to make a clock that's functional, but if it's so inaccurate that you have to reset it frequently, then it's not very useful. And it turns out that achieving a useful level of accuracy is not trivial.
A clock fundamentally has two parts: a counter and an oscillator. The counter assumes that the oscillator operates accurately at a known frequency and displays the current cycle count, calibrated as a time. Some clocks use AC line frequency as their oscillator. Doing so outsources the problem, and is actually a good move (it should be mentioned that if you want to make a line-powered clock, you should buy yourself a UL approved low voltage AC transformer "wall wart" to do so. You shouldn't mess with AC line voltage directly, and for a clock there's certainly no need to do so), but more on that later.
There's very little to say about the counter portion of a clock. It's really all about the oscillator. Oscillators can be characterized by two factors - their accuracy and their stability. Put simply, accuracy is the difference between their actual frequency and their expected frequency and stability is the rate of change of accuracy over time.
There are lots of choices available for oscillators, but for amateur clockmakers, the only two worth seriously considering are AC line frequency or crystals.
Put simply, AC line frequency is very accurate, but highly unstable. You can count on a line frequency driven clock to be very accurate over a long term, but in the short term, there's no point in attempting to display seconds, because there can be multiple seconds of drift before it's corrected. But it is corrected eventually - the electric grids are typically disciplined so that in the course of a day the correct number of cycles take place.
If you want a battery powered clock, then you'll need to use a crystal. For the purpose of this discussion, crystals are quite stable, but their absolute accuracy is relatively poor. When I discovered this, it came as quite a shock. I thought that if I bought a crystal with a 10 ppm tolerance that that meant that I could count on the frequency being within 10 ppm. In fact, what that specification means is that if you buy a pile of that type of crystal, they will all be within 10 ppm of each other. And that's not the same thing at all.
A typical arrangement for a crystal clocked modern microcontroller is a crystal wired to two pins of the controller, with a loading cap on each lead to ground. The crystal will have a characteristic loading capacitance. The two capacitors, the PCB traces and the controller will all contribute capacitance. But what's the impact of that?
If you plot a crystal's frequency against the total loading capacitance, you get an inverse logarithm. That is, with no or low capacitance, the frequency will be too high. As you increase the loading capacitance, the frequency will drop precipitously at first, but then it will flatten out. Too much capacitance will eventually swamp the oscillator, but that happens much further on.
What the crystal manufacturers do is design and trim the crystals so that the desired frequency (within the tolerance, at least) is achieved with a particular capacitance value. And that value typically is far enough along the inverse log curve that it's somewhat flat, but not so far along that it can't still be pulled slower. The manufacturers choose this because they know that designers are going to want to engineer in the ability to fine tune the frequency, so there has to be room to pull the frequency lower, but at the same time, you want to reduce the sensitivity of the crystal by having the "sweet spot" be on a flatter portion of the curve.
So if you do the math correctly and pick the theoretically correct capacitor values - even if you take all of the parasitic capacitance into account - and then build your clock using a crystal with a 10 ppm tolerance, you still might find that it's 20 ppm slow. That's 12 seconds a week. The crappiest dime store digital watch can do far better than that. What happened? Well, if you were to build a dozen of them, what you'd find is that all of them would be within 10 ppm of each other, centered around some value. Given our single sample, we'd expect the center to be between 10 ppm and 30 ppm slow.
What happened is that the various component tolerances all contributed error. In the case of my crazy clock design, I tried crystals from three different manufacturers. With the same loading caps and same circuit, each wound up having a different batch center frequency with the three batches spread over a 20 ppm range! Altering the loading cap values gave even more points. I wound up going with a particular crystal and an loading cap value pairing that yielded a batch that averaged 5 ppm fast, ±10 ppm. That was the best I could do.
If you were building just one, then the best idea would be to substitute a variable capacitor for one of the loading caps. You could then trim the frequency manually. If you noticed the clock was running slow, you could just tweak it a little and it would come back into line. But if you're building a bunch of clocks, that's impractical. Much better would be to add the ability to "trim" the oscillator in software. That's what I did for the crazy clock.
It's not that hard to do. Out of every million oscillator cycles you need to either add or subtract "n" of them to effect an "n ppm" trimming. Or if you look at it another way, if you take one million and divide it by "n," then you need to add or remove a single cycle after counting that many.
The crazy clock works by arranging for one of the controller's timers to generate 10 Hz interrupts. It does this by performing a fractional division system. The software trimming simply counts how many cycles have been counted and increments or decrements the current cycle's count for one interrupt whenever the trimming counter overflows. What that allows me to do is write into EEPROM a trimming value. At startup, the math is done once and the trimming counter initialized appropriately.
That's as much as you need to do to just make a clock. Going further you can delve much more deeply into crystal stability factors, which will lead you to temperature stability, aging, and lots more.
A clock fundamentally has two parts: a counter and an oscillator. The counter assumes that the oscillator operates accurately at a known frequency and displays the current cycle count, calibrated as a time. Some clocks use AC line frequency as their oscillator. Doing so outsources the problem, and is actually a good move (it should be mentioned that if you want to make a line-powered clock, you should buy yourself a UL approved low voltage AC transformer "wall wart" to do so. You shouldn't mess with AC line voltage directly, and for a clock there's certainly no need to do so), but more on that later.
There's very little to say about the counter portion of a clock. It's really all about the oscillator. Oscillators can be characterized by two factors - their accuracy and their stability. Put simply, accuracy is the difference between their actual frequency and their expected frequency and stability is the rate of change of accuracy over time.
There are lots of choices available for oscillators, but for amateur clockmakers, the only two worth seriously considering are AC line frequency or crystals.
Put simply, AC line frequency is very accurate, but highly unstable. You can count on a line frequency driven clock to be very accurate over a long term, but in the short term, there's no point in attempting to display seconds, because there can be multiple seconds of drift before it's corrected. But it is corrected eventually - the electric grids are typically disciplined so that in the course of a day the correct number of cycles take place.
If you want a battery powered clock, then you'll need to use a crystal. For the purpose of this discussion, crystals are quite stable, but their absolute accuracy is relatively poor. When I discovered this, it came as quite a shock. I thought that if I bought a crystal with a 10 ppm tolerance that that meant that I could count on the frequency being within 10 ppm. In fact, what that specification means is that if you buy a pile of that type of crystal, they will all be within 10 ppm of each other. And that's not the same thing at all.
A typical arrangement for a crystal clocked modern microcontroller is a crystal wired to two pins of the controller, with a loading cap on each lead to ground. The crystal will have a characteristic loading capacitance. The two capacitors, the PCB traces and the controller will all contribute capacitance. But what's the impact of that?
If you plot a crystal's frequency against the total loading capacitance, you get an inverse logarithm. That is, with no or low capacitance, the frequency will be too high. As you increase the loading capacitance, the frequency will drop precipitously at first, but then it will flatten out. Too much capacitance will eventually swamp the oscillator, but that happens much further on.
What the crystal manufacturers do is design and trim the crystals so that the desired frequency (within the tolerance, at least) is achieved with a particular capacitance value. And that value typically is far enough along the inverse log curve that it's somewhat flat, but not so far along that it can't still be pulled slower. The manufacturers choose this because they know that designers are going to want to engineer in the ability to fine tune the frequency, so there has to be room to pull the frequency lower, but at the same time, you want to reduce the sensitivity of the crystal by having the "sweet spot" be on a flatter portion of the curve.
So if you do the math correctly and pick the theoretically correct capacitor values - even if you take all of the parasitic capacitance into account - and then build your clock using a crystal with a 10 ppm tolerance, you still might find that it's 20 ppm slow. That's 12 seconds a week. The crappiest dime store digital watch can do far better than that. What happened? Well, if you were to build a dozen of them, what you'd find is that all of them would be within 10 ppm of each other, centered around some value. Given our single sample, we'd expect the center to be between 10 ppm and 30 ppm slow.
What happened is that the various component tolerances all contributed error. In the case of my crazy clock design, I tried crystals from three different manufacturers. With the same loading caps and same circuit, each wound up having a different batch center frequency with the three batches spread over a 20 ppm range! Altering the loading cap values gave even more points. I wound up going with a particular crystal and an loading cap value pairing that yielded a batch that averaged 5 ppm fast, ±10 ppm. That was the best I could do.
If you were building just one, then the best idea would be to substitute a variable capacitor for one of the loading caps. You could then trim the frequency manually. If you noticed the clock was running slow, you could just tweak it a little and it would come back into line. But if you're building a bunch of clocks, that's impractical. Much better would be to add the ability to "trim" the oscillator in software. That's what I did for the crazy clock.
It's not that hard to do. Out of every million oscillator cycles you need to either add or subtract "n" of them to effect an "n ppm" trimming. Or if you look at it another way, if you take one million and divide it by "n," then you need to add or remove a single cycle after counting that many.
The crazy clock works by arranging for one of the controller's timers to generate 10 Hz interrupts. It does this by performing a fractional division system. The software trimming simply counts how many cycles have been counted and increments or decrements the current cycle's count for one interrupt whenever the trimming counter overflows. What that allows me to do is write into EEPROM a trimming value. At startup, the math is done once and the trimming counter initialized appropriately.
That's as much as you need to do to just make a clock. Going further you can delve much more deeply into crystal stability factors, which will lead you to temperature stability, aging, and lots more.
Sunday, September 20, 2015
FE-5680A Breakout board users guide
This is the permanent home for the user's guide for the FE-5680A breakout board.
The FE-5680A is a Rubidium frequency standard widely available used on eBay. It has a DB-9M receptacle as its interface to the outside world and requires +15 VDC @ 1A and +5 VDC at ~100 mA to operate. This breakout board supplies both of those from a 20+ watt 16-24 VDC input - easily obtainable from a surplus laptop power adapter.
In addition to the 2.1mm barrel connector for input power, there is a two pin SIP header footprint on the bottom of the board which can be used as an alternative. There's also a 2 pin SIP header on the top of the board with the RF output, and a 4 pin SIP header that carries the PPS and RS-232 signals. Lastly, there is an LED in the corner of the board that indicates that the module has obtained a physics lock.
The 2 pin and 4 pin SIP headers bring the respective interface pins from the module directly out with no conditioning or other circuitry. The LOCK LED is buffered by a transistor so as to not unduly load the respective module pin (doing so can prevent the PPS signal from working). The pinouts of the various models of FE-5680A vary quite significantly, and the pin labels are nominal ones for the most frequent case.
Some 5680As do not require an external 5 volt power supply. If yours is one, then take an Xacto knife and cut the trace running between the two pads of the solder jumper immediately adjacent to the interface connector. Be careful to not cut any adjacent traces on the board. Keep the knife blade only between the jumper's pads. If you need to re-enable the +5 supply you can solder the jumper closed again.
Note that both the 5680A and portions of the breakout board (particularly around the +5 LDO) will get quite hot during operation. This is normal. In particular, the module is internally heated to insure stability of its internal oscillator. Attempting to dissipate this heat will simply make more work for the oven.
The FE-5680A is a Rubidium frequency standard widely available used on eBay. It has a DB-9M receptacle as its interface to the outside world and requires +15 VDC @ 1A and +5 VDC at ~100 mA to operate. This breakout board supplies both of those from a 20+ watt 16-24 VDC input - easily obtainable from a surplus laptop power adapter.
In addition to the 2.1mm barrel connector for input power, there is a two pin SIP header footprint on the bottom of the board which can be used as an alternative. There's also a 2 pin SIP header on the top of the board with the RF output, and a 4 pin SIP header that carries the PPS and RS-232 signals. Lastly, there is an LED in the corner of the board that indicates that the module has obtained a physics lock.
The 2 pin and 4 pin SIP headers bring the respective interface pins from the module directly out with no conditioning or other circuitry. The LOCK LED is buffered by a transistor so as to not unduly load the respective module pin (doing so can prevent the PPS signal from working). The pinouts of the various models of FE-5680A vary quite significantly, and the pin labels are nominal ones for the most frequent case.
Some 5680As do not require an external 5 volt power supply. If yours is one, then take an Xacto knife and cut the trace running between the two pads of the solder jumper immediately adjacent to the interface connector. Be careful to not cut any adjacent traces on the board. Keep the knife blade only between the jumper's pads. If you need to re-enable the +5 supply you can solder the jumper closed again.
Note that both the 5680A and portions of the breakout board (particularly around the +5 LDO) will get quite hot during operation. This is normal. In particular, the module is internally heated to insure stability of its internal oscillator. Attempting to dissipate this heat will simply make more work for the oven.
Important
Not all FE-5680As have the same pinout (the one indicated is the most common, so far as we are aware). Please carefully check your particular model against the pinout below to insure your unit is not damaged by improper connections. Before connecting your breakout board to your FE-5680A, please power it up and verify that the correct voltages appear on pins 1 (15V) and pin 4 (5V) relative to pins 2 and 5 (ground).DB-9 pinout
- +15 V supply
- ground
- !LOCK (low means lock achieved)
- +5 V supply
- ground
- 1 PPS
- RF out
- RS-232 serial in
- RS-232 serial out
Schematic
Sunday, July 26, 2015
GPS Disciplined Oscillator User Guide
This is the permanent home for the GPS Disciplined Oscillator User Guide. More information can also be found at the Hackaday.io project page.
Versions:
There is a mni-DIN 4 pin diagnostic connector on the board. It has a ground pin, two 3.3v async serial lines and a PPS output. One of the serial lines is the transmit data pin from the GPS module, the other is the transmit data pin from the controller. The controller transmit pin is tied to the GPS module receive pin (and vice-versa) as well as the diagnostic port. With normal firmware, the controller will not transmit anything. The GPS data will be at 9600 bps and can be tapped for other purposes, if desired. The PPS output is buffered. The rising edge will, in principle, be synchronized to the GPS second, but the output buffer will introduce a few ns of latency. It's recommended, therefore, that this be only used as a frequency standard, rather than a timing output (the latency should be fixed length given a fixed load).
When the "run" lock indication is present on the LEDs, you can expect the Allan deviation for the DOT050V variant for all tau to be 1e-9 or better. Typical performance levels are between 6E-11 and 9E-11 for tau 6E-1 through 3E+3, and then proceeding downwards from there. No representation or assertion is made about the phase of the output relative to GPS, only the frequency. You can expect the OH300 variant to be around 7E-12 for tau 1E0, rising to around 2E-11 at tau 3E+3 and then proceeding downwards from there.
After power is applied, it may take the GPS receiver up to a minute (assuming good GPS reception) to obtain a 3D fix (as indicated by the change from once-per-second blinking of the FIX LED to once every 15 seconds, plus the 0 and 1 LEDs changing from blinking back and forth to extinguishing). Once a GPS lock is indicated, it will take anywhere from 20 to 40 minutes for the coarse mode to bring the frequency within approximately 1E-9. The fine mode should take a few minutes more, and then the run mode should turn on and stay. If the GPS lock is lost, the unit will free-run until GPS is re-acquired, and then the startup process will repeat (but should be much faster, as the free-running frequency should be much closer to the target).
Note that the oscillator is sensitive to movement. If you move it while it's operating, you can expect phase disturbances that the PLL will have to correct. While each output is isolated, large changes in load can do the same. After changing output connections, or jostling the unit, you should give the oscillator a few minutes to settle.
The coarse mode implements a basic FLL that attempts to get close to center as quickly as possible. Once there, the FLL is maintained until the phase drifts close to the phase discriminator center point (for a maximum of 20 minutes). The coarse PLL mode operates with a time constant of 50 seconds, and the fine PLL mode with a time constant of 200 seconds.
The serial port of the GPS module is also connected to the controller. The controller watches for NEMA $GPGSA sentences and looks for an indication of a proper 3D fix. If the GPS is not 3D locked, then it will be ignored and the system will hold-over until it comes back.
There are four separate power supply systems. First, 5 volts comes in from the external power input. There is a TVS diode to serve as a crude over-voltage and reverse polarity protection, and a tantalum cap to act as a noise filter. This is the primary source of 5 volt power for the other power supplies. For the digital section, a 47 µH inductor provides isolation from noise imposed by the digital circuitry. From the digital 5v bus, a dedicated LDO supplies 3.3 volt power for the GPS module.
From the 5v input bus, a 3.3 volt oscillator supply is derived using either an LDO for the TCXO variant or an SC189Z buck converter for the OCXO variant. The buck converter has an extra LC added onto the output to form a pi filter to further reduce noise and ripple.
Also from the 5v input bus, a separate high precision 3.3 volt regulator supplies the reference voltage for the DAC and also the supply voltage for the compression amp and the virtual ground voltage divider.
Versions:
- v1.0 - original prototype design
- v1.1 - Change from an ATMega328p controller to an ATTiny4313
- v1.2.1 - Add a buck converter to replace the LDO regulator
- v1.4 - Numerous power bus cleanup and stabilization fixes, the return of the LDO, and change the buffer amp to an inverting compression amp to increase DAC granularity.
- v1.5.3 - Redesigned to fit in new extruded aluminum enclosure
- v1.6.2 - OH300 variant
- v1.7.2 - Change to a 20 MHz oscillator, 5 volt logic system. Derive output from controller timer, use 2 DIP switches to select output frequency from four options.
- v1.7 - OH300 variant for 1.7.x
- v2.2 - Go back to a 10 MHz oscillator, but add a phase comparator system, a separate high precision LDO for the DAC reference, an extra LC filter on the 3.3v supply output, remove the output frequency selection infrastructure, switch to an ATTiny841 controller, remove the battery clip and add a mini-DIN 4 diagnostic connector on the back panel.
- v2.2.1 - DOT050V variant for v2.2.
- v2.4.1 - Add JFET to increase phase detector voltage linearity. Add pi network to one output for +13 dBm sine. Change ext ant jack to board-mount SMA.
- v2.5.1 - DOT050V variant of 2.4.1.
The GPS Disciplined Oscillator board is an extremely accurate source of a 10 MHz signal. The signal is available either as a 5V square wave or a +13 dBm sine wave (both with 50Ω impedance). This can be used as a calibration source or an external reference for any number of different pieces of lab equipment, or can even be used as a master clock for microcontroller projects that require extreme clock precision.
At the heart of the board is a VCTCXO that has an inherent short-term stability of ±1 ppb or a VCOCXO that has a short-term stability of ±100 ppt. However, the fixed frequency variants of these oscillators only have an initial accuracy of ±1 ppm. For applications where both the accuracy and stability are important, using a "steerable" oscillator with feedback from an external reference is preferable. GPS offers an extremely accurate and cost effective synchronization source, however typically only a 1 PPS signal is available (though that 1 PPS signal is within ±10 ppb). This board uses a microcontroller to observe both the oscillator output and the PPS signal and tune the oscillator so that it emits as closely to an exact 10 MHz as can be measured. In addition, there is a phase discriminator circuit that will give additional phase correction information to the controller, approximately at nanosecond resolution.
The power supply should be 5 volts DC and capable of supplying at least 1W for the TCXO variant and 5W for the OCXO variant. There are three LEDs on the bottom right corner of the board. They are labeled FIX, 0 and 1. The FIX LED comes straight from the GPS receiver. At startup, or if the fix is lost, it will blink once per second. When a fix is (re)acquired, it will begin to blink once every 15 seconds. The 0 and 1 LEDs will blink back and forth when the GPS fix is lost. If they're not blinking, then they form a binary number 0-3, which correspond to the PLL operating mode. 0 (no LEDs on) corresponds to the coarse tuning mode, 1 (LED 0 on, 1 off) the fine tuning mode and 2 (LED 1 on, 0 off) the "run" mode. In general, with good GPS reception, the unit should arrive at the run mode within an hour. It's in this mode that you should expect to achieve the expected performance. If the GPS fix is lost, the unit will free-run until it returns, then re-enter the coarse, fine and then run modes.
There are two independent output ports. Each outputs a separate copy of the same signal. One output is a sine wave with approximately +13 dBm level, the other is a 5 volt, 50% duty cycle square wave. This output can be fed, if desired, into 50 ohm coax.
The GPS module has an internal patch antenna, but there is an external antenna connector on the board if you need to connect an external antenna. Depending on your board version, it is either a U.FL connector or an SMA edge-mount connector. The antenna will be fed 3.3 volts at up to 25 mA. In order for the external antenna to be recognized, it must present a DC load of at least 200 Ω. If you buy your unit in an enclosure, the internal patch antenna will not be useful because of the shielding provided by the enclosure, so an external antenna is required.
The operating temperature range of the board is 0-70°C. Rapid temperature swings should be avoided for best frequency stability.
If you need to upgrade the firmware, there is a 6 pin AVR ISP connector on the edge of the board. For board versions before v1.7, the programmer must be able to program at 3.3 volts with the target powered. DO NOT APPLY 5 VOLTS TO THE PROGRAMMING PORT OR PROGRAM WITH 5V LEVELS! You will likely irreparably damage either the oscillator or the GPS module (the two most expensive components). Programming the OCXO variant must take place with the board powered with its normal power supply, as most programmers will not be able to supply sufficient power for the oscillator to operate normally. For versions 1.7 and beyond, you should use 5 volt programming, but the recommended method is to always power the board with its own power supply and use a programmer configured for target power.
If you need to upgrade the firmware, there is a 6 pin AVR ISP connector on the edge of the board. For board versions before v1.7, the programmer must be able to program at 3.3 volts with the target powered. DO NOT APPLY 5 VOLTS TO THE PROGRAMMING PORT OR PROGRAM WITH 5V LEVELS! You will likely irreparably damage either the oscillator or the GPS module (the two most expensive components). Programming the OCXO variant must take place with the board powered with its normal power supply, as most programmers will not be able to supply sufficient power for the oscillator to operate normally. For versions 1.7 and beyond, you should use 5 volt programming, but the recommended method is to always power the board with its own power supply and use a programmer configured for target power.
There is a mni-DIN 4 pin diagnostic connector on the board. It has a ground pin, two 3.3v async serial lines and a PPS output. One of the serial lines is the transmit data pin from the GPS module, the other is the transmit data pin from the controller. The controller transmit pin is tied to the GPS module receive pin (and vice-versa) as well as the diagnostic port. With normal firmware, the controller will not transmit anything. The GPS data will be at 9600 bps and can be tapped for other purposes, if desired. The PPS output is buffered. The rising edge will, in principle, be synchronized to the GPS second, but the output buffer will introduce a few ns of latency. It's recommended, therefore, that this be only used as a frequency standard, rather than a timing output (the latency should be fixed length given a fixed load).
When the "run" lock indication is present on the LEDs, you can expect the Allan deviation for the DOT050V variant for all tau to be 1e-9 or better. Typical performance levels are between 6E-11 and 9E-11 for tau 6E-1 through 3E+3, and then proceeding downwards from there. No representation or assertion is made about the phase of the output relative to GPS, only the frequency. You can expect the OH300 variant to be around 7E-12 for tau 1E0, rising to around 2E-11 at tau 3E+3 and then proceeding downwards from there.
After power is applied, it may take the GPS receiver up to a minute (assuming good GPS reception) to obtain a 3D fix (as indicated by the change from once-per-second blinking of the FIX LED to once every 15 seconds, plus the 0 and 1 LEDs changing from blinking back and forth to extinguishing). Once a GPS lock is indicated, it will take anywhere from 20 to 40 minutes for the coarse mode to bring the frequency within approximately 1E-9. The fine mode should take a few minutes more, and then the run mode should turn on and stay. If the GPS lock is lost, the unit will free-run until GPS is re-acquired, and then the startup process will repeat (but should be much faster, as the free-running frequency should be much closer to the target).
Note that the oscillator is sensitive to movement. If you move it while it's operating, you can expect phase disturbances that the PLL will have to correct. While each output is isolated, large changes in load can do the same. After changing output connections, or jostling the unit, you should give the oscillator a few minutes to settle.
The coarse mode implements a basic FLL that attempts to get close to center as quickly as possible. Once there, the FLL is maintained until the phase drifts close to the phase discriminator center point (for a maximum of 20 minutes). The coarse PLL mode operates with a time constant of 50 seconds, and the fine PLL mode with a time constant of 200 seconds.
Theory of operation
At the heart of the system is a voltage controlled, temperature compensated crystal oscillator or oven controlled crystal oscillator running at 10 MHz. The voltage control pin has a range of 0.3-3.0 volts and swings the output frequency either ±10 ppm (for the TCXO) or ±0.4 ppb (for the OCXO). This voltage must be kept as linear, stable, and noise-free as possible. The output of the DAC is fed into a resistor divider network. The resulting transfer equation is Vout = -n*(Vin-1.65) + 1.65, where n is roughly 0.5 for the TCXO and 0.8 for the OCXO. This results in a range of 0.825 volts (DAC value 0) to 2.476 volts (DAC value 0xffff), for a tuning range of roughly 12 ppm in 200 ppt steps for the TCXO, or a range of 0.2475 volts (DAC value 0) to 3.0525 volts (DAC value 0xffff), for a tuning range of roughly 800 ppb in 15 ppt steps for the OCXO. The DAC is a 16 bit serial DAC. Its default power-up state is to output a mid-range voltage. To insure that the DAC is not accessed while the controller is being programmed, there is a pull-up resistor on the !SYNC line (which is effectively a chip-select line). This is necessary because during programming the output from the controller will be floating.
The output of the oscillator goes into a 1:4 fan-out buffer (with a loading capacitor to bring the load on the oscillator to its rated requirement of 15 pF). One of the outputs of the buffer goes into the clock input line of the ATTiny841. Another goes into the input of a divide-by-10 chip, and then to the phase discriminator. The other two are presented as outputs, after going through an impedance resistor (to absorb reflected power from impedance mismatches). One of those two has a simple pi network low-pass filter to convert the output to sine.
The phase discriminator is a 4046 PLL chip. The VCO section is disabled by pulling the INH pin high. The signal pin is fed from the 1 MHz clock from the divide-by-ten. The reference pin is fed from the GPS PPS pin. As a result, the PD3 output is a positive-going pulse anywhere between 0 and 1 µs wide. This output is fed through a Schottky diode into an RC network with a time constant of 680 ns. The result is a voltage between 0 and approximately 4 volts roughly proportional to the width of the pulse. A 10 MΩ resistor across the cap yields a discharge time constant of 6.8 ms, which insures that the cap is discharged before the next PPS pulse arrives. The output of this arrangement is fed into an ADC input pin of the controller. The PPS interrupt will cause the ADC to be read, resulting in a value between 0 and 1023 that roughly corresponds to a phase shift of -512 to +512 ns. The arrangement is not tremendously precise, but it doesn't need to be - the important part is the rate at which the phase changes, not what the absolute phase actually is. The software will lock the phase to what amounts to a totally arbitrary - but constant - value.
The phase discriminator is a 4046 PLL chip. The VCO section is disabled by pulling the INH pin high. The signal pin is fed from the 1 MHz clock from the divide-by-ten. The reference pin is fed from the GPS PPS pin. As a result, the PD3 output is a positive-going pulse anywhere between 0 and 1 µs wide. This output is fed through a Schottky diode into an RC network with a time constant of 680 ns. The result is a voltage between 0 and approximately 4 volts roughly proportional to the width of the pulse. A 10 MΩ resistor across the cap yields a discharge time constant of 6.8 ms, which insures that the cap is discharged before the next PPS pulse arrives. The output of this arrangement is fed into an ADC input pin of the controller. The PPS interrupt will cause the ADC to be read, resulting in a value between 0 and 1023 that roughly corresponds to a phase shift of -512 to +512 ns. The arrangement is not tremendously precise, but it doesn't need to be - the important part is the rate at which the phase changes, not what the absolute phase actually is. The software will lock the phase to what amounts to a totally arbitrary - but constant - value.
The ATTiny841 is directly clocked from the oscillator. Its internal timers are therefore clocked at this frequency. The ATTiny841 has an input capture capability, where the present value of the 16 bit timer can be "captured" on a rising edge of its ICP pin. This also causes a capture interrupt. The ICP pin is fed from the GPS module's PPS pin. The firmware will effectively count how many cycles of the 10 MHz oscillator output occur between each PPS rising edge. A single count delta in one seconds represents ±100 ppb, which when averaged is used by the "coarse" tuning mode to get the frequency within 1 ppb or so, which means the phase shift will be slow enough for the PLL to be able to lock without having to unwrap the swings.
The serial port of the GPS module is also connected to the controller. The controller watches for NEMA $GPGSA sentences and looks for an indication of a proper 3D fix. If the GPS is not 3D locked, then it will be ignored and the system will hold-over until it comes back.
There are four separate power supply systems. First, 5 volts comes in from the external power input. There is a TVS diode to serve as a crude over-voltage and reverse polarity protection, and a tantalum cap to act as a noise filter. This is the primary source of 5 volt power for the other power supplies. For the digital section, a 47 µH inductor provides isolation from noise imposed by the digital circuitry. From the digital 5v bus, a dedicated LDO supplies 3.3 volt power for the GPS module.
From the 5v input bus, a 3.3 volt oscillator supply is derived using either an LDO for the TCXO variant or an SC189Z buck converter for the OCXO variant. The buck converter has an extra LC added onto the output to form a pi filter to further reduce noise and ripple.
Also from the 5v input bus, a separate high precision 3.3 volt regulator supplies the reference voltage for the DAC and also the supply voltage for the compression amp and the virtual ground voltage divider.
Schematics
Thursday, July 23, 2015
A GPS disciplined oscillator
I've started a new project over on Hackaday... It's for a GPS disciplined OCXO. What it does is make a 20 MHz LVCMOS square wave that you can use as a reference for other projects or devices in your lab. Although I went with 20 MHz, a lot of lab test equipment works better on 10 MHz, so I plan on building at least a variant (if not the only version) that outputs 10 MHz.
Check out the work in progress over on hackaday.io!
Check out the work in progress over on hackaday.io!
Subscribe to:
Posts (Atom)