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.

This isn’t an isolated case… my mother who works at the Brisbane International airport, often complains about the radio etiquette of her fellow colleagues. A lot of people have a radio thrust into their hands, and haven’t a clue how to use them. In trying to figure it out, they often fall trap to the same bad habits.

I myself have found a lot of this by mistake, and by observing others. A lot of this is also applicable to using regular telephones … I found the tip of standing still when talking helpful when I needed to make a call to emergency services on my mobile phone — the particular spot where I was at the time, the phone would drop out if I moved more than 6 inches in any direction. Learning not to talk too close, or too loudly into a microphone, also helps.

The following is a little chart I came up with. No, the stick figures are not XKCD grade, they’re not meant to be. Click on the image below for a copy as a PDF, or get the SVG source here.  File is provided in the public domain, but attribution would be appreciated.  If you use radios in your workplace, and observe this kind of behaviour in your colleagues, you might like to print this out and stick it on a wall somewhere.

The headlight still continues to give me grief.  An interesting discovery though this evening.  Since the battery is no good, I’ve permanently mounted it to the bicycle frame.  This was achieved by removing the plastic bracket which is used to mount the headlight on the handlebars or on the helmet mount (using a rubber O-ring), and replacing this with a bracket bent out of a short piece of aluminium.  It fastens to the bicycle frame at the front right above the front wheel, using a bolt hole normally used for mounting rim brakes (my bike has disc brakes).

The upshot is that the headlight’s casing has a pretty good electrical connection to the bicycle frame.  Turns out this is a big no no with these lights.  Kiss goodbye HF if you do… you’ll get crap everywhere from 400kHz right up into the VHF.  I’ll have to do some further investigation, but I found that if I insulated the case from the frame, it helped on the 400kHz and HF emissions.  I think something parasitic is causing the 2m grief as this continues (that, or it’s less critical on the case being earthed).

For a while I thought it might’ve been something lurking around 415kHz… the standard IF frequency of most superhetrodyne receivers, but alas, can’t see anything there.  Otherwise it’d explain why it appears to be everywhere.  I definitely suspect it’s not supposed to be oscillating there though, so I think parasitic oscillations are the cause here.  I’m slowly researching my own power supply for the LED in this headlamp, so its days are numbered.

The insulation was achieved by breaking a cheap plastic picnic knife, drilling a couple of mounting holes, and mounting the headlight on that.  That quelled the HF interference quite a bit, and I was able to listen to the HF bands on my way into Brisbane.  At least it was nice to listen to something other than that sodding wedding in the UK.  (C’mon fellas, yes, great and all but can’t we just confine it to one station?)

I was concerned about the longevity of this arrangement however.  And as it turned out, I was right to be concerned.  It broke as I approached the Normanby Fiveways.  I went over a bump, heard a crack, and noticed the headlight dangling by the power lead.  I pulled over, threw it in the basket and grabbed the backup headlight.  At least there was one on the helmet, a 1W LED, so I still complied with local laws for night riding.  I didn’t have a mounting for the backup light, I just pointed it forward sitting in the bottom of the front basket, with it on flash as a warning to drivers.

Once at the destination, I reverted the headlight back to being directly mounted on the bicycle frame.  Interference was intermittent, but when it was acting up, it did wipe out 80m with S6 noise.  Not good when most stations are barely making S6 as it is.  I wound up turning off the main headlamp as for the most part I could see where I was going, and I knew the route.  As I got out of town this was less of an issue due to the lack of traffic, and of course I was on bicycle paths or the footpath for 90% of it.  That at least allowed me to hear what was going on with the net.

The other flaw I had was that the helmet’s speaker connections were acting up… wound up unplugging the earpiece side of the headset adaptor and using the internal speaker.  Thankfully I could still use the helmet’s microphone and the rest of the wiring harness… just not the speakers in the helmet.  I noticed this as I pulled out of my street, in fact I was aware there was a problem, but now I know where the problem is now.  I’ll get onto it tomorrow.  And I’ll look at a better way to mount this headlamp in an insulated fashion as an interim solution to a power supply replacement.

It’s an interesting comparison between radios and mobile phones.  And some are of the belief that all you do with a radio, is talk on it, or that mobile phones can completely replace radios.  Rather than respond there, I’ve decided there’s enough content there for a completely separate post.  I have highlighted my main arguments here for those who just want to quickly skim through.

Indeed, mobile phones do exist, and they are very handy things.  They do generally come with some sort of hands-free capability.  This is true of my Nokia 3310 … the connectors are available from JayCar, and the headset schematic is trivial.  This is not true of all mobile phones unfortunately.  Much the same is true of my radios, the FT-897D takes a standard RJ45 connector for the microphone, the FT-290R II takes a more obscure 8-pin “Foster” connector, but even they can be sourced if you look around.

RFI is a worse problem for mobile phones however, GSM seems to have a happy knack of being able to inject itself into almost anything unless you’re careful with your circuit design.

It’s worth considering what the primary point of the exercise is however, and how radio and mobile phones differ.

Mobile phones are great if you want to call someone specific. They are highly optimised for one-to-one conversations.  In fact, it’s highly expensive to do anything else.  Conference calls are a rare thing and you pay through the nose for the privilege.  Mobile phone charges are high enough already — I would not like to be paying for the cost of a one hour conference call twice daily on my way from/to work.

To contrast the fees, it costs me $20/month for a mobile phone service through Telstra (excluding calls).  I rarely see a phone bill above $30, but I’d probably see that climb to triple digits if I used it in the manner I use my radio.  The radio license costs me $65/year, regardless of whether I leave my station packed-up and inoperable, or whether I’m using it all 31557600 seconds of the year.

When I was riding frequently however, I regularly participated in discussions on my commutes.  It does make the ride more enjoyable when you can have a friendly chat on the way in.  The beauty of radio though is that you don’t all have to be in close enough proximity to hear each other baseband.

