The problem with newer sound devices is the rather limited sync range possible with the modern audio CODECs. Many will not do sample rates that aren’t a multiple of 44.1kHz or 48kHz, and I have a headset that won’t record any other sample rate other than 16kHz. ALSA’s plug: doesn’t play nice with JACK, and I shelved the whole project for later.

Well, tonight I did some tinkering with gstreamer to see if it could do the routing I needed. Certainly all the building blocks were there, I just had to get the pipeline right. A bit of jiggling of parameters, and I managed to get audio going in both directions, and to a RIFF wave file to boot. I’ve put it in a shell script for readability/maintainability:

#!/bin/sh
# GStreamer bi-directional full-duplex audio routing script
# Stuart Longland VK4MSL

CAPT_BUFTIME=50000
CAPT_LATTIME=25000
PLAY_BUFTIME=20000
PLAY_LATTIME=1000

STREAM_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
OUTPUT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=16000
OUTPUT="${1:-out.wav}"

HEADSET_DEV=hw:Headset
HEADSET_CAPT_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
HEADSET_CAPT_BUFTIME=${CAPT_BUFTIME}
HEADSET_CAPT_LATTIME=${CAPT_LATTIME}
HEADSET_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
HEADSET_PLAY_BUFTIME=${PLAY_BUFTIME}
HEADSET_PLAY_LATTIME=${PLAY_LATTIME}

SNDCARD_DEV=hw:NVidia
SNDCARD_CAPT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_CAPT_BUFTIME=${CAPT_BUFTIME}
SNDCARD_CAPT_LATTIME=${CAPT_LATTIME}
SNDCARD_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_PLAY_BUFTIME=${PLAY_BUFTIME}
SNDCARD_PLAY_LATTIME=${PLAY_LATTIME}

