-
Antenna connection options
11/04/2017 at 23:35 • 0 commentsSo far, the clock has used a drop-in edge-mount SMA connector. Having built and sold a bunch of these, it is a tiny bit awkward that the power and antenna connections are on the side. The back would be better.
In addition, I've found an amplified patch antenna with a u.fl connector that would be a... not terrible choice for a built-in antenna, if one was going to be forced to use one (it works if you have it sitting in or near a window, for example, but not terribly well in the middle of a room).
Both of these are reasonably good arguments for trying a board with a u.FL jack mounted on the board instead of the SMA jack. You could bury the patch antenna inside the case somewhere if you wanted to go that way, or you could use an SMA pigtail and mount it anywhere on the back panel. If the antenna was internal, then the hole for the back panel could be a knock-out so that it wouldn't have to be used in that case.
As for the power jack, replacing the right-angle power jack with a vertical one is potentially an option. The jack is just a little more than a half an inch tall, which means that a square cut-out in the back panel the same size would likely be the best option for exposing it.
-
Backup power options
09/23/2017 at 03:59 • 0 commentsThere are four ways you can configure the GPS chip:
- Without any backup power at all
- With a super-cap
- With a primary cell
- With a secondary cell
Turns out that the schematic for a secondary cell and a supercap are the same. For the secondary cell, the series resistor limits the charge current to just a trickle to avoid hitting it too hard.
Of course, the tradeoff between a supercap and secondary cell is that the supercap doesn't hold the power very long, while the secondary cell won't have a terribly long lifetime.
The primary cell probably is the most effective system. A CR-1220 cell will provide backup power for more or less the same period of time as its shelf life. The circuit is rather different for a primary cell. You use a pair of Schottky diodes with a common cathode connection (A BAT54C is ideal for this). The cathode goes to the VBack pin on the GPS module (with a 1 µF bypass cap). One anode goes to Vcc, the other to the positive side of the primary cell. As long as the battery voltage is lower than Vcc (the nominal voltage of a CR1220 is only 3 volts, not 3.3), this arrangement will prevent back-feeding power into the cell, and prevent the cell from powering anything except the VBack pin when the power is off.
The primary cell also offers the most flexibility. Adding the battery bail to the board isn't very expensive, and the GPS module will operate just fine with no battery installed. The voltage drop across the schottky diode isn't problematic - VBack is allowed to be slightly lower than Vcc.
EDIT: I've built a board with the battery backup configuration, and it works just fine.
-
Crystal vs RC osc
08/08/2017 at 06:37 • 0 commentsI got a board made of rev 5.1 - the same as the 5.0.2 board but with the footprints added for a 3.2x2.5mm 4-pad crystal and two loading caps on the R port pins. I built that board this evening with a 16 MHz crystal in place, and added support in the code to use the external crystal oscillator and PLL (configured to double) to make a 32 MHz clock. My motivation for doing so was to compare the stability of an undisciplined crystal against the FLL disciplined 32 MHz XMega RC oscillator.
To measure it, I modified the code to display (instead of the time) the delta of the number of ticks in the capture ISR and the expected value (32 million).
As I kind of knew from experience, with the FLL corrected RC oscillator, it bounced around fairly wildly several thousand ticks in each direction. The crystal oscillator, by contrast, stayed fairly consistent. In this particular example, it was about 1080 counts slow - about 33 parts per million. If I put my thumb on the crystal, I could get it to diverge a handful of counts or so over the course of a few seconds. That too is kind of to be expected - crystals are sensitive to temperature. But still, the crystal is by far more stable than the RC oscillator. Again, not an unexpected result.
I'm still undecided whether it's worth adding the part. Unlike the case with the ATTiny841, there's no speed advantage to adding it - the chip still runs at its maximum 32 MHz speed. But if the system clock were that stable, we could switch the firmware over to using a free-running, disciplined clock model as opposed to the absolute interrupt-driven reactive model the clock uses today. In other words, we could just have the capture ISR record the timestamp of the PPS rising edge and let the clock tune itself. Doing so would allow us to reclaim most of the 70 µs capture ISR latency, though we still would likely be stuck with the 100 µs worst-case display update latency. So we'd potentially be able to cut the accuracy spec in half (in fact, if we ran the clock 50 µs ahead of actual time, we could instead wind up with a ±50 µs spec instead of a 0-100 µs slow spec). We could even potentially dare to allow the clock to free-run if GPS drops out from time to time (though that raises the specter of having to quantify how long free-running is acceptable, or how to indicate it and so on).
That is, however, a mighty big firmware change for a very, very marginal gain for a clock that only has 100 ms granularity.
Still, since the clock works, I'll commit the code changes to the GitHub repo and upload the latest schematic and board files. You have the choice of populating the crystal footprints with a 16 MHz crystal or not populating them. There is an XTAL macro in the code that determines whether or not the firmware will attempt to use it.
-
A different errata
08/06/2017 at 04:25 • 0 commentsthe latest code for the clock will check the GPS-UTC offset (that is, the leap second count) once an hour at the bottom of the hour. If the default value is wrong, it will set the default to the current value.
One side effect of this command, it turns out, is that the GPS receiver throws away the fix and survey and starts over. This means that the clock will show "no GPS" until a fix is reestablished.
This isn't a huge deal - this will only ever happen once the very first time the clock is powered up past the half hour and once for every leap second after that.
I've sent in an inquiry to SkyTraq to make sure this is an intentional behavior. I'll edit this log when I hear back from them.
Edit:
I heard back from SkyTraq. The reboot in response to that command is by design.
-
Errata
07/22/2017 at 14:17 • 0 commentsThe v5 prototypes have shown some reduced sensitivity on the antenna input. The symptom has been S/N numbers in the GPGSA sentences about 10 dB lower than other units show.
Turns out that the problem is caused by a lack of bypassing on the AP2331. I'm going to add footprints for bypass caps on all future boards, but it appears that just tacking an 0805 or 0603 0.1 µF ceramic cap across the output of the 2331 is a sufficient workaround. Another option is to add an external bias-T if your antenna needs power and open the voltage selection jumper or remove the 0.033 µH bias inductor.
You can test your own clock by taping the GPS receiver serial output. Use a jumper wire to temporarily tie !RESET to ground on the programming header and watch the S/N numbers compared to the numbers while the controller is running. If there's no difference, then you don't have the symptoms.
So far, only the versions with the XMega have shown any issues, and those aren't going to ship before the current inventory is exhausted.
-
Version 5.0.1
07/21/2017 at 16:55 • 0 commentsVersion 5.0.1 has been built. It replaces the PAM2305 + LDO with a MP2149GJ dual buck regulator. One half of it makes the 3.3 volts for the controller and GPS, the other half makes ~2.3v for the display.
I'm a bit torn, though. The MP2149GJ is a little pricey in comparison to the older design. I could fairly easily use either a pair of PAM2305 adjustable units or a single adjustable and a single 3.3v fixed (or an LDO - like for v5.0) for less money in terms of the BOM price. But the MP2149GJ reduces the BOM quite a bit - one chip, one inductor twice, one ceramic cap three times, three feedback resistors (one common value between the two sides) instead of (for v5.0) two chips, an inductor, two different pairs of ceramic caps, a third ceramic cap as part of the feedback network and two resistor values.
I'd still rather have some sort of constant current supply for the LED segments. If I did that, I could feed the TBD62783 from either 3.3v or 5v (depending on the LED Vf), and introduce a current regulator on each of the anode lines. Classically, this would be in the form of a JFET and resistor. But having to do that 8 times with discrete components would be pretty silly.
There are LED driver chips intended to do the job, but most of them are low-side drain switches, which means that they'd be designed for common anode displays, and most of them use serial input of one form or another instead of parallel. Serial input is nice for saving pins, but I don't really need to save pins - the XMega_E5 has plenty for what we want to do.
-
More on leap second preservation
07/17/2017 at 14:33 • 0 commentsI exchanged some mail with SkyTraq. While I was coding my leap second default update code, I happened to notice that the newer clocks didn't show the leap second error even when powered up without my new code. It turns out that if you preserve VBatt at all then the module will checkpoint the current GPS-UTC offset in flash when Vcc drops. From what I can tell, it's not stored in the same place, since the GPS offset command doesn't return the current value as the "default," but the supercap is preventing the 2 second delta at every power-up after the very first one.
I asked them how long VBatt must be maintained in order to have this save take place, as the clock doesn't really benefit a lot from preserving the almanac and current time for 45 minutes (with good reception it boots up in 10 seconds instead of 30), but this leap second offset save really is a good thing. If the same effect could be done with a few dozen ms worth of VBatt, then a 1000µF polymer cap instead of a 0.1F supercap would be just as good at 1/3 the price. I haven't gotten an answer from them about this, but will update this log when I do. The good news is that a suitable polymer cap would fit in the same footprint as the supercap, so future designs can pick either option.
Update:
SkyTraq got back to me with an answer. It turns out that the flash update happens on powerup, if the RAM contents have been preserved by VBatt. So a tantalum or electrolytic cap wouldn't be helpful unless the power came back really quickly. The code to reset the default when it's wrong periodically is the way to go, and with it the value of the supercap has dropped quite a bit, it turns out. -
The Leap Second Fix
07/15/2017 at 16:51 • 0 commentsOne issue with the clock is that when it cold boots the built in count of the current number of leap second can be wrong until GPS updates the receiver, which happens about every 12 minutes.
It would be ideal if the receiver would update this value whenever it determines that it's wrong. It would only ever do so once the first time the clock starts and once every leap second. But it doesn't currently.
The fantastic news is that this is an operation that we can manually perform with the SkyTraq binary protocol! I found an application note on the Internet, and have used it to add this functionality to the clock. The clock will ask whether the current leap second delta from GPS is valid or not and whether it differs from the default or not. If it is valid and different, an update command is sent to update the default. This action is performed every hour on the half hour.
In addition, at startup the date code of the GPS module firmware is now displayed briefly after the display self-test.
These changes are currently being tested in the v5 clock code, but will be back-ported to all versions of the code.
This obviates the need for the super capacitor on the board, now that I've just had a run of boards manufactured with it installed.
In looking over the binary protocol, it appears that there may be another good idea now that we can speak the binary protocol. GPS works on a 1024 week cycle, which is just short of 20 years. If you don't do anything, then when that 20 week cycle elapses, the date will wrap around to the beginning. This is the GPS version of the Y2K bug. SkyTraq worked around this by declaring a "UTC reference date" and commands to set and retrieve it. The idea is that the 1024 week window is forced to include the reference date near the beginning. If you update the reference date, the 1024 week window will slide forward along with time. It's probably a good idea to set this value once a year. The alternative is to connect a PC up to the serial pins while holding the !RESET line of the controller low and execute the reference date setting command yourself (SkyTraq has a Windows program to do this for you).
-
How worthy is the clock?
07/10/2017 at 16:08 • 0 commentsThe Hackaday Prize rules ask for answers to a few specific questions:
- What are the challenges the project addresses?
- How does the instant project address those challenges?
- How does solving those challenges change the world?
The Global Positioning System was fundamentally designed to solve the problem of navigation - knowing where you were in space (relative to the Earth). But solving that problem fundamentally required distributing hyper-accurate time. And providing accurate timekeeping is a secondary goal of GPS. GPS has been widely used in industry and science as a source of accurate time (and from it accurate frequency references, etc).
For consumers, so-called "Atomic" clocks are available at premium prices in relatively pedestrian retail stores. Such clocks are actually radio clocks (as are GPS clocks), but their source is the WWVB 60 kHz time signal broadcast from Ft. Collins, CO. This signal is only really available in North America, its availability varies widely, and the accuracy of such clocks depends on that level of availability. The attraction of those clocks largely is that they set themselves and automatically corect for Daylight Savings Time. They typically run on batteries which usually need to be replaced at least annually.
GPS reception is much more available not only around the world, but in North America it relies merely on line of sight reception from the GPS satellites, which are in orbits that move around. Because of that, continuous GPS coverage is easier to obtain than WWVB (where continuous availability is limited to only a few states surrounding Colorado). Because of this a GPS clock doesn't have to maintain its own accurate timekeeping - it can count on continuous service from the GPS system to tell it the current time.
WWVB's timecode includes DST status, but only for the US (which is sensible given the fact that its coverage area is limited). GPS does not, but GPS includes the date, which is sufficient for a clock to compute DST on its own. In fact, the GPS clock includes rulesets for the EU, Australia and New Zealand in addition to the US (and you can also turn DST off). Adding additional DST rulesets would simply require adding them to the firmware (the same goes for ruleset changes).
The idea of a clock that sets itself and displays accurate time without any need for maintenance has been made possible by GPS, but that same facility has not been made available routinely to consumers other than via radio clocks limited to use within a particular region. Every modern smart phone or Internet connected computer can obtain accurate time over the Internet, but using something like that as a simple standalone clock would be swatting a fly with a sledgehammer.
Everything about the design of this project has been about balancing accuracy against cost. No other product of which I am aware offers a display granularity of 100 ms, an accuracy of under 200 µs, and a price tag under US$150.
-
Draft business plan
07/10/2017 at 15:39 • 0 commentsThis is the draft business plan required for Best Product entries in the Hackaday Prize Best Product category.
The clock is currently in the Tindie store, and selling for prices that are appropriate for the costs of sourcing the components in the current sales quantities.
To make the GPS clock a better product, the sales volume needs to go up. With sufficient demand, the assemblies can be sourced in quantities that will drive the prices lower. In particular, with sufficient volume, transitioning from the current laser-cut wood and acrylic case to an injection molded plastic case would dramatically reduce the cost of the enclosure (given enough volume to amortize the tooling costs).
As a product, the clock has some challenges facing it. The clock requires an external antenna. This is because in general people don't want their clocks to sit where GPS reception is best. An external antenna makes placement of the clock itself less troublesome. But not everyone is going to have (or find) a spot sufficiently good for reception.
Additionally, the clock is just a clock. It has no functionality other than displaying the current time to within 200 µs. This is a deliberate choice - adding more features to the clock makes the user interface more complicated than it otherwise needs to be (and it's already fairly complicated for a consumer product) and further increases the cost.
Increasing the sales volume would require increased marketing for the clock, but hopefully in the longer term would be offset by reducing manufacturing costs as the volume went up. The same reductions in cost would allow the price to be reduced.
But even at its current price, the clock is still offers the highest accuracy:price ratio available anywhere. The clock maintains that accuracy with no maintenance of any kind - it even automatically handles daylight savings time changes. Even without the accuracy, a plug-in clock that set itself and automatically tracked DST would already be worth most of the current price.