Local 3D printing option

This is somewhat offtopic, but I have a few Palm foldable keyboards sitting around that I would like to make use of. First problem: the keyboard uses a proprietary 10-pin connector. Solution: download a cad file from github.com/cy384/ppk_usb and 3D print it. Second problem: I don't own a 3D printer, so how do I print it?

I found that our local library (rodgerslibrary.org) has a 3D printer, and will print things for 10 cents per gram. The cost of printer filament alone often runs 2-3 cents per gram, so that's a really good price. It's a TKI 3D printer, and they have a selection of PLA filament in various colors. To use it, I converted the cad file to .stl, and took it to the library on a USB stick, where Linda processed it and set up the printer. Library personnel do all the actual handling of the printer - no gefingerpoken by the lookenspeepers. This object was about 2 grams, so it cost me all of 20 cents to get it printed. It took about 25 minutes - could have been faster, but she decided to run the printer at low speed for something this small. It's a library, so there's plenty to look at while waiting.

First step was to download the appropriate cad file from cy384's github site. It's designed in openscad, which is in the Debian repository, so I installed that. Importing the *.scad file and exporting an .stl file took only a few seconds. The longest dimension is about 3 cm.

And here's the finished product, with a penny for size reference. The object is flipped in this photo: the front in the openscad screenshot is the back in this photo. The printer software automatically added the panel so it would stick to the base while printing, and it added the supports so the ears could be printed properly.

Here it is sitting on the keyboard connector after a little bit of trimming with a sharp knife.

And here it is fully plugged in. Fits snugly and perfectly, so the design was good, and the printer did its job well. Next step is to wrap wires in the slots to make contact with the pins, and then I can start working on the software.

So if you're within driving distance of the Hudson, NH library and have an occasional need for 3D printing, it's a great resource. They have a shelf full of PLA filament in various colors. Check the library website for days and times the printer is available. The librarian did say they only run the printer when the library is open, so make sure your print jobs take less than 12 hours.
There's only one machine and printing takes a long time, so there might be a queue. I went in on a Monday night and there was no wait - your mileage may vary.

STM32F042 USB quirks with libopencm3

Needed a simple microntroller for an RF project, so picked the STM32F042F6P6 from ST.  It's cheap, comes in a 20-pin package, and has a built-in full speed USB device interface. It has an internal oscillator that can be synced to the USB signals from the host, so it doesn't even need a crystal.
It has a built-in DFU bootloader (among other programming options), so it requires no additional hardware to load the program.
After getting a simple LED blinker program to run, I decided to run some USB demo programs from the LIBOPENCM3 package. None of the demos are for this exact chip, but some are for the STM32F072, which is similar. Tried the tests/gadget-zero sample and ... No Go. The program loads and the LED's blink, but the USB device does not show up.
Turns out, there are a couple of subtle differences between this chip and the ones in bigger packages

• The USB interface pins are shared with two other pins, and by default the USB pins are not connected to the outside world. Need to set a configuration bit so they can be used.
• The peripheral clock needs to be turned on for the SYSCFG subsystem. I'm not sure whether that's a difference in the chips, or a quirk in libopencm3, but it's needed.

The setup calls at the beginning of the program for crystal-less USB operation are:

rcc_clock_setup_in_hsi48_out_48mhz();
rcc_periph_clock_enable(RCC_SYSCFG_COMP);
SYSCFG_CFGR1 |= SYSCFG_CFGR1_PA11_PA12_RMP;
crs_autotrim_usb_enable()
rcc_set_usbclk_source(RCC_HSI48)

where the highlighted lines had to be added. With those two lines, gadget-zero shows up as a USB device in Linux. I was also able to the a cdc_acm demo working.

Acknowledgments

Several websites mention the pin-remapping issue, but the IFUSB project (github.com/julbouln/ifusb) was where I found the clock-enable issue and solution. IFUSB looks like a nice little peripheral, by the way.
Libopencm3 is at github.com/libopencm3/libopencm3
For programming, I use dfu-util: dfu-util.sourceforge.net. It's already included in Debian and probably other distributions.

Offtopic: phone scam

NOTE: the phone number below is what they said on the message. It might be fake, so whoever has that number might be totally innocent.

This was interesting. I got a scam phone call this morning. My best attempt at a transcription as follows:

