HDMI breakout PCB

This is probably only useful to a small handful of people, but if you're and engineer developing HDMI products that might include you.
For some work developing HDMI-compatible FPGA code, I needed to observe the control signals with a scope. So I built up this little breakout PCB. The high-speed video TMDS signals are routed directly through from one connector to the other. I tried to keep them equal length and as short as possible. Don't have any way to verify impedance and reflections, but it works ok on one TV with short HDMI cables.
The low speed (CEC, SCL, etc) signals are brought out to the header in the back in the photo. Jumpers allow the signals to pass through, or they can be disconnected to test and modify them.
The PCB is shared on OshPark. See http://oshpark.com/profiles/sensicomm  if you want to use this design. It uses standard HDMI female connectors, available from DigiKey and many other vendors. Soldering the fine-pitch surface mount pins on the connectors is a bit of a challenge. I tried soldering individual pins, but ended up using the flood it with solder and mop up the excess with solder-wick method.

Linux system clock and hardware clock accuracy?

This is a followup to the "my Debian Tweaks" post on on Jan 21. Briefly, my PC tends to spend a lot of time disconnected from the Internet, and the default clock management as implemented in /etc/init.d/hwclock.sh doesn't work very well in that case.

Debian timekeeping background

Linux on Intel-based PC's has two timekeepers, often referred to as the system clock and the hardware clock. The system clock is based on a high frequency crystal oscillator and is mainly intended for timing and scheduling programs and such. It doesn't run when the system is turned off, so it needs to be initialized with the current time when the PC is powered on. The hardware clock is a battery-backed circuit that keeps time even when the PC is off; it provides a value to initialize the system clock at power up and is rarely used for anything else. Debian systems assume the system clock is more accurate than the hardware clock, and they update the hardware clock every time the system is powered down (see /etc/init.d/hwclock.sh).

So how accurate are the crystal oscillators for system and hardware clocks?

Relative accuracies of these clocks depend on the specific PC. The only spec I found in a quick search is 500 parts per million (PPM) in the Intel HPET timer spec software-developers-hpet-spec-1-0a.pdf. The system clock may or may not be related to the HPET timer. Timing crystals are usually spec'ed at 100 PPM or better even for cheap crystals, so 500PPM sounds like a really loose spec.
The PC hardware clock typically uses a 32.768 kHz watch crystal and a battery-backed timing circuit (you can see the coin cell battery in the photos in my Dec 24 2012 posting). Watch crystals are readily available with 20 PPM accuracy specs, and the frequency is generally stable with time and temperature. For example, the CFS206 available from Digikey and other distributors is 20PPM accuracy, 3PPM per year max drift and .034 PPM per degree C temperature sensitivity. So timekeeping accuracies of a few PPM should be feasible with some calibration.
The US National Institute of Standards and Technology did an interesting study of wristwatches, tf.nist.gov/general/pdf/2276.pdf, and found that even a cheap[2] ($30) modern watch can achieve better than 1 PPM timekeeping accuracy. Older quartz watches were orders of magnitude worse, which implies that manufacturers have started calibrating the crystals in the last few years. So a PC's hardware clock should be capable of similar performance.

How good are the clocks in my PC?

Here's a quickie experiment with my main PC, an Acer Aspire 5253 notebook  with hardware clock updating disabled in hwclock.sh.  I set the hardware clock on Feb 13, 2013, and it hasn't been touched since. The hardware clock lost 6.227 seconds in 4609045 seconds (about 53 days), which is an average frequency offset of 1.35 parts per million (PPM).[1] In contrast the Linux system clock lost 0.44 seconds in 9103 seconds (about 2.5 hours), which is 48 PPM.
I checked a couple of older systems and their hardware clocks are in the 6 to 10 PPM range. So newer PC's are probably being calibrated like newer watches are. I suspect that the hardware clock is still more accurate than the system clock on the older PC's, but the difference should be less pronounced.

