Tag Archives: Hardware NTP Server

More new PCBs

With a new job looming (actually, already started), it is the best time to start working on electronics projects again. No, I don’t know how that works either.

NTP Server 1.5 board has been made and now awaits testing. It’s pictured below:

The changes are documented on the history page. The two major changes are using a switch-mode power supply instead of a linear one, and removing some external flash that is no longer required now I have a working XBoot setup.

The other board to arrive is the first cut at an Arduino clone based on an XMEGA 64-pin chip. There are a few XMEGA based clones floating around, this one is mostly focussed on trying to support a wide range of 64-pin XMEGA chips and provide some extra hardware to get you started. This board is pictured below:

These are the first boards I’ve had made by the people at Hackvana. The build quality is good, with very clear silk and all drills have been correct. (I’ve had boards from other places with incorrect drills). In particular, despite the very small silk text for component labels (which, I should really have made a lower weight), they’re all clear enough to be read. Tented vias also came through just fine, and Hackvana will accept two drill files for plated and unplated holes, if you prefer to not plate mounting holes.

We’ll see how the boards perform when I get around to completing an assembly, but they look pretty good so far!

A busy few weeks

Rather unexpectedly, it’s been a busy few weeks on the electronics front. The result has been two new projects show up, and actual real honest progress on two other projects!

The two new designs are shields for an Arduino-based project that the great people at Nicegear are working on. One is a isolated driver and input shield, that allows switching higher voltages than the little Arduino can normally drive at much higher currents; the other is a compact switch-mode supply shield to allow you to run an Arduino off higher voltages without generating large amounts of heat.

The driver shield has been already built and tested by Nicegear, and works mostly as expected. There has been a revision to it already to include more voltage input options for the Arduino on the same shield as the drivers and input isolation. The original revision was limited to 12V for powering the Arduino.

The switch-mode supply shield hasn’t been built or tested just yet, but I’ve breadboarded the design so I am reasonably certain it’s going to work okay.

On the existing projects front, both the XMEGA-based Arduino clone and my long term NTP Server project have new boards ordered and on the way. The XMEGA board turned out pretty well I think, I’m hopeful with upcoming multiarch support in the Arduino IDE to see better support for such boards. On aspect about this board is rather than overloading the shield header with a bunch of useful but in-the-way peripherals, all additional hardware is conflict-free and allows full use of all the shield pins.

For example, the board includes pads for an 8-pin SOIC SPI flash or SRAM chip. While the SPI interface is wired to the usual Arduino pins for this (10-13), the CS line for the chip is on a discrete pin not shared with any of the shield pins. The same is true of extra LEDs, 32.768kHz watch crystal for the RTC, etc.

The NTP server had a minor polish up from the last post on it, but otherwise it’s down to just getting the board made and see if I’ve nailed down the last remaining issues. The software side of this is looking almost complete enough to start field testing!

Project Updates

A few small updates on the state of various projects..

NTP Server: Version 1.5 board looks mostly final now. The 3.3V switchmode regulator design has been checked on a breadboard and seems to run 1.4 just fine, so we’ll be going with that on the 1.5 board. This will reduce the heat significantly, as the reverse-polarity diode (which itself loses about half a watt) is being replaced with a P-channel MOSFET and the switchmode supply loses far less heat compared to the linear regulators (almost 1.6W are sourced from them alone). Software side I’ve removed all the (hugely problematic) single precision floating point code and use the time reported in integer milliseconds instead. Much nicer!

AVR Programmer: First build has been completed, and it largely works with the LUFA code compiled and uploaded into it. Various issues have come up, such as the bootloader switch not working quite as expected (The bootloader will only enter DFU mode if the switch is closed and we’re coming out of external reset which isn’t just a power-on-reset. Ick.) External flashing of the MCU doesn’t work right (unsure why) and it seems to hold !RESET low on targets. There is a 1.1 which is in progress.

