freedv

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.

2017/03/25 by Redhatter (VK4MSL) Amateur Radio Emergency Communications Public Syndication Thinktank WICEN 0

Getting the UDRC-II to play nice with the Yaesu FT-897D

The Yaesu FT-897D has the de-facto standard 6-pin Mini-DIN data jack on the back to which you can plug a digital modem. Amongst the pins it provides is a squelch status pin, and in the past I’ve tried using that to drive (via transistors) the carrier detect pin on various computer interfaces to enable the modem to detect when a signal is incoming.

The FT-897D is fussy however. Any load at all pulling this pin down, and you get no audio. Any load. One really must be careful about that.

Last week when I tried the UDRC-II, I hit the same problem. I was able to prove it was the UDRC-II by construction of a crude adapter cable that hooked up to the DB15-HD connector, converting that to Mini-DIN6: by avoiding the squelch status pin, I avoided the problem.

One possible solution was to cut the supplied Mini-DIN6 cable open, locate the offending wire and cut it. Not a solution I relish doing. The other was to try and fix the UDRC-II.

Discussing this on the list, it was suggested by Bryan Hoyer that I use a 4.7k pull-up resistor on the offending pin to 3.3V. He provided a diagram that indicated where to find the needed signals to tap into.

With that information, I performed the following modification. A 1206 4.7k resistor is tacked onto the squelch status pin, and a small wire run from there to the 3.3V pin on a spare header.

UDRC-II modification for Yaesu FT-897D

I’m at two minds whether this should be a diode instead, just in case a radio asserts +12V on this line, I don’t want +12V frying the SoC in the Raspberry Pi. On the other hand, this is working, it isn’t “broke”.

Doing the above fixed the squelch drive issue and now I’m able to transmit and receive using the UDRC-II. Many thanks to Bryan Hoyer for pointing this modification out.

2016/11/20 by Redhatter (VK4MSL) Amateur Radio Emergency Communications FreeDV Homebrew Public Syndication WICEN 0

Giving the Raspberry Pi the finger

So, recently, the North West Digital Radio group generously donated a UDRC II radio control board in thanks for my initial work on an audio driver for the Texas Instruments TLV320AIC3204 (yes, a mouthful).

This board looks like it might support the older Pi model B I had, but I thought I’d play it safe and buy the later revision, so I bought version 3 of the Pi and the associated 7″ touch screen. Thus, an order went to RS for a whole pile of parts, including one Raspberry Pi3 computer, a blank 8GB MicroSD card, a power supply, the touch screen kit and a case.

Fitting the UDRC

To fit the UDRC, the case will need some of the plastic cut away, rectangular section out of the main body and a similarly sized portion out of the back cover.

Modifications to the case

When assembled, the cut-away section will allow the DB15-HD and Mini-DIN6 connectors to protrude out slightly.

Case assembled with modifications

The UDRC needs some minor modifications too for the touch screen. Probe around, and you’ll find a source of 5V on one of the unpopulated headers. You’ll want to solder a two-pin header to here and hook that to the LCD control board using the supplied jumper leads. If you’ve got one, use a right-angled header, otherwise just bend a regular one like I did.

5V supply for the LCD on the UDRC

You’ll note I’ve made a note on the DB15-HD, a monitor does NOT plug in here.

From here, you should be ready to load up a SD card. NWDR recommend the use of Compass Linux, which is a Raspbian fork configured for use with the UDRC. I used the lite version, since it was smaller and I’m comfortable with command lines.

Configuring screen rotation

If you try to boot your freshly prepared SD card, the first thing you’ll notice is that the screen is up-side-down. Clearly a few people didn’t communicate with each-other about which way was up on this thing.

Before you pull the SD card out, it is worth mounting the first partition on the SD card and editing config.txt on the root directory of that partition. If doing this on a Windows computer ensure your text editor respects Unix line endings! (Blame Microsoft. If you’re doing this on a Mac, Linux, BSD or other Unix-ish computer, you have nothing to worry about.)

Add the following to the end of the file (or anywhere really):

# Rotate the screen the "right way up"
lcd_rotate=2

Now save the file, unmount the SD card, and put it in the Pi before assembling the case proper.

Setting up your environment

Now, if you chose the lite option like I did, there’ll be no GUI, and the touch aspect of the touchscreen is useless. You’ll need a USB keyboard.

You might choose like I did to run passwd again here to set root‘s password too.

