Homebrew, open source, repurposed, hacked, software defined, open hardware

Monday, 14 July 2014

Printer/Scanner film adapter EL wire (CCFL) inverter extraction

Some useful E-waste in the form of a Canon printer/scanner with a film adapter in the lid was pulled apart.

As well as some DC motors, shafts, screws, springs and plastic panels, an EL wire (CCFL) light source was found in the lid that served as a 35mm slide or 35mm film trans-illumination source.

The first step in awakening the light source was to establish the polarity of the two wires going to the CCFL inverter module.

The two lower voltage wires which ran to the CCFL inverter from the printer's main PCB were grey and black, and the high tension wires going to the EL wire were pink and white.

The circuit board of the inverter had no markings to indicate the polarity of the lower voltage grey/black pair, but a transistor near the low voltage grey/black input jack had its emitter marked on the PCB, and this was common to the grey wire.
Further inspection of the PCB traces confirmed that a nearby electrolytic capacitor's negative lead was common to the emitter and the grey lead, making the grey lead GROUND, and the black lead POSITIVE.

A variable voltage DC supply was connected to the leads and the voltage slowly increased. Half the CCFL panel lit up somewhere in the order of 15V, and by 24V it was fully lit.

This was consistent with one of the DC voltage produced by the AC->DC SMPS module in the printer being 24V, with no 12V or 5V options.

At 24V DC, the inverter was drawing around 200mA. The plastic surround will be retained and a small lamp is planned in conjunction with a spare 24V wall wart / DC plug pack.

Maybe someone pulling something similar apart will find this useful and possibly avoid destroying their inverter if it has similar BLACK=positive wiring.

Wednesday, 25 June 2014

A PCM290x based USB sound card for radio amateur and other uses

The June 2014 edition of Amateur Radio magazine published a design for a USB sound card based on the PCM290x family of CODECs.

The depicted prototype used the PCM2904:

The board has optional connectors for the 3 switches supported by the CODEC, an SPDIF header for the codec models that support it, as well as space for 2 optional input and 2 optional output level adjustment potentiometers (Jumpered with 4 small wire links in the photo).

The board is 50mm x 50mm and has been designed for easy mounting in existing commercial rigs or homebrew rigs, or as a standalone unit. Input and output 3.5mm stereo sockets are supported to make connections simpler, as well as simple headers for those not using 3.5mm audio leads, and a Type B USB socket mounts directly to the board.

The option of an external regulated power supply for the ADC/DAC section of the CODEC is also supported.

Soldering was quick and easy, in fact three boards were done at once, using my hotplate liftoff jig technique.

A quick test after construction was successful with a G5RV equipped FT-817:


SDR homebrewers need to be aware of the one sample audio packet misalignment issue in some of the PCM290x revisions, and must either

1) choose unaffected revisions by studying the errata, or
2) empirically determine if the codec used does it, or
3) adjust their software to avoid phasing errors if using an affected codec

High quality hackvana made boards are now available at Aztronics

Here's the artwork, but homebrewers may struggle with the vias.

"Battery exhausted" on the Nikon Coolpix S3600 - a workaround - and Nikon firmware update hints for linux

The fairly new Nikon Coolpix S3600 had not been charged for a few weeks, and on trying to charge it with a USB cable, the charging light on the camera flashed rapidly  indicating an inability to charge, and then a "Battery exhausted" message appeared on the screen, and then the camera turned itself off completely.

This was a pretty revelatory disclosure from a device I was trying to charge.

It had a certain Rube Goldberg-esque-ness about it too.

The camera's manual told me it wouldn't charge below 5 degrees C. It was warmer than that, but I tried warming the battery in my hands and tried again - no luck.

I tried with the SD card in, out, back in again. No luck.

This seems to be a problem common to Li-ion batteries, namely, difficulty charging when a bit flat. The battery was an EN-EL19 3.7V 700mAh 2.6Wh battery.

I tried voltages ranging between 4.2V and 5.5V on the USB cable, but there was no change to the rapidly flashing light on the camera indicating inability to charge.

Some googling found the Nikon help page, which suggested a firmware upgrade to fix the charging problem that occurs with fairly flat batteries for multiple models, but the S3600 was not among the models with a firmware update available.

