soundmodem

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.

Mucking around with AX.25 and APRS

Recently I purchased a second hand Kantronics KPC-3 packet TNC. Brisbane Area WICEN make heavy use of packet at one particular event, the International Rally of Queensland, where they use the 1200-baud network to report the scores of rally cars as they progress through each stage.

Now, I’m a newcomer to radio compared to most on the band. I got my license in 2008, and I’ve only had contact with packet for the last two years, and even then, mostly only at a distance.  I had a hand-held that did APRS, and I’ve also done some APRS using soundmodem and Xastir.  Full-blooded AX.25 has taken me some time, and I’m slowly coming to grips with some of it.

One thing I wanted to try and figure out, is how to re-lay traffic from a host connected to the RF world, to a host on a local network.  I knew there was some protocol that did it, but didn’t know what, or how it worked.  Turns out the protocol I was thinking of was AXIP, which basically overlays AX.25 frames directly atop IP.  There’s also a version that encapsulates them in UDP datagrams; AXUDP.

The following are my notes on how I managed to get some routing to happen.

So, my set-up.  I have my FT-897D set up on 145.175MHz FM, the APRS frequency in Australia.  (I did go hunting for BBSes the other night but came up blank, but since APRS uses AX.25 messaging, it’ll be a start.)

To its data port, I have the KPC-3, which connects to my trusty old P4 laptop via good ol’e RS-232 (the real stuff, not pretend USB-RS232, yes the laptop is that old).  This laptop is on my local LAN, with an IP address of 192.168.64.141.

In front of me, is my main workhorse, a MacBook at the address of 192.168.64.140.  Both laptops are booted into Linux, and my target is Xastir.

First thing I had to do was compile the AX.25 kernel modules, and the ax25-tools, ax25-apps.  The userspace tools needed for this are: ax25ipd and kissnetd.

On the RF-facing system

This is the P4 in my case, the one with the TNC. First step is to get the TNC into KISS mode. In the case of Kantronics TNCs, the way to do this is to fire up your terminal emulator and run int kiss followed by reset.

Important note: to get it back, shut down everything using the serial port then run echo -e '\0300\0377\0300' > /dev/ttyS0. This sends the three-byte exit-kiss-mode sequence (0xc0 0xff 0xc0).

Configure /etc/ax25/ax25ipd.conf. Three things you’ll need to set up:

  • mode: should be tnc
  • device: should be whatever your serial device is (more on this later)
  • your default route: this is the host that will receive ALL traffic

In my case, my ax25ipd.conf on the P4 laptop looks like this:

socket ip
mode tnc
device /dev/ttyS0
speed 9600
loglevel 2
broadcast QST-0 NODES-0
# This points to my MacBook; d means default route
route 0 192.168.64.140 d

Once done, we start the ax25ipd service as root, it should fork into the background, and checking with netstat should show it as listening on a raw socket.

On the client machine

Here, we also run a AXIP server, but this time to catch the packets that get flung our way by the other system. We want Xastir to pick up the traffic as it comes in. Two ways of doing this.

One is to configure kissattach to give us a PTY device which we then pass onto ax25ipd, then run Xastir as root and tell it to use the AX.25 stack directly. Gentoo’s Xastir ebuild ships with this feature disabled, so not an option here (unless I hack the ebuild like I did last time).

The AX.25 tools also come with kissnetd: this basically generates several PTYs and links them all together so they all see eachother’s KISS traffic. So ax25ipd will receive packets, pass them to its PTY, which will then get forwarded by kissnetd to the other PTY attached to Xastir.

There is one catch. Unlike in kernels of yore, kernel 2.6 and above (3.x is no exception) do not have statically configured PTY devices. So all the AX.25 docs that say to use /dev/ptyq0 for one end and /dev/ttyqf for the other? Make that /dev/ptmx for one end, and the tool will tell you, what the other end is called. And yes, it’ll change.

Run kissnetd -p 2; the parameter tells it to create two PTYs. The tool will run in the foreground so make a note of what they’re called, then hit CTRL-Z followed by bg to bring it into the background.

vk4msl-mb stuartl # kissnetd -p 2
kissnetd V 1.5 by Frederic RIBLE F1OAT - ATEPRA FPAC/Linux Project

Awaiting client connects on:
/dev/pts/1 /dev/pts/4
^Z
[1]+  Stopped                 kissnetd -p 2
vk4msl-mb stuartl # bg 1

Now, in this example, PTYs 1 and 4 are allocated. I can allocate either one of them to Xastir or ax25ipd, here I’ll use /dev/pts/4 for ax25ipd and the other for Xastir. It is possibly best if you make symlinks to these, and just refer to the symlinks in your software.

# ln -s /dev/pts/4 /dev/kiss-ax25ipd
# ln -s /dev/pts/1 /dev/kiss-xastir

Whilst you’re at it, change the ownership of the one you give to Xastir to your user/group so Xastir doesn’t need to run as root.