After that, you’ll want to install some software. Your choice of desktop environment is entirely up to you, I prefer something lightweight, and have been using FVWM for years, but there are plenty of choices in Debian as well as the usual suspects (KDE, Gnome, XFCE…).

For the display manager, I’ll choose lightdm. We also need an on-screen keyboard. I tried a couple, including matchbox-keyboard and the rather ancient xvkbd. Despite its age, I found xvkbd to be the most usable.

Once you’ve decided what you want, run apt-get install with your list of packages, making sure to include xvkbd and lightdm in your list. Other applications I included here were network-manager-gnome, qasmixer, pasystray, stalonetray and gkrellm.

Enabling the on-screen keyboard in `lightdm`

Having installed lightdm and xvkbd, you can now configure lightdm to enable the accessibility options.

Open up /etc/lightdm/lightdm-gtk-greeter.conf, look for the line show-indicators and tack ;~a11y on the end.

Now down further, look for the commented out keyboard setting and change that to keyboard=xvkbd. Save and close the file, then run /etc/init.d/lightdm restart.

You should find yourself staring at the log-in screen, and lo and behold, there should be a new icon up the top-right. Tapping it should bring up a 3 line menu, the bottom of which is the on-screen keyboard.

On-screen keyboard in lightdm

The button marked Focus is what you hit to tell the keyboard which application is to receive the keyboard events. Tap that, then the application you want. To log in, tap Focus then the password field. You should be able to tap your password in followed by either the Return button on the virtual keyboard or the Log In button on the form.

Making FVWM touch-friendly

I have a pretty old configuration that has evolved over the last 10 years using FVWM that was built around keyboard-centric operation and screen real-estate preservation. This configuration mainly needed two changes:

Menus and title bar text enlarged to make the corresponding UI elements finger-friendly
Adjusting the size of the FVWM BarButtons to suit the 800×480 display

Rather than showing how to do it from scratch, I’ll just link to the configuration tarball which you are welcome to play with. It uses xcalendar which isn’t in the Debian repositories any more, but is available on Gentoo mirrors and can be built from source (you’ll want to install xutils-dev for xmake), stalonetray and gkrellm are both in the standard Debian repositories.

FVWM on the Raspberry Pi

Enabling the right-click

This took a bit of hunting to figure out. There is a method that works with Debian Wheezy which allows right-clicks by way of long presses, but this broke in Jessie, and the 2016-05-23 release of Compass Linux is built on the latter. So another solution is needed.

Philipp Merkel however, wrote a little daemon called twofing. Once installed, doing a right click is simply a two-fingered tap on the screen, there’s support for other two-fingered gestures such as pinching and rotation as well. It is available on Github, and I have forked this, adding some udev rules and scripts to integrate it into the Raspberry Pi.

The resulting Debian package is here. Download the .deb, run dpkg -i on it, and then re-start the Raspberry Pi (or you can try running udevadm trigger and re-starting X). The udev rules should create a /dev/twofingtouch symbolic link and the installed Xsession.d/Xreset.d scripts should take care of starting it with X and shutting it down afterwards.

Having done this, when you log in you should find that twofing is running, and that right clicks can be performed using a two-fingered prod.

Finishing up

Having done the configuration, you should now have a usable workhorse for numerous applications. The UDRC shows up as a second sound card and is accessible via ALSA. I haven’t tried it out yet, but it at least shows up in the mixer application, so the signs are there. I’ll be looking to add LinBPQ and FreeDV into the mix yet, to round the software stack off to make this a general purpose voice/data radio station for emergency communications.

2016/11/12 by Redhatter (VK4MSL) Amateur Radio Computing Emergency Communications Open Source Public Syndication WICEN 0

Donation from the Northwest Digital Radio

Well, today’s mail had a surprise. Back about 6 years ago, I was sub-contracted to Jacques Electronics to help them develop some device drivers for their video intercom system. At the time, they were using TI’s TLV320AIC3204 and system-on-modules based on the Freescale i.MX27 SoC.

No driver existed in the ALSA tree for this particular audio CODEC, and while TI did have one available under NDA, the driver was only licensed for use with a TI OMAP SoC. I did what just about any developer would do, grabbed the closest-looking existing ALSA SoC driver, ripped it apart and started hacking. Thus I wound up getting to grips with the I²S infrastructure within the i.MX27 and taming the little beast that is the TLV320AIC3204, producing this patch.