Furthermore, for the models listed, the instructions, for either OSX or Windows, both required me to turn on the camera and use the menu system to undertake the firmware upgrade... and also use the camera to format an SD card to deliver the new firmware.... Attentive readers will have noticed that the camera battery was flat.... or rather... "Battery exhausted"...

Further reading of the manual told me that the camera can charge slowly while attached to a computer. After plugging the camera into the linux netbook, however, it dutifully mounted, and the slow flash of the light on the camera told me it was now charging.

Well, this got around the unwillingness to charge problem.

I emailed Nikon about the problem. They got back to me within 24 hours and suggested I take it to an authorised repair centre.

"Kindly be advise that currently no known issue about the charging of the battery for the S3600. Kindly you may take the camera to the nearest Nikon service centre for further inspection. Details of the service centre are as per below:"
This seemed odd, because I found at least one reference to the same problem by another S3600 owner, a Mr S. McKay, on the web, and he'd been charged about the price of the camera in repairs not covered by warranty for what seemed like the same issue:


With a workaround now for the charging problem, I couldn't see the point of taking it anywhere. I will have to wait and see if they release a firmware update.

I was curious though about how I would be able to do an update using GNU/Linux. Having a look at some of the available firmware, I found it was available as either a self executing .exe archive, for example F-S6300-V11W.exe, or an OSX hfsplus compressed filesystem ".dmg" file, for example F-S6300-V11M.dmg, in the case of the S6300 model anyway.

... good to know that Nikon cater to both types of operating system...

So, for a worked exercise, and as a bit of a how to for others using GNU/Linux, I thought I'd extract firmware using ubuntu flavoured GNU/Linux for the S6300... that way, when an S3600 update is eventually released, I won't need to reinvent the wheel, and others might find it useful.

Nikon firmware update linux howto:

This guide uses the Nikon S6300 as an example.

Other Nikon camera firmware files may differ.

Firmware upgrade instructions for other cameras may also differ.

Be warned, using this guide with the wrong firmware could brick your camera, so use at your own risk.

Carefully compare these instructions with those provided by Nikon on their support website, to ensure you do not inadvertently brick your camera.

Repeat, use at your own risk!!!

First, download the OSX file F-S6300-V11M.dmg from the Nikon website into a local working directory, i.e.
Then, you need to download the latest sourcecode for the dmg2img utility from
which at the time of writing is dmg2img-1.6.5.tar.gz
gunzip dmg2img-1.6.5.tar.gz
tar xvf dmg2img-1.6.5.tar
cd  dmg2img-1.6.5

if you get "error: bzlib.h: No such file or directory"
sudo apt-get install libbz2-dev

if you get "error: openssl/sha.h: No such file or directory"
sudo apt-get install libssl-dev
then try to run make again

you can then run dmg2img from this directory to uncompress F-S6300-V11M.dmg

./dmg2img -i ../F-S6300-V11M.dmg -o ../F-S6300-V11M.img

You should see something like:
dmg2img v1.6.5 (c) vu1tur

../F-S6300-V11M.dmg --> ../F-S6300-V11M.img

opening partition 0 ...             100.00%  ok
opening partition 1 ...             100.00%  ok
opening partition 2 ...             100.00%  ok
opening partition 3 ...             100.00%  ok

Archive successfully decompressed as ../F-S6300-V11M.img

you now have an uncompressed hfsplus filsystem image called F-S6300-V11M.img in your  working directory. Go back to your working directory.
cd ..
I'll assume you don't have hfsplus filesystem support installed. You need to install ... you guessed it... hfsplus
sudo apt-get install hfsplus
sudo modprobe hfsplus
Now, you should be able to mount the image as a virtual device on a suitable mount point, in this case, I have chosen /mnt as a suiatble spot to mount it
sudo mount -o loop -t hfsplus ./F-S6300-V11M.img /mnt/
Then, if it has worked, you can
cd /mnt
ls -la
And you should be greeted with:
total 8204
drwxr-xr-x  1 root root       8 Apr  3  2013 .
drwxr-xr-x 23 root root    4096 May 31 00:26 ..
----------  1 root root 8388608 Apr  3  2013 .journal
----------  1 root root    4096 Apr  3  2013 .journal_info_block
drwxr-xr-x  1  501  501       3 Apr  3  2013 S6300Update
-rw-rw-rw-  1 root  501    3784 Apr  3  2013 .SymAVQSFile
d-wx-wx-wt  1  501  501       2 Apr  3  2013 .Trashes
You can then
cd S6300Update/
cd firmware
ls -la
and you will find
total 21636
drwxr-xr-x 1 501 501        3 Apr  3  2013 .
drwxr-xr-x 1 501 501        3 Apr  3  2013 ..
-rwxr--r-- 1 501 501 22151360 Mar 25  2013 firmware.bin
it is the "firmware" folder containing the "firmware.bin" file that needs to be copied onto the root directory of an SD card that has been freshly formatted in the camera.