Radios are well suited to group discussions, since radio is an inherently shared medium. At most a repeater site which can relay the traffic between stations is all that is necessary.  I’ve also had quite successful simplex contacts on the 2m band over 50km, and overseas on the 40m band.  Mobile phones only achieve coverage over a few kilometres line-of-sight, coverage is extended by cellular towers which perform a similar function to repeaters.

If you’re in a discussion on the radio, good operating practice states that you leave a gap between transmissions so that other stations may break in if needed.  The breaking station may be someone wanting to get in touch with one of the other operators on frequency, may be an interested party, or could even be a person in distress.

It’s relatively simple for someone to jump in on a conversation.  Mobile phones however, prohibit this unless, once again, you pay severely for the privilege.  How often have you been in a situation where you’ve been trying to chase a caller off the phone so that the line is free for that important call you’ve been waiting for?  Not such a problem with radio.

Mobile phones give you a certain degree of privacy in communications.  Encryption standards vary between mobile phone standards, but all of them (except AMPS, which is now extinct) provide some means of privacy.  Radios generally don’t unless you pay through the nose for a set and a suitable license.  Encryption is also forbidden on amateur bands.

Both allow a certain amount of experimentation.  If you have a mobile phone that provides an antenna socket, it is theoretically possible to construct your own antennas.  You are not however able to alter the transmission mode or frequency of operation, nor are you able to construct your own mobile phone (homebrewing) without significant expense, as the device you construct must be tested and approved by local authorities before you may connect it to a network.  (In Australia, the body responsible is the ACMA, and the approval you need comes in the form of a “regulatory compliance mark”, formerly “A-tick”.)

You can however readily experiment with software running on top of modern smartphones, if you phone is that new.  (Mine isn’t)  Or, if you have a >= 3G capable phone (again, mine isn’t), you can hook a small computer up and use standard VoIP software.

Radios on the other hand, if your license permits it (mine does), can be completely constructed from scratch.  You choose the frequency and mode, there are boundaries where you cannot go, but there’s still a hell of a lot of freedom that mobile phones do not provide.  All amateur transceivers have socketed antennas, allowing experimentation with other antenna types.  Multi-band sets permit experimentation with different frequency bands, all of which differ in their properties.  Transmission modes include pretty much all analogue modes, and in most license classes, many forms of digital communication.

Mobile phones typically are fairly easy to use (there are people however that never seem to get it however), while radios almost always require a certain level of training.  Amateur radio requires you to sit two or three separate exams (usually two written exams for theory and regulations, and a practical test).

Some might ask why I use such an old mobile phone?  Well, you’ll notice the FT-290R II isn’t a spring chicken either.  I use stuff because they do the job.  The old Nokia 3310 has been solid and reliable.  There’s minimal “fluff” to cause problems.  Someone dials my number, it rings.  I dial a number, it calls that person.  Text messages, easy.  My needs don’t require anything more sophisticated.  Don’t unnecessarily complicate, I say.  When I’m out and about, this means I’m contactable two ways … primarily by radio, but if the phone rings, I can pull over and plug the phone in instead to take the call.

In my situation on a bicycle, it is also paramount that I do not have my hands tied up manipulating radio/phone controls. My solution was to wire up a small keypad which provides push-to-talk and four directional buttons.  On the mobile phone, the PTT becomes my answer button, and I can dial a person by momentarily pressing the button, waiting for the prompt, and announcing the “voice tag” of the person in the phone book.  The phone then rings that person automatically.

On the radio, I mainly use memory channels, so I’m moving up and down the memory channels.  Usually I just switch to a given frequency, and stay there.  When I want to talk, I press the button down — or, more recently I added a switch which is equivalent to “holding the button”.  So I just flick the switch to go to transmit, and flick it back again.  In the meantime, I’m able to use my hands for operating the bicycle.

Contrast this with trying to juggle a netbook computer running a VoIP package such as Skype.  It’d be a nightmare, those user interfaces are not designed for mobile operation. They’re simply not appropriate.  SIP-based VoIP is better in some ways as you can code your own application, but even then, you’re at the mercy of the mobile phone carrier’s network.  VoIP is very sensitive to NAT and dynamic IP addresses, and I think operating mobile in this manner would be a bit much to expect.  Skype also cannot handle a group as large as radio can.  (SIP can handle over 200 participants in a conference, limited by server bandwidth.  On the radio, I’ve regularly participated in nets with more than 10 people on air at a time.  Skype is limited to 5 IIRC, or maybe you pay for more.)

Amateur radio is largely infrastructure independent. On the bicycle I can get around obstacles that would be impassable in a car.  Wtih high capacity batteries, and a reasonable power set on a high mountain top, I can achieve significant simplex range, thus allowing me to relay traffic over great distances, without any requirement for intermediate infrastructure.

“Ohh, I’ll just use the phone for that” you say.  Yeah, right.  Try that in the Lockyer Valley just now.  Many of the mobile phone towers went for a swim, as did the exchanges.  Areas around Grantham are without any forms of mobile or land-line based telephony.  And of course, no Internet.  The same situation was the case for people caught up in the Black Saturday bushfires down in Victoria.  I’d imagine communications are under very heavy strain in Christchurch at the moment.

Mark Pesce made a very valid point in his LCA2011 keynote, communications can also be disrupted for political reasons, such as what has happened in Egypt and Lybia.  What do you do then?  Radio’s not perfect, but it sure beats being left without a means to let people know you’re okay.  With mobile phones, you are dependent on others to bring online infrastructure, before you can make a call from your phone to the other.  (Unless you experiment with something like the Serval Batphone, which has its limitations.)

