Blogospheric Refraction

The life and times of Stuart Longland (VK4MSL)

The problem

For some time now, we’ve been putting up with interference from a few stations, who for now will remain nameless.  Foul language, deliberate interference, the list goes on…

Allegedly some of these people have been doing it for longer than I’ve been alive.

It is as if, these people, believe we are not entitled to use a small patch of radio spectrum to engage in a little friendly chat.

Some have even gone as far as vowing to do “everything they can” to “ruin” amateur radio.

This means war.

Well, we could complain to the ACMA… apparently some have done this already… many times.  If they haven’t acted after 20 years worth of complaints, I don’t think they’ll ever act.  Not without a very substantial amount of evidence.

There is nothing however, that stops us, getting on the band and having a chat, except one thing.  Someone parking on the frequency we choose and interfering with our communications.  Yes, we could QSY, but experience has shown the culprits just chase us up and down the band.

They cannot be on all frequencies however.  One big group, on one frequency, is vulnerable to attack.  Numerous smaller groups, scattered across the band however, is far more resilient.  They cannot be on all frequencies at the same time.  More to the point, more ears open and listening, means more data points … bonus points if those “ears” are directional.

My proposal

What we need to do is stir up some activity on the 80m band.  The 80m amateur band is a wonderful local chit-chat band.  It has almost guaranteed propagation for distances over 1000km on any given evening.  It is open to all license classes.  (Well, if you ignore the DX window.)  I’m proposing a contest with a difference.

Most contests, you make contact with a station, exchange numbers, then it’s ta ta… (or “73″) and you go your separate ways.  Not terribly exciting listening.

I’m proposing a social ragchew contest.  I want to encourage as many people, on as many groups, as possible.  The more people, the better.  Talk about anything you like.  QRP and QRO stations welcome.  Mobile and portable stations, also welcome.  Newcomers, especially welcome.  Make it a large group, or a small group, doesn’t matter.  It doesn’t have to be a formal net, just so long as there’s at least three people.

How will it be scored?

This is something I’m still thinking about… but I’m thinking something along these lines… I would love your input.

For every hour, or part thereof, each member of a group chatting on the same frequency, will get one point for each member of that group.

So if 3 of you talk for 2¼ hours, that’s 3×3=9 points.

Multipliers

  • Triple points for every station who has held their license:
    • Less than 12 months
    • Greater than 50 years
  • Double points for every:
    • Station that is “mobile” (i.e. moving between localities) or  “portable” (i.e. set up temporarily at some location for less than one week)
    • QRP station (running 5 watts or less)
    • DX contact (overseas)

I’m thinking these should be added together, so if in your group of VK’s you happen to score someone joining your group from Europe (for example) that only just got their license a month ago and is running QRP whilst mobile, add 24 points to each group member for every hour or part thereof that they participate on your group.

What about interference?

More than likely, this will stir up the trolls that seek to ruin our experience.  Part of the aim of this, is that a lot of people will be listening.  The following is something anyone can do, even the shortwave listeners.

  • Log the following:
    • the time in UTC
    • your location (latitude/longitude or Maidenhair Locater)
    • the signal strength
    • the nature of interference
  • If you can, record the interference
  • If you have a directional antenna, point that in the direction where the signal is strongest.  Use that to measure the signal strength, and log the bearing, along with the antenna type.

With enough evidence, we can flush out these serial pests once and for all.

When will it be held?

This is open to discussion… I’m thinking Friday or Saturday night.  I’m thinking it should start some time in the evening when the band opens up, maybe after 7:00PM.

The contest should remain open until the last group participating in the contest goes clear… if a group manages to successfully run to dawn the next day, good on them, maybe there should be bonus points for their efforts. :-)

Let me know what your thoughts are… this is, as I say, a request for comment.  Feel free to get in touch with me directly or leave a comment here.

(I’m not one normally for airing dirty laundry in this manner, but I feel it is marginally better than airing it on the air.)

Dear Mal,

Please.  What is your problem?

This evening, your behaviour on this band was absolutely appauling.  For someone who has apparently had a radio license for longer than I’ve been alive, I am disappointed.  Sadly this is not an isolated incident but for now I’ll turn a deaf ear to previous offences and just focus on tonight’s offence.