Set up /etc/ax25/ax25ipd.conf on the client. Here, I’ve given it a route for all WIDE* traffic to the other host. It might be possible to just use 0 as I did before, I wasn’t sure if that’d create a loop or not.

socket ip
mode tnc
device /dev/kiss-ax25ipd
speed 9600
loglevel 2
broadcast QST-0 NODES-0
# This points to my P4, attached to the TNC; d means default route
route WIDE* 192.168.64.141 d

Now start up ax25ipd and Xastir, you should be able to bring up the interface and see APRS traffic, more over, you should be able to hit Transmit and see the TNC broadcast your packets.

Some stations visible direct via RF

Some stations visible direct via RF (click to enlarge)

Experiments with AX.25

This weekend just gone I was at Imbil helping out with the International Rally of Queensland, reporting scores for the car rally there.  This was my first look at packet radio in action.  Prior to this I had enabled the amateur radio options in the kernels I built, but never tried actually hooking radio to computer.  I shall be posting some notes on how I got this working…

zhouman ~ # uname -a
Linux zhouman 2.6.35.7-lm2f-nb #2 Wed Oct 13 00:42:58 EST 2010 mips64 ICT Loongson-2 V0.3 FPU V0.1 lemote-yeeloong-2f-8.9inches GNU/Linux
zhouman ~ # ifconfig sm0
sm0 Link encap:AMPR AX.25 HWaddr VK4MSL
inet addr:172.31.32.1 Bcast:172.31.32.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:256 Metric:1
RX packets:365 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:24236 (23.6 KiB) TX bytes:6850 (6.6 KiB)

zhouman ~ # mheard
Callsign Port Packets Last Heard
VK4EA-9 sm0 6 Mon May 16 17:59:12
VK4NRL-9 sm0 1 Mon May 16 17:58:40
VK4VP-1 sm0 8 Mon May 16 17:58:38
VK4RAI-3 sm0 9 Mon May 16 17:57:58
VK4TIM-9 sm0 14 Mon May 16 17:57:56
VK4TDI-1 sm0 2 Mon May 16 17:57:39
VK4DC-1 sm0 15 Mon May 16 17:57:07
VK4TEC-9 sm0 120 Mon May 16 17:56:08
VK4FY-1 sm0 18 Mon May 16 17:54:38
VK4RMO-3 sm0 1 Mon May 16 17:54:33
VK4RGC-3 sm0 3 Mon May 16 17:52:48
VK4RC-1 sm0 8 Mon May 16 17:51:29
VK4FIL-1 sm0 4 Mon May 16 17:46:44
VK4RIL-13 sm0 4 Mon May 16 17:45:43
VK4RBR-3 sm0 5 Mon May 16 17:42:59
VK2RDO-3 sm0 2 Mon May 16 17:41:19
VK4RRC-13 sm0 3 Mon May 16 17:36:39
VK2JUB-1 sm0 2 Mon May 16 17:34:44
VK4BNQ-1 sm0 1 Mon May 16 17:26:58
VK4LDA-9 sm0 2 Mon May 16 17:24:59
VK2POO-9 sm0 9 Mon May 16 17:21:24
VK2XFL-9 sm0 1 Mon May 16 17:21:09
VK4RSR-3 sm0 1 Mon May 16 17:20:04
VK4IE sm0 1 Mon May 16 17:15:04
VK4ALJ-3 sm0 1 Mon May 16 17:15:00
VK4HPW-9 sm0 5 Mon May 16 17:13:23
zhouman ~ #

Set-up consisted of:
Linux kernel on Lemote Yeeloong, latest soundmodem driver, Yaesu FT-897D, homebrew interface cable plugged into Yeeloong’s onboard sound card, USB serial driving BC547 in interface cable for PTT.

zhouman ~ # cat /etc/ax25/soundmodem.conf
<?xml version="1.0"?>
<modem>
<configuration name="FT897-D">
<chaccess txdelay="150" slottime="100" ppersist="40" fulldup="0" txtail="10"/>
<audio type="alsa" device="plughw:0,0" halfdup="0" capturechannelmode="Mono"/>
<ptt file="/dev/ttyUSB0"/>
<channel name="Channel 0">
<mod mode="afsk" bps="1200" f0="1200" f1="2200" diffenc="1"/>
<demod mode="afsk" bps="1200" f0="1200" f1="2200" diffdec="1"/>
<pkt mode="MKISS" ifname="sm0" hwaddr="VK4MSL" ip="172.31.32.1" netmask="255.255.255.0" broadcast="172.31.32.255"/>
</channel>
</configuration>
</modem>
zhouman ~ #

I’ve shut it down for now, but I’ll give it a bit more work on 145.175MHz tomorrow. Once I get something working, I might set something up using the O2 or one of the Fulongs (probably the latter) and see about getting soundmodem back into Gentoo.

Update: After hand-editing the ebuild to enable APRS support, I can successfully report that not only is soundmodem working, but so is Xastir on my Yeeloong, as can be seen on aprs.fi.