sstv

Hacking SSTV

Slow-scan television is a means of transmitting still images over HF radio. It has its origins in the 1950s, where operators would use a CRT monitor with a long-sustain phosphor in a darkened room to see the image, but modern implementations today use digital signal processing computer software on a conventional OS like Windows or Linux.

For the non-radio folk, you can think of it as a radio-flavoured facsimile service. A picture is taken, scanned (or created directly on the computer), the resulting image file is then encoded as a series of audio tones that are then transmitted over the air. The vast majority of standards out there use frequency modulation (FM) for the actual base-band signal sent to the radio, although there are some newer ones (like the Digital Radio Mondiale-based HamDRM, of which EasyPAL is probably its best known implementation) that use more advanced modulation techniques.

I would like the ability to send and receive SSTV on the bicycle. The Raspberry Pi 4 I have earmarked for the bike can do it, and I’ve been using it here with QSSTV to send and receive pictures as a home station. However, while this is a very capable client, being a desktop application, it is awkward to use on a headless Raspberry Pi. Best solution I’ve come up with is to use a VNC desktop, which is tedious.

I looked around for what else there was, and the answer was, not a lot. So I’d have to get my hands dirty.

Transmitting

Transmitting actually isn’t that difficult, there exist several CLI programs that will take an image file, and spit out an audio file (usually Microsoft RIFF .wav) that I can then play out the sound card. Not sure if they do the FSK ID at the end, but that’s not exactly difficult to figure out, and I can probably modify a tool to add it.

In my early experiments with SSTV, this is exactly how I sent some of my early transmissions. But I’d need to fire up an image editor to compose the image — it was cumbersome. However with the raster image already in-hand, it wasn’t too bad.

Keying the radio is done simply, I have two ways actually… one is to use the “Computer Aided Transceiver” port on my radio (Yaesu FT-897D in this case) to send PTT on/off commands. The other was via the GPIO pins on the Pi, which on the NWDR DRAWS board, are mapped to the appropriate pin on the data port. Both work, and are relatively straightforward.

So whilst there’s a few loose ends to tie up here, it seems that is largely handled.

Receiving

This was a big problem, and one I was stuck on for a while. Nearly everything I could find was a GUI application. I didn’t want to run a GUI for this, I wanted a CLI tool that sat in the background and did its thing, ideally launched at boot by systemd. I wanted a few things:

  • capture of metadata parameters into a separate file
  • periodic update of the partial image during reception
  • execute a script when something happens

I found one CLI receiver, there’s this one, but it assumes I have a recording of it already. I’d need something to spot the VIS header then start recording. QSSTV did nearly everything I wanted, but was a GUI application, couldn’t write out the metadata nor could it trigger a script. slowrx was the same.

I do note that the KiwiSDR seems to use slowrx in its decoder, and they’ve managed to solve this issue, so I took a closer look. With some work, I was able to split slowrx into two parts, a back-end I called libslowrx.a, and a front-end slowrx application. I then wrote a crude slowrxd application that ran on the CLI and used libgd to write image files (I did think of using libpng directly, but its API is fiddly to use). I started this a few days back and polished it off over the week-end. This is released on Github.

As a proof-of-concept, I threw together this SSTV cam website. There, I took inspiration from VK7OO’s SSTV site. I don’t have an SDR, but that doesn’t mean I can’t create a waterfall of the transmission, I made slowrxd write the transmission to a file, then used good ol’e sox to generate a spectrogram.

I made slowrxd generate a NDJSON log file as it received the image, which meant all kinds of metadata could be emitted live as it happened, including the SSTV mode at the start and the FSK ID at the end, timestamped to the millisecond. This could be parsed with sed and jq to pull out the necessary bits.

file could tell me how big the image was (I guess I could have put that in the log), and netpbm has lots of tools for putting images together. Drawing text was more tricky, but I found convert (from ImageMagick) could give me an image that had the text I wanted in a font I liked, then I could tell netpbm‘s pamcat and pamcomp could put the pieces together.

bash ran the whole show, generated the HTML, then used rsync to upload over SSH. Easy.