New Breadboard PSU: Following on from the tests on the new switchmode supply for the NTP server, I’ve sketched out a new breadboard PSU which uses the same design. This would be an alternative to the linear one I already make and sell. At the moment it’s a single output design, I’m thinking about ways to make it dual-output or at least easily switchable between 5V and 3.3V.

XMEGA Arduino: Most of this design is completed. I need to just do a build to see how it plays out. The new XMEGA C3 line looked interesting but imposes some annoying routing problems. While using the C3 would provide a USB XMEGA which isn’t encumbered by crypto modules (and, therefore, export regs) and the C3 has USB pins where they are on the AxU chips, it has the same selection of peripherals as the D3 and USB is camped on top of one of the SPI ports. Which makes routing hard. May stick to the D3+MEGA16U2 bridge approach for now.



All electronics exists to convert electricity into (mostly) heat. It just happens to do something useful along the way. The progression on the design so far has been to consider digital issues first (make the circuit work at all), then mechanical (fit to the case), and now is down to thermal – what to do with the heat.

Now that I’ve started to run the prototypes in the target case I have some idea of the temp of the board, components, and how the case feels. And it’s warmer than I want.

This is somewhat of an issue since the stability of the clock is related to the temperature. If a crystal has a stability of, say, 20ppm, it is always stated with a temperature range at which that holds true. For (most) cheap crystals that’s 25 degrees. As it gets colder or warmer it gets worse.

During the design some of this was taken into consideration. Firstly, since we are aligning ourselves to GPS sources, the stability is less critical: we have a stable external reference less influenced by our local temperature. It does mean we’re limiting how long we can run without GPS sources (it’s currently in the “minutes” range, which is not far off what a $4k device does and this costs nothing like that). This is currently implemented in a coarse-grain way, we just adjust our internal clock being fed by the DS3234 output.

Secondly, the decision to use the DS3234 RTC instead of a watch crystal was driven by the fact it’s a Temperature Compensated Crystal Oscillator, that is it has a temp sensor and can tune the crystal inside it to compensate for the local temperature. Over the range 0 to 40 degrees it claims 2ppm out of the box, and 3.5ppm between -40 and +85. So even with a lot of heat it’s still significantly more stable than a cheap watch crystal.

There are some things I haven’t implemented yet which I’ll now need to consider.

The DS3234 exposes it’s tuning interface, and the datasheet mentions that with an external trusted reference (oh hai GPS) you can feed it extra offset information to further compensate for both aging and to obtain finer precision (you get about +/- 0.1ppm of control). I’ll need to add an extra step after GPS lock to tune the DS3234 against the GPS pulses, and retune it from time to time.

Once the case is closed up properly (it’s not fully closed right now), it may need some holes cut in specific places to improve natural convection. Likely places will be right under the (not very efficient, therefore a source of a lot of heat) LDO regulator. It also will likely need holes in both endplates to ensure any air that is around can get into the case.

We’re also running the main MCU at full clock rate without any regard for clocking down based on demand. While it’s a lot of work to implement, I could look at power management for the MCU by implementing dynamic clocking.

Those things can be done without changing any aspect of the board design.  But there’s board design changes I’m looking at as well.

The 1.5 board now has space for a 16x16x4mm fan in one endplate, with PWM control so we can run it as slow as possible. Like many things, it’s there if I finally decide it needs a fan, but it’s something I’m going to try to avoid. The fan is 3.3V so doesn’t need it’s own LDO (since a lot of fans are 12V, fewer 5V), but should probably have a transistor between the MCU and it to source as little current from the MCU as possible.

The LDO has also been re-arranged to make it easier to attach a small heatsink to. Ideally this will move heat away from going into the board so much, as I suspect that’s what is really causing the reported temps to be as high as they are. It might only work best with real airflow over it, but we’ll see how that goes.