I’m not sure if you’re the one that has been playing music over the top of us… some have made this allegation.  I’m happy to give you the benefit of a doubt, but the tirade that followed is very unbecoming of a radio amateur.  Foul language, deliberate interference, not identifying, name-calling, and generally making a nuisance.  As best I can tell, completely unprovoked.

You claimed, “I was here first”.  I was listening on 3584kHz from around 9:15PM.  I did hear Danny ask “Is the frequency in use“.  Several times.  I was mobile at Red Hill at the time.  Prior to this the frequency, as best I could hear with my marginal antenna, was devoid of all activity.  None the less, we gave you the benefit of the doubt, and after listening to your protest, we did the respectful thing and QSY’ed to 3590kHz.

Not a minute after we had done so, there you were, trying to talk over us (and only succeeding with the exceptionally weak stations), and misbehaving as before.  We had left you 3584kHz, moved to 3590kHz, and you followed us up the band.  Why?

All I have heard, is the ramble from a seeming madman.  All I, and others want to do, is use of 2.4 kHz, to have our friendly weekly chit chat.  You are even welcome to join in if you wish to be civil and play by the rules.  If you wish to have a discussion with someone else, we are not going to stop you.

On the 80m band, you’ve got 3.503kHz to 3.700kHz and 3779kHz through to 3800kHz.  You can go anywhere on that spectrum which isn’t already in use, why pick the frequency we’re using?  If you still wish to use the frequency we’re on, why not do the gentlemanly thing, and ask politely?  We’re reasonable, we will move if you ask nicely.

Please, I am asking as nicely as I possibly can, please leave us alone.  We do not wish to interfere with you, please don’t interfere with us.

Regards,

Stuart VK4MSL, and other regulars of the Australia Wide Night-Owl and Insomnia Net.

Some have looked at my bicycle, with the HF regalia and have commented on how extreme the setup there is.

However, it is worth pointing out, my station only covers the bands between 80m and 70cm (3.5 ~ 450MHz).  The radio can do 160m, however my license doesn’t permit me to go there, and 80m really stretches the friendship of the autotuner as it is.

For true DC-to-daylight though, or very close to it, have a squiz at the portable/field day station setup Roy VK4ZQ has come up with.  This is as close as most will ever get to DC-to-daylight… covering all bands from 80m through to 3cm.  Nicely done.

It was interesting when I posted a news article to the WIA regarding IPv6, how quickly it got shot down by “experts”.

A recent addition to our network was a 2008-model Apple MacBook, which I have dual-booting Gentoo and MacOS X 10.6.7 nicely.  One quirk of this particular laptop though, is that it will, when running its native OS, intermittently drop off the IPv4-only network.

The first tip-off to this is usually things like Skype ceasing to work.  Then I’ll notice DNS isn’t resolving (DNS is IPv6-accessible, but not many systems support RDNSS).

As a work-around to the problem, and also for my own self-education, I decided I’d have a crack at getting NAT64 and DNS64 to work.  What are they exactly?

NAT64 as the name suggests, is a variant of NAT that translates IPv6 to IPv4.  In doing so, allowing my MacBook that’s just disappeared from the face of the IPv4-only world, to still access the IPv4-part of the Internet.

DNS64 is a service that synthesizes AAAA records for host names that do not provide one.

The two work together to provide Internet access to an IPv6 only host.

What you will need to know

Make sure you have the following information on-hand.  I’ll use the following examples:

  • Your server’s IPv4 address on the local network: e.g. 192.168.0.1/24
  • IPv4 NAT address pool: This must not overlap with your existing networks.
    Examples use 192.168.255.0/24, I used 172.16.24.0/24
  • TAYGA’s tunnel IPv4 address: This will be the first address in the above subnet (i.e. 172.16.24.1)
  • Your network’s IPv6 subnet: e.g. 2001:dead:beef:1200::/56
  • IPv6 NAT address pool: This needs to be a non-overlapping portion of your address space.  In my case, I’m borrowing a /56 from AARNet, and I used a /64 for this, setting the lower 8-bits of the prefix to 0×64.  It only needs to be /96 in size.
    Example used: 2001:dead:beef:1264::/96

NAT64 setup

To get NAT64 working; start by installing TAYGA.  This is a userspace daemon uses the TUN device to route between IPv4 and IPv6.  On Gentoo, begin by running emerge tayga.  (You may need to keyword it.)

