I think this kind of barely fits within the rules, but it's interesting enough that I figure I'd post it anyways.

High-Precision, GPS-Synchronized timestamp generator for data-acquisition purposes.

This is a rather interesting project that is intended to be used for providing a easy way of synchronizing multiple independent data-acquisition systems.

Basically, I work in a research lab, and we often have instruments that have multiple independent data-acquisition systems, which can be physically separated by as much as 50 feet. We need to be able to correlate the time at which samples from each system were taken, which can be difficult if you want to resolve sampling-times to a great degree of precision. Using something like a USB data-acquisition system, just the USB latency can introduce several hundred milliseconds of unknown latency, that can vary from acquisition to acquisition.

The previous solution was a 24-bit parallel counter that was simply bussed everywhere, requiring an enormous wiring harness, and was kind of a pain in the butt.

This system uses a specialized timing GPS module that can synthesize arbitrary frequency clocks, that are phase and frequency locked to the atomic clocks in the GPS satellites.

The MCU is responsible for tying together the GPS data messages (I had to heavily extend and optimize a existing protocol parser for the GPS data). The GPS is configured to use a proprietary binary protocol, and it's all parsed by the parser I wrote.

The project has gone through a number of revisions (pictured below).

Design

Revisions!
Rev 1: Never worked, due to the fact that I was initially hoping to use a software dPLL off a much less expensive GPS, to synthesize a higher-frequency clock from only the 1 PPS output. It's probably possible to make it work, but the time-investment just made it not worthwhile. (and I'm too crappy a coder)

Used a parallax propeller MCU. The lack of decent compiled languages was a major issue as well.

Rev 2: Shifted to a ATmega2560. Worked, had lots of funky design aspects inherited from the first rev. Primarily, the continued use of shift-registers for the 32-bit output, despite the more then sufficient number of IO on the ATmega2560.

First board that ran Optiboot, and was actually programmed entirely using the standard Arduino toolchain, before I got irritated with it and started modifying the toolchain to better suit my purposes.

Rev 3: Also worked. The bodged wiring is because this board incorporated a built-in USB hub to reduce the number of required USB ports (the FTDI interface requires 1 USB, and the GPS has a USB interface as well). Unfortunately, the GPS wouldn't properly enumerate, though the FTDI device worked fine, and I've used this hub elsewhere without issue. Weird.

I don't have a proper USB debugger, so I just dropped the USB hub entirely, rather then trying to fix the issue. The GPS usb isn't really used much outside of set-up anyways.

Rev 4: Semi-final ATmega2560 version. Added a LCD for GPS status, fiddled with LEDs and so forth. Also, better footprints for the possible super-capacitors for maintaining the GPS status when not powered.

This is the last Optiboot version.

MStime is the MSTOW, or Millisecond-Time-Of-Week, which is the name of the GPS data value that is output on the timestamp out. It's a 32-bit variable that increments once per milliseond, and rolls over each week. It's a more obscure part of the GPS standard.

ITOW is another GPS-related value, being a value that corresponds to the 1PPS signal. The correlation between the two isn't properly reflected on the LCD, since I do not have the CPU time to update the LCD at the rate I'd like. This was actually one of the major things that improved in the upgrade to the Xmega devices.

Rev 5: Complete architecture switch. Now uses a ATxmega128A1U processor. Not really "Arduino" at all anymore, but the ability to have multiple interrupt levels on the xmega processor series allowed me to considerably improve the code structure.

The two bodge-wires are from me doing some experimentation, the board worked fine without them as well.

Looking forward:

Rev 6!
Add the ability to use different LCD sizes, more ESD protection on GPS antenna connection (that was an issue), ability to use a CR2032 battery for maintaining the GPS clock instead of super-capacitors.

Also, much better labeling of debug and status LEDs.

And bonus Nyan-Cat!

(These boards are out for fabrication right now. When I get them, I'll add pictures of the real board.)

I did some long-duration testing between two of the ATmega2560 boards, and over 72 hours, the RMS time-error between the two units was ~20 uS. This was with two completely independent antennas too. My design goal was < 1 ms, so I'm pretty damn happy with that.

On the whole, I think this does a good job illustrating how Arduino can be a useful tool for early prototyping for "real" products/systems. I use it for getting an initial test-version running with minimal effort, and when I'm confident the idea will work, I actually put the work in to migrate away to a completely custom, purpose-specific implementation.

Something is going on with my SVN server at the moment, and anonymous login isn't working, so I can't post links to the source and board files. When I get it fixed, I'll edit that in.

Sorry for the crappy cell-phone pictures.