So one does not completely replace the other.  They are complementary. The theory requirement keeps a lot of people away from amateur radio, however I’m happy to report I’ve never received a telemarketing call on the radio.   More to the point, there is more to amateur radio than just talking to people, just like there’s more to the police force than just arresting people.

As for me, radio has fascinated me for a long time.  I first became interested in radio from a very young age, but I particularly got into it after studying how it worked at university.  This is what lead me on to amateur radio.  So for me, it’s as much technical as it is social.  I enjoy meeting up and talking with people, but I also enjoy the experimental aspect of it.

At the moment, a large amount of my energy is going into bicycle mobile operation, particularly with regards to HF communications.  This does necessitate big antennas.  Antenna installations are always a trade-off between physical size, efficiency and band-width, and it can be a real challenge to get things working, but it’s rewarding when it pays off.

Some would argue: “Why bother? Just use a mobile phone.”  That’s like asking a car enthusiast, “why muck around under the bonnet when you can take your car to the garage down the road?”  Or to the avid gardener, “Why bother growing your own veges, there’s a greengrocer in the shopping centre?”.  Yes, they do exist.

I also would like to point out that the commercial world has gained lots from home experimenters.  You use a NAT router for your home Internet connection?  What’s the OS it runs?  Many run Linux.  Did we get Linux from a big commercial organisation originally?  No, it came from an avid homebrewer of operating system kernels, and was never intended to be “big and professional like gnu”.  Did we get Single Sideband from the commercial world?  No, it was an Amateur Radio inspired invention.  Likewise with a lot of high frequency design techniques that are in mobile phones today.  Heck, in the future we’ll probably be adding Codec2 to that list.

The world needs amateurs of all persuasions.  For this reason, declaring something “obsolete” just because you can do the subset of things you do with another more contemporary technology, is a short-sighted way of viewing things.  The amateur world benefits from the professional world, and vice versa.  It’s often the case that someone who works in a particular industry for a living, goes home then hacks on various projects related to that industry for fun in his/her spare time.

So, “why not just use a mobile phone”?  Because I find radio fun, I enjoy it, and I hope that some day, what I learn can be shared and applied in a professional setting to improve technology as a whole.  After all, isn’t having fun what the world is all about?

For the technically minded, I do apologise if it seems a bit dumbed down, but not all the target audience are computer-savvy.

At the recently held linux.conf.au conference in Brisbane, Google Vice President Dr. Vinton Cerf, and APNIC Chief Scientist Geoff Huston both gave talks covering this very issue.  For those who want an in-depth overview of the problem, I recommend viewing both these videos:

• LCA2011 Keynote: Dr Vinton Cerf
• LCA2011 Keynote: Geoff Huston

Back in 1973 when the beginnings of what became IPv4 was being conceived, it was decided that an address space of 2³² addresses (or 32-bits, about 4 billion) would be sufficient for what was considered, back then, an experiment.  The “Internet” (then known as ARPAnet) barely spanned 5 computers.  Computers occupied rooms and were not portable, nor was there any significant wireless telephony infrastructure at the time.  The problem is, the experiment never ended, and now IPv4 in this modern age of handheld computers and wireless Internet, is being pushed to its absolute limits.

Most people are familiar with using a telephone.  You need to know the number of the person you want to want to contact (or the phone number for directory assistance and quoting a name).  Only then can you place the call, and get in touch.  Now unlike a telephone network, where the call is established and a bi-directional connection exists for the duration of the contact, on the Internet, its more like dialling a voice mail service and leaving a message.  I need to leave that person my phone number so that they can get back in touch with me (or rather, leave a message in my voice mail box).

Extending the metaphor a bit, it is common for computers to have multiple connections going on at a time.  Servers also often run multiple services on the same system.  Thus, each system uses separate ports, akin to individual mailboxes.  Each computer has 65536 of them¹.  On the sending side, a free port is usually allocated at random and used for the duration of the connection.  At the server end, a fixed port is used to “listen” for incoming requests.  When sending data from one computer to another, the sender needs to tell the receiver which mailbox (or port) the data came from, and which it belongs in, so that data goes to the right place, and any replies can be correctly addressed.

The problem now, is that the address space on this global network is now in the hands of regional registries.  These regional centres look after the Internet services for a given geographic region.  Once those registries run out, it’s game over.  Internet service providers are forced into deciding between one of four actions:

1. Turning away new users (the infamous “No Vacancy” sign)
2. Implementing Carrier-wide Network Address Translators
3. Becoming a walled garden
4. Moving over to something new

I can see option 1 is not going to be popular, so I’m not even going to discuss it.

Option 2 is already happening in parts of Asia.  Rather than giving everyone a number that is recognised world-wide, they give you and fellow customers private ones.  They then employ an intermediate server, a Network Address Translator to re-write the addresses on the IP packets so that they appear to be sent from that server.  NATs of course are not just things that exist in ISPs, home internet routers often do exactly this.  Another example of NAT is Microsoft’s Internet Connection Sharing.

When a computer sitting behind the NAT wishes to contact a server outside, the NAT instead picks one of its ports, and places the outgoing message there.  It then replaces the source address and port with its publicly visible address, and the port number it chose, and forwards that on to the outside world.  When the reply comes back, it re-writes the destination on the reply to point to the original address and port number of the originating computer.

There isn’t a theoretical limit to the number of computers that can exist behind a NAT.  The limitation is the number of ports.  Ports may not be shared by two applications, if a program or service is already using a given port number, it is essentially unavailable for others until that program or service is finished.

That means that for any computer, there can be a maximum of 65536 connections at any one time.  NATs are not magical devices, and this limit applies to them too.  In this modern age of parallel computing, even web browsers will frequently launch multiple connections in parallel.  Some of these connections are short lived (such as the time taken to download the text off this page), some take a while (such as the time taken to download one of the keynote speeches linked to earlier).  The resource demand will change over time with user habits.