Hi, my name is Keith Jordan, and this message is intended to contact you regarding an enforcement action executed by the United States Treasury,
intending your serious attention.
 
Ignoring this will be an intentional second attempt to avoid initial appearance before a magistrate judge or a grand jury for a federal criminal offense.
My number is 817 533 9843
I repeat  it's 817 533 9843
I invite you to cooperate with us and help us to help you.
Thank you.

I recorded this to my computer by holding the phone in front of the microphone while playing back the message, and then merging the audio with a photo of the caller id using:
ffmpeg -i /tmp/x.jpg -i scam.wav -acodec copy /tmp/simple.mov
I can display and play the result using mplayer on Debian Linux, not sure how it works anywhere else.

Us Treasury says to report this sort of thing:
www.treasury.gov/services/report-fwa/Pages/Report-Email-Scams.aspx
We'll see what happens.

Presentation: Codecs for Land Mobile Radio

Marina in front of Wentworth on the Sea.

On August 19 2016 I presented a talk to the "Enhanced Digital LMR Seminar" at Wentworth on the Sea, New Castle, NH (near Portsmouth).

The talk is an overview of speech codecs and their application in digital Land Mobile Radio systems. It's intended for an audience of radio system users and specialists rather than voice codec experts.

Slides for the presentation are online at:
joe1505.github.io/talks/index.html

Mobile-friendly web page

Decided it's time to make my websites mobile-friendly, since Google seems to consider that important these days. So I ran the tester at

• https://www.google.com/webmasters/tools/mobile-friendly/

which identified about 30 errors, including "Links too close together" and "Text too small to read" on multiple items. The latter error is particularly interesting because I typically use not-too-fancy html+css, and I don't set the font size anywhere. One of the main features of html is the separation of content and presentation, so decently written html should not require much tweaking for different displays. The html markup tells what things are, and the browser should be able to figure out a reasonable way of displaying those things.

After a little digging, I found the first step in mobilifying a web page is to add the magic incantation:

•  <meta name=viewport content="width=device-width, initial-scale=1">

to the <head> section of the html file.

As it turns out, that's the last step as well: All the other error messages went away when I added that one line. As I understand it, that line basically tells the browser "just use html the way it's intended to be used" and then everything is fine.

Reorganizing this blog.

I decided it's time to reorganize the domain name setup for this blog. Previously, it was accessible via two web addresses:

• blog.sensicomm.com 
• sensicomm.blogspot.com 

 One side effect of this setup is that the blog's cookies are set up under my sensicomm.com domain. I decided that I don't like the idea of scripts that I didn't write and don't control running under  the identity of a domain that I do control.

So in the new setup this blog is still accessible and will appear unchanged using the blogspot address. The sensicomm address contains static copies of all previous postings, but not any comments made on those postings.

If you have a web site containing a like to an old blog post, you might want to update the link. For example,

1. http://blog.sensicomm.com/2015/09/pebble-watch-programming.html
2. http://sensicomm.blogspot.com/2015/09/pebble-watch-programming.html

The old address of this post[1] now points to the static copy of that post, while the new address[2] contains both the post and any comments.

Lattic iCEcube2 on Debian

I recently started looking at Lattice chips for a project that needs a fairly small FPGA. They have small devices that are significantly lower in cost than the larger Xilinx Spartan chips I've used in the past. To explore further, I ordered the ICE40HX1K eval board ($22) and downloaded the free iCEcube2 IDE for my Debian stable(Jessie) 64-bit PC.
The first try at installing the IDE hit issues:
 error while loading shared libraries: libXext.so.6: cannot open shared object file: No such file or directory
The library is installed, so obviously the IDE wants the 32-bit version. I haven't tried to work with 32-bit stuff since Debian went to the multiarch approach, so that led to a new learning experience. Previously one would install ia32 versions of the needed libraries. After a bit of googling, I found that the current approach is (as root, or using sudo):
dpkg --add-architecture i386 # Include 32-bit stuff
apt-get update  # Add in the lists of 32-bit packages.
apt-file search libXext.so.6 # Find out what package I need - libxext6 in this case.
apt-get install libxext6:i386 # Add the 32-bit version of thepackage.
Now, the install fails because it's missing libpng12.so.0, so repeat the apt-file search and apt-get install steps for that. In Total I ended up installing  libpng12-0:i386, libsm6:i386, libxi6:i386, libxrender1:i386, libxrandr2:i386, libxfixes3:i386, libxcursor1:i386, libxinerama1:i386, libfreetype6:i386, libfontconfig1:i386, libglib2.0-0:i386.
With that, iCEcube2 installs and runs.