This installs the binary, but crucially, it comes with no init scripts.  You will need to create one yourself like this:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/gpm/files/gpm.rc6,v 1.12 2004/07/15 01:02:02 agriffis Exp $

depend() {
    need gw6c net.nat64
}

start() {
    ebegin "Starting tayga"
    start-stop-daemon --start --quiet -p /var/run/tayga.pid \
        --exec /usr/sbin/tayga -- \
        -u nobody -g nogroup \
        --pidfile /var/run/tayga.pid
    eend ${?}
}

stop() {
    ebegin "Stopping tayga"
    start-stop-daemon --stop --quiet --pidfile /var/run/tayga.pid
    eend ${?}
}

Now, edit /etc/tayga.conf, using /etc/tayga.conf.example as a guide.  There are comments provided.  The following are the settings I used (with the above addresses):

#
# TAYGA's IPv4 address.  This is NOT your router's IPv4 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping) at this address.
#
# This address can safely be located inside the dynamic-pool prefix.
#
# Mandatory.
#
ipv4-addr 172.16.24.1
# ... etc ...
#
# The NAT64 prefix.  The IPv4 address space is mapped into the IPv6 address
# space by prepending this prefix to the IPv4 address.  Using a /96 prefix is
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
#
# This must be a prefix selected from your organization's IPv6 address space
# or the Well-Known Prefix 64:ff9b::/96.  Note that using the Well-Known
# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
# (RFC1918) addresses, per RFC 6052.
#
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives.  (See below.)
#
# Optional.
#
prefix 2001:dead:beef:1264::/96
#
# Dynamic pool prefix.  IPv6 hosts which send traffic through TAYGA (and do
# not correspond to a static map or an IPv4-translatable address in the NAT64
# prefix) will be assigned an IPv4 address from the dynamic pool.  Dynamic
# maps are valid for 124 minutes after the last matching packet is seen.
#
# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.
#
# Optional.
#
dynamic-pool 172.16.24.0/24
# ... etc ...

Now, having done this… you just need to make sure the nat64 device gets created and initialised by openrc.  In /etc/conf.d/net:

# NAT64 configuration for TAYGA
config_nat64=(
   "192.168.0.1/24"
   "2001:dead:beef:1264::1/64"
)
routes_nat64=(
        "172.16.24.0/24"
        "2001:dead:beef:1264::/96"
)

preup() {
        case ${IFACE} in
                nat64)
                        /usr/sbin/tayga --mktun
                        ;;
        esac
}

Now, symlink /etc/init.d/net.lo to /etc/init.d/net.nat64, start the tayga service, and you should find that you can ping e.g. 2001:dead:beef:1264::8.8.8.8 (8.8.8.8 is Google DNS).

DNS64 setup

All good and well if you know the IP addresses, but most people don’t.  Now emerge totd.  Use /usr/share/doc/totd-VERSION/totd.conf.sample.bz2 as an example for configuring /etc/totd.conf:

; $Id: totd.conf.sample,v 1.9 2003/09/17 15:56:20 dillema Exp $
; Totd sample configuration file
; you can have multiple forwarders, totd will always prefer
; forwarders listed early and only use forwarders listed later
; if the first ones are unresponsive.
forwarder 2001:dead:beef:1234::1 port 65053
forwarder 127.0.0.1 port 65053
forwarder 8.8.8.8 port 53
forwarder 8.8.4.4 port 53

; you can have multiple prefixes or even no prefixes at all
; totd uses them in round-robin fashion
prefix 2001:dead:beef:1264::
; the port totd listens on for incoming requests
port 53
; the pidfile to use (default: /var/run/totd.pid)
pidfile /var/run/totd.pid
; interfaces totd listens on (UDP only for now and not on Linux)
; If left out totd will only open wildcard sockets.
;interfaces br0
; 6to4 reverse lookup
stf

In my case, I have a local caching name-server (BIND), which I’ve moved to port 65053. The trick-or-treat daemon now sits on port 53 where the rest of the network expects it. You can now start the totd service, point your /etc/resolv.conf files to it, and everything should Just Work.

Testing

Easiest way is to shut off IPv4, and set up /etc/resolv.conf on your client with the IPv6 address of your server running totd.  You should now be able to browse IPv4-only sites as if IPv4 were running.  I achieved this test by plugging into Ethernet, turning off wicd (it kept wanting to start-up dhcpcd), then manually bringing the interface up and configuring /etc/resolv.conf.

