Project Logs

Collapse

• Changes coming

  Nick Sayer • 12/05/2021 at 05:51 • 0 comments

  The default baud rate for the serial I/O for the PX1100T is 115,200 baud. Which makes sense given how much more information gets sent given the quad constellation support. That means there has to be a #define in the code to switch from one module to the other.

  In addition, there are some message changes. $GPRMC becomes $GNRMC, $GPGSA likewise become $GNGSA, but it's sent once for each constellation, with an ID field. The biggest change, though, is that $GPGSV turns into $GxGSV, where x is either P, L, A or B for GPS, GLONASS, Galileo or Beidou respectively.

  With support for up to 5 GSV messages per constellation there can be up to 80 satellites. This means slightly rearchitecting the SNR display in the menu system. Now it's 3 2 digit numbers: the total number of visible satellites (the number of satellites in all the $GxGSV messages), the total number of satellites that are being used for the fix (the sum of the "satellites used" values in all of the $GNGSA messages) and the maximum SNR for any single satellite (from $GxGSV). Lastly, there's the GPS mode indication from $GNRMC. This has a bunch of possible values, but the two that are likely to actually show up are "A" for Autonomous mode or "d" for Differential mode (meaning that at least one SBAS is contributing to the fix). Differential mode is ostensibly what you want to see, though for this particular application it's probably not very significant (it can improve the location fix potentially by an order of magnitude, but I don't know how much this results in improvement to the PPS jitter. And for this clock that hardly matters in any event).

  Preliminary tests suggest that the quad constellation support results in improved indoor reception, although a good outdoor antenna placement is still strongly recommended.

• New GPS receiver

  Nick Sayer • 11/27/2021 at 22:32 • 0 comments

  Well, between the pandemic and the fire at the Japanese oscillator factory, SkyTraq has told me that they're going to have to EOL the Venus838LPx-T module that I've been using in damn near everything. I've got about 120 of them left, so there's plenty of time, but I have also gotten ahold of their replacement, the PX1100T, which looks to be a whole lot more convenient all around.

  Firstly, it's the same price at Q:100. It supplies antenna power on its own, so there's no need for the external on-board bias-T. TBD is it's behavior when faced with a short circuit on the antenna jack. We'll see. It would suck, but in principle we could add a blocking cap and do our own external bias-T with our proven circuit. But even better is that the module is compatible with all four of the existing GNSS systems today - GPS, GLONASS, Galileo and Beidou. It also comes as a castellated PCB module, so no more LGA, which was a fiddly assembly process for me. It has fewer connections, and fewer support components on the board. The one big disadvantage is that there is no FIX LED output pin.

  I could get rid of it. For the GPS Clock it's a bit redundant, but for the GPSDOs it's somewhat handy to have it, so I've decided to add support for emulating it on a currently unused pin of the XMega.

  This isn't too hard to do - just hit the OUTTGL register's bit for the pin in question in the PPS ISR as long as the GPS Lock indication is set. And any place where you clear the lock indication, hit the OUTSET register on the same pin. That yields the same behavior as before - on for bad GPS, flashing at 1/2 Hz for good.

• New feature: SNR report screen

  Nick Sayer • 04/20/2020 at 20:13 • 0 comments

  I've added a new feature to the v5 firmware... the first screen in the menu system is now a signal quality report. The hour digits say "nX" where X is the number of satellites in view (this is reported by GPGSV). Numbers higher than 9 will be hex characters, so A, b or C. Normally this should be C (12). The minute/second digits are Sxx where xx is the highest SNR value reported in the active GPGSV sentence fragments - that is, the best SNR value reported. The 10th of a second digit will show the number of satellites that are currently being used for the fix (that is, the number of PRNs listed in the GPGSA sentence).

  In general, you want an absolute bare minimum of 4 satellites contributing to the fix. With a good antenna this number should be more like 8 or 9. You'll likely always see the number of satellites in view as 12, as that's simply taken from the almanac as the 12 closest ones. SNR values above 40 are excellent. 35-40 are good, 30-35 are barely adequate, and under 30 are bad. The receiver is configured with a default SNR mask of 27, so numbers below that mean that no satellites are good enough to use.

  If you have a v5 or v6 clock and a PDI capable programmer, you can update the flash yourself. If not, you can send your clock to me and I'll do it for you.