As the code was a derivative work, the code was automatically going to be under the GPLv2 and thus was posted on the ALSA SoC mailing list for others to use. This would help protect Jacques from any possible GPL infringement regarding the use of that driver. I was able to do this as it was a clean-room implementation using only material in TI’s data sheet, thus did not contain any intellectual property of my then-employer.

About that time I recall one company using the driver in their IP camera product, the driver itself never made it into the mainline kernel. About 6 months later, another driver for the TLV320AIC3204 and 3254 did get accepted there, I suspect this too was a clean-room implementation.

Fast forward to late August, I receive an email from Jeremy McDermond on behalf of the Northwest Digital Radio. They had developed the Universal Digital Radio Controller board for the Raspberry Pi series of computers based around this same CODEC chip. Interestingly, it was the ‘AIC3204 driver that I developed all that time before that proved to be the code they needed to get the chip working. The chip in question can be seen up the top-right corner of the board.

Universal Digital Radio Controller

Timely, as there’s a push at the moment within Brisbane Area WICEN Group to investigate possible alternatives to our aging packet radio system and software stack. These boards, essentially being radio-optimised sound cards, have been used successfully for implementing various digital modes including AX.25 packet, D-Star and could potentially do FreeDV and other digital modes.

So, looks like I’ll be chasing up a supplier for a newer Raspberry Pi board, and seeing what I can do about getting this device talking to the world.

Many thanks to the Northwest Digital Radio company for their generous donation! 🙂

2016/10/13 by Redhatter (VK4MSL) Amateur Radio Emergency Communications Linux Development Public Syndication WICEN 0

Implementing EEPROM emulation on the SM1000

Well, lately I’ve been doing a bit of work hacking the firmware on the Rowetel SM1000 digital microphone. For those who don’t know it, this is a hardware (microcontroller) implementation of the FreeDV digital voice mode: it’s a modem that plugs into the microphone/headphone ports of any SSB-capable transceiver and converts FreeDV modem tones to analogue voice.

I plan to set this unit of mine up on the bicycle, but there’s a few nits that I had.

There’s no time-out timer
The unit is half-duplex

If there’s no timeout timer, I really need to hear the tones coming from the radio to tell me it has timed out. Others might find a VOX feature useful, and there’s active experimentation in the FreeDV 700B mode (the SM1000 currently only supports FreeDV 1600) which has been very promising to date.

Long story short, the unit needed a more capable UI, and importantly, it also needed to be able to remember settings across power cycles. There’s no EEPROM chip on these things, and while the STM32F405VG has a pin for providing backup-battery power, there’s no battery or supercapacitor, so the SM1000 forgets everything on shut down.

ST do have an application note on their website on precisely this topic. AN3969 (and its software sources) discuss a method for using a portion of the STM32’s flash for this task. However, I found their “license” confusing. So I decided to have a crack myself. How hard can it be, right?

There’s 5 things that a virtual EEPROM driver needs to bear in mind:

The flash is organised into sectors.
These sectors when erased contain nothing but ones.
We store data by programming zeros.
The only way to change a zero back to a one is to do an erase of the entire sector.
The sector may be erased a limited number of times.

So on this note, a virtual EEPROM should aim to do the following:

It should keep tabs on what parts of the sector are in use. For simplicity, we’ll divide this into fixed-size blocks.
When a block of data is to be changed, if the change can’t be done by changing ones to zeros, a copy of the entire block should be written to a new location, and a flag set (by writing zeros) on the old block to mark it as obsolete.
When a sector is full of obsolete blocks, we may erase it.
We try to put off doing the erase until such time as the space is needed.

Step 1: making room

The first step is to make room for the flash variables. They will be directly accessible in the same manner as variables in RAM, however from the application point of view, they will be constant. In many microcontroller projects, there’ll be several regions of memory, defined by memory address. This comes from the datasheet of your MCU.

An example, taken from the SM1000 firmware, prior to my hacking (stm32_flash.ld at r2389):

/* Specify the memory areas */
MEMORY
{
  FLASH (rx)      : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM (rwx)       : ORIGIN = 0x20000000, LENGTH = 128K
  CCM (rwx)       : ORIGIN = 0x10000000, LENGTH = 64K
}

The MCU here is the STM32F405VG, which has 1MB of flash starting at address 0x08000000. This 1MB is divided into (in order):

Sectors 0…3: 16kB starting at 0x08000000
Sector 4: 64kB starting at 0x0800c000
Sector 5 onwards: 128kB starting at 0x08010000