To whoever were responsible for developing this new feature in the latest Portage releases…

zhouman portage # FEATURES=-test USE=-handbook\ -doc emerge -eukDN --keep-going system kde-meta vim poppler =xulrunner-2.0.1-r1 =vim-core-7.3.189 =gvim-7.3.189 gst-plugins-base vim =gst-plugins-theora-0.10.32 =firefox-4.0.1-r1
Calculating dependencies... done!

!!! One or more updates have been skipped due to a dependency conflict:

app-editors/vim-core:0

(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
~app-editors/vim-core-7.3.189 required by (app-editors/gvim-7.3.189::gentoo, binary scheduled for merge)
(app-editors/vim-core-7.3.219::gentoo, ebuild scheduled for merge) conflicts with
=vim-core-7.3.189

!!! The following update(s) have been skipped due to unsatisfied dependencies
!!! triggered by backtracking:

app-editors/vim:0
[binary R ] x11-proto/xf86vidmodeproto-2.3.1
[binary R ] sys-libs/zlib-1.2.5-r2
[binary R ] sys-libs/ncurses-5.9
[binary R ] x11-proto/xproto-7.0.21
[binary R ] virtual/libintl-0
[binary R *] sci-visualization/gnuplot-4.4.2-r1
[ ... ]
[ebuild N *] kde-base/kdebase-meta-4.6.4 USE="(-aqua)"
[binary R *] media-libs/mediastreamer-2.7.3-r3
[ebuild N *] kde-base/kopete-4.6.4 USE="addbookmarks autoreplace contactnotes highlight history jingle nowlistening pipes privacy sms ssl statistics texteffect translator urlpicpreview v4l2 xmpp zeroconf (-aqua) -debug -gadu -groupwise -handbook (-kdeenablefinal) -latex -meanwhile -msn -oscar -otr -qq -skype -testbed -webpresence -winpopup -yahoo"
[binary R *] media-plugins/mediastreamer-ilbc-2.0.3
[ebuild N *] kde-base/kdenetwork-meta-4.6.4 USE="(-aqua) -ppp"
[ebuild N *] kde-base/kde-meta-4.6.4 USE="accessibility nls (-aqua) -sdk -semantic-desktop"

The following keyword changes are necessary to proceed:
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kglobalaccel-4.6.4 **
#required by kde-base/kdemultimedia-meta-4.6.4[mplayer], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/mplayerthumbs-4.6.4 **
#required by kde-base/kdeedu-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/rocs-4.6.4 **
#required by kde-base/kdegames-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kigo-4.6.4 **
#required by kde-base/kajongg-4.6.4, required by kde-base/kdegames-meta-4.6.4[python], required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/oxygen-icons-4.6.4 **
#required by kde-base/kdebase-runtime-meta-4.6.4, required by kde-base/kdebase-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)
>=kde-base/kdebase-menu-4.6.4 **
#required by kde-base/kdeutils-meta-4.6.4, required by kde-base/kde-meta-4.6.4, required by kde-meta (argument)

[...]

NOTE: This --autounmask behavior can be disabled by setting
EMERGE_DEFAULT_OPTS="--autounmask=n" in make.conf.

Use --autounmask-write to write changes to config files (honoring CONFIG_PROTECT).
zhouman portage #

THANK-YOU

You’ve just made my life trying to install and test big collections of software in Gentoo/MIPS much easier. :-)

Well, I’ve been meaning to get around to fixing up svxlink in Gentoo for a long time now. For those who don’t know, svxlink is a client and server for the EchoLink amateur radio linking system.

We had to stop releasing the Qtel client, as it relied on Qt3 which we no longer ship in Gentoo.  On top of this, the ebuild installed non-Gentoo init scripts, fails to build with gcc-4.6 and fails due to underlinking.  (My thanks go to Diego for pointing these flaws out.)

At the moment I’m working on the first problem, which is that the builds that were in-tree are crusty and old.  svxlink did release version 11.05 not long back, and ohh yes, they’ve changed their versioning scheme too to match Ubuntu.  However, their trunk branch is still dependent on Qt3 if you want Qtel.  There is an experimental Qt4 branch, which is what I’ve been working with.

