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

Saturday, 2 August 2014

Ubuntu apt xapian index update manager very slow on older machines and how to fix it

I found this fix in the ubuntu bug reporting forum.

The symptoms are older machines with slower processors or limited RAM will grind to a halt when the package updater launches in the background. The machine becomes basically unusable for minutes at a time.

The bug has not been definitively fixed yet across multiple releases of Ubuntu, but this fix sorts it out.

One fix I came across involves installing a dummy xapian indexing package in the hope that nothing breaks, but this fix is more elegant.

Credit goes to Bill Bennert, quoted from:

first of all
sudo apt-get install cpulimit

Then, you need to edit /etc/cron.weekly/apt-xapian-index to utilize the newly installed cpulimit.

Once the cron job has been modified, you wouldn't even know that  the index is being updated.

Here is the modified version of apt-xapian-index:


# ionice should not be called in a virtual environment
# (similar to man-db cronjobs)
egrep -q '(envID|VxID):.*[1-9]' /proc/self/status || IONICE=/usr/bin/ionice

# Check if we're on battery
if which on_ac_power >/dev/null 2>&1; then
    on_ac_power >/dev/null 2>&1

    # Here we use "-eq 1" instead of "-ne 0" because
    # on_ac_power could also return 255, which means
    # it can't tell whether we are on AC or not. In
    # that case, run update-a-x-i nevertheless.
    [ "$ON_BATTERY" -eq 1 ] && exit 0

# Rebuild the index
if [ -x "$CMD" ]
    if [ -x "$IONICE" ]
        # background process so we can limit it...
        nice -n 19 $IONICE -c 3 $CMD --quiet &
        nice -n 19 $CMD --quiet &
    # regulate the cpu for this process...
    # GETPID and PID could be put into one line, but...
    GETPID="ps -Alf | grep -v 'grep' | grep '$CMD' | awk '{print \$4}'"
    PID=$(eval $GETPID)
    if [ "$PID" != "" ]
        # -z to let script die after pid dies. -l to limit to 5%
        cpulimit -z -p $PID -l 5

Monday, 28 July 2014

Rewinding and Modifying Intermediate Frequency (IF) Can Transformers For Variable Inductor Applications

Ongoing experiments relating to determination of quartz crystal motional parameters led to the need to make a G3UUR crystal test circuit resonate at around 10MHz using an LC tank circuit, with an inductor in place of the usual crystal.

A 10.7MHz intermediate frequency transformer, also known as an IF can, is commonly used in the IF strip of FM radios.

A 10.7 MHz IF can, with minor modifications, seemed ideal for as a 10Mhz variable inductor for this particular purpose as its usual frequency of operation was close to the required frequency.

The "Xicon 42IF123" IF can was available from www.minikits.com.au and was selected.

The first step is to remove the small capacitor in the base of the can, visible from underneath.  As shown in the circuit diagram, the capacitor is in parallel with the tapped primary coil of the transformer, and allows the primary to resonate at around 10.7MHz. It is not needed if the IF can is to be used simply as an inductor.

The capacitor can be removed with a sharp knife, scalpel, or similar.  

The shielding can is then carefully removed from the plastic base, taking care not to damage the vertical ferrite bobbin with the windings. 

The inductances of the windings had already been experimentally determined.

The tapped winding between pins 1 and 2 was calculated to have an inductance range: 2.5uH - 4.5uH

The primary winding between pins 1 and 3 was calculated to have an inductance range: 5.5uH - 10uH

The secondary winding between pins 4 and 6 was calculated to have an inductance range: 0.269uH - 0.383 uH

To use the tapped primary winding between pins 1 and 2 in a standard G3UUR colpitts circuit oscillating at around 10MHz required the inductance to be reduced around 30-40%. Without modification, the winding between pins 1 and 2 allowed a standard G3UUR colpitts circuit to oscillate between around 6.0MHz and 8.0MHz

There appeared to be about eight turns for the winding between pin 1 and 2, which, conveniently, was the most accessible winding, located at the top of the ferrite bobbin.

Accordingly, to effect a reduction in inductance of about 30-40%, three turns had to be removed.

After three turns had been unwound, the wire was carefully scraped clean of enamel insulation and re-attached to pin 1 with the soldering iron, after which the shielding can was replaced. The windings were then checked for continuity with a multimeter.

After confirming continuity of the windings, the modified IF can was placed in the G3UUR colpitts circuit using the winding between pins 1 and 2 in place of the crystal.The oscillator could now be tuned from around 9.0MHz up to 11.0Mhz, which achieved the intended goal of 10MHz operation.

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.