We need at least two sectors, as when one fills up, we will swap over to the other. Now it would have been nice if the arrangement were reversed, with the smaller sectors at the end of the device.

The Cortex M4 CPU is basically hard-wired to boot from address 0, the BOOT pins on the STM32F4 decide how that gets mapped. The very first few instructions are the interrupt vector table, and it MUST be the thing the CPU sees first. Unless told to boot from external memory, or system memory, then address 0 is aliased to 0x08000000. i.e. flash sector 0, thus if you are booting from internal flash, you have no choice, the vector table MUST reside in sector 0.

Normally code and interrupt vector table live together as one happy family. We could use a couple of 128k sectors, but 256k is rather a lot for just an EEPROM storing maybe 1kB of data tops. Two 16kB sectors is just dandy, in fact, we’ll throw in the third one for free since we’ve got plenty to go around.

However, the first one will have to be reserved for the interrupt vector table that will have the space to itself.

So here’s what my new memory regions look like (stm32_flash.ld at 2390):

/* Specify the memory areas */
MEMORY
{
  /* ISR vectors *must* be placed here as they get mapped to address 0 */
  VECTOR (rx)     : ORIGIN = 0x08000000, LENGTH = 16K
  /* Virtual EEPROM area, we use the remaining 16kB blocks for this. */
  EEPROM (rx)     : ORIGIN = 0x08004000, LENGTH = 48K
  /* The rest of flash is used for program data */
  FLASH (rx)      : ORIGIN = 0x08010000, LENGTH = 960K
  /* Memory area */
  RAM (rwx)       : ORIGIN = 0x20000000, LENGTH = 128K
  /* Core Coupled Memory */
  CCM (rwx)       : ORIGIN = 0x10000000, LENGTH = 64K
}

This is only half the story, we also need to create the section that will be emitted in the ELF binary:

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } >FLASH

  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */
    *(.rodata)         /* .rodata sections (constants, strings, etc.) */
    *(.rodata*)        /* .rodata* sections (constants, strings, etc.) */
    *(.glue_7)         /* glue arm to thumb code */
    *(.glue_7t)        /* glue thumb to arm code */
	*(.eh_frame)

    KEEP (*(.init))
    KEEP (*(.fini))

    . = ALIGN(4);
    _etext = .;        /* define a global symbols at end of code */
    _exit = .;
  } >FLASH…

There’s rather a lot here, and so I haven’t reproduced all of it, but this is the same file as before at revision 2389, but a little further down. You’ll note the .isr_vector is pointed at the region called FLASH which is most definitely NOT what we want. The image will not boot with the vectors down there. We need to change it to put the vectors in the VECTOR region.