One irritation I had was trying to make it possible to install the client component or the server component.  svxlink has its own, very custom, build system based on recursive makefiles.  (Yes, I know, considered harmful and all that.)  The build system first builds the core libraries, then it starts looking at Qtel and svxlink’s server components.  The first thing was to try and split these up.

The new ebuilds will introduce a svxlink-libs package.  This is relatively straightforward, and it just builds & installs the libasync, libechlib and liblocationinfo libraries.  The catch is when building qtel and svxlink, the build system looks for the built binaries inside the source tree.

I have submitted a patch upstream that remedies this.  Eventually I’ll look at how we can fix some of the other flaws in the build system.  So far I’m still battling svxlink itself, but I soon will have svxlink-libs and qtel packages available for testing in the Portage tree.  svxlink itself will also need to wait until I can set up a test node on simplex somewhere… my O2 looks like a likely possibility.

I’ll keep you all informed as this progresses.  Qtel appears to be working (although I’m battling some funnies with the sound device on the Apple MacBook)… just a matter of fixing some issues with the build system for svxlink and I should be able to have svxlink back in the tree once again.

If you live in Australia, do not purchase or operate this headset.

This is what the offending article looks like:This headset radiates a carrier on the 2m amateur band.  Specifically around 147.000MHz.  In some parts of the world, the 2m amateur band extends from 144.000MHz to 146.000MHz.  Here in Australia however, it goes all the way up to 148MHz, meaning these headsets are effectively pirate stations smack bang in the middle of the FM portion of the 2m band.  They are probably quite legal in the country where they were originally sold, but they are not legal here.

There are a lot of repeaters that operate around 147MHz, particularly in Brisbane.  VK4RBN at Mt. Glorious is one of the most heavily used repeaters in Brisbane, and so you can guarantee there are people listening on that frequency that will hear your transmissions, and will likely complain.  We’re also getting good at direction finding.

So far the importers have gotten little more than a slap over the wrist for the illegal C-tick approval of these devices.  I think the ACMA need to grow some teeth here if we expect to get on top of this problem.  The last offenders were lucky, they got the choice of stopping the use of the headset, or copping a $400 fine … the article was not confiscated.  The importers got a $1500 fine… nowhere near enough, and the devices continue to be sold by distributors.

The end user may not have been technical enough to understand what was going on, but the importers almost certainly should have if they were slapping C-ticks on equipment.

More information:

Well, after 9 years of solid service, the Nokia 3310 I’ve been using finally bit the dust this weekend.  And so now I’m getting my wish list together for what I’m looking for in a new device.

One thing that gives me the irrits is companies trying to tell you the customer, what one wants.

The phone I had, was bought outright (I think for something like AU$350).  It replaced an older Ericsson A1018S which had been bought a few years earlier on a pre-paid service… that phone sat in its box unused and the prepaid service expired.  When I came to use it, we bought a new ~AU$10/month service through Telstra… and I’ve been pretty much plodding along with that.

My needs are basic … I send the occasional text message, and make the odd phone call, but normally the phone will remain dormant.  I rarely go over $30/month on a phone bill.

One feature of the Nokia 3310 I thought initially was a gimmick, was the voice tags facility in the phone book.  With a hands-free kit plugged in, you pressed the answer button momentarily, then announced the names of one of the contacts in the phone book.  It would then try to match that to one of the voice tags, and on positive match, would dial that number.  This was invaluable on the bicycle, as it turned out.  I had the headset embedded in the helmet, with the PTT button on the handlebars for communicating via radio … the same rig plugged in the phone, the PTT became the answer button, and it meant that in order to dial a frequently used number, I didn’t have to take my hands off the handlebars at all.

Looks like I’ll have to learn to live without this feature.  The other thing was the older phone had a monochrome LCD screen … reflective type.  Much easier to read in broad daylight than today’s back-lit colour fancy affairs.  It was also less prone to damage than touch-screen devices.

One thorn though; the 3310 had no external antenna jack.  If you were in a bad spot, tough luck.  And there have been times I have been in such locations.  If you can plug in an external antenna, you can either get a higher gain antenna/directional antenna, or put a low-gain antenna up high, and get better performance.  A dipole may not offer much gain, but it should do considerably better than the minimal thing built into the handset, and of course it will do much better up high where the handset can only be as high as the user’s head (or their hand, if using a headset).