There’s also some evidence the Ethernet section is drawing more power than it should do, as a result of not quite getting the front-end right. There’s fixes for that in 1.5 as well.

All in all, it feels like I’m getting into the real tail end of the project now to be considering these sorts of issues. There’s less making-it-work-at-all, and more making-it-awesome.

New boards have arrived!

The new revision of the NTP Server and a test build of the LUFA AVR Programmer boards have arrived. The service from Seeedstudio was pretty quick and excellent for pricing, although one of the boards had some drills not correctly done. Still, it’s far cheaper than getting larger runs made so I am quite happy.

Sadly, I appear to have made some mistakes with the stencils that were cut by Ponoko – the detail has been lost a lot more than previous cuts. I suspect I didn’t take into account laser kerf enough, but I also think they were cut without protective paper on both sides as previous ones were done. That seems to make a lot of difference. I shall get them re-cut in the next few days.

Now off to order more parts from Element 14 to prepare for the first builds of these new designs!

New boards on the way

I finally committed to a new set of boards for a couple of projects. NTP Server 1.4 and the LUFA-based AVR programmer both have been sent off to be manufactured, and assembly should take place in a few weeks time. I’ll separately post about the changes for the NTP Server.

The LUFA board is an quick prototype to see how badly I’ve misread the USB AVR datasheets. It is based off the hints provided in a readme associated with some LUFA code, and vague attempts to read the USB sections of the Mega 16U2 datasheets. It includes a level shifter to support 1.8 – 5V targets which covers all the useful ranges of both Mega and XMega MCUs.

I’m not sure how the little LUFA board is going to turn out, but it was fairly cheap to get made and I’m bound to learn something out of it as a result.

These are the first boards being made by Seeedstudio’s Fusion PCB service, which for very short runs looks cheaper than previous options. It’s only 10 boards (compared to the 25 or so I was getting from other runs) so it’s more expensive per board but much cheaper to do a run because it’s a smaller number of  boards. We’ll see how they turn out.

Final revision no really!

I think the number of times I’ve said “this is really the final revision” is now too numerous to count, but honestly this time I think it’s fairly close to final. (That’s downgraded from yesterday’s remark to people that asked,  where I said “actually is final”.)

The most recent scare with the design was what looked like a short in the antenna cable causing various things to reset and may now be damaged. It’s unclear to me exactly what happened, but we’re no longer getting a stable consistent GPS lock. The antenna is active – it has 3.3V fed up into it to power an LNA in the weather-sealed puck antenna – but there’s no current limitation on what’s fed up this path.

The datasheet for the GPS has a large example circuit to provide hints to the GPS chip that either the antenna is disconnected (only works for active antennas), or has a short and automatically disables the power into the antenna. But the design is far more than I really need, and takes up enough board space I’d have to do some serious rearrangement. It’d be nice to use the GPS chip’s LNA control line and reporting antenna modes, but the main thing is just limit current and suppress shorts.

I’ve generally ignored putting any significant additional current limitation into the design because none of it is exposed to any external connections. All the failure modes of any of the parts would just result in the board being tossed rather than fixed, and none of them actually are subject to external connectors – except now realising the antenna is directly. (The ethernet jack does have power going into the internal side of the transformer, but since it’s internal side a broken cable plugged into the jack doesn’t cause more power to be drawn.)

Instead, I’ve decided to just add a simple PTC fuse to the power input side of the antenna, limiting it to 125mA which is comfortably more than any active antenna should need, but should blow fast enough to prevent significant damage to the board. Whether I add some remote control of that power using a MOSFET or some sort of reporting of the failure to the GPS or MCU I haven’t decided. It depends on how much board space I need. A PTC fuse is small enough to just throw one on there without much concern.

(PTC fuses are tiny resistors which have a Positive Temperature Coefficient, that is as they try to carry more current they heat up, and a high enough current/temp will result in a very high resistance, enough to stop the current flowing. They reset themselves by cooling down. Their self-resetting nature and simplicity makes them useful for this sort of case. PTC fuses are commonly used in external power ports such as USB.)