Without much work, I could replace this script with another that just does a nc -u localhost port and sends me a single UDP message with the event details so it could be handled by a separate daemon. So I think now I have a solution for that now.

Templating

This is a sore point in QSSTV, it has a template editor, but it uses its own format that’s basically proprietary to QSSTV using Qt abstractions. The code is open-source, so we can pick that apart to figure out exactly what its reading/writing, but it’d be a longer project… and the QSSTV templates are pretty limited.

The more I thought about it, the more I started to think about SVG as a template format — it has everything I need and some. I could use a well-known and highly capable editor like Inkscape to design the templates, leaving fields for my application to fill-in, then use a SVG rasteriser to spit out the image at any resolution I wanted.

For a rasteriser, whilst not ideal, I can use Inkscape itself quite successfully. At the cost of dragging in GTK+ libs (and it complaining that DISPLAY not being set), I can rasterise a SVG with one command:

inkscape -o output.png output.svg

The catch was, how do you do templates in Inkscape? Initial research was disheartening, but then I wondered… SVG supports CSS just like HTML. While you can attach style attributes to a CSS class, you don’t have to. SVG doesn’t care if you don’t… and with that, I can identify nodes in the SVG document by the class assigned.

Inkscape makes this possible through the Selectors and CSS palette accessed through the Object menu. Also useful here is the Object Properties palette available in the same menu.

The Object menu, showing the Selectors and CSS option highlighted.

Inkscape Template workflow

To create a template in Inkscape… firstly, create your image as you normally would. Put whatever dummy text in your text fields and dummy images in embedded bitmaps you need to change from code later. Get it looking the way you want with that dummy text.

Next, use the Object Properties palette to assign meaningful values to the objects you want to manipulate. Each ID you assign must be unique, so this by itself isn’t useful for fields that are duplicated, but will help later when you come to assign CSS classes to these fields. The IDs should contain only alpha-numeric characters (0-9, a-z, A-Z), hyphens (-) and underscores (_) (apparently other characters are allowed except white-space, but sticking to this limit will make life a lot easier).

Inkscape assigning IDs to the various elements we want to manipulate.

Finally, we use the Selectors and CSS palette to assign classes. Click on an element you wish to assign classes to:

Selectors and CSS palette open with an object selected.

You’ll see there are two panes, either side-by-side or one above the other, the little button group down the bottom-right switches the view. Depending on which one is selected, you want either the bottom one or the right-hand one.

On the same row is + and - buttons for adding new “CSS selectors”. When you click + a pop-up box appears with a default being the ID of the object prefixed with a #. Delete the default text, then type in a . followed by the CSS class name, again just stick to alpha-numerics, hyphens and underscores… don’t try anything fancy. Then click OK.

You should find in the right (or bottom) pane, you now have the class defined, and your object (identified by the ID you assigned earlier) is listed as one of the members of that class. There’s a + icon beside the class which you can click to add another selected object to the same class, and a garbage can icon beside each member to remove that member from the class.

In the left (upper) pane, you can set style information for this class as well as for the specific selected object. Leave the style information blank for each class (you can apply styles if you like, but we’re simply using the class name as a label here to convey semantic information).

When you’re happy, save the SVG image. Inkscape SVG is fine unless you’re using something different for a rasteriser that requires standard SVG.

Editing the template is done by simply opening the SVG file in Inkscape and editing it like any other document, keeping in mind those two special panes for assigning CSS classes.

Python-based Templating engine

I did a quick experiment today, and came up with this very crude Python script to demonstrate a templating engine:

#!/usr/bin/env python3

from xml.etree import ElementTree
from collections import namedtuple
import datetime

SVGField = namedtuple("SVGField", ["element", "classes"])

svgdoc = ElementTree.parse("test.svg")
svgroot = svgdoc.getroot()

if svgroot.tag == "svg":
    namespaces = None
else:
    assert svgroot.tag.startswith("{") and svgroot.tag.endswith(
        "}svg"
    ), "Root element is not a SVG tag"
    # Pick out the namespace URI
    namespaces = dict(svg=svgroot.tag[1:-4])

# Figure out what the text and image tags will be called, they'll have
# the same namespace as the `<svg>` tag.
TEXT_TAG = "{%s}text" % namespaces["svg"]
IMAGE_TAG = "{%s}image" % namespaces["svg"]