My Setup

The hardware clock in the Acer Aspire is more accurate than the system clock by a factor of 35, so that's why I don't let hwclock.sh update the hardware clock on shutdown; instead I manually set the time using ntpdate-debian every month or so, and manually update the hardware clock at that time. That keeps me within 3 seconds or so of true time, which is more than adequate for my purposes.
There are routines (adjtimex and such) that attempt to improve the calibration of the hardware clock and/or the system clock. They generally assume the oscillators are off by a fixed percentage from the true rate and that frequency changes due to temperature and drift are insignificant. In the 1 PPM range I doubt that that's true, so I don't bother with adjtimex and friends.

Side Notes

[1] I checked my Timex DataLink USB watch at the same time, and it lost about 2 seconds over the same interval. So it's averaging around 0.5 PPM.
[2] And if you want to spend a few thousand dollars, you can get a Grand Seiko SBGX059 which is spec'ed at less than 10 seconds per year, or about 0.3 PPM. Nice, but I think I'll stick with my sub-$100 Timex.

ARM presentation at Consultants Network of NH

On February 6 I made a presentation to the IEEE Consultants Network of New Hampshire (www.consultantsnh.org) entitled "Beagles and Berries: the World of Low-Cost ARM Computing," about the history of the ARM architecture and describing and demonstrating the Texas Instruments Beagleboard (www.beagleboard.org) and the Raspberry PI (www.raspberrypi.org).
My slides are available for download at https://sites.google.com/site/sensicommllc/Home .

My Debian tweaks

When doing a new Debian Linux installation, there are a set of basic configuration changes that I nearly always make. While the issues do not apply to everyone, I think they are common enough that many others may find them useful. As always, your mileage may vary, use at your own risk, etc.
My system is Debian Testing installed on a laptop that is typically shut down at night and that often runs disconnected from the Internet. So here are the problems I often see and my solutions:

1. PC locked by fsck. The fsck partition check program typically runs every 30 reboots or so on EXT2/EXT3 filesystems (and maybe others). This automatically happens during the boot process and, per Murphy's law, it usually happens while setting up a critical demo or presentation. The problem is that it can't be interrupted, so the group gets to spend several minutes watching the progress bar slowly move. The fix is to add the lines:
   [options]
   allow_cancellation = true
   to the file /etc/e2fsck.conf. One site that discusses this fix and potential issues is wiki.archlinux.org/index.php/Fsck
2. Boot pauses due to exim. When booting while not connected to the Internet, the exim mail handling program may hang for 60 seconds. I found that adding
   MAIN_HARDCODE_PRIMARY_HOSTNAME = mypc.example.com
   to /etc/exim4/exim4.conf.localmacros gets rid of the hang, where mypc.example.com should be changed to whatever is appropriate for that PC. Depending on other configuration options, this line might belong somewhere in  /etc/exim4/conf.d instead.
3. Annoying computer beep.For some reason, many programs seem to think a loud "beep" on errors is a helpful feature. I'm one of the legions that disagree, so I disable the pcspkr device by adding
blacklist pcspkr
blacklist snd_pcsp
to a file in the /etc/modprobe.d/blacklist directory. See www.thinkwiki.org/wiki/How_to_disable_the_pc_speaker_%28beep!%29 for example.
4. Hardware Clock. Normal PC's have a hardware clock that keeps track of the date and time of day even when the PC is powered off, and Linux also has a system clock that keeps time when running. This system clock is initialized from the hardware clock while booting. In normal Debian setups the /etc/init.d/hwclock.sh script also copies the system clock back to the hardware clock during system shutdown. That's a problem in my system because it's using the less accurate clock to reset the more accurate clock. One fix is to install the ntpdate package; then the system time gets set whenever an Internet connection comes up. Another option I use sometimes is to edit hwclock.sh to disable the hardware clock update, and just set it manually. I'm planning a more detailed post on this issue.