The first big problem with NATs though, comes when you have an application that needs to be contactable from the outside world.  The application for all intents and purposes is like a server, and is listening for connections.  The trouble is, this computer is behind a NAT, and its actual address is a private network address.  Even if an outside computer knew what it was, it wouldn’t know how to get there, and quite likely, wouldn’t be allowed even if it did.  So the only way to be contacted, is via this NAT box.

Now suppose you tell someone (or the application does on your behalf) your NAT box’s IP address, and the port number your application is listening on and an outsider tries to make contact.  The NAT box hears the request, but where does it send it?  It knows nothing about this port!  The NAT box has to be told to reserve one of its ports (which again must be unique), and to forward any packets sent there, to the right port on your computer.

The hardest bit here is that not all NAT devices work the same way in this regard, there is no de-jure standard for configuring a port-forward.  Microsoft UPNP is one of many de-facto standards that exist, and not all NAT devices or applications support it.  A lot of these also have lots of problems of their own.  In some cases, you have to set this up yourself.  Doable if the NAT device is under your control, but in the future we may be faced with NAT devices that are controlled by ISPs.

The applications that will be hardest hit by this will be any applications that rely on peer-to-peer communications.  This includes, amongst other things, the file-sharing services in instant messenger clients, peer-to-peer file sharing services such as Bit-Torrent, and Voice-over-Internet Protocol applications such as Skype and EchoLink.  IRLP, which relies on nodes having a static public IP address will be hit particularly hard, many ISPs already charge extra for the privilege of a static IP.

Hardware devices that use the Internet are not immune from this too — in fact the situation there may be made worse, since in a lot of cases, the port numbers used are hard coded in the device’s firmware.   You may ring up to get that special port forwarded, and already discover that another customer of the same ISP rang up 5 minutes ago and claimed it before you.

Ignoring these niggles, NATs don’t sound too bad if everyone is playing by the rules.  But what if someone decides to set up an Internet marketing company and starts filling up everyone’s email boxes with yet more “Discount Viagra” offers.  The way things are here in Australia, the ISP gives each customer a public IP address (which may be static, or it may change on a regular basis), and that is used as the public address on a NAT device owned by the customer.  If a customer were to do that, the IP address of that NAT device is visible in the emails sent — an ISP can simply look up who had that IP address at that time, and can immediately take action.

Now, suppose that instead, the ISP relied on NAT.  The IP address would be that of the ISP’s NAT box.  The culprit could be any one of the many users sitting behind it.  “Jjust log each connection on the NAT box” you say.  Deary me, could you imagine how slow that would be?  Not to mention the disk space used!

Now what happened if at the same time, other users were legitimately sending emails to that same network?  The logs point to a dozen users, which one was it?  If the complainant told you the source port used in the connection when the email was sent, maybe you can look that up, but I’m yet to see that sort of information recorded in system logs, email headers certainly don’t have them.

Clearly, this is not a solution.  It’ll make address space stretch a little further, but not without causing a world of pain for software developers who have to make their software compatible with differing standards, and causing the rest of us grief as we drown in a mountain of malware and spam.  If you think spam today is bad, you ain’t seen nothin’ yet!

The other way ISPs can go, is to close off from the world, and becoming a walled garden.  That is, you need to be a member of their network, to be in contact with other users that happen to also use their network.  Or if they provide connectivity to neighbours, it’s costly, and/or heavily controlled.  Anyone remember CompuServe, America Online, The Microsoft Network?  Ring any bells?  Those long-ago isolated bulletin board systems?  If they do, I apologise for stirring up bad memories.  If they don’t, count yourself lucky, and hope like hell ISPs don’t go back there!

I did say there was a fourth solution didn’t I?  Something new?  The Internet Engineering Task Force weren’t naïve enough to assume 32-bits would be enough.  They recognised that this would be a problem way back in the early 90′s.  They formed the Internet Protocol Next Generation working group, which in 1998 produced RFC2460:² Internet Protocol version 6.  IPv6 extends the address space to 128 bits, a big improvement on IPv4.  It also addresses a number of other bug-bears that people had with IPv4.

Some notable ones include: Mobile IPv6 extensions to allow a portable computer (such as a smart phone) to remain contactable at the same address as it roams between multiple networks, improved quality-of-service handling for real-time streaming and multimedia, automatic addressing and simplified headers to make routing easier.

The biggest feature though is the address space.  NAT is not implemented in IPv6, it is not necessary as there’s enough space to move around.  Rather than being given a single IPv4 address which you must share with all your computers, in IPv6, you get given a whole network address prefix.  Typically this prefix is 64-bits long, leaving you the remaining 64-bits of space to allocate to each of your computers.  How many addresses is that?  Remember the 4-billion (approximate) number I quoted for IPv4?  Square it!  If you have a computer network bigger than that, I do not want to see your power bill!

Modern computer operating systems can function on IPv6 already.  Microsoft Windows XP includes support, which can be enabled by following a few easy steps.  Windows Vista and 7 come with it enabled out-of-the-box, as do Mac OS X, Linux and the BSDs (FreeBSD, OpenBSD, NetBSD, etc…).  Hardware devices can be made to support IPv6 by a simple firmware upgrade, if one is available.  If a manufacturer has not published a firmware upgrade for a device you own to support IPv6, contact them now!

ISPs world wide are dragging the chain on IPv6 take-up.  There are some notable exceptions, here in Australia for instance Internode offer native IPv6 for their customers.  I’m unaware of others in Australia.  If your ISP is one of the IPv4 sheep, it’s now time to contact your ISP and ask them what they are doing about IPv6.  In the meantime, you can get an IPv6-in-4 tunnel from a tunnel broker such as AARnet, Hurricane Electric or Sixxs.