Now that the phone has died, I’m in the market for a new one.  The phone I am using for now is a ZTE T7.  Not overly bad, I suppose it’s taking a bit of getting used to.

Something I’d like to investigate is the possibility of being able to develop applications for these more modern phones.  While I traditionally criticised the more modern phones with all the bells and whistles, I recognise this is where industry is moving.

I don’t care for a camera on a phone.  The GPS devices on some of them are pretty minimal in functionality and are inconvenient to use – at least the T7′s one is.  The T7 GPS will only give you latitude and longitude, maybe altitude and speed, and has no track-log ability, and certainly no maps or navigation.  Plus you can’t refer to it while on a call.

I can make up for some shortcomings in a phone if I can code applications to run on it.  With the modern smartphones, this is a possibility that didn’t exist back in 2002 when we bought the 3310.  These days, iOS, Android, Windows Phone, Maemo and the like are all the rage.  The T7 appears to have Java on it, probably J2ME… I’ll have to research this. (Update: it does… MIDP 2.0)

For me to make use of the features, I’d really need to be able to develop the applications using the (mostly Linux-based) tools I have, or can get easily.  Microsoft Visual Studio is something like AU$1000, and I really disliked WinCE 5.0 so there goes Windows Phone.  Apple iOS has all sorts of strings attached to it, and while the development kit is only $5 (if you can pay)… it’s a 4.5GB download!  No thank-you.

Android and Maemo however are quite viable for my needs.

However, the key thing for me, having a phone that can work in regional areas, and can be enhanced with an external antenna, is more important to me, than having all the software bells and whistles.  When I look at what’s on the market today, it seems one cannot purchase a ruggedised Android-based phone, which features an external antenna jack.  In fact, so far the only devices I know of available to me, look to be a small subset of the ZTE range, or one (non-Android) Samsung phone.

Pathetic.

And no, don’t even bother mentioning capacitive/inductive coupling cradles… the 6dB gain I might get from a decent antenna will be lost in the very lossy coupling.  They are a very poor workaround, they are not a solution.

As an open-source enthusiast, something which at least respects this would be in my favour.  If I can adapt what’s there to suit my needs, this makes life easier.  Calendaring, for instance, I can code up something on my web server to share a calendar with my device.  If I can make my own software, it can use any protocol I like… otherwise I have to work within its confines.  Okay, I can live with that, but only if I am told what those confines are.  If I have a specification of the synchronisation protocol used between device and phone, I can possibly do something to scratch my own itch (and possibly others’), but if it’s all in secret, I am powerless to do anything.

It seems the assumption on the part of the mobile phone manufacturers as a whole, is that if you live or work out in a regional area (or even if you only travel out there on rare occasions), you’re obviously too stupid to care.  This assumption I greatly object to.  The assumption that, because you’re a dumb user, you only know of a two-OS IT world, where anything that isn’t plastered with Windows logos, must obviously be emblazoned with a piece of fruit that has a chunk missing from it.

Wrong.

I’m still continuing to look around.  Needless to say, I’m getting pretty disgusted by the lack of choice out there.

My Nokia 3310 died recently, and so I’ve been borrowing my father’s old ZTE T7 mobile phone.  This has had one useful side-effect in that I was able to back-up the contents of my SIM card, namely, the phonebook.

JoinME for MacOS X is quite capable of loading the data from the phone and storing it on the computer, but there is one problem… where did it go?

Turns out, after a quick fiddle with Instruments.app (part of the Xcode suite) I found them under /System/Library/MobileList/phoneBook.plist.  They’re in the standard Mac OS X plist file format, which is an XML derivative.  I have now backed this file up into a place where I know where to find it and can free up some much needed space on the SIM. :-)

Ohh, and to ZTE: You know fellas, it’d be nice if you didn’t keep trying to hide our data on us!  The phone book on my SIM card is not your intellectual property.

  1. The BP servo on the way to Donnybrook is bad when it comes to caravans… the one heading back to Brisbane is even worse.
  2. Horses have an aversion to orange and red coloured clothing (pity the organisers handed out red caps and orange shirts… also good thing we’re not the SES).
  3. Do not shine a torch in the eyes of a horse, especially not a 3W LED torch!
  4. Be prepared for organisers to give you information at the last possible minute, and not consider the needs of the radio communications people.
  5. Sometimes a short-cut, isn’t.