# Figure out all classes defined and the elements using them
classnames = {}
for elem in svgdoc.iterfind(".//*[@class]", namespaces=namespaces):
    elem_classes = set(
        [cls for cls in elem.attrib.get("class", "").split(" ") if cls]
    )

    field = SVGField(elem, elem_classes)

    for cls in elem_classes:
        classnames.setdefault(cls, []).append(field)

print("All classes: %s" % ", ".join(sorted(classnames.keys())))
NOW = datetime.datetime.utcnow()

# These would be sourced from command line arguments or some file, the
# following shows how to replace the content of text fields.
for cls, fields in classnames.items():
    if cls == "freq":
        value = "123456.789 kHz"
    elif cls == "sstvmode":
        value = "Dummy SSTV Mode"
    elif cls == "utcdate":
        value = NOW.strftime("%Y-%m-%d")
    elif cls == "utctime":
        value = NOW.strftime("%H:%Mz")
    elif cls == "heading":
        value = "Test heading"
    elif cls == "message":
        value = "Test message text"
    else:
        print("Skip fields of class %s" % cls)
        continue

    for field in fields:
        if field.element.tag == TEXT_TAG:
            for tspan in field.element.iterfind(
                "./svg:tspan", namespaces=namespaces
            ):
                tspan.text = str(value)
        elif field.element.tag == IMAGE_TAG:
            # Iterate over the attributes and look for the href tag, which
            # may be prefixed by a namespace.  Make a note of the new value.
            changes = {}
            for attr in field.element.attrib.keys():
                if attr == "href" or (
                    attr.startswith("{") and attr.endswith("}href")
                ):
                    changes[attr] = str(value)

            if changes:
                # Apply the changes
                field.element.attrib.update(changes)


svgdoc.write("output.svg")

If I run this script against my mock template… I get an SVG that renders to this:

Rendered template with all text fields filled in from user-supplied data.

Next steps

What I need to do next I guess is to write a web-based front-end that I can use with my tablet, but the mechanics of what I need is all there now. I can design templates for simple messages or embedding a copy of the image another station sent me so I can reply to their transmission. I can render those templates to raster images for transmission. I can capture and display the incoming SSTV traffic.

I just need to put it together now.

Digital Emergency comms ideas

Yesterday’s post was rather long, but was intended for mostly technical audiences outside of amateur radio.  This post serves as a brain dump of volatile memory before I go to sleep for the night.  (Human conscious memory is more like D-RAM than one might realise.)

Radio interface

So, many in our group use packet radio TNCs already, with a good number using the venerable Kantronics KPC3.  These have a DB9 port that connects to the radio and a second DB25 RS-323 port that connects to the computer.

My proposal: we make an audio interface that either plugs into that DB9 port and re-uses the interface cables we already have, or directly into the radio’s data port.

This should connect to an audio interface on the computer.

For EMI’s sake, I’d recommend a USB sound dongle like this, or these, or this as that audio interface.  I looked on Jaycar and did see this one, which would also work (and burn a hole in your wallet!).

If you walk in and the asking price is more than $30, I’d seriously consider these other options.  Of those options, U-Mart are here in Brisbane; go to their site, order a dongle then tell the site you’ll come and pick it up.  They’ll send you an email with an order number when it’s ready, you just need to roll up to the store, punch that number into a terminal in the shop, then they’ll call your name out for you to collect and pay for it.

Scorptec are in Melbourne, so you’ll have to have items shipped, but are also worth talking to.  (They helped me source some bits for my server cluster when U-Mart wouldn’t.)

USB works over two copper pairs; one delivers +5V and 0V, the other is a differential pair for data.  In short, the USB link should be pretty immune from EMI issues.

At worst, you should be able to deal with it with judicious application of ferrite beads to knock down the common mode current and using a combination of low-ESR electrolytic and ceramic capacitors across the power rails.

If you then keep the analogue cables as short as absolutely possible, you should have little opportunity for RF to get in.

I don’t recommend the TigerTronics Signalink interfaces, they use cheap and nasty isolation transformers that lead to serious performance issues.