Many online services are slowly making the move over to IPv6.  Google can be accessed via ipv6.google.com for instance.  This blog is accessible via IPv6 (thanks to AARnet).  Sixxs have a big list of sites that are IPv6 enabled.  In June (the 8th to be exact) this year, there will be a world-wide test of IPv6.  Google (as in their entire site), FaceBook and Microsoft’s Bing search engine among many other sites will be going IPv6-enabled on World IPv6 day.  If you’re not already on IPv6, it’d be great if you could join us.

Openness is one of the things that made the Internet popular.   There is a very real threat that this openness or freedom we currently experience will be lost.  If you’re a software developer, we need you to ensure your software works with IPv6 for it to keep working into the future.  If you’re a network administrator, you need to ensure your network is IPv6 compatible.  If you’re a consumer, we need you to start pestering the help desks of these software companies, device manufacturers and ISPs to ensure the commercial world sees the user demand for this!

To quote Mark Pesce, “a resource shared is a resource squared”.  We need to ensure the Internet remains open and free, for all people into the future.

2. RFC = Request for comment

With addressing in IPv6, there’s enough addresses to cover every square metre of the earth’s surface with something like 100 addresses or so.  Not sure if a standard exists for mapping geographic co-ordinates to addresses, but one just occurred to me that I might try some day.

The Maidenhead locator system divides the world up into a series of squares.  At its coarsest level, it divides into zones which are each 10? latitude and 20? longitude.  There form a 18×18 grid, and are usually denoted by a letter.

Wikipedia: The world is divided into 324 (18²) Maidenhead fields.

These are divided further into grid squares, measuring 1? × 2? in size.  They form a 10×10 grid, and are usually addressed by a number…

Wikipedia: Fields are divided into 100 squares each.

Within this, there are subsquares, representing 2.5′×5′ (that’s minutes, not feet) forming a 24×24 grid, addressed again by letter.  The grid square where I’m located, QG62LN represents an area that covers the suburbs of The Gap, the southwest bit of Enoggera, the northwest bit of Bardon, and the western end of Ashgrove.

Suppose we were to encode this maidenhead locator into the address.  It’s probably less useful in traditional IP networks, but maybe it will have a use.  In Amateur Radio it may be useful for the purpose of routing between mobile stations.  In fact, it’s this mobile context where I see it being most useful.  Lets first consider how many bits we’d need to store each component:

• Zone level, 18×18 grid: 5 bits for latitude, 5 bits for longitude, or alternatively for 324 zones, 9 bits.
• Square level, 10×10 grid: 4 bits for latitude, 4 bits for longitude, or alternatively for 100 squares, 7 bits.
• Subsquare level, 24×24 grid: 5 bits for latitude, 5 bits for longitude or alternatively for 576 subsquares, 10 bits.

Logically you’d be using numbers starting at zero for the addresses in all fields, so A would be translated to 0, etc.  My QTH locator (QG62LN) would be translated as follows: Q?16, G?6, 6?6, 2?2, L?11, N?13.

You can either address latitude and longitude individually, packing them as separate fields, or you can lump them together to possibly save one bit of space.  For instance, I can concatenate the two 5-bit values representing the zone QG into a 10-bit value: 10,0000,0110? = 0x206. Or I can save some space by realising there are only 324 zones which can be represented with 9 bits like so: ((16×18) + 6) = zone 294 ? 1,0010,0110? = 0x126. The grid square can be similarly encoded (0110,0010? = 0x62 or 011,1110? = 0x3e), and likewise the subsquare.

How would you pack these into an IP address? I was thinking something along one of these two:

   Zone      Square   Subsquare
 Lat   Lng   La   Ln   Lat   Lng
.---. .---. .--. .--. .---. .---.
10000 00110 0110 0010 01011 01101 = 28 bits

  Zone    Square  Subsquare
.-------. .-----. .--------.
100100110 0111110 0100010101      = 26 bits

Presumably these would form the lower 28 or 26 bits of your prefix.

I’ve been toying with the idea of a small multicast VoIP/digital comms protocol for use over wireless radio links. The typical use case might be to replace UHF FM radio transceivers with modern smart phones, using multicast IPv6 networking over 802.11b. (It will have other modes too, transmission over amateur radio bands for instance.)

In some commercial settings, or over the Internet, it’d be great for traffic to be authenticated using HMAC-SHA1 or even encrypted. Looking at IPsec, I see it provides exactly this. My thought, why re-invent the
wheel when a solution may already exist?

The question though: Is it possible for a userspace application (non-privileged) to request that the UDP packets it generates/receives from/to a particular address be encrypted or hashed against a specified key?

i.e. if I decide to communicate with someone on the same wireless link, and by means of asymmetric crypto at higher layers we establish a shared AES key, can I configure the stack for traffic between these two hosts
on-the-fly and without root privileges?

The remote face would then be mounted on the front of the bicycle, and connect to the radio at the rear to allow easy bicycle mobile operation.  An extension of this would be control of a separate 2m radio, and a GPS to allow APRS from the bicycle.

The idea was to have the memory work like a relational database.  Rather than just recalling memory channels, and having a big long list, I could scroll through the repeaters by callsign, location (service area), or combined with GPS, proximity.  Modern flash technology would make this easily doable.

Likewise, for DTMF, rather than having to carry around a cheat sheet or remember IRLP node numbers, wouldn’t it be nice to just be able to scroll through a node list by country/region/callsign, select one, hit the “Call” button, put your callsign across and have it automatically dial the moment you raised the PTT?

I don’t have the ability to manufacture PCBs of the standard required for ICs such as most 32-bit microcontrollers.  SOIC is about as fine as I can muster, and prototyping services are expensive.  Thus I was looking for a stamp module or premade board.