Now I can start playing with the eval board when it shows up.

Notes:

hackaday.io/project/6592-dipsy/log/24272-installing-icecube-2-on-ubuntu-14042-lts  Pointed me in the right direction to complete the install. Their Dipsy project uses the Lattice chip, and looks interesting.

Pebble watch programming to extend battery life.

These are my observations to date on battery life with the Pebble classic watch. I figure the data will be of interest to other watch face developers.

For my own Pebble watchface I wanted:

• Simple digital display with seconds counter.
• Show current date.
• Large characters to be readable in poor light conditions.

Once it was running, I wanted to measure and optimize battery life. The watch reports battery state in 10% increments, so I track the level changes as a function of time.
Pebble has some hints online at developer.getpebble.com/guides/best-practices/battery-perform-guide/ . Basically, they say to do as little as possible when servicing the timer ticks, and minimize the portion of the screen that's updated.
The plot here was obtained with the watchface shown in my previous post: blog.sensicomm.com/2015/09/pebble-watch-programming.html . The green lines are the first version: I call the routines to update everything on the screen every second. For the blue line, I update the seconds display every second, but the rest of the display only updates every minute. For the red line, I update the seconds every second (obviously), the hour and minute update when the minute changes, and the day updates every hour. The short magenta line is like red, except I turn the backlight off (instead of auto) and turn the watch off at night. Bluetooth was off in all cases.
Observations:

• The time from end-of-charging to 90% battery level varies widely, from a few minutes to many hours. My guess is that the battery keeps trickle charging even after the display shows charge is complete: the shortest times to 90% were when I took the watch off charge immediately, and the longest were when it was connected for an hour or so after the indicated completion of charge.

• That said, minimizing unnecessary screen updates appears to make a significant difference in power use: an additional day or so before the battery drops to 40% remaining power.

• I probably won't bother keeping the backlight off or turning the watch off at night: the savings don't seem that great and the inconvenience is significant.

• The screen backlight was in auto mode: it comes on for a few seconds when the watch shakes. It did occasionally come on during all tests (except magenta). No sure how much difference it made.

Again, this is for the Pebble Classic; no idea how it works on other Pebbles.

Pebble watch programming.

Time for a new watch. I chose the Pebble classic because I like the idea of a daylight-readable (e-paper) display and multi-day battery life between charges. The fact that several were available on ebay at good prices didn't hurt either.
Yes, I do love the display. It's a crisp and clear monochrome, easily readable in sunlight. In the photo, you may notice a bit of "rainbow" effect to the left of the time and date. That seems to be a polarization effect: it's noticeable when wearing polarized sunglasses or with indirect illumination from a clear sky. In direct sunlight or artificial light the rainbows go away.

Programming

The watch has an ARM chip in it, so of course I have to develop my own watch face. Pebble has an online development platform, but I decided to install the SDK on my Debian PC. I got the SDK from developer.getpebble.com/sdk/ and installed it per the instructions, which includes installing several libraries and python packages. A couple of notes:

• The "pip install -r requirements.txt" command takes a long time to run -- several minutes.
• I did not install the Pebble-supplied ARM compiler: it requires a later version of glibc than I have installed. I already had a compiler installed (blog.sensicomm.com/2014/02/stm32-on-linux-again.html), and it seems to work fine.
• To tell the SDK where the existing compiler is:
• cd $HOME/pebble-dev/PebbleSDK-3.3/
• ln -s  /opt/gcc-arm-none-eabi arm-cs-tools

And it works. I was able to compile a sample program using the "pebble build" command and install it using Bluetooth and an Android phone.

HDMI-VGA adapter for Raspberry Pi