Receive audio

For the receive audio, we feed the audio from the radio and we feed that via potentiometer to a 3.5mm TRS (“phono”) plug tip, with sleeve going to common.  This plugs into the Line-In or Microphone input on the sound device.

Push to Talk and Transmit audio

I’ve bundled these together for a good reason.  The conventional way for computers to drive PTT is via an RS-232 serial port.

We can do that, but we won’t unless we have to.

Unless you’re running an original SoundBLASTER card, your audio interface is likely stereo.  We can get PTT control via an envelope detector forming a minimal-latency VOX control.

Another 3.5mm TRS plug connects to the “headphone” or “line-out” jack on our sound device and breaks out the left and right channels.

The left and right channels from the sound device should be fed into the “throw” contacts on two single-pole double-throw toggle switches.

The select pin (mechanically operated by the toggle handle) on each switch thus is used to select the left or right channel.

One switch’s select pin feeds into a potentiometer, then to the radio’s input.  We will call that the “modulator” switch; it selects which channel “modulates” our audio.  We can again adjust the gain with the potentiometer.

The other switch first feeds through a small Schottky diode then across a small electrolytic capacitor (to 0V) then through a small resistor before finally into the base of a small NPN signal transistor (e.g. BC547).  The emitter goes to 0V, the collector is our PTT signal.

This is the envelope detector we all know and love from our old experiments with crystal sets.  In theory, we could hook a speaker to the collector up to a power source and listen to AM radio stations, but in this case, we’ll be sending a tone down this channel to turn the transistor, and thus or PTT, on.

The switch feeding this arrangement we’ll call the “PTT” switch.

By using this arrangement, we can use either audio channel for modulation or PTT control, or we can use one channel for both.  1200-baud AFSK, FreeDV, etc, should work fine with both on the one channel.

If we just want to pass through analogue audio, then we probably want modulation separate, so we can hold the PTT open during speech breaks without having an annoying tone superimposed on our signal.

It may be prudent to feed a second resistor into the base of that NPN, running off to the RTS pin on an RS-232 interface.  This will let us use software that relies on RS-232 PTT control, which can be added by way of a USB-RS232 dongle.

The cheap Prolific PL-2303 ones sold by a few places (including Jaycar) will work for this.  (If your software expects a 16550 UART interface on port 0x3f8 or similar, consider running it in a virtual machine.)

Ideally though, this should not be needed, and if added, can be left disconnected without harm.

Software

There are a few “off-the-shelf” packages that should work fine with this arrangement.

AX.25 software

AGWPE on Windows provides a software TNC.  On Linux, there’s soundmodem (which I have used, and presently mirror) and Direwolf.

Shouldn’t need a separate PTT channel, it should be sufficient to make the pre-amble long enough to engage PTT and rely on the envelope detector recognising the packet.

Digital Voice

FreeDV provides an open-source digital voice platform system for Windows, Linux and MacOS X.

This tool also lets us send analogue voice.  Digital voice should be fine, the first frame might get lost but as a frame is 40ms, we just wait before we start talking, like we would for regular analogue radio.

For the analogue side of things, we would want tone-driven PTT.  Not sure if that’s supported, but hey, we’ve got the source code, and yours truly has worked with it, it shouldn’t be hard to add.

Slow-scan television

The two to watch here would be QSSTV (Linux) and EasyPal (Windows).  QSSTV is open-source, so if we need to make modifications, we can.

Not sure who maintains EasyPal these days, not Eric VK4AES as he’s no longer with us (RIP and thank-you).  Here, we might need an RS-232 PTT interface, which as discussed, is not a hard modification.

Radioteletype

Most is covered by FLDigi.  Modes with a fairly consistent duty cycle will work fine with the VOX PTT, and once again, we have the source, we can make others work.

Custom software ideas