Hopefully, that’ll reduce the risk of a short! Soon it will be ready!

It would help if I knew what done looked like

Clearly posting about the NTP Server v1.4 board being done was a mistake, as I ended up launching myself into a major overhaul of it anyway. Yep, 1.4c was forked into 1.4d and has many many changes.

Part of the problem is I’m not settled on what “done” looks like. I was originally planning on not migrating from a simple watch crystal RTC to the DS3234 RTC until after 1.4 was completed. But working with the XMega RTC has given me a lot of niggly issues around getting it to behave well with aligning the clock.

The problems with the XMega RTC are a mix of just the result of using a 20ppm crystal (ie, you get 20ppm accuracy, and that’s not so cool) and some interesting choices about how it’s built.

Some AVR Megas have an async clock timer, usually it’s the single 8-bit timer. It’s pretty basic, but 8-bit is actually a good choice since you can cover off the rest of the needed bits for a 32.768kHz crystal off interrupts, once every 256 ticks is not a heavy interrupt workload. The Xmega doesn’t have an async clock timer, instead there’s an explicit 16-bit RTC with a crystal input.

At first (mostly when reading the datasheet) this looks pretty good. But, there’s a few annoyances. A number of Megas (and, more specifically, the ones I’ve been using like the 1284P) allow not only a 32.768kHz crystal but an external clock input. This allows you to use a variety of other clock options. The Xmega RTC has no such option, not in the A and D series anyway, and that’s almost all of the ones actually shipping. (You can brute force an external clock into a crystal input but I’d prefer to stay within what the datasheet says the chip is expecting.)

The other issue with the RTC is the way you access it. Because it’s running in it’s own clock domain – specifically off whatever 32-ish-kHz source you chose – you have to jump through a lot of busywaiting to get configuration pushed into it. Busywait. Set something. Busywait. Set something else. And so on. The same problem plagues accessing the current count, if you want to change it yet more busywaiting.

You also don’t get any capture options with the RTC, it has just compare and period registers, that’s it.

This makes it quite difficult to align the RTC to a fine degree. Sure, it’s great if you just need a simple timer to fire, say, a 1Hz interrupt to do something else in your code. It’s actually very good at that. But if you actually care what “now” really is, then it doesn’t cut it.

Falling out of that has been a large redesign, and involving the DS3234 RTC to replace the simple crystal. Thankfully while they did take away async clocking for a timer, they replaced it with a much more awesome system and the result is any of the normal 16-bit timers can provide a better replacement with finer control and more reliable capture. I’ll probably post about that some other time.

I’ll still be using the Xmega RTC, but it’ll just be there as a system clock for trivial event timing that we don’t really care about alignment for. Hell, 1% RC oscillators used as an RTC will be fine for many other timing needs in the code.

NTP Server Progress Update

Just a brief update on the NTP Server project. The most recent revision of the board is starting to look good, and parts have been ordered, but not yet the PCB. What is being done at the moment is checking the scaling of the new parts against the PCB footprints on paper.

This is useful to just check before we order the PCBs that the parts we think match our PCB actually do. At this point it’s cheap to change the PCB (since it hasn’t been made yet), or order different parts. Once the PCB is actually made, there’s a large cost sunk into it which is not recoverable – it either works or it doesn’t.

There’s a long list of changes for this revision, I’ll post those when the PCB is ordered.

One more alarming part of this revision is the MCU appears to have tripped over some limit on CPU cycles before regulations involving WMDs start kicking in. No, I’m not making WMDs, but there are international treaties governing the movement of “high technology” that could be used in their creation.

Today was the first time I’d encountered that for any parts being ordered, and now I’ve had to sign documentation saying I’m honestly not building nukes, or biological weapons, or anything involved in delivering them. How strange.