I chose to copy the firmware folder to my working directory called "Coolpix" at this point
cd ..
cp -R firmware ~/Coolpix
cd ~/Coolpix
I then unmounted the virtual filesystem
sudo umount /mnt
So, you now have a local copy of the firmware.

your Camera should be charged by now. Press the menu button, go into the tools "Wrench/spanner" icon, and scroll down to Firmware. It should say "Version 1.0" if you have the battery charging issue.

Now, insert a spare SD card and format it in the camera. Having done this, turn the camera off.

Insert the SD card in the linux machine which should automount it
should show something like (for my spare 512MB SD card it shows this):
/dev/sdb1         495232        64    495168   1% /media/NO_NAME
now, copy the firmware file over to the card
cp -R firmware/ /media/NO_NAME/
Then check if it is there
ls /media/NO_NAME/
which should show:
DCIM  firmware  MISC  NIKON001.DSC
then look in the firmware folder:
ls /media/NO_NAME/firmware/
which should show something like:
-rw-r--r-- 22151360 Jun 25 00:09 firmware.bin
then unmount the card:
sudo umount /media/NO_NAME/
then put the card into the camera. Turn the camera on, press the menu button, go into the tools "Wrench/spanner" icon, and scroll down to Firmware. It should allow you to upgrade if you have the right firmware.

Wednesday, 15 May 2013

HP mini 110 1006TU upgrade fun - or - problem solving a dying HDD swap partition under linux

Random pauses, screen greying out, and sudden drops in network traffic throughput on a stock standard HP Mini 110 1006TU with 1GB of RAM and running Ubuntu 12.04 LTS.

Maybe this troubleshooting summary will help someone out there with their linux box. So here it is.

I assumed it was just Ubuntu bloat, but it did seem to come on most predictably when switching quickly between the many running applications, or if the annoying update manager decided to do its thing automatically in the background.

During a particularly long, grinding pause with fairly continuous HDD activity, I brought up a console and noticed a lot of errors in dmesg, like this:
May 13 22:38:47 esh-laptop kernel: [31006.614642] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
May 13 22:38:47 esh-laptop kernel: [31006.614652] ata1.00: BMDMA stat 0x5
May 13 22:38:47 esh-laptop kernel: [31006.614659] ata1.00: failed command: READ DMA EXT
May 13 22:38:47 esh-laptop kernel: [31006.614675] ata1.00: cmd 25/00:08:85:ec:51/00:00:12:00:00/e0 tag 0 dma 4096 in
May 13 22:38:47 esh-laptop kernel: [31006.614678]          res 51/40:00:85:ec:51/40:00:12:00:00/e0 Emask 0x9 (media error)
May 13 22:38:47 esh-laptop kernel: [31006.614685] ata1.00: status: { DRDY ERR }
May 13 22:38:47 esh-laptop kernel: [31006.614691] ata1.00: error: { UNC }
May 13 22:38:47 esh-laptop kernel: [31006.636491] ata1.00: configured for UDMA/100
May 13 22:38:47 esh-laptop kernel: [31006.636523] ata1: EH complete

Clearly, the kernel was having trouble with the HDD.

After deciding to do a scheduled "once every 3.5 years if it really seems necessary" backup to an external HDD, and managing to do so without difficulty, I had a play with the internal HDD.

I turned swap off with:

$sudo swapoff

I then ran gparted.

$sudo gparted

The swap partition was 2.8GB, and using the /dev/sda5 partition.

gparted had no trouble re-formatting the partition and threw up no errors... which didn't really tell me much about the health of the swap partition.

After quitting out of gparted, the next thing to try was a format of the swap partition with actual checking of the sectors:

$sudo mkswap -c /dev/sda5

About 3 hours later with innumerable syslog errors, the mkswap failed claiming too many errors were found.

Hmmm. Not good.

I decided that the next thing to do was play with the location of the swap partition. To do so required booting off a different drive - but a netbook has no CD/DVD drive.