This year Santa left an HDMI to VGA adapter under the christmas tree. I have an old LCD monitor with only a VGA input while the Raspberry Pi and Beagleboard/Beaglebone boards only have HDMI outputs.
The specific adapter is under $10 from seeedstudio.com, although I see a bunch of others on ebay and other sites that look similar.
Setup on the Raspberry Pi was pretty easy - only one Google search. Had to edit the /boot/config.txt file to force the Pi to use the HDMI output and to set the screen resolution (both VGA and HDMI can report screen resolution back to the host, but it doesn't seem to happen with this setup).
Configuration info was found at www.raspberrypi.org/forums/viewtopic.php?p=269212.
Internally the adapter is just a Chrontel CH7101A chip to do the HDMI-VGA conversion, and an Everest Semiconductor ES7144LV audio output chip. My unit pulls about 180 milliAmps from the +5 volt output of the HDMI connector. That's way more than the 50 mA maximum (according to Wikipedia), but the Pi is driving it without any problems. I haven't tried the adapter with Beagles yet, but research so far indicates that they require an externally powered adapter because they can't supply enough current via HDMI.
Caution: poking around inside will most likely void the warranty and might smoke the adapter and/or the Beagleboard. You're on your own if you try something like this:
Interestingly, there's space on the lower right corner of the PCB for a USB connector as an alternate +5 input. I took out the zero-ohm resistor (R1, just to the left of the USB connector footprint), and brought out 3 wires: Ground, HDMI +5 out, and +5 power in. Now I can just connect the +5's together for the Pi and should be able to use external power for the Beagles.

Debian on BeagleBoard classic.

I have one of the original beagleboards with the omap3 processor, which is ARM+DSP coprocessor. Originally it used the Angstrom Linux distribution, which uses bitbake to build the kernel and all related software tools. I saw recently that Debian is now supported on this device; I like to run Debian on everything including my PC's, BeagleBone Black, and Raspberry Pi (raspbian - almost Debian), so why not on the beagleboard as well?
My hardware setup is a USB-serial adapter from a Linux (Debian, of course) host to the serial port of the Beagleboard. I also have a Sabrent USB-Ethernet adapter on the Beagleboard.
The "official" instructions seem to be at elinux.org/BeagleBoardDebian, which I found from beagleboard.org/project/debian. Per those instructions, I downloaded the netinstall package from github.com/RobertCNelson/netinstall (using git of course), and put it on a 16GB SD card using the command:

sudo ./mk_mmc.sh --mmc $SDCARD --dtb omap3-beagle --distro wheezy-armhf --firmware --serial-mode

On my PC I have SDCARD=/dev/sdb, because that's where the memory card shows up when it's plugged in. MAKE SURE you get this right, because you could wipe out a disk on the PC if you get it wrong. I decided to uses the --serial-mode option to work from the serial port and avoid any HDMI display issues.
Moved the SD card from the PC to Beagleboard, powered up, and got a typical Debian install menu on the serial port! I used

minicom -D /dev/usb/prolific2303 -b 115200 -o

to connect to the USB-serial port. The Beagleboard serial port does not use the modem control lines, so had to turn off the "Hardware Flow Control" and "Modem has DCD" options in minicom.
The netinstall process was just like installing Debian on a PC: select some options and wait for it to download a bunch of packages. It found the Sabrent ethernet and used it with no problem; device usb0 shows up as a network device as well, so it should be possible to install by using a USB connection to the PC host, but I didn't try that.
Finished the install, rebooted the Beagleboard, aaaannnd - nothing happened!!! Load process just stopped in uboot. After a few hours of screaming, hair-pulling, and spelunking in uboot macros, I found the problem:
I had set up /boot as a separate partition.
The uboot macros look for  /boot/uEnv.txt on each partition and then boot Linux using that partition as the root partition. Made /boot a normal directory instead of a mount point, patched up /etc/fstab, and uboot brought up Debian with no problem.
Did my usual Debian tweaks (sensicomm.blogspot.com/2013/01/my-debian-tweaks.html) and everything seems to be working as expected.

Goats and Coffee

OK, this post is way off normal topics. Last month my wife and I were part of a team that visited a non-government organization working on economic development in Guatemala. The project related to raising goats and fighting the coffee rust fungus that's been causing so many problems in Central America.
I put together a writeup that gives more background on the problem and how it's being approached: www.rothweiler.us/guatemala-2014 .
It's outside my area of expertise, but looks like an interesting approach that makes good use of local resources. Comments (positive or negative) from folks with more experience are welcome.

Parallel port jtag

I've been using a homebrew version of the Xilinx DLC5 parallel port jtag adapter for programming my fpga boards. The DLC5 is no longer supported by Xilinx, but some Linux jtag programmers still support it.
Recently I moved to a new PC, and my DLC5 hack no longer works with that parallel port. I can see on the scope that the right pins are moving, but the chip won't program. I suspect that either the rise and fall times are too slow, or there's noise on the signal lines.
Anyway, I had a sample of the SiLabs si8663 digital isolator, so I decided it's time to build a new interface. The Si8663 is a hex isolator (3 signals each direction), that's spec'ed to operate up to 150 Mbps bit rate (WAY more than needed for this app). Another neat feature is that the drivers on each side work from 2.5 to 5.5 volts, providing a level shifter at no extra charge.
Board is available on OshPark (www.oshpark.com) for anyone interested. Project name is "isopartag 140513". Circuit's simple: chip + 4 bypass caps on the bottom. The design includes resistors to tap power from unused pins of the parallel port, but they haven't been added yet, to that feature is untested. For now I just tap 5 volts from an unused keyboard or mouse port.
Caution:The Si8663 comes in two versions: a wide body for safety isolation, and a narrow body intended more for electrical noise isolation. I'm using the narrow version, and the board is not designed with wide separation between the input and output sides. In other words, this design is for low voltages only, don't use it where safety is an issue.

via-rhine in Debian Wheezy

This blog post is only of interest to a small handful of people,  but since you found it, it might be you :). As always with system changes, there's a chance of damage or data loss. So check your backups first.