So we can use a few off-the-shelf packages to do basic comms.

  • We need auditability of our messaging system.  Analogue FM, we can just use a VOX-like function on the computer to record individual received messages, and to record outgoing traffic.  Text messages and files can be logged.
  • Ideally, we should have some digital signing of logs to make them tamper-resistant.  Then we can mathematically prove what was sent.
  • In a true  emergency, it may be necessary to encrypt what we transmit.  This is fine, we’re allowed to do this in such cases, and we can always turn over our audited logs for authorities anyway.
  • Files will be sent as blocks which are forward-error corrected (or forward-erasure coded).  We can use a block cipher such as AES-256 to encrypt these blocks before FEC.  OpenPGP would work well here rather doing it from scratch; just send the OpenPGP output using FEC blocks.  It should be possible to pick out symmetric key used at the receiving end for auditing, this would be done if asked for by Government.  DIY not necessary, the building blocks are there.
  • Digital voice is a stream, we can use block ciphers but this introduces latency and there’s always the issue of bit errors.  Stream ciphers on the other hand, work by generating a key stream, then XOR-ing that with the data.  So long as we can keep sync in the face of bit errors, use of a stream cipher should not impair noise immunity.
  • Signal fade is a worse problem, I suggest a cleartext (3-bit, 4-bit?) gray-code sync field for synchronisation.  Receiver can time the length of a fade, estimate the number of lost frames, then use the field to re-sync.
  • There’s more than a dozen stream ciphers to choose from.  Some promising ones are ACHTERBAHN-128, Grain 128a, HC-256, Phelix, Py, the Salsa20 family, SNOW 2/3G, SOBER-128, Scream, Turing, MUGI, Panama, ISAAC and Pike.
  • Most (all?) stream ciphers are symmetric.  We would have to negotiate/distribute a key somehow, either use Diffie-Hellman or send a generated key as an encrypted file transfer (see above).  The key and both encrypted + decrypted streams could be made available to Government if needed.
  • The software should be capable of:
    • Real-time digital voice (encrypted and clear; the latter being compatible with FreeDV)
    • File transfer (again, clear and encrypted using OpenPGP, and using good FEC, files will be cryptographically signed by sender)
    • Voice mail and SSTV, implemented using file transfer.
    • Radioteletype modes (perhaps PSK31, Olivia, etc), with logs made.
    • Analogue voice pass-through, with recordings made.
    • All messages logged and time-stamped, received messages/files hashed, hashes cryptographically signed (OpenPGP signature)
    • Operation over packet networks (AX.25, TCP/IP)
    • Standard message forms with some basic input validation.
    • Ad-hoc routing between interfaces (e.g. SSB to AX.25, AX.25 to TCP/IP, etc) should be possible.
  • The above stack should ideally work on low-cost single-board computers that are readily available and are low-power.  Linux support will be highest priority, Windows/MacOS X/BSD is a nice-to-have.
  • GNU Radio has building blocks that should let us do most of the above.

Emergency communications considerations

So, there’s been a bit of discussion lately about our communications infrastructure. I’ve been doing quite a bit of thinking about the topic.

The situation today

Here in Australia, a lot of people are being moved over to the National Broadband Network… with the analogue fixed line phone (if it hasn’t disappeared already) being replaced with a digital service.

For many, their cellular “mobile” phone is their only means of contact. More than the over-glorified two-way radios that was pre-cellular car phones used by the social elites in the early 70s, or the slightly more sophisticated and tennis-elbow inducing AMPS hand-held mobile phones that we saw in the 80s, mobile phones today are truly versatile and powerful hand-held computers.

In fact, they are more powerful than the teen-aged computer I am typing this on. (And yes, I have upgraded it; 1GB RAM, 250GB mSATA SSD, Linux kernel 4.0… this 2GHz P4 still runs, and yes I’ll update that kernel in a moment. Now, how’s that iPhone 3G going, still running well?)

All of these devices are able to provide data communications throughput in the order of millions of bits per second, and outside of emergencies, are generally, very reliable.

It is easy to forget just how much needs to work properly in order for you to receive that funny cat picture.

Mobile networks

One thing that is not clear about the NBN, is what happens when the power is lost. The electricity grid is not infallible, and requires regular maintenance, so while reliability is good, it is not guaranteed.

For FTTP users, battery backup is an optional extra. If you haven’t opted in, then your “land line” goes down when the power goes out.