• Build report 6.0

  Nick Sayer • 11/03/2019 at 06:18 • 0 comments

  The version 6.0 boards are a success.

  I built one with red LEDs and it's quite good. It's a touch dimmer than 5.0 was, but I think that's overall a good thing - the versions up to now were a little too bright insofar as the low end of the brightness range was still too bright. With the per-segment 30 mA current limit there is absolutely no brightness variation of the AM/PM LEDs when the colons blink, which was a small issue before. There's no trace of ghosting with the 1 kΩ pull-downs on the anodes (though to be fair it wasn't an effect that was noticeable with red anyway. I'll build a blue one and then we'll see).

  Moreover, it works normally even with 9 volts supplied on the input power (thanks to the wide-input LDO for the 3.3v rail). The LDO did start to get a bit warm, however, and this was with the antenna disconnected, so it wasn't supplying any antenna power. This means that the board could conceivably be used as the brains behind very large displays where the Vf of the segments is much higher.

• A dramatic simplification

  Nick Sayer • 10/19/2019 at 21:31 • 0 comments

  I don't know why I haven't thought of this before.

  There's no reason to be so fussy about figuring out the precise voltage for the displays. The high side driver chip is perfectly happy to be fed by 5v and use 3.3v input levels from the controller. Given that, there's no reason not to just put series resistors in the anode lines. In that universe, there's also no reason we can't just use an LDO instead of a switching supply for the controller and GPS receiver - we use the same arrangement in the talking clock and it works fine.

  Better yet, they make 30 mA current limit "diodes" that we can use instead of resistors. That way we don't have to tailor the resistors for the LEDs' Vf - we can source any color we can get in the correct pinouts and let the current limiter dynamically tailor itself to the Vf of the displays.

  I'm going to try this architecture and if it works, it'll be the follow-on version to v3.1 in the store.

  EDIT: One difficulty I had not fully considered was that the current regulator has an overhead voltage of 1.8 volts. Given a 5v input, that means a maximum Vf of 3.2v, which is right where the blue LEDs sit. The 5V input voltage was necessary because it was the maximum voltage of the 3.3v LDOs I've got handy, but it turns out you can get pin-compatible wide input LDOs. One factor to consider going that route is the maximum power dissipation of the LDO, but back-of-the-envelope calculations with the NCP718SN330T1G show that the input voltage can go all the way up to about 9 volts before power dissipation becomes a concern. That suggests that running with blue LEDs would be best with a 6 volt supply, but there are folks who have asked about using very large LEDs with much higher Vf. It turns out that's not a problem at all with this new design. The high-side switch and current limiters can handle an input of up to something like 45 volts, and if you remove the on-board LDO and supply 3.3v through the PDI header on the board, it'll work just fine. In this configuration you'd probably also want to solder the antenna power jumper to the 3.3v side or open it and use an external bias-T so as to not feed too high a voltage to your antenna.

• Recent developments

  Nick Sayer • 10/14/2019 at 16:12 • 0 comments

  With a new design for a 3D printed/printable case, I'm going to ditch the long-shaft buttons and go with normal ones. There will be a button extension that will sit in the back of the case between the actual switch and the back panel. This should make life much easier for my assembler.

  In playing with rastered LED matrices in other contexts, I've learned that ghosting can be sometimes caused by the internal LED capacitance self-powering the LEDs after the raster on-period has ended. The workaround for this is resistors from the anode(s) to ground. I've added at least footprints for these to the board, though whether they'll be universally populated or not remains undecided.

  Lastly, I've ordered a board with footprints for non-right-angle through-hole antenna and power connectors. Going this way would allow the antenna and power to come into the back rather than the sides. Some validation with a case design will be needed to decide whether or not this will be the way forward, but it's at least worth an experiment or two.

• Long term LED reliability with v5

  Nick Sayer • 03/06/2019 at 16:56 • 0 comments

  I've been running some v5 boards as a test for a while now, and I've had a couple of digits on different displays begin to fail (the failure mode is they start to be markedly dimmer than the rest). The only reasonable explanation is that I'm over-driving them, so that means the Vf must be reduced slightly so that the displays are more reliable.

  Fortunately, the store inventory of v3.1 boards is still holding up, so there's time to repeat the experiment with a different feedback divider on the LED Vf buck converter.

• Improved brightness again

  Nick Sayer • 11/20/2017 at 07:31 • 0 comments

  I figured out a way to preserve the 2 µs turn-off delay and still have a brighter display (comparable to what was there before).

  The display raster timer will now alternate between two counts - a short value for the turn-off delay time, and a longer value for the actual display.

  With this configuration, we can go back to a 10 kHz raster rate, but with a 75% duty cycle (actually, 75% of 12.5% since the display lights one digit at a time). This doesn't sound like much, but it's actually dramatic from what you can see.

  The bad news is that the accuracy spec (as you'll recall, it's the PPS ISR latency plus the worst-case display refresh) now becomes 125 µs. But again - that's a worst case value. Since a display update resets the raster, we display the least significant digits immediately, so their latency will be much closer to 25 µs. It's only the hour digit an AM/PM indicators that wind up taking the worst-case time, and they don't change nearly as often.

• A quick idea to improve accuracy

  Nick Sayer • 11/05/2017 at 17:45 • 0 comments

  Right now the spec for the clock is 200 µs.

  I think I can turn the spec for the v5 hardware down to 100 µs.

  Recall that the accuracy spec consists of two parts: the ISR latency for the PPS signal, and the display raster update time. You have to account for both, because at the end of the PPS ISR, you've updated the "registers" that display the time, but you have to potentially wait for an entire raster cycle to occur before the display actually changes.

  Right now, the raster cycle displays all 8 digits, and there are four brightness periods for each digit, meaning a full raster cycle takes 32 interrupts, and they happen at 320 kHz.

  If you flip that around, so that the brightness cycles happen outside and the digit rasters happen inside, then the display raster frequency jumps from 10 kHz to 40 kHz, which means a full raster cycle takes not 100 µs, but 25.

  Now, there's a problem: this only works at full brightness. If you dim the display, then there will be somewhere between 25 µs and 75 µs periods of time when the display is not visible. The workaround for that is to give the code outside of the raster ISR the ability to override the raster cycling and have it start from zero right away. In principle, this should only happen once every 10th of a second (or once a second if tenths are not displayed), so the glitch in display brightness should not wind up being visible.

  I'm going to test this idea and see what the impact is.

  EDIT:

  Turns out today is an excellent day to test changes, seeing as how it's DST transition day. For the purpose of most of the code, the fact that it's the transition month probably is what matters the most.

  The issue with this new display mechanism is that the high side switch has a turn-off specification of 2 µs. Well, with the interrupt timer for display rastering hitting every 100 counts, that means those interrupts are 3.125 µs apart. If you try and put a delay in, then essentially the main loop never gets a chance to run at all.

  The workaround is to, unfortunately, cut the raster rate in half and stick an empty slot between each lit-up slot. This also winds up reducing the brightness a bit, but frankly the maximum brightness was pretty bright, and the loss isn't too noticeable. The four brightness levels are still meaningful.

  With this change, the latency of the PPS ISR is now 26 µs. With the worst-case display update time of 50 µs, that means that the accuracy now is 76 µs, better than twice as good as it was. But more to the point, because the digit raster order goes from least-significant to most, the only really high latency digits are the least important ones. In general, you can count on the 100 ms and 1 second digit to be updated within 12.5 µs of the end of the ISR, or 38.5 µs after PPS.

  Unfortunately, these changes require the v5 display rastering system, so the improvements can't be ported back to the MAX6951 hardware.

• Whither Holdover

  Nick Sayer • 11/05/2017 at 17:34 • 0 comments

  A few people have asked about holdover as a feature. Holdover is the ability of a radio clock (and the GPS clock is a radio clock, of course) to free-run when reception fails.

  It's not been a priority because with proper antenna placement GPS should always be available, and holding over should not be necessary. This assumption has been a driving force in keeping the hardware and firmware simple. When there's no GPS lock, you just display "no GPS" and wait.

  The problem with holdover is that the statement of how accurate the clock is gets a lot more complex. Right now, I can say that the clock is "within 200 µs." In actual fact, the clock is somewhere between 70 and 170 µs slow because it takes 70 µs for it to process the PPS pulse to completion and the display raster cycle is 100 µs long.

  But holdover introduces the possibility of longer term drift as long as reception remains unavailable. The magnitude of any potential drift will be proportional to how long ago the last sync occurred. You can "tune" the crystal oscillator while reception is available - that is, determine the exact number of clock cycles between PPS interrupts - but you need to quantify the magnitude of any potential changes in that offset.

  You can limit the scope of the problem by limiting how long you're willing to hold over before giving up. But even then, if your crystal has a 10 ppm stability, that's still 36 ms in an hour.

  You can throw money at the problem. A TCXO can provide a frequency stability of 50 ppb. That would give you a maximum drift in an hour of 180 µs. But a DOT050V adds $30 to the BOM cost (so $60 to the retail price).

  In any event, you'd definitely want to give some feedback of how long you've been holding over. You could just do this with a single LED - on constantly for GPS being available, and mostly off with a blink code indicating how long holdover has been in effect (n blinks in a row mean n time periods of holdover, and after 5 time periods the clock should give up).

  But again, all of this is just an effort to mitigate poor antenna placement. I'm just not really convinced it's worth the effort.

View all 51 project logs