I have an old Averatec notebook that I use for travel and when I don't want to take risks with my main PC. I'm planning a trip so it's time to update to the latest debian distribution. After the update, everything seems to work, except the via-rhine wired ethernet.
The symptoms appear similar to Debian bug report 708757 . After a lot of hacking and experimenting, I finally upgraded to the latest kernel in wheezy-backports and the problem went away.

Details:

lspci shows the device as:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)

It does work with Debian kernel packages:
 linux-image-2.6.32-5-686  # Old, from previous Debian distribution.
 linux-image-3.14-0.bpo.1-686-pae # Very latest, bleeding edge.

And does not work with
linux-image-3.2.0-4-686-pae # debian stable kernel for my system.

Fix:

To get the very latest kernel, you need the backports repository. Best instructions I found were:
scottlinux.com/2013/11/23/how-to-install-newer-kernel-from-debian-wheezy-backports
 Basically,
1) add wheezy-backports to /etc/apt/sources.list
2) apt-get update
3) apt-get -t wheezy-backports install linux-image-3.14-0.bpo.1-686-pae
4) done. reboot to use the new kernel.

Cleanup:

One side effect of the bug is that it returns a wrong and somewhat random MAC address for the ethernet controller. Recent versions of Debian try to ensure that each MAC address is always associated with a consistent eth* number. So each random mac address gets assigned to a new eth* number. If this is happening the output of dmesg will show messages like:

udev: renamed network interface eth0 to eth7

Every time udev sees a new MAC address it adds it to /etc/udev/rules.d/70-persistent-net.rules,
so the fix is to edit that file and remove all the junk MAC addresses.


Xilinx Spartan-3 I/O timing

Working on updating the MHZ100Q project, and one significant design issue is I/O delay. To review, the Xilinx Spartan-3A FPGA generates a 100MHz clock using an internal DCM block, and this clock drives an external 100MHz A/D converter. The total delays through the output buffer, A/D clock to output pins, and FPGA input buffer add up to 9 to 16 ns, while the clock cycle time is 10 ns. So aligning the clock and data at the input latch is tricky.
Per the A/D data sheet, the value on the output pins is stable for about 5ns (minimum) and the FPGA data sheet says the latches need about 1ns to capture the value (setup+hold times from the clock edge). So we have a 4 ns window in which everything will work right.
It's hard to measure the actual offset at the internal latch input of the FPGA, so for initial setup I would like to be able to adjust the phasing of the A/D clock relative to the internal latch clock over the full 10 ns range.
First option is to use the built-in delays. The *.ucf file supports the per-pin specifications IFD_DELAY_VALUE and IBUF_DELAY_VALUE which put variable amounts of delay between the input pin and the logic (the former applies when using the latch built-in to the I/O Block, and the latter applies when the I/O Block is just used as a buffer). Total adjustment range is about 2 ns, which might be enough.
Next step up in complexity is to use the Digital Clock Module (DCM) to adjust the phase of the generated clock. The DCM can produce essentially any clock phase, but for this application, I think I can just use the 4-phase quadrature outputs. That gives me effectively 0 2.5, 5, 7.5 ns adjustment points, and combined with the IFD_DELAY_VALUE, I can get within 0.5 ns of any required timing offset.