This is not a fact that people think about. Most will say, “that’s fine, I’ve got my mobile” … but do you? The typical mobile phone cell tower has several hours battery back-up, and can be overwhelmed by traffic even in non-emergencies.They are fundamentally engineered to a cost, thus compromises are made on how long they can run without back-up power, and how much call capacity they carry.

In the 2008 storms that hit The Gap, I had no mobile telephone coverage for 2 days. My Nokia 3310 would occasionally pick up a signal from a tower in a neighbouring suburb such as Keperra, Red Hill or Bardon, and would thus occasionally receive the odd text message… but rarely could muster the effective radiated power to be able to reply back or make calls. (Yes, and Nokia did tell me that internal antennas surpassed the need for external ones. A 850MHz yagi might’ve worked!)

Emergency Services

Now, you tell yourself, “Well, the emergency services have their own radios…”, and this is correct. They do have their own radio networks. They too are generally quite reliable. They have their problems. The Emergency Alerting System employed in Victoria was having capacity problems as far back as 2006 (emphasis mine):

A high-priority project under the Statewide Integrated Public Safety Communications Strategy was establishing a reliable statewide paging system; the emergency alerting system. The EAS became operational in 2006 at a cost of $212 million. It provides coverage to about 96 per cent of Victoria through more than 220 remote transmitter sites. The system is managed by the Emergency Services Telecommunications Agency on behalf of the State and is used by the CFA, VICSES and Ambulance Victoria (rural) to alert approximately 37,400 personnel, mostly volunteers, to an incident. It has recently been extended to a small number of DSE and MFB staff.

Under the EAS there are three levels of message priority: emergency, non-emergency, and administrative. Within each category the system sends messages on a first-in, first-out basis. This means queued emergency messages are sent before any other message type and non-emergency messages have priority over administrative messages.

A problem with the transmission speed and coverage of messages was identified in 2006. The CFA expressed concern that areas already experiencing marginal coverage would suffer additional message loss when the system reached its limits during peak events.

To ensure statewide coverage for all pagers, in November 2006 EAS users decided to restrict transmission speed and respond to the capacity problems by upgrading the system. An additional problem with the EAS was caused by linking. The EAS can be configured to link messages by automatically sending a copy of a message to another pager address. If multiple copies of a message are sent the overall load on the system increases.

By February 2008 linking had increased by 25 per cent.

During the 2008 windstorm in Victoria the EAS was significantly short of delivery targets for non-emergency and administrative messages. The Emergency Services Telecommunications Agency subsequently reviewed how different agencies were using the system, including their message type selection and message linking. It recommended that the agencies establish business rules about the use of linking and processes for authorising and monitoring de-linking.

The planned upgrade was designed to ensure the EAS could cope better with more messages without the use of linking.

The upgrade was delayed several times and rescheduled for February 2009; it had not been rolled out by the time of Black Saturday. Unfortunately this affected the system on that day, after which the upgrade was postponed indefinitely.

I can find mention of this upgrade taking place around 2013. From what I gather, it did eventually happen, but it took a roasting from mother nature to make it happen. The lesson here is that even purpose built networks can fall over, and thus particularly in major incidents, it is prudent to have a back-up plan.

Alternatives

For the lay person, CB radio can be a useful tool for short-range (longer-than-yelling-range) voice communications. UHF CB will cover a few kilometres in urban environments and can achieve quite long distances if good line-of-sight is maintained. They require no apparatus license, and are relatively inexpensive.

It is worth having a couple of cheap ones, a small torch and a packet of AAA batteries (stored separately) in the car or in a bag you take with you. You can’t use them if they’re in a cupboard at home and you’re not there.

The downside with the hand-helds, particularly the low end ones, is effective radiated power. They will have small “rubber ducky” antennas, optimised for size, and will typically have limited transmit power, some can do the 5W limit, but most will be 1W or less.

If you need a bit more grunt, a mobile UHF CB set and magnetic mount antenna could be assembled and fitted to most cars, and will provide 5W transmit power, capable of about 5-10km in good conditions.

HF (27MHz) CB can go further, and with 12W peak envelope power, it is possible to get across town with one, even interstate or overseas when conditions permit. These too, are worth looking at, and many can be had cheaply second-hand. They require a larger antenna however to be effective, and are less common today.