The easiest way to do this is to download an ubuntu install .iso for the platform you are using, and find a USB drive to turn into a bootable live Ubuntu boot drive.

In this case, for the x86 netbook, I downloaded:


and then ran:


This allowed me to choose the image .iso and install it onto a spare 2GB+ USB drive.

I was then able to restart the netbook and boot off the USB stick by hitting F9 on booting to tell the BIOS to boot from the USB drive instead of the internal HDD.

I then ran the disk utility from the Dash home, and found, as expected, that there were some bad sectors:

I ran gparted again, while booted off the USB boot drive, and was able to shrink the main root and usr partition /dev/sda1 by about 3GB.

Having done so, I then grew the /dev/sda5 swap partition by 3GB into the freed up space.

I then shrank the /dev/sda5 partition by 3GB leaving the space formally occupied by the (apparently somewhat trashed) swap partition unallocated.

The next test was to format the swap partition:

$sudo mkswap -c /dev/sda5

This completed the formatting without complaint within only a few minutes. So, the problem was indeed the bit of disk with the swap partition, which was now unallocated.

The next thing was to see the new UUID for the swap partition:

$sudo blkid
/dev/sda1: UUID="06a5ce9f-60e8-4df4-bf8e-44996bee3601" TYPE="ext4"
/dev/sda5: UUID="87559234-ffb2-43bc-bfd0-5a53026ae558" TYPE="swap"

and see how it compared to /etc/fstab:

$more /etc/fstab
# /etc/fstab: static file system information.
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=06a5ce9f-60e8-4df4-bf8e-44996bee3601 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=72b5bb58-3d8a-4dc9-888e-2b86db41c81c none            swap    sw              0       0

So, the UUID had changed and now the fstab needed updating by changing fstab's entry for the swap partition to the new value.

$sudo gedit /etc/fstab

a quick cut and paste and save, and fstab had the new UUID in it.

swap was then turned back on with:

$sudo swapon /dev/sda5

On rebooting, the new swap area with its new UUID came up automatically, as expected.

Here are before and after shots showing swap off and then back on, by running the following command:


No more syslog errors either.

Part of the reason the swap partition had been trashed is that Ubuntu has become a bit bloated and 1GB of RAM isn't a lot of RAM these days for running a few applications at once. Ubuntu struggles to even install on a box with 512MB of RAM, sometimes hanging.

To avoid excessive swap use, it seemed time to max out the RAM to 2GB.

The 1GB DDR2 667MHz 200 pin SDRAM SODIMM was removed (with due attention to static precautions) by undoing the two screws on the panel under the keyboard to access the SODIMM. It was the following part:

SPS-MEM, 1G, PC5300 537664-001

A 2GB DDR2 800MHz 200 pin SDRAM SODIMM was found at msy.com.au for around AUD$30.
It was not PC5300, but PC6400, i.e. it was 800MHz rated not 667MHz rated. Not a problem. It's working a treat, as evidenced by the screenshot above, showing "Mem:   2052568k total".

It reminds me of a rule of thumb for un*x boxes... keep adding RAM until the HDD light goes out.....

If you've made it this far, you're probably wondering "why spend money on an old machine?". Well, it's compact, does the job, and linux allows me to make do with ancient hardware that would otherwise get thrown out. I'm happy to spend a bit to keep a machine running for another year or two or three.

The next issue is the hard drive. Many would argue that a hard drive with increasing bad sectors is probably in a bit of death spiral. So the next job is to replace the HDD. These have become crazy cheap too these days. AUD$50 for a 5400RPM 500GB Seagate at msy.com.au as well. $50 is cheap insurance if it avoids a catastrophic data loss.

Wednesday, 1 May 2013

The VK5HSE i-Kaktusss iambic keyer, beacon, and morse trainer

Just a quick posting about the i-Kaktusss iambic keyer featured in the May edition of Amateur Radio magazine, published by the Wireless Institute of Australia.

The i-kaktusss is an "Iambic keyer and Koch trainer using a seventeen segment screen".

It also has PS/2 keyboard support, and provision for simple keyer fabrication with paperclips if desired on the actual PCB, if an external iambic keyer is unavailable.

The immediate conversion of the Morse keyed in via the paddles to a character on the LED display makes learning Morse much more reflexive, and the practice modes with pseudo random text and stored text playback avoid all the hassles of practice tapes and CDs, by giving a quick display of the character after it is sounded.