Widgets

Just posted a couple of little designs: a switching power supply and a wideband preamp. Blank pcb's are available from Oshpark www.oshpark.com/profiles/sensicomm , and my documentation is at http://mhz100q.sourceforge.net/widgetries.shtml . Mostly for my own tests and experimentation, but others might find them useful.

STM32 on Linux, again.

Starting another project using the STM32 micro, so time to update and reinstall the toolchain. This is an update to my previous post on the topic at http://blog.sensicomm.com/2012/01/stm32-stm32f4discovery-arm-eval-board.html

Compiler

Previously I used the summon-arm gersion of GCC http://summon-arm-toolchain.org/
but the git repo says it's "not under active development" any more. They recommend https://launchpad.net/gcc-arm-embedded , which seems to be an offically ARM-supported
version.

It looks like Debian has packaged the launchpad version into the "unstable" branch: http://packages.debian.org/sid/gcc-arm-none-eabi but I'm running "stable" so I got it directly from launchpad instead. Install was simple:

• Download  gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
• unpack in /opt,
• add to PATH
• Create symlink:  cd /opt && ln -s gcc-arm-none-eabi-4_8-2013q4 gcc-arm-none-eabi

That's my setup, the chosen directory is just a matter of personal preference.

Programming tools:

I'm using the STM32F4DISCOVERY board for development, so there are two ways to get code
into the chip:

1. Use the st-link USB input to the built-in programming hardware.
2. Connect directly to the USB port of the STM32F4 chip and use dfu-util.

I used dfu-util before. That's now in Debian, and should still work but I haven't retested it.



Code for the st-link interface is available and built with no problem:

• git clone git://github.com/texane/stlink.git stlink
• cd stlink && ./autogen.sh && ./configure && make && make install

Programs are installed in /usr/local/bin: st-flash st-info st-term st-util

An example was successfully placed in flash using:
st-flash write *.bin 0x8000000

Libraries:

The open source libraries and examples at http://libopencm3.org/wiki/Downloads built without problem using the launchpad compiler. My build command was:
PATH=/usr/bin:/bin:/opt/gcc-arm-none-eabi/bin DESTDIR=/opt/libopencm3 make install

ST has standard peripheral library source code on their website, but it doesn't come with Makefiles. A USB serial example at http://vedder.se/2012/07/usb-serial-on-stm32f4/ includes some (all?) of the ST libraries and compiles fine with the launchpad compiler. I downloaded and unpacked STM32F4_USB_CDC.zip and "make" ran without problems. I only had to change the top-level Makefile so that BINPATH points to the directory that arm-none-eabi-gcc is in
(BINPATH=/opt/gcc-arm-none-eabi/bin for my install).

HDMI Breakout Part 2

 I see the PCB in my Nov 6, 2013 post is getting some interest, so here's more info about it. The image to the left is a Kicad screenshot. The breakout connector (P1, CONN_5X2) is at the top, and pin 1 is the top right pad. Odd-numbered pins on top, and even-numbered on the bottom.
Top connections are:
1 Ground
3 HOTP-J
5 DCC_D-J1
7 DCC_C-J1
9 CEC-J1
and the bottom connections are:
2 +5V (J1 and J2 both)
4 HOTP-J2
6 DCC_D-J2
8 DCC_C-J2
10 CEC-J2

So to use the board as a passthrough connection, add jumpers connecting 3-4, 5-6, 7-8, and 9-10. Obviously, it's NOT a good idea to have a jumper connecting 1 and 2 (ground and +5V).

Here's the schematic. Pin 20 is the metal shell of the connector, not a real pin.

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.