exec    gst-launch-0.10 \
    alsasrc device=${HEADSET_DEV} \
            name=headset-capt \
            slave-method=resample \
            buffer-time=${HEADSET_CAPT_BUFTIME} \
            latency-time=${HEADSET_CAPT_LATTIME} \
        ! ${HEADSET_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=headset \
        ! audioresample \
        ! audioconvert \
        ! ${SNDCARD_PLAY_FMT} \
        ! alsasink device=${SNDCARD_DEV} \
            name=sndcard-play \
            buffer-time=${SNDCARD_PLAY_BUFTIME} \
            latency-time=${SNDCARD_PLAY_LATTIME} \
    alsasrc device=${SNDCARD_DEV} \
            name=sndcard-capt \
            slave-method=resample \
            buffer-time=${SNDCARD_CAPT_BUFTIME} \
            latency-time=${SNDCARD_CAPT_LATTIME} \
        ! ${SNDCARD_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=soundcard \
        ! audioresample \
        ! audioconvert \
        ! ${HEADSET_PLAY_FMT} \
        ! alsasink device=${HEADSET_DEV} \
            name=headset-play \
            buffer-time=${HEADSET_PLAY_BUFTIME} \
            latency-time=${HEADSET_PLAY_LATTIME} \
    interleave name=recorder-in \
        ! audioconvert \
        ! audioresample \
        ! ${OUTPUT_FMT} \
        ! wavenc \
        ! filesink location="${OUTPUT}" \
    headset. \
        ! queue \
        ! recorder-in.sink1 \
    soundcard. \
        ! queue \
        ! recorder-in.sink0

Now the fun begins ironing out the kinks in my data cable for the FT-897. At present, it works for receive, and seems to work for transmit. I use VOX on the radio itself and keep the headset’s microphone on mute when I don’t want to transmit.

At present, I was getting a bit of distorted audio coming back through the headset when I transmitted, almost certainly RF-pickup in the cable and line-in circuitry of the computer’s sound card. I’ll have to see if I can filter it out, but the real test will be seeing if such distortion is present on the outgoing signal — or rather, if it’s significantly audible to be a problem.

The seller on eBay that sold me the device have been completely unresponsive as to the problems, so looks like I kissed about $250 goodbye.  Ahh well, such is life.  They are still being sold on eBay, but buyer beware, they are cheap, and it’s pot luck whether yours is cheerful, or nasty like mine.  If you want something reliable, look elsewhere.

Having made this mistake, well, I’m looking to make lemonade from the lemon.  First step, was to figure out what on earth I had.  So out with the screwdriver.

You’ll notice on the top and bottom of the unit, there are four small plugs concealing screws.  These hold the LCD screen assembly in place.  Undo these, then you need to carefully work your way around and release the clips that hold the LCD screen assembly.  Do not try to detach the LCD touch panel from the LCD!  I initially couldn’t get it to budge, so I tried doing exactly this in the hunt for possible hidden screws (there were none).  This was the end result:

Why one should not try to detach the touch panel.

Never mind I say… the unit was just about destined for the bin as it was.  External USB HID devices work for what I’m after, but it’ll mean any touch-related fun is out unless I can pick up a replacement 4-wire panel.  Element14 and RS have them at >$80, to which I say, bugger it, I’ll do without.

Having pulled the unit apart, the main PCB is held to the back shell by a few screws, one thing is immediately apparent.  The whole device is based on what looks to be a fairly generic System-on-Module based around the Vimicro VC0882BCXA System-on-Chip, and the Vimicro VC7822EL companion chip.

Flytouch III PCB

Top left is a Wifi module based on the Realtek RTL8111, and to the right, the GPS module (which hooks to one of the serial ports from what I recall).  Down the bottom of the image are the USB ports.  Near the HDMI socket is a Silicon Image SiI9022ACNU HDMI transmitter.

The system on module looks interesting, and I’m curious to find out more about it, as for hobby projects, the pins are not too small to deal with using a soldering iron.  The OS and boot loader exist on the microSD card.  I tried putting a 16GB card in, but evidently I wasn’t getting the partition table right as it wouldn’t boot.  I haven’t tried hooking up a serial port as yet, so it’s hard to know what is wrong.  Some research indicates that ttyS0 lurks on this board just near the aforementioned microSD socket:

The system on module within the Flytouch III

I haven’t spotted the bad joints that were giving me grief. In fact, having gotten it out of the case, I find the top USB port (flakey from day one) seems to be behaving, and I’ve had no issues with it running with the case apart.  Otherwise I’d be running a soldering iron over a few joints just to make sure everything was right.

Next step?  Well for now, I’ll put it back together (minus touchscreen) and put it aside.  I’ll have a look at tacking a connector onto those serial pins, with a level shifter so I can interact with the serial console.

Having gotten bootloader access, I should be able to debug the SD card cloning issue, then I can have a close gander at what the current u-boot and kernel are doing to tickle the hardware.  End game?  Well, Android isn’t much use without a touch screen, so I’ll be probably hacking together a Gentoo-based environment with some amateur radio related software.  We shall see.

At that point it turned up only just before I was due to leave, so I wasn’t able to get the accessories I wanted. I cobbled together my own 12V charger lead by snipping the original power supply and soldering on a cigarette lighter socket, but otherwise I used the handheld in its out-of-the-box configuration.

Having gotten back, I have purchased the FGPS-2 GPS module, CT-136 GPS adaptor and the BU-1 Bluetooth module.

Transceiver performance

The set works quite well. The antenna is pretty deaf and useless on 6m, maybe I can get a better after-market tri-bander whip, but on 2m and 70cm it works reasonably well. I’ve heard APRS traffic over distances of 100km, and even been heard on APRS by a digipeater some 90km away.

Audio quality is good, both transmit and receive. Plug in a pair of stereo headphones, and the wideband FM receiver sounds excellent; in stereo to boot.

Probably my biggest nit, is you can’t simultaneously charge and externally power the set. To charge, you must either detach the battery and drop it into a separate charger cradle (an optional extra) or turn off the set.

GPS Performance

When I purchased the VX-8DR, it was a real toss up between it and the VX-8GR. The reason I went the VX-8DR was because it had 6m, and Bluetooth. Having gotten the GPS, I’ve run into the problem a lot have reported; the GPS module is deaf as a post.

The VX8-GR doesn’t improve on this either. However, the good news, is that because my module is external, I can (1) mount it in a better spot, or (2) replace it with a better compatible module.  For VX8-GR owners, this is the end of the road, they can do nothing but moan to Yaesu.  I at least have options.

The module is mounted vertically inside the FGPS-2 casing. Usually with GPS modules such as these, they embed a small patch antenna, whose radiation pattern is perpendicular to the plane of the antenna surface. Being vertical, this means when you hold the radio vertically (as you normally would), GPS reception is poor because the radiation pattern is directly in front of the radio.

The radio seems to perform a lot better, if the radio is held with the screen facing upwards towards the sky. It’ll even work inside my house if I do this. It seems this is a screw-up on par with the iPhone 4.  Another alternative is to replace the module, the FGPS-2 apparently uses 9600 baud serial with NMEA format strings.  However, it seems the parser in the VX-8 is rather crude.  I have a module that does NMEA at 4800 baud, so I’ll either need to coax it up to 9600, or use a microcontroller to buffer and convert rates, and perhaps do some tweaking of the sentence format to make up for the VX-8′s shortcomings.

My hunch; if I make an alternative bracket to the CT-136 adaptor, I can nail this, and another problem, the inability to plug in the GPS and a headset. I have the CT-M11 cable, and thus I plan to make a bracket to connect the FGPS-2 to the end of this cable; allowing me to also plug in a wired headset.

Bluetooth

I bought the Bluetooth as an insurance policy to give me another means of interfacing a headset. Then began the fun of getting it to work with my headsets. I have a couple; a Bullant earmuff-headset, a lightweight mono Digitech headset, and a “MyTalker” headset.

The first was one set I bought some years ago, back when the Bluez was far less stable than it is today, and also long before I was into Amateur Radio or possessed a Bluetooth-capable phone. I tried pairing using a USB Bluetooth dongle, but had little luck, so they got put on one side. Also despite advertising being able to stream music, it only supports HFP and HSP profiles, so you get to listen to your tunes in 8kHz 8-bit mono. They are sold at some hardware stores, such as Mitre 10 The Gap (where I bought my set).

The handheld did pair with this set, but I couldn’t get PTT to work, and the headset itself also had a few faults; namely it was always noisy, and the broadcast receiver stopped working, so I’ve taken them apart for now to see if I can fix these issues. I can key the radio up using the radio’s PTT, but then both internal and headset microphones go live.

The second set is sold by Jaycar, catalog number AA2080. This would be my preferred set to use with the radio as it can pair with two devices simultaneously. It supports the same profiles as the earmuffs, but it’s at least more lightweight.

The BU-1 takes one look at this set, and turns its nose up at it, with the VX-8 giving up and displaying “PAIRING ERROR”.

I also bought the MyTalker set from Jaycar, catalog number XC4894. This set is much like the earmuffs. It embeds its own microphone, but the unit itself provides a 3.5mm socket for you to plug in your own headphones, or use the supplied earphones (which are awful and uncomfortable, don’t use them). At the other end of the unit, is a lead terminated with a 3.5mm plug to plug into a music player. I’ve modded this set to be able to use an external microphone, switchable between a transceiver and the Bluetooth set, allowing a headset connected to a radio to also connect to a phone. I’m still working on this bit.

The VX-8 treats this set with much the same contempt as the mono headset before.

Today, I poppsed in and bought a more expensive set; this time I looked for A2DP functionality, Jaycar have one, catalog number AA2082. Like the AA2080 it can talk to two devices, unlike the AA2080 it supports AVRCP and A2DP. Also, not advertised, is it can function as an analogue headset; supplied in the box is a dual 3.5mm to mini-USB cable that can plug into the headset and allow you to use it with a non-Bluetooth capable device.

I plugged it into the bicycle’s battery to charge on the way home. When I got home, I read the instructions (which are in awful Chinglish). Basically, the English translation of the pairing instructions go like this:

1. Hold in the MFB button (the centre one on the right ear-cup) in for several seconds. You will hear the voice prompts “Hello”, followed by “Enter Pin Code 0000 on phone”.
2. When you hear the latter prompt, tell your device to start looking for the headset
3. When it finds a device called “AA2082″, select it, and enter 0000 as the pin code

So, the steps I followed:

1. Turn on the VX-8
2. Hold in the MENU key to bring up the Set menu, then select BLUETOOTH PCODE
3. Enter 0000 on the keypad.
4. Hold in the MFB button on the headset until you hear the “Enter Pin Code” prompt
5. Hit V/M on the VX-8
6. After a few brief moments, you should see “PAIRING COMPLETE”, press PTT to confirm.

Having got this working, I notice a few things:

• Stereo (A2DP) sounds a little weird, perfectly clear, but the compression is apparent. I’ll experiment with the laptop later to see if it’s the headset or the radio.
• Mono works well, pressing MFB toggles PTT on the VX-8. VOX doesn’t seem to work, but no great loss as I find VOX to be a disaster when outdoors.
• In mono mode, a buzzing is apparent on the received audio. This isn’t audible on transmitted audio, nor did I notice this on received audio when I tried using the headset with my mobile phone.
• Range seems to be quite restricted, possibly due to where the module is installed it doesn’t get the reception it perhaps needs. A2DP suffers more from this than HFP, with drop-outs being frequent. Again, I’ll need to do some experimentation with the laptop, and perhaps some experimentation with the radio without the battery installed to see if that helps performance.

I’m tossing up whether I get one of these motorcycle Bluetooth headsets.  I ride on the bicycle quite a lot, and at the moment I use headsets embedded in the helmet that are home-built from old computer headsets.  The longevity of the microphone seems to be the biggest problem  I also am on the look-out for an earmuff headset for things like the Imbill car rally, ideally one that can do A2DP.  The Bullant ones I know can’t do this.  I see some earmuffs in the $400+ price bracket that offer Bluetooth, but no idea if that includes A2DP, and frankly, I shudder at that price.

The motorcycle ones are designed to fit a wide range of helmets, and they look as if they’ll fit a set of cheap regular earmuffs quite well.  They typically sell for about $200, support A2DP, multiple devices, and intercom.  Add in $30 for a set of earmuffs, and it makes this a much more attractive option.

More experimentation will be needed I think, but this is looking promising.  I’ll probably post up more details as I come across them.

It’d be nice if Yaesu had been a bit more up-front on what the BU-1 supports: the AA2080 supports both HFP and HSP, yet the BU-1 won’t touch it, the Bullant set supports the same profiles yet the BU-1 works fine with it.  The reasoning for this is not clear, but it does seem that it’ll reliably talk to A2DP capable headsets, so maybe that is a starting point for others.

Likewise with the CT-136, I’ll see if I can fabricate a bracket using the CT-M11 cable, and see where that gets me.

Having gained root access earlier, I was able to use dd and nc to siphon off a copy of the internal SD card, which appears as /dev/block/mmcblk0. To grab a copy, first plug the unit into Ethernet (it’ll be faster, trust me) and have another Linux box handy:

Start up netcat on a Linux system:
$ busybox nc -l -p 8123 > tablet.img

Then on the tablet, become root:
$ /system/bin/su

Then start copying to the other system (here; its IP is 12.23.34.45):
# dd if=/dev/block/mmcblk0 | nc 12.23.34.45 8123

Sit back and wait, it should be done in about 5 minutes. Now if you look at the partition table, you’ll see the following:

Disk tablet.img: 482 cylinders, 255 heads, 63 sectors/track
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
tablet.img1            63   5535320    5535258   b  W95 FAT32           < -- User applications, data live here
tablet.img2       5535321   7612181    2076861   5  Extended
tablet.img3       7612248   7677783      65536  bb  Boot Wizard hidden  <-- Kernel?
tablet.img4       7677784   7743319      65536  bb  Boot Wizard hidden  <-- UBoot?
tablet.img5       5535384   6059608     524225  83  Linux               <-- /system partition
tablet.img6       6059672   7595608    1535937  83  Linux               <-- Android internal?
tablet.img7       7595672   7611992      16321  83  Linux               <-- ???

Partitions 3 and 4 are a complete mystery. They're not a standard Linux file system, but, the former appears to hold a copy of the Linux kernel, and the latter seems to hold a copy of UBoot. You can bust the image apart using the following script:


/sbin/sfdisk -uS -l tablet.img | grep ^tablet.img | while read part; do
pn=$( echo "$part" | cut -c 11-11 );
s=$( echo "$part" | cut -c 13-25 );
l=$( echo "$part" | cut -c 36-48 );
echo "[$pn][$s][$l]";
dd if=tablet.img of=tablet-$pn.img skip=$(( $s )) count=$(( $l ));
done


You might have to play with column offsets.

The initial part of partition 3 looks like this:

00000000  41 4e 44 52 4f 49 44 21  c0 d7 4b 00 00 80 00 10  |ANDROID!..K.....|
00000010  b5 2a 15 00 00 00 00 11  00 00 00 00 00 00 f0 10  |.*..............|
00000020  00 01 00 10 00 08 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000240  b8 29 4b 8c 7c d2 1f 65  cf b3 3a 78 bc 87 c0 61  |.)K.|..e..:x...a|
00000250  2e 24 79 a5 00 00 00 00  00 00 00 00 00 00 00 00  |.$y.............|
00000260  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  27 05 19 56 43 d9 c4 f4  4e ab c7 11 00 4b d7 80  |'..VC...N....K..|
00000810  80 00 80 00 80 00 80 00  d5 42 0e 53 05 02 02 00  |.........B.S....|
00000820  4c 69 6e 75 78 2d 32 2e  36 2e 33 35 2e 37 00 00  |Linux-2.6.35.7..|
00000830  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000840  d3 f0 21 e3 10 9f 10 ee  56 00 00 eb 05 a0 b0 e1  |..!.....V.......|
00000850  52 00 00 0a 6c 00 00 eb  05 80 b0 e1 4f 00 00 0a  |R...l.......O...|
00000860  7b 00 00 eb 13 00 00 eb  c0 d0 9f e5 00 e0 8f e2  |{...............|
00000870  10 f0 8a e2 30 5f 11 ee  02 50 85 e3 30 5f 01 ee  |....0_...P..0_..|
00000880  02 00 80 e3 1f 50 a0 e3  10 5f 03 ee 10 4f 02 ee  |.....P..._...O..|

Note the rather prominent “Linux-2.6.35.7″. Similarly, if we pick through partition 4:

00020eb0  11 12 a0 41 10 13 a0 51  30 1c 81 41 10 02 a0 e1  |...A...Q0..A....|
00020ec0  1e ff 2f e1 ff ff ff ff  ff ff ff ff ff ff ff ff  |../.............|
00020ed0  00 10 05 60 20 10 05 60  00 13 05 60 20 13 05 60  |...` ..`...` ..`|
00020ee0  40 13 05 60 00 16 05 60  20 16 05 60 00 19 05 60  |@..`...` ..`...`|
00020ef0  20 19 05 60 00 1c 05 60  20 1c 05 60 40 1c 05 60  | ..`...` ..`@..`|
00020f00  55 2d 42 6f 6f 74 20 32  30 31 30 2e 30 36 20 28  |U-Boot 2010.06 (|
00020f10  4f 63 74 20 32 39 20 32  30 31 31 20 2d 20 31 37  |Oct 29 2011 - 17|
00020f20  3a 32 37 3a 30 31 29 00  18 13 ea 80 20 13 ea 80  |:27:01)..... ...|
00020f30  27 13 ea 80 2e 13 ea 80  35 13 ea 80 3c 13 ea 80  |'.......5...< ...|
00020f40  43 13 ea 80 4a 13 ea 80  51 13 ea 80 58 13 ea 80  |C...J...Q...X...|
00020f50  5f 13 ea 80 67 13 ea 80  6f 13 ea 80 77 13 ea 80  |_...g...o...w...|
00020f60  7f 13 ea 80 87 13 ea 80  8f 13 ea 80 97 13 ea 80  |................|

Since I like open source, and didn’t like the idea of spending several hundred on a hand-held GPS with proprietary firmware & map data which I need to constantly purchase updates for, I opted for the cheapskate route.  I picked up a GL4Ever Flytouch III Tablet off eBay.  The unit I have came loaded with Android 2.3 (Gingerbread).

Ultimately I may replace the OS, or at least, the kernel, soon as I have sources for it, but in the meantime, it runs what it came with.  I have however, already managed to gain root access.

Those who might do a search for how to do so, may come across this guide.  I tried this first, and found I had no joy.  USB Debugging was enabled out-of-the-box on the unit I have, but z4root did not successfully enable root access.  The following are my notes on how I gained a shell with root access on the device.  Ohh, and I warn you, there is no warranty given in the instructions below.  If it breaks, you get to keep the pieces.

1. Download and install Gingerbreak.
2. Run Gingerbreak, it will run for a while, before resetting the device.  Upon starting, you should now notice you have a Superuser application installed.
3. Next, install Android Terminal.
4. Now, run /system/bin/su.

/bin/su is a symbolic link to /bin/busybox which was installed without the setuid bit, and is broken anyway, you’ll find if you do add a setuid bit, it will report that it can’t find the ‘root‘ user.  This system has no /etc/passwd or equivalent user database, so it has no idea who ‘root‘ is, but it knows who UID 0 is, and that’s what matters.  The latter ‘su‘ you’ll find has the necessary permissions, and knows about UID 0.

Other things I’ve found… the operating system lurks on a SD card embedded in the device.  Or at least, it’s presented as a SD card; /dev/block/mmcblk0.  The user-accessible SD-card port is /dev/block/mmcblk1.  You can verify this by ejecting the card, doing a ls /dev/block, then inserting a card and repeating.

On my TODO list, is to make a DD-copy of this block device, and pick through to see how one swaps out the kernel.  I’ll post notes if I figure this out.  I am also yet to obtain the kernel sources, I’ll chase those up before long.

The back-story is that I had made my MacOS X root and /Users partitions too big. I had successfully shrunk both, however, I discovered MacOS X’s Disk Utility does not support moving partitions, only resizing.  So, I created a new non-journalled HFS+ partition, booted into a Linux LiveCD, used rsync to clone the data.

All good and well, except after I deleted the old partition, I found I could not resize a non-journalled partition.  Fine, I hit “Enable Journaling”… no dice, it wouldn’t do it, and wouldn’t explain why.

So I was in a pickle.  The partition was too small for my needs, there was room to grow it, but it couldn’t do that unless journalling was enabled, and it wouldn’t enable it for me.

Further investigation, I fire up the Terminal and have a squiz on the command line, I spot something rather interesting:

vk4msl-mb:~ root# cd /Volumes/Home
vk4msl-mb:Home root# ls
.DS_Store		.fseventsd		Shared
.Spotlight-V100		.journal		stuartl
.TemporaryItems		.journal_info_block
.Trashes		.localized

Ohh yes, that might be a probable cause. rsync it seems, copied the .journal file over. And thus when Disk Utility open()‘s .journal (presumably with O_CREAT), the MacOS X kernel reports EEXIST (the file already exists).

I tried renaming it (with mv):

vk4msl-mb:Home root# mv .journal{,.old}
mv: rename .journal to .journal.old: Operation not permitted

Okay, that didn’t work. That said, the old partition was journalled, this one is not. So it probably doesn’t contain anything of great relevance now. It does have data:

vk4msl-mb:Home root# ls -ld .journal
----------@ 1 root  wheel  25165824 Apr  4  2011 .journal

So I decided to kiss it goodbye:

vk4msl-mb:Home root# rm .journal
override ---------  root/wheel uappnd,uchg,nodump,opaque for .journal? y
vk4msl-mb:Home root# rm .journal_info_block
override ---------  root/wheel uappnd,uchg,opaque for .journal_info_block? y
vk4msl-mb:Home root# ls
.DS_Store	.TemporaryItems	.fseventsd	Shared
.Spotlight-V100	.Trashes	.localized	stuartl

All gone. Having done this, I now found that Disk Utility was more than happy to not only enable journalling, but grow the partition as I originally asked.

vk4msl-mb:~ root# mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s3 on /Volumes/Home (hfs, local, journaled)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk0s7 on /Volumes/Data (hfs, local)
vk4msl-mb:~ root# df -h
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/disk0s2    93Gi   20Gi   73Gi    22%    /
devfs          123Ki  123Ki    0Bi   100%    /dev
/dev/disk0s3   242Gi   82Gi  160Gi    34%    /Volumes/Home
map -hosts       0Bi    0Bi    0Bi   100%    /net
map auto_home    0Bi    0Bi    0Bi   100%    /home
/dev/disk0s7    84Gi  893Mi   83Gi     2%    /Volumes/Data

If others find themselves in this sticky situation, this might be a way out. I would strongly advise they back up any data before messing with file systems in this manner however.

If only you had realised this years ago, I might not be battling Microsoft SQL Server 2000 using RDP over a 31.2kbps PSTN modem link yesterday and this morning.  I might’ve instead been using a mysqldump-like tool over something akin to SSH, which would have been very welcome yesterday and today.

I got fed up of restoring my firmware for the Broadcom wireless chip in my late-2008 model MacBook.  Anyone who has one of these might find the current in-tree versions of net-wireless/b43-firmware is missing files needed by the modern b43 driver (namely ucode16_mimo.fw), and net-wireless/b43-fwcutter doesn’t well, cut it, for extracting the newer files.

If you’ve got a newer 802.11n-based Broadcom chip, you might find the following ebuilds handy:

• net-wireless/b43-firmware-5.10.56.27.3
• net-wireless/b43-fwcutter-015 and net-wireless/b43-fwcutter-9999

The first is the firmware mentioned in this post.  It needs a newer fwcutter binary than is provided in Portage.  You’ve got the choice of the latest version, or the bleeding edge via git.  Both work at time of writing, although neither are guaranteed.

The ebuilds are not in-tree, I’ll leave that for the actual maintainer for these ebuilds to pick them up if desired, I’ve put them in an overlay accessed via the following command:

git clone git://git.longlandclan.yi.org/overlays/b43.git

Or you can take a squiz via gitweb.

Well, today I did some more work on the 2m linear.  Earlier this week I ordered some SMA connectors and some 1N5711 diodes for the project.

Two 1N5711 diodes will be used to make a voltage peak detector, to detect when the amplifier is subjected to power above 60mW.  The SMA connectors will be the interconnects between the modules.  This afternoon’s effort was spent soldering the SMA connectors onto two of the boards, and mounting the 2m amplifier module onto the heatsink.

The EME157B2 preamplifier kit was originally intended to be mounted in a masthead box, with BNC connectors soldered to the PCB, and stuck up a pole near the antenna.  In my application, I wanted it to be in the same enclosure (with suitable shielding) as the power amp, so that I could use its RF detection to automatically switch the power amplifier on.  I will also be using different relays, mounted on a separate board.

Instead of mounting the SPDT relays for the kit on the EME157B2 board, I’ve instead left these off.  I also omitted the 2N7000 MOSFET which turns on the relays, and L4, an RF-blocking choke which permits the preamp to run from a 12V source supplied up the coax.  I instead will power the preamp directly.

Since the relays will be on a separate board, the plan is to run wires from the gate and source connections where the 2N7000 belongs, and run those out to a controller board.  With the relays gone, the RF detection and the preamp are essentially two distinct circuits.  So 3 SMA connectors will be needed.  Here is the completed board with the SMA connectors fitted, and suitable jumpers installed, ready for tuning.

Completed 2m preamplifier. Connectors going left-to-right: Antenna input, Amplifier output, RF detector input.

Next, I finished off the power amplifier board, mounting it to the heatsink.  I have left one EMC filter disconnected for now, as the instructions say to power it up first with it disconnected to set the trim pot for 4.5V bias.  Rather than mounting the board flat on the heatsink, I have instead opted to mount the PCB at 90? to the module.  I had to make the supplied eyelets a fraction longer to accommodate this.  I also mounted SMA connectors on this board.

Completed 2m power amplifier. RF input is on the left.

The plan is, I’ll route RG195 coax on the left side to a small module which will contain the overload detection circuit and two SMAs for an external attenuator module.  On the right, a low-pass filter will be connected.  I also had a stab at tapping holes into the sides of the heatsink for mounting a bracket.  This bracket would hold the fans on top, and would bolt onto the main enclosure.  In doing this, I managed to bugger up two of the 8 holes, and thus what I’ll probably do, is buy a M4 tap tomorrow, drill them all out to 3mm and tap them to 4mm.  These are structural holes, so bigger is probably better anyway.

Much of today though was spent designing the controller.  I’m still finalising the design, but a rough schematic is below.

2m amplfier controller

So, not yet going, but big parts are built now.

Background

A few months back, I grabbed the trusty FT-290R II ready to do my weekly run from The Gap to Tarragindi.  Quick test to check everything’s okay… the power meter swings to full scale, but strange, I’m not hitting any repeaters.

Okay, grabbed the FT-897D instead, and I just did my weekly radio duties with that instead.  When I came home that evening, I had a closer look.  The FT-290R II was emitting a signal, the hand-held was picking that up.  It was also receiving just fine.  On a hunch I took off the FL-2025 linear, and hooked the antenna up directly to the radio.  Bingo… the radio works, the linear does not.

So, the linear had died, and thus I was in need of a new one.  Hand helds really don’t have much punch for mobile use, in fact, the FT-290 has been brilliant on the bike.  Not menu driven, so it’s real easy to drive while riding, simple, no frills, and sufficient grunt to get out of a bad area.  It also does SSB (and CW, but I’ll leave that to LY2KW).

I could buy a new set, in fact, I may get a FT-857D, as the 897D is a heavy lump of a radio to lug around, and there are times when HF capability is useful.  It is less than ideal on the bike however due to its size and weight.  There was nothing wrong with the FT-290, just its linear was dead, thus I was limited to its barefoot transmit power of 2.5W, even less than most handhelds.

So, I decided I’d try my hand at a semi-homebrew linear amplifier.

The concept

I wanted an amplifier that could achieve at least 25W of transmit power using SSB.  As I’d likely use it for things like WIA broadcasts, I wanted one that would also handle transmitting for a long period of time.

Designing a full blown amplifier on 2m is a bit beyond me with my limited homebrew experience.  It is also an issue sourcing the PCB material needed for VHF projects.  A lot out there call for FR4 grade fibreglass PCBs.  I have no idea what Jaycar sell.  So this was going to be a potential minefield.  Thus, I opted for a kit.

Minikits sell one based on the Mitsubishi RA30H1317M.  The same kit, can also take the 60W module, which sounded good to me.  Most of the time I’d be running it at 30W, but having 60W capability sounded good.  I purchased this, along with the 30W module as well just in case.

I also thought a pre-amp would be nice.  The same supplier sells this preamp kit.  The kit also offers RF sensing, which would allow the amplifier to auto-detect the radio transmitting, and switch into transmit mode automatically.  This also allows for filtering, to prevent reception of pagers (not fun copping an earful of one of those when you’re wearing a helmet-embedded headset riding a bicycle).

Cooling

Minikits recommends using a Pentium 4 heatsink for 30W modules, however it wasn’t clear if this would be sufficient for 60W modules.

I wanted the amplifier module to stay below 100?C while operating with ambient temperatures at 40?C.  Pretty sure I don’t want to operate a radio under such conditions, so it should work fine in all conditions that I’m likely to encounter.

The amplifier module is about 45% efficient, thus about 135W is dissipated when operating at full power.  By my calculations, I was looking for cooling that can provide 0.22?C/W.

A quick search revealed that I could get one via Conrad which in the open air achieves 0.84?C/W.  Combined with a fan, it can achieve 0.24?C/W.  Jaycar sell this fan, which is quite capable.  In fact, two of them will fit across the back of the heatsink, so with dual fans, I should be well and truly within limits.

I placed the order for the heatsink a fortnight ago.  Due to a mix-up, I didn’t get it until Wednesday, but that’s fine, I wasn’t in any hurry.  With the heatsink now in my possession, I today headded to Jaycar to pick up some of the bits and pieces I’d need for this project, starting with the enclosure.

One thing I did neglect to procure today, were the fans… but no biggie, I’ll get those later.

Prior work

Well, technically day one was some time ago.  I had already mostly built the amplifier kit, and the preamp.  The preamp got built way back when I first obtained the kits.

The power amp was built later, however the instructions suggested that I wait until I have the amplifier module mounted on the heatsink before I go soldering it to the PCB.

Amplifier kit and 60W module

Day 1

Having got the heatsink, enclosure and tools, I set to work.  Initially I positioned, drilled and tapped the two M3 holes for mounting the amplifier module.  I haven’t tried putting the amplifier in place yet, but it looks like the holes are positioned pretty well.

Amplifier module on heatsink

My plan, is to bend the pins on the module at 90? and mount the PCB horizontally.  Both module and PCB would be passed through the side wall of the enclosure, with the heatsink outside.  I originally wanted the heatsink inside the case (with vent holes), but of course, Jaycar are not good at providing internal dimensions, and I soon discovered it’d be awkward to fit.

It took a bit of experimentation to cut the hole in the side.  No, I won’t be winning any prizes for my metal work, in fact, it never was one of my best subjects.

Heatsink and empty enclosure

Next steps:

My immediate next step will be to mount the amplifier module, solder it to the PCB, and mount the PCB inside the case.  Then I mount the heatsink and fans to the case.

I have a controller that I have designed at digital logic level, however I’ll need to do some further design work to make sure it’ll do what I intend, before procuring the parts and building it.