It also has modes that play the morse and display the character entered on a PS/2 keyboard.

It will also work just fine as a beacon or a plain old iambic keyer.

The i-Kaktusss can be powered by either a 12V DC supply or a USB cable.

The PCB has been designed with wide tracks and large pads to make homebrewing easier and also soldering by novices easier, and there is copious provision for headers for external wiring if required.

The i-Kaktusss is the culmination of my ongoing attempts to become familiar with the gEDA PCB design tools on linux, with guidance from Jim VK5TR and Mitch at Hackvana, who supplied the PCBs.

Once you get the hang of schematic capture in gschema, followed by conversion into a PCB design file, and playing with the layout in PCB, you'll try things you'd not dreamt of with breadboards, veroboard, paddyboard/manhatten construction, or deadbug construction.

Best of all, the gEDA tool suite is free.

Anyway, getting back to the i-Kaktusss:

The current i-Kaktusss construction manual is available here

A zipped copy of the current i-Kaktusss software is available here

And a git repository has been set up here for the i-Kaktusss software

And i-Kaktusss kits are available at Aztronics

The PicAXE software which is free to download is available here and has copious online documentation available here, which will allow builders to modify if needed and load the code onto the PicAXE28x2.

Amateur radio is all about collaborative efforts which advance the art, so software patents and restrictive intellectual property rights are not just an obstacle to encouraging the younger generation to solder, code and experiment, they are antithetical.

Accordingly, the i-Kaktusss software has been released under a GPL3 licence, and the PCB has been released under the TAPR open hardware licence.

BASIC has been used for the first release of the i-Kaktusss to maximise the ease with which programming novices can implement their own changes to the code.

Saturday, 23 March 2013

50 Ohm SMD Dummy Load Prototype Construction

The PCBs for my first go at a SMD 50 ohm dummy load arrived the other day followed by the 2200 ohm SMD resistors.

For those that don't know what a dummy load is, it is basically a resistor that you put on the output of a radio frequency source, such as a transmitter, while testing or experimenting, so that you can do things like:

1) avoid transmitting rubbish while testing and doing R&D with the circuit it is attached to, or

2) do power measurements

The reason it is 50 ohms is because most amateur radio equipment with unbalanced outputs, such as PL-259, BNC or N connectors, is designed to work into loads that look like a 50 ohm resistance to the equipment.

Why 50 ohms, and not 75 ohms like a TV antenna?

The 50 ohms comes from the practicality that a 50 ohm characteristic impedance coaxial line is a good compromise between power handling and loss.

A lower impedance (around 30 ohms) would improve power handling, and a slightly higher impedance (around 70 ohms) would reduce losses, and 50 ohms was chosen as a reasonable compromise.

Why do it with SMD parts?

The smaller an RF circuit is, the less prone to parasitic inductance and capacitance effects which will make it deviate from ideal behaviour, in this case, behaving like a 50 ohm resistor.

Why 44 resistors?

More resistors equals more power handling ability, and forty four 2200 ohm resistors in parallel equals 50 ohms, and a nominal 11 watts power handling capacity.

My quick and dirty way to solder SMD parts uses a hot plate and a jig to lift the PCB off the hot plate at just the right time.

You can also see http://www.ahars.com.au/htm/hb_reflowsoldering.html for more details.

We start with solder paste, an applicator, in this case a needle, and some tweezers, the PCB, the SMD parts, and good lighting:

We apply solder paste to the pads. This took about 5 minutes. One half was done with discrete blobs on pads, the other half with long smears along the pads for comparison. Smears are quicker:

We apply the SMD parts with tweezers. Another 5-10 minutes. Older amateurs on beta blockers and not using energy drinks might be quicker:

We put the PCB on the reflow jig, which is in contact with the hotplate. We turn on the hotplate, and for this hotplate, I know it has to go for 250 seconds, then turn off the hotplate, then lift the jig off the hotplate at 280 seconds, starting at room temperature:

At around 180 seconds, most of the solder paste has melted, going from grainy grey to a shiny silver appearance:

At 250 seconds it is turned off, and at 280 seconds, the jig is gently lifted and chocked with whatever is nearby, and the hotplate can be moved out of the way:

After the PCB has cooled, any residual solder balls can be removed with a cotton bud. As can be seen, a long line of solder paste worked out much the same as carefully placed dollops on each pad:

Before adding the BNC connector, we check that it comes to 50 ohms with the multimeter, to check that there were no solder bridges from the reflowing. We then add the BNC connector:

We want the dummy load to behave like a 50 ohm resistor, to enable us to see how our equipment we connect to the dummy load is behaving. To know if it will behave like a 50 ohm dummy load, we need to test it.

A crude but effective test of the dummy load's behaviour at different frequencies is to use the impedance bridge of the kit built VK5JST antenna analyser.

An antenna analyser is, after all, a piece of equipment designed to see if an antenna behaves like an ideal 50 ohm load for our transmitter... so testing a dummy load with it is not too heretical, just don't tell Jim, VK5JST...

We find an SWR of 1.03 at 50MHz or so. This is within the error margins of the analyser's impedance bridge at these frequencies, and the 50 ohm load appears to be behaving like a fairly ideal 50 ohm load:

Then, at 30 MHz or so, the SWR is about 1.02:

And at 25MHz and below, the analyser thinks it is a fairly pure 50 ohm load with no reactive components at all, giving an SWR of 1.00:

The next step is to get some proper testing done with a vector network analyser or similar gear, for more accurate performance assessment, but preliminary indications are quite encouraging.

The optional through hole power measurement components (Capacitor, diode and resistor) can be added later if desired.

So, SMD reflow soldering needn't be slow, painful, or expensive. Within half an hour of starting to apply solder paste, the BNC was on and I was testing the dummy load.

Thursday, 21 March 2013

VK5HSE Step Attenuator Construction

For those early adopters who can't wait for AR magazine...

Nearest parallel resistor values for the 1dB/2dB/3dB/5dB/10dB/10dB/10dB Pi-Networks are:

869.548 ohms:  use 6800 || 1000

5.769 ohms: use 6.8 || 39

436.212 ohms: use 1200 || 680

11.615 ohms: use 33 || 18

292.402 ohms: use 2700 || 330

17.615 ohms: use 820 || 18

178.489 ohms: use 22000 || 180

30.398 ohms: use 390 || 33

96.248 ohms: use 270 || 150

71.151 ohms: use 560 || 82

I recommend double checking the final parallel value for each pair before soldering them in, as it will be harder to find errors once they form a pi network, and I may have made a mistake transcribing the values.

Once each pi network is soldered, you can use the white silkscreen rectangle to write the particular pi-attenuator section's attenuation in dB.

The photos are detailed enough to give a rough idea of the 1% resistor colour codes.

The good VK5TR hath spake unto me that 20dB pi attenuators would verily invite excessive coupling, so yeah, values have not been calculated for 20dB pi networks.

Barry, VK5BW, very kindly did some tests looking at return loss, insertion loss, and VSWR.

Testing used the photographed step attenuator shown below, with the second BNC connector also soldered on.

1% metal film resistors were used for the pi-attenuator sections going from left to right: 1dB, 2dB, 3dB, 5dB, 10dB, 10dB, 10dB

In summary, for HF:

SWR < 1.1 across all bands up to and including 6m, and

SWR < 1.05 if > 5dB attenuation used, across all bands up to and including the 6m band

At 150MHz:

Insertion loss of ~ 0.15dB at 150Mhz

At 150MHz, attenuation steps remain quite accurate for the 10 & 5dB switches

Bleed through with all attenuators switched in at 150Mhz estimated at < 1dB

SWR increases to about 2.0 by 150MHz.

Here are some fairly hi resolution photos. You can right click on the images and select "Open link in new tab" if you want to see them at full resolution and skip the default "fit to browser window" slide show format.

And now some close ups of the 10dB pi attenuator network, in case the above photos aren't crisp enough.

First, the top side of the board showing the switch, and the parallel and equal pi attenuator legs:

And then the underside of the board showing the series segment of the pi attenuator network:


Power handling will depend on the resistors used.

Wire wound resistors would add inductance and render the attenuator somewhat useless.

Diverging from the design (i.e. resistor placement WRT side of the board, adding shielding between or around sections, etc...) may improve performance, but without further testing you won't know.

The transmission line design assumes 1.6mm FR4 with 1oz copper, which is the standard PCB option from Hackvana.

Thanks again to Barry, VK5BW for running the tests, and the developers of the gEDA toolsuite under GNU/Linux, without which the barriers to learning PCB design would be much greater.