Beware of fakes though… A CB radio must meet “type approval”, just being technically able to transmit in that band doesn’t automatically make it a CB, it must meet all aspects of the Citizens Band Radio Service Class License to be classified a CB.

If it does more than 5W on UHF, it is not a UHF CB. If it mentions a transmit range outside of 476-478MHz, it is not a UHF CB.  Programming it to do UHF channels doesn’t change this.

Similarly, if your HF CB radio can do 26MHz (NZ CB, not Australia), uses FM instead of SSB/AM (UK CB, again not Australia), does more than 12W, or can do 28-30MHz (10m amateur), it doesn’t qualify as being a CB under the class license.

Amateur radio licensing

If you’ve got a good understanding of high-school mathematics and physics, then a Foundation amateur radio license is well within reach.  In fact, I’d strongly recommend it for anyone doing first year Electrical Engineering … as it will give you a good practical grounding in electrical theories.

Doing so, you get to use up to 10W of power (double what UHF CB gives you; 6dB can matter!) and access to four HF, one VHF and one UHF band using analogue voice or hand-keyed Morse code.

You can then use those “CB radios” that sell on eBay/DealExtreme/BangGood/AliExpress…etc, without issue, as being un-modified “commercial off-the-shelf”, they are acceptable for use under the Foundation license.

Beyond Voice: amateur radio digital modes

Now, all good and well being able to get voice traffic across a couple of suburban blocks. In a large-scale disaster, it is often necessary to co-ordinate recovery efforts, which often means listings of inventory and requirements, welfare information, etc, needs to be broadcast.

You can broadcast this by voice over radio… very slowly!

You can put a spreadsheet on a USB stick and drive it there. You can deliver photos that way too. During an emergency event, roads may be in-passable, or they may be congested. If the regular communications channels are down, how does one get such files across town quickly?

Amateur radio requires operators who have undergone training and hold current apparatus licenses, but this service does permit the transmission of digital data (for standard and advanced licensees), with encryption if needed (“intercommunications when participating in emergency services operations or related training exercises”).

Amateur radio is by its nature, experimental. Lots of different mechanisms have been developed through experiment for intercommunication over amateur radio bands using digital techniques.

Morse code

The oldest by far is commonly known as “Morse code”, and while it is slower than voice, it requires simpler transmitting and receiving equipment, and concentrates the transmitted power over a very narrow bandwidth, meaning it can be heard reliably at times when more sophisticated modes cannot. However, not everybody can send or receive it (yours truly included).

I won’t dwell on it here, as there are more practical mechanisms for transmitting lots of data, but have included it here for completeness. I will point out though, due to its simplicity, it has practically no latency, thus it can be faster than SMS.

Radio Teletype

Okay, there are actually quite a few modes that can be described in this manner, and I’ll use this term to refer to the family of modes. Basically, you can think of it as two dumb terminals linked via a radio channel. When you type text into one, that text appears on the other in near real-time. The latency is thus very low, on par with Morse code.

The earliest of these is the RTTY mode, but more modern incarnations of the same idea include PSK31.

These are normally used as-is. With some manual copying and pasting pieces of text at each end, it is possible to encode other forms of data as short runs of text and send files in short hand-crafted “packets”, which are then hand-deconstructed and decoded at the far end.

This can be automated to remove the human error component.

The method is slow, but these radioteletype modes are known for being able to “punch through” poor signal conditions.

When I was studying web design back in 2001, we were instructed to keep all photos below 30kB in size. At the time, dial-up Internet was common, and loading times were a prime consideration.

Thus instead of posting photos like this, we had to shrink them down, like this. Yes, some detail is lost, but it is good enough to get an “idea” of the situation.

The former photo is 2.8MB, the latter is 28kB. Via the above contrived transmission system, it would take about 20 minutes to transmit.

The method would work well for anything that is text, particularly simple spread sheets, which could be converted to Comma Separated Values to strip all but the most essential information, bringing file sizes down into realms that would allow transmission times in the order of 5 minutes. Text also compresses well, thus in some cases, transmission time can be reduced.