Whilst we’re here, we’ll create a small region for the EEPROM.

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } >VECTOR


  .eeprom :
  {
    . = ALIGN(4);
    *(.eeprom)         /* special section for persistent data */
    . = ALIGN(4);
  } >EEPROM


  .text :
  {
    . = ALIGN(4);
    *(.text)           /* .text sections (code) */
    *(.text*)          /* .text* sections (code) */

THAT’s better! Things will boot now. However, there is still a subtle problem that initially caught me out here. Sure, the shiny new .eeprom section is unpopulated, BUT the linker has helpfully filled it with zeros. We cannot program zeroes back into ones! Either we have to erase it in the program, or we tell the linker to fill it with ones for us. Thankfully, the latter is easy (stm32_flash.ld at 2395):

  .eeprom :
  {
    . = ALIGN(4);
    KEEP(*(.eeprom))   /* special section for persistent data */
    . = ORIGIN(EEPROM) + LENGTH(EEPROM) - 1;
    BYTE(0xFF)
    . = ALIGN(4);
  } >EEPROM = 0xff

Credit: Erich Styger

We have to do two things. One, is we need to tell it that we want the region filled with the pattern 0xff. Two, we need to make sure it gets filled with ones by telling the linker to write one as the very last byte. Otherwise, it’ll think, “Huh? There’s nothing here, I won’t bother!” and leave it as a string of zeros.

Step 2: Organising the space

Having made room, we now need to decide how to break this data up. We know the following:

We have 3 sectors, each 16kB
The sectors have an endurance of 10000 program-erase cycles

Give some thought as to what data you’ll be storing. This will decide how big to make the blocks. If you’re storing only tiny bits of data, more blocks makes more sense. If however you’ve got some fairly big lumps of data, you might want bigger blocks to reduce overheads.

I ended up dividing the sectors into 256-byte blocks. I figured that was a nice round (binary sense) figure to work with. At the moment, we have 16 bytes of configuration data, so I can do with a lot less, but I expect this to grow. The blocks will need a header to tell you whether or not the block is being used. Some checksumming is usually not a bad idea either, since that will clue you in to when the sector has worn out prematurely. So some data in each block will be header data for our virtual EEPROM.

If we don’t care about erase cycles, this is fine, we can just make all blocks data blocks, however it’d be wise to track this, and avoid erasing and attempting to use a depleted sector, so we need somewhere to track this. 256 bytes gives us enough space to stash an erase counter and a map of what blocks are in use within that sector.

So we’ll reserve the first block in the sector to act as this index for the entire sector. This gives us enough room to have 16-bits worth of flags for each block stored in the index. That gives us 63 blocks per sector for data use.

It’d be handy to be able to use this flash region for a few virtual EEPROMs, so we’ll allocate some space to give us a virtual ROM ID. It is prudent to do some checksumming, and the STM32F4 has a CRC32 module, so in that goes, and we might choose to not use all of a block, so we should throw in a size field (8 bits, since the size can’t be bigger than 255). If we pad this out a bit to give us a byte for reserved data, we get a header with the following structure:

	15	14	13	12	11	10	19	8	7	6	5	4	3	2	1	0
+0	CRC32 Checksum
+2	CRC32 Checksum
+4	ROM ID								Block Index
+6	Block Size								Reserved

So that subtracts 8 bytes from the 256 bytes, leaving us 248 for actual program data. If we want to store 320 bytes, we use two blocks, block index 0 stores bytes 0…247 and has a size of 248, and block index 1 stores bytes 248…319 and has a size of 72.

I mentioned there being a sector header, it looks like this:

	15	14	13	12	11	10	19	8	7	6	5	4	3	2	1	0
+0	Program Cycles Remaining
+2
+4
+6
+8	Block 0 flags
+10	Block 1 flags
+12	Block 2 flags
…

No checksums here, because it’s constantly changing. We can’t re-write a CRC without erasing the entire sector, we don’t want to do that unless we have to. The flags for each block are currently allocated accordingly:

	15	14	13	12	11	10	19	8	7	6	5	4	3	2	1	0
+0	Reserved															In use

When the sector is erased, all blocks show up as having all flags set as ones, so the flags is considered “inverted”. When we come to use a block, we mark the “in use” bit with a zero, leaving the rest as ones. When we erase, we mark the entire flags block as zeros. We can set other bits here as we need for accounting purposes.

Thus we have now a format for our flash sector header, and for our block headers. We can move onto the algorithm.

Step 3: The Code

This is the implementation of the above ideas. Our code needs to worry about 3 basic operations:

reading
writing
erasing

This is good enough if the size of a ROM image doesn’t change (normal case). For flexibility, I made my code so that it works crudely like a file, you can seek to any point in the ROM image and start reading/writing, or you can blow the whole thing away.

Constants

It is bad taste to leave magic numbers everywhere, so constants should be used to represent some quantities:

VROM_SECT_SZ=16384:
The virtual ROM sector size in bytes. (Those watching Codec2 Subversion will note I cocked this one up at first.)
VROM_SECT_CNT=3:
The number of sectors.
VROM_BLOCK_SZ=256:
The size of a block
VROM_START_ADDR=0x08004000:
The address where the virtual ROM starts in Flash
VROM_START_SECT=1:
The base sector number where our ROM starts
VROM_MAX_CYCLES=10000:
Our maximum number of program-erase cycles

Our programming environment may also define some, for example UINTx_MAX.

Derived constants

From the above, we can determine:

VROM_DATA_SZ = VROM_BLOCK_SZ – sizeof(block_header):
The amount of data per block.
VROM_BLOCK_CNT = VROM_SECT_SZ / VROM_BLOCK_SZ:
The number of blocks per sector, including the index block
VROM_SECT_APP_BLOCK_CNT = VROM_BLOCK_CNT – 1
The number of application blocks per sector (i.e. total minus the index block)

CRC32 computation

I decided to use the STM32’s CRC module for this, which takes its data in 32-bit words. There’s also the complexity of checking the contents of a structure that includes its own CRC. I played around with Python’s crcmod module, but couldn’t find some arithmetic that would allow it to remain there.

So I copy the entire block, headers and all to a temporary copy (on the stack), set the CRC field to zero in the header, then compute the CRC. Since I need to read it in 32-bit words, I pack 4 bytes into a word, big-endian style. In cases where I have less than 4 bytes, the least-significant bits are left at zero.

Locating blocks

We identify each block in an image by the ROM ID and the block index. We need to search for these when requested, as they can be located literally anywhere in flash. There are probably cleverer ways to do this, but I chose the brute force method. We cycle through each sector and block, see if the block is allocated (in the index), see if the checksum is correct, see if it belongs to the ROM we’re looking for, then look and see if it’s the right index.

Reading data

To read from the above scheme, having been told a ROM ID (rom), start offset and a size, the latter two being in byte sand given a buffer we’ll call out, we first need to translate the start offset to a sector and block index and block offset. This is simple integer division and modulus.

The first and last blocks of our read, we’ll probably only read part of. The rest, we’ll read entire blocks in. The block offset is only relevant for this first block.

So we start at the block we calculate to have the start of our data range. If we can’t find it, or it’s too small, then we stop there, otherwise, we proceed to read out the data. Until we run out of data to read, we increment the block index, try to locate the block, and if found, copy its data out.

Writing and Erasing

Writing is a similar affair. We look for each block, if we find one, we overwrite it by copying the old data to a temporary buffer, copy our new data in over the top then mark the old block as obsolete before writing the new one out with a new checksum.

Trickery is in invoking the wear levelling algorithm on an as-needed basis. We mark a block obsolete by setting its header fields to zero, but when we run out of free blocks, then we go looking for sectors that are full of obsolete blocks waiting to be erased. When we encounter a sector that has been erased, we write a new header at the start and proceed to use its first data block.

In the case of erasing, we don’t bother writing anything out, we just mark the blocks as obsolete.

Implementation

The full C code is in the Codec2 Subversion repository. For those who prefer Git, I have a git-svn mirror (yes, I really should move it off that domain). The code is available under the Lesser GNU General Public License v2.1 and may be ported to run on any CPU you like, not just ST’s.

2015/09/27 by Redhatter (VK4MSL) Amateur Radio Bicycle Mobile Computing FreeDV Homebrew Open Source Public Syndication Thinktank 0

Chip Manufacturer shenanigans

Well, a little nit I have to pick with chip manufacturers. On this occasion, it’s with ST, but they all do it, Freescale, TI, Atmel…

I’m talking about the assumptions they make about who uses their site.

Yes, I work as a “systems engineer” (really, programmer and network administrator, my role is more IT than Engineering). However, when I’m looking at chip designs and application notes, that is usually in my recreation.

This morning, I had occasion to ask ST a question about one of their application notes. Specifically AN3969, which deals with emulating an EEPROM using the in-built flash on a STM32F4 microcontroller. Their “license” states:

   License

      The enclosed firmware and all the related documentation are not covered
      by a License Agreement, if you need such License you can contact your
      local STMicroelectronics office.

      THE PRESENT FIRMWARE WHICH IS FOR GUIDANCE ONLY AIMS AT PROVIDING
      CUSTOMERS WITH CODING INFORMATION REGARDING THEIR PRODUCTS IN ORDER FOR
      THEM TO SAVE TIME. AS A RESULT, STMICROELECTRONICS SHALL NOT BE HELD
      LIABLE FOR ANY DIRECT, INDIRECT OR CONSEQUENTIAL DAMAGES WITH RESPECT
      TO ANY CLAIMS ARISING FROM THE CONTENT OF SUCH FIRMWARE AND/OR THE USE
      MADE BY CUSTOMERS OF THE CODING INFORMATION CONTAINED HEREIN IN
      CONNECTION WITH THEIR PRODUCTS.

Hmm, not licensed, but under a heading called “license”. Does that mean it’s public domain? Probably not. Do I treat this like MIT/BSD license? I’m looking to embed this into LGPLed firmware that will be publicly distributed: I really need an answer to this. So over to the ST website I trundle.

I did have an account, but couldn’t think of the password. They’ve revamped their site and I also have a new email address, so I figure, time for a new account. I click their register link, and get this form:

ST Website registration

Now, here’s where I have a gripe. Why do they always assume I am doing this for work purposes? This is something pretty much all the manufacturers do. The assumption is WRONG. My account on their website has absolutely nothing to do with my employer. I am doing this for recreation! Therefore, should not, mention them in any way.

Yet, they’re mandatory fields. I guess ST get a lot of employees of the “individual – not a company” company.

I filled out the form, got an email with a confirmation link which I click, and now this is something a lot of companies, not just chip makers, get wrong. Apart from the “wish it was” two factor (you can tell my answer was bogus), they dictate some minimum requirements, but then enforce undisclosed maximum requirements on the password.

ST Website password

WTF? “Special” characters? You mean like printable-ASCII characters? Or did a vertical tab slip in there somehow? Password security, done properly, should not care how long, or how complex you choose to make your password: so long as it meets a minimum standard. A maximum length in the order of 64 bytes or more might be reasonable, as might be a restriction to what can be typed on a “standard” US-style keyboard layout may be understandable.

In this case, the password had some punctuation characters. Apparently these are “special”. If they restrict them because of possible SQL injection, then I’m afraid ST, you are doing it wrong! A base64 or hex encoded hash from something like bcrypt, PKCS12 or the like, should make such things impossible.

Obviously preventing abuse by preventing someone from using the dd-dump of a full-length Blu-ray movie as a password is perfectly acceptable, but once hashed, all passwords will be the same size and will contain no “special” characters that could upset middleware.

Sure, enforce a large maximum length (not 20 characters like eBay, but closer to 100) so that any reasonably long password won’t overflow a buffer. Sure, enforce that some mixed character classes be used. But don’t go telling people off for using a properly secure password!

2015/09/26 by Redhatter (VK4MSL) Amateur Radio FreeDV Public Syndication Rants 0

Hand-held radio musings

Just recently, I managed to kill yet another hand-held. Not deliberately, just a combination of conditions and not adapting my behaviour to suit.

I have a Yaesu VX8-DR, which I mainly use on the bicycle for APRS. It isn’t bad, the GPS could be faster, and the Bluetooth is more of a gimmick (in that it only works with some Bluetooth headsets and is intermittent at best), but my biggest nit with it, is that you can’t charge the thing while it’s turned on.

This leads me to the bad habit of just leaving a DC power lead semi-permanently plugged into the side, with the other end plugged into the 12V supply on the bicycle. You guessed it… one bad day of rain, some water got in via the DC jack and basically destroyed it. I’m pretty sure warranty doesn’t cover that kind of abuse.

I’m not in a hurry to buy another one. In fact, I probably won’t. I’m too clumsy to look after an expensive one, so better just to keep the two Chinese cheapies going (Wouxun KG-UVD1P’s). This lead me to thinking about what I specifically like in a hand-held, and what features I’d look for.

Looking around, it seems the vast majority of sets out there are evolutionary. An extra handful of memory channels, higher power, bigger battery, ohh look Bluetooth, and this one has {insert some semi-proprietary-digital-mode here}. Yawn!

Most of them have tiny screens which can’t show a decent amount of information at a glance. Digital voice is a long way being usable, with about 3 or 4 proprietary or semi-proprietary competing standards. What about D-Star you say? Well, what about it. Nice mode, pity about the codec. How about P25? Same deal.

If a digital mode is going to succeed in Amateur radio, it’ll be necessary for a home base to be able to implement it with nothing more than a desktop or laptop computer loaded with appropriate Free Software and a sound card interface. Not a silly proprietary “DV-Dongle” or some closed-source blob that speaks gibberish no other software can understand.

As for portable use; it should be possible for a hand-microphone that implements the mode on a DSP be plugged into an existing hand-held (like the Wouxun or Yaesu sets I mentioned earlier) to make it interoperable — open standards will help keep costs down here.

Until such a mode comes along (and they’re working on it — already making excellent progress on HF, keep it up guys!) there’s no point in pouring money into a digital mode that will be a white elephant in a few years.

By far the most popular mode on VHF and UHF is plain old FM. The mode Armstrong made. It’s everywhere, from your cheap $100 Chinese firecracker set to the most expensive SDR, they all offer it. Repeaters abound, and it’s available to pretty much all amateur license classes. And it works good enough for most.

The big problem with FM, is interfacing with repeaters. In particular, the big use case with hand-helds and repeaters, is being able to recall the settings for a repeater where ever you happen to be. Now you can carry around a booklet with the settings written in, and punch them into your radio each time.

This works better for some than others. On the KG-UVD1P with its horrid UI, it is a tiresome affair. The Yaesu VX-8DR and Kenwood TH-F7E aren’t bad, once you get used to them. It’s still fiddly and time consuming, definitely not an option while mobile. This is where memory channels come in.

Now I realise that sets which stored more channels than you could count on one digit-challenged hand were considered a revolution about 10 years ago. Back then the idea that you could basically control a digital counter, which would supply an address to an EEPROM that would spit out the settings to drive a PLL synthesizer and other control circuitry was truly remarkable.

Today, the EEPROM and counter have been replaced by a MCU that reads the keypad matrix and outputs to a LCD panel, but we’re still basically incrementing a counter that’s acting as an address offset into non-volatile memory. The only change has been the number of channels. The Kenwood set I had gave you 400. The VX-8, gives you 1000 — which can be optionally grouped into 24 banks (by far the best system I’ve seen to date). The Wouxun gives you a poultry 128.

The hardest thing about this is finding a given repeater in a list. 128 is more than enough if you don’t travel, or if you pre-programme the set with the appropriate channels in some logical ordering before you leave. In there hints another factor; “logical ordering”, since there’s no way to sort the memory channels by anything other than channel number.

In this day and age, 1000 channels, linearly indexed, is a joke. I can buy a 2GB MicroSD card from the supermarket for $10. How much repeater data could you store on one of those? FAT file system drivers are readily implementable in modern MCUs and a simple CSV file is not that big a deal for a MCU to parse.

It wouldn’t be difficult to build up a few indexes of byte locations to store in NVRAM, and have the CSV store frequency, call sign, a Maidenhead locator and other settings of all the repeaters in the country, then allow the user to choose one searching by frequency, by call-sign, or if the user gives their current grid square (or it derives it from a GPS), by proximity. That would be a revolution. The same card could also store a list of Echolink and IRLP nodes, and make a note of such nodes via RF so it can automatically suggest the nearest IRLP node, take you there, then dial whatever node for you after you announce yourself on the frequency.

I’ve seen more elaborate software written for 8-bit micros like the Apple II, the Commodore 64 and the Sinclair ZX Spectrum back in the day, so clearly not beyond today’s equally powerful AVR, PIC, MSP430 and ARM chips. A STM32F103RE packs 64KB RAM, 512KB flash and a SDIO interface in a nice small TQFP64 package and costs less than $8. Even for a Wouxun, that’ll maybe add no more than 20% still keeping it rather competitive with the opposition.

As for user interface? We don’t need Android on there, although that could be nice. A decent size resistive touch-screen with a reflective dot-matrix LCD would more than suffice. This technology, thanks to mobile phones, is cheap enough to implement in this application. The MCUs needed to drive them have also come down in cost greatly.

Even without the touch-screen — a LCD bigger than a matchbox would allow for text that is easily readable, menus that aren’t constrained in their presentation, and a generally nicer user experience.

SDR hand-helds will likely be the next big revolution, if they are affordable, but I feel that’ll be a way off, and for rag chew on a local repeater, I doubt SDR will be that much superior. It certainly will push the price up though.

I suppose a start will be to try and come up with a suitable front-end device that can be bolted onto existing transceiver hardware, maybe something that drives the computer control port of a mobile rig such as the FT-857 or IC-706.

From there, it just takes one brave manufacturer to package such a device up with a suitable transceiver in a hand-held form factor to put something to market. If they did so in a way that could keep this UI module open-source, even better. Bonus points if there’s a bit of an interface that can take a DSP for digital modes.

Want D-Star, P25, FreeDV, Wongi? You got it, just slot in the right module, load on the firmware into the UI module, and away you go. Want to do something special? Break out the text editor and compiler and start hacking. The RF side of things can still be as it was before, so shouldn’t pose any more of a problem for regulators than a transceiver with a digital modes jack and computer control interface.

I’m not sure if anyone has worked on such a front-end. Another option would be a cradle that takes a modern smart-phone or tablet, interfaces via USB to the set, and uses the smart-phone as the UI, also extending the phone’s battery at the same time by supplying the 5V it needs to charge. Bonus points if it can feed the audio signal to/from the phone for digital modes and/or interfacing with BlueTooth. A pocket APRS I-Gate and Echolink node, perhaps? Whatever takes your fancy.

I guess the real answer here will be to come up with something and see if there’s any interest — the “throw it against the wall and see what sticks” approach.

2013/03/08 by Redhatter (VK4MSL) Amateur Radio Public Syndication Rants Thinktank 0