Luminary Micro (now TI) make a few nice ones, and during my work at Laidley, I got to use the LM3S8962 Ethernet/CAN evaluation board.  One nice feature was that it had the JTAG built-in via a FTDI USB-serial chip.  However, the licensing for the board support package irks me — despite their code being useless on anything other than one of their chips, they still see it necessary to modify the BSD license adding a clause that prohibits its use on non-TI microcontrollers.  I had a crack at writing my own “free-software” Stellaris library, but haven’t gotten that far with it.

I happened to stumble on this board based around the STM32F103VET.  They were being sold on eBay for about $60 at the time, so I decided at that price I’d buy three.  ST’s driver library appears to be very liberal in its licensing (in fact they claim there is “no license”, I don’t know if this means “public domain”, or whether I treat it like BSD).

The LCD panel uses the Ilitek ILI9320 display controller with internal graphics RAM, and is capable of 18-bit colour.  The board also features a RTC backup battery, Texas Instruments TSC2046 touchscreen controller and on-board RS232 level converter.  The STM32 also functions as a USB peripheral, and can be programmed using the stm32loader bootloader script via RS232.

Interestingly, the LCD controller documentation states that no part of that documentation may be reproduced without written permission.  I’m not sure if writing an open-source driver classes as “reproducing” the documentation (as I’d be making documented #define statements in C).

The devices come with example source and have a pre-loaded µC-GUI demonstration on them.  So far I’ve managed to distill enough out of these sources to get working touchscreen, LCD and UART.  I’ll probably start looking at FreeRTOS next and seeing if I can get a workable device going.

STM32F103 board running a simple "Hello World" app

Hello world application for STM32

Guess now I had better start planning my application.

So far I’ve stuck with 13.8V 9Ah gel cell batteries. These are far from ideal, but are pretty good for the price. They are lighter and cheaper than an equivalent capacity NiMH or NiCd pack, however one downside is that they do not take too kindly to deep cycling.

When I first started my work at Jacques Electronics, I found one battery would get me there and home again, with capacity to spare. I’d have one at home charging, and the other on the bike.

This was with plenty of activity on the 2m band, transmitting full power on the FT-290R II. Given this radio has a 25W linear amplifier, this represents an approximate 4A load when I went to transmit.

Towards the end of my time there, I noticed the capacity had been significantly reduced. A combination of road vibration and deep cycling had reduced the capacity to the point that I now need to take two batteries with me.

So once again, I’m looking around. They seem to go for about 6 months before they start to fail… and we’ve already got a big collection of dead gel cell batteries ready for recycling… something has to change.

Lithium Iron Phosphate (LiFePO₄) is what I’m looking at. Now, there’s a choice… do I go for pre-made packs? Or do I homebrew my own out of cells?

For the latter to be an option, I must consider how I’ll balance them properly. These cells are expensive and not very forgiving (although they’re better than Lithium-Cobalt or Lithium-Ion Polymer cells). What follows is some thoughts on how to construct such a battery management system… which could be completely wrong… so don’t take this as gospel.

The mission

To construct a battery pack to replace the 13.8V 9Ah gel cell packs, using Lithium Iron Phosphate technology. The battery may develop a maximum voltage potential of 15V DC, and must provide at least 9Ah effective storage capacity.

Cell count dimensioning

Looking around, the literature I can find suggests the typical LiFePO₄ cells have an operating voltage between 3.2 and 3.6V. Therefore, to obtain 13.8V, I’d need four of them in series… producing 12.8V to 14.4V.

The cells themselves come in various capacities… some I can get easily are K2 Energy 26650EV cells. These pack about 3.2Ah per cell… EVWorks sell them for under AU$8 when you buy 10 or more. If I’m to use those, I’d need 3 cells in parallel to give me approximately 9.6Ah.

Total number of cells: 12, at $7.15 a cell: AU$85.80 for a 4S3P pack.

“Ideal” cell balancing

Now, the best way I can think of to balance these things, is to do it on the individual cell level. To maintain maximum life of an individual cell, one must ensure that when charging, the cell voltage does not exceed 4.2V. When discharging, the cell voltage must not fall below 3V.

There are also factors such as current flow, cell temperature and age. However, for simplicity’s sake, we’ll consider only the voltage for now.

Given these restrictions, it would seem wise to break apart these two actions, and consider them separately.

Charging

The desirable feature when charging an individual cell, is that the cell voltage itself is prevented from exceeding 4.2V. This is of great importance with some Lithium type batteries, as the cells can explode.

My first instinct is to look at zener avalanche breakdown in diodes. A zener diode in reverse bias will continue to reject current flowing through it until such time as the avalanche voltage is exceeded. Then it begins to conduct, and the voltage drop across it will always be equal to the avalanche voltage… given sufficient series resistance.

This sounds like the sort of behaviour we’re after. So the input circuit becomes something like this:

Therefore we look for a zener that has the avalanche voltage close to (but below) the 4.2V needed. Bad news is, there isn’t a 4.2V zener, we can go 3.9V… a little too low, or 4.3V, a little too high.

By adding an otherwise gratuitous 1N4004 diode between zener and battery, we can utilise a 5.1V 1N4733. Due to the forward voltage drop of the 1N4004, the battery will only see voltages up to 4.0V despite the higher zener voltage.  When the battery is below this voltage, it will charge with a current decided by R_lim.

This circuit certainly won’t fast-charge a big pack… but in my case, an overnight charge is quite acceptable. The individual V_charge+ and V_charge- are wired in series to charge all the cells from a higher voltage supply, and the strings themselves may be wired in parallel.

Discharging

All good and well, but what’s the point of stuffing a battery with charge if you’re not going to take the charge out at some point? The other side of the equation is discharging.

The magic number to beware of, is 3.0V… drop below that, and the cells will be irreversibly damaged. The same tool, the zener, can be used to detect when the battery is low. One trick we can do is to swap the zener with the resistor normally placed in series with it. The zener will still have its avalanche voltage across it, the resistor’s voltage now indicates the state of the battery.

If we pass this through a NPN transistor, we wind up with negated output that can directly drive two MOSFETs. One MOSFET will permit the current to flow only when the cell voltage is above the zener avalanche voltage. The other, will shunt current past the cell when the voltage of the cell is too low.

All good… but the MOSFETs would want to be capable of delivering about 20A continuous for my needs. An IRF9540N could do it with a heatsink. That’s not so much a problem, but the cost is. Each MOSFET costs about $5 locally… so there’s $10 per cell, 12 cells… $120 just in MOSFETs… the BMS will cost more than the cells!

Reducing costs

The charging side is fine, however the discharging aspect of this system is going to be too pricey for my liking. So a re-think is needed.

The same current that would turn the NPN on, could instead turn on the LED in an optical isolator. An optical isolator incorporating a NPN transistor would then pull down on a resistor when the cell voltage is above the zener avalanche voltage.

In this circuit, when the battery voltage is high enough, the optical isolator is active, pulling the NPN’s base low and leaving V_nLow floating.  All modules’ V_nLow signals would be wired together, forming a wired OR with the open collectors.  When a cell gets below voltage, the LED turns off, causing the isolator to turn off and the NPN’s base to rise.  It then turns on, and pulls V_nLow down.

This signal with a suitable pull-up resistor can drive a NPN transistor for driving a P-channel MOSFET, so that when V_nLow gets pulled low, the load is disconnected and an alarm raised.

This BMS, while undoubtedly not as good as the previous option, would provide the low-voltage protection, and can be made for under $50. I’m curious to know how others’ have tackled the problem though. This is how I’m thinking of approaching it… I may just buy a premade pack instead.

There are many benefits for why free software firmware would be good… However, you’ve got to convince the marketeers and management of such companies that this is a good idea. This is not so simple. In extreme cases, you’ve also got to convince government… more on this later.

Take my current project at my workplace. We’re developing a new video intercom system. The devices are based on the Freescale i.MX27, and incorporate an 800×480 LCD, resistive touchscreen, USB port, ethernet (with PoE), mono internal speaker/microphone, handset interface and a small software-controlled relay. The audio interfaces are mono, but capable of sample rate up to 192kHz (limited to 96kHz by ALSA) and it wouldn’t be difficult to get stereo out of them. I wouldn’t mind buying one later on to play with at home … maybe one of the early ones with psychodelic colours (the first revisions didn’t have the LCD lines routed quite right) since we’ll want to sell the others. My role was with the audio CODEC, the TLV320AIC3204, some code for this is already on the ALSA-devel mailing list (the continued development of this driver is the mainly the reason why I want one for home).

They’re a fun little device to play with… and there may be some who might be interested in hacking such devices. They already run Linux… a few of them at my workplace run Gentoo even — mostly the test modules. However, the firmware for these, particularly at the higher levels will remain proprietary. I’ve released the CODEC driver as GPLed software … and ideally I’d like to see the rest of the kernel changes released openly. I’ll play this by ear first however. The good news is that if someone wanted to port Linux over from scratch, it’s real easy to get Linux booting on these things (tip: start with the Freescale MX27ADS support, I ported kernel 2.6.34 this way).

The CODEC driver I’m mostly happy with… the machine/fabric driver I use for ASoC on this thing however … let’s just say, it’s a hack. The CODEC’s clock is generated from a pin on the MCU, and so I have to use some rather “creative” methods to configure that clock and make it available to the CODEC. There’s no way it would be accepted into mainline… and we’ve since found that clock drifts the moment you look at the chip funny. Ahh well, live and learn.

There’s also a GPIO module that allows us to use the keypad controller (which is not routed via IOMUX AFAIK) as a GPIO chip… similarly, it was a monkey-see-monkey-do hack… but I might be able to make that more acceptable to upstream.

So there’s the issue that such code is considered a bit of an embarrasment to its author. (I don’t speak of other code on these things, just the parts I have written!)

Secondly, there’s the thorny issue of intellectual property. The firmware on these VoIP stations incorporate a proprietary protocol for VoIP. Why not go with SIP? Basically this protocol was designed to run on their earlier products… which were all based on small 8-bit microcontrollers. SIP was just too much for a ~40MHz 8-bit micro like the Rabbit 3000. Thus a simpler protocol was developed. I have no idea about the specifics, other than the fact that it was developed to suit the lower-end microcontrollers in use at the time. I think in future the newer units may wind up moving over to SIP, but for now, deadlines are on top of us, we’ll go with what we know works for now. Given how much of Jacques’ business relies on this protocol, I don’t see them opening it up to their competitors anytime soon.

Finally, there’s one of support. The modules we use were purchsed from Ka-Ro Electronics, and the kernel we use was supplied by them directly… based on kernel 2.6.28. To my knowledge, there’s no openly-available patches that allow a user to run the latest Linux kernels on the Ka-Ro modules — you more or less either have to forward port the patches that Ka-Ro provide, or try to hack up a patch of your own (this is what I did). Now, Ka-Ro clearly have their reasons for not openly releasing a patch for their hardware, I haven’t enquired as to why this is… I have a patch that gets their TX27 module working under kernel 2.6.34 (theoretically newer kernels too) but I’ll probably run it by Ka-Ro themselves before I release it.

Ka-Ro presumably will only provide support for the kernels and board-support packages that they provide, which is reasonable. They started with a known stable kernel, and started their development on that (it was a year old before they touched it), and released it knowing it would be reliable. Obviously they cannot provide the same guarantee to newer kernels… because they won’t necessarily know what might have changed — you could encounter severe bugs that were not their doing and thus, a lot of time and effort is spent trying to fix a problem that was not their doing. Similarly, at Jacques, we don’t have the resources to answer questions from inquisitive geeks wanting to turn the monitor station in their apartment into a music player or web server. At best, we’d be able to put some of it online, but we’d have to say “Sorry, can’t answer questions, you’ll just have to work it out yourself.”

In the Amateur Radio world… homebrewing, and home-modification of equipment is common. In fact, once upon a time, it was the only way to get on air unless you had a lot of money! Thankfully, one can now purchase a radio station for far less money than it would cost to design, build, and debug, and the build quality in general will be much higher. Of course if you do go the homebrew route, you’ll at least be wiser and richer for the experience.

The difficulty with homebrewing radios these days, is getting parts, and working with them. Back in the day, things were valves, and discrete components… maybe the odd DIP-packaged IC… and no more than double-layer PCBs. The two Yaesu FT-897Ds I have, incorporate multi-layer boards (4 I think) and SMD devices. One got cooked in a storm, frying the microphone preamp and a DDS chip (although the finals appear to be okay, and it makes a good shortwave receiver). The complexity of this radio made it impossible to repair, and so I had to buy a second one (or rather, insurance did). Now, I’m mostly very happy with this radio, but there are one or two niggles I have with regards to its interface… and a few features I’d like to implement.

Yaesu do provide a block diagram of their transceiver, but they don’t provide the code to the Hitachi H8300 microcontrollers that reside inside the unit… and there are several of them. Suppose I get the microphone circuitry fixed in the cooked one… I might be able to get FM functionality back. The DDS chip was responsible for the carrier sidetone generation with SSB, and for generating the carrier in AM and CW. It’s no longer manufactured… and the chances of a different chip being compatible with the existing firmware are next to zilch. I’ve still got it… I intend to build my own radio out of the bits that are left over (the Phoenix897 project) … it’ll be here that I’ll be able to explore the possibilities in terms of implemented features.

However, one challenge will be designing and producing PCBs that will be suitable for use with today’s devices. The construction methods of the past such as wire-wrap and dead-bug, work fine for discrete components, work okay for DIPs, SOICs, TSSOPs and QFPs… but I’m afraid you can forget it on a BGA or LCC. So you have to build a proper PCB, and the track work has to be very fine. Then there’s the actual fitting of components onto the board.

The boards I was building for the electric harvester project I was involved in at Laidley didn’t involve anything smaller than TSSOP ICs, or discrete SMD capacitors/resistors smaller than 0603 (most were 0805) … easily hand-soldered. At Jacques we’re dealing with components even smaller… they don’t get soldered by hand — instead they’re oven baked. It takes a few hours to lay out a board, and the slightest bump will scatter all those carefully placed components. The smaller components are not marked… with no means of identifying them, they get tossed. (And yes, I did accidentally bump some one Friday evening… not proud of that at all.) I can see me going through a lot of components because a PCB gets knocked for six.

So the modern components are much harder to work with. An ideal solution to my dillema would be a pre-built radio that I can customise the firmware on. Alas, the closest I’ll get to this, is SDR kits such as the Softrock… even they have to be supplied in “kit” form. FCC rules basically forbid manufacturers from producing off-the-shelf transceivers with customisable firmware… or at least that’s how I understand it. Not sure whether the EU works the same… and the ACMA’s EMC directives are more or less based on the FCC’s… so I suspect that’s the issue here.

More or less the worry is that you might hack the firmware to circumvent the bandplan restrictions that may exist in your area (i.e. modifying a transceiver to broadcast WFM on the 88-108MHz band for example). I’m not sure how this is different to homebrewing a set, or modifying a set yourself … but being able to just hack the firmware yourself is not something the various spectrum management organisations want us to do.

This is sad in a way… I think there would be a big market in having a radio that had completely opensource firmware.

One of my big niggles is that the transceiver I have won’t remember power limits by mode… I can do 100W PEP, but only 30W average, so for FM I find myself constantly winding the power back to 30W, but the moment I kick the radio into SSB, I’m winding back up to 100W. More than once I’ve accidentally called into a FM net on 2m using 50W because I had been using 2m SSB the previous night (my radio only does 50W on 2m)… or accidentally found myself transmitting 100W on a 10m FM repeater.

IRLP/Echolink functionality, and memory channel organisations are other improvements… remembering node numbers is a chore I could well do without… and I find there’s often not enough channels to cover all the repeaters in the country… or it’s difficult to organise them in a manner that allows quick retrieval. Modern storage, modern microcontrollers, I see no reason why this can’t be stuffed into a relational DB (something akin to SQLite) so that you just whistle up the repeater by location, callsign or frequency… and if it has IRLP or Echolink, be able to just choose a node, browsing by country/state or provence… put your callsign across then press a single button to dial it for you… then at the touch of a button, it dials “73″ for you to close the link. (or maybe after a fixed period of inactivity, it can put your ident across, wait 10 seconds, then dial “73″ for you).

My old TH-F7E could remember 10 DTMF code sequences and 400 channels, the memory channels just being sequentially accessed… so you really had to put careful thought into ordering or you were relying on cheat sheets to figure things out, in that case why even have the memory channels at all?

I’d also be nice if the set could do HF CB… I can receive it… I see no reason why the set can’t just automatically drop its power to the 12W and restrict its modes to USB/LSB and set the channel spacing accordingly as per the CBRS. I can make a radio with opensource firmware do that… then again, I could also make it do 100W on that same band, and violate the CBRS. One has to convince the government that we won’t try to do the latter (although there are plenty that already do).

All of the above I’ll probably look at implementing when I go and rebuild the old FT897D … and you can bet your bottom dollar I would have tackled some of them already had there been opensource firmware on these rigs. However, the red tape one would have to deal with in order to make such a radio available on the market, I can well understand why the firmware on these things is proprietary.

In a perfect world … if only such a utopia existed!