To put this into perspective, a drive from The Gap where that photo was taken, into the Brisbane CBD, takes about 20 minutes in non-peak-hour normal circumstances. It can take an hour at peak times. In cases of natural disaster, the roads available to you may be more congested than usual, thus you can expect peak-hour-like trip times.

Radio Faximile and Slow Scan Television

This covers a wide variety of modes, ranging from the ancient like Hellschreiber which has its origins in the German Military back in World War II, various analogue slow-scan television modes through to the modern digital slow-scan television.

This allows the transmission of photos and visual information over radio. Some systems like EasyPAL and its elk (based on HamDRM, a variant of Digital Radio Mondiale) are in fact, general purpose modems for transmitting files, and thus can transmit non-graphical data too.

Transmit times can vary, but the analogue modes take between 30 seconds and two minutes depending on quality. For the HamDRM-based systems, transmit speeds vary between 86Bps up to 795kBps depending on the settings used.

Packet Radio

Packet radio is the concept of implementing packet-switched networks over radio links. There are various forms of this, the most common in amateur radio being PACTOR, WINMOR, the 1200-baud AFSK and 9600-baud FSK and 300-baud AFSK packet modes.

300-baud AFSK is normally used on HF links, and hails from experiments using surplus Bell 103 modems modified to work with radio. Similarly, on VHF and UHF FM radio, experiments were done with surplus Bell 202 modems, giving rise to the 1200-baud AFSK mode.

The 9600-baud FSK mode was the invention of James Miller G3RUH, and was one of the first packet radio modes actually developed by radio amateur operators for use on radio.

These are all general-purpose data modems, and while they can be used for radioteletype applications, they are designed with computer networking in mind.

The feature facilities like automatic repeating of lost messages, and in some cases support forward error correction. PACTOR/WINMOR is actually used with the Winlink radio network which provides email services.

The 300-baud, 1200-baud and 9600-baud versions generally use a networking protocol called AX.25, and by configuring stations with multiple such “terminal node controllers” (modems) connected and appropriate software, a station can operate as a router, relaying traffic received via one radio channel to a station that’s connected via another, or to non-AX.25 stations on Winlink or the Internet.

It is well suited to automatic stations, operating without human intervention.

AX.25 packet and PACTOR I are open standards, the later PACTOR modems are proprietary devices produced by SCS in Germany.

AX.25 packet is capable of transmit speeds between 15Bps (300 baud) and 1kBps (9600 baud). PACTOR varies between 5Bps and 650Bps.

In theory, it is possible to develop new modems for transmitting AX.25, the HamDRM modem used for slow-scan television and the FDMDV modem used in FreeDV being good starting points as both are proven modems with good performance.

These simply require an analogue interface between the computer sound card and radio, and appropriate software.  Such an interface made to link a 1200-baud TNC to a radio could be converted to link to a low-cost USB audio dongle for connection to a computer.

If someone is set up for 1200-baud packet, setting up for these other modes is not difficult.

High speed data

Going beyond standard radios, amateur radio also has some very high-speed data links available. D-Star Digital Data operates on the 23cm microwave band and can potentially transmit files at up to 16KBps, which approaches ADSL-lite speeds. Transceivers such as the Icom ID-1 provide this via an Ethernet interface for direct connection to a computer.

General Electric have a similar offering for industrial applications that operates on various commercial bands, some of which can reach amateur frequencies, thus would be usable on amateur bands. These devices offer transmit speeds up to 8KBps.

A recent experiment by amateurs using off-the-shelf 50mW 433MHz FSK modules and Realtek-based digital TV tuner receivers produced a high-speed speed data link capable of delivering data at up to 14KBps using a wideband (~230kHz) radio channel on the 70cm band.  They used it to send high definition photos from a high-altitude balloon.

The point?

We’ve got a lot of tools at our disposal for getting a message through, and collectively, 140 years of experience at our disposal. In an emergency situation, that means we have a lot of different options, if one doesn’t work, we can try another.

No, a 1200-baud VHF packet link won’t stream 4k HD video, but it has minimal latency and will take less than 20 minutes to transmit a 100kB file over distances of 10km or more.

A 1kB email will be at the other end before you can reach for your car keys.  Further experimentation and development means we can only improve.  Amateur radio is far from obsolete.