Mar 312013
 

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)

Mar 082013
 

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.

Mar 032013
 

This isn’t the first time I’ve commented about user interfaces.  This weekend has been particularly wet, and while I did have plans to get out of the house for a few hours, I’ve spent a week-end indoors.

This meant time to go tinker with a few projects, amongst those being my desktop configuration.  In particular, key bindings, and panel placement.

My desktop is largely based on what I was running when I was at university.  At this time, I was mostly limping around with aging Pentium II class laptops with display resolutions of 800×600 pixels.  No space for big spacious panels here.  I was running KDE at the time.

I frequently had a need to move windows around without the use of an external mouse.  The little writing boards that the university provides in its lecture theatres are barely big enough to accommodate a writing pad let along a laptop!  The laptops I had generally had the small track-point type cursor, which while usable, wasn’t great.

That, and small screen real-estate dictated a desktop which was space efficient and mostly keyboard driven.

Now, I could have gone the route of tiling window managers.  I recall trying out Ratpoison at one point, decided it wasn’t for me, and let it go.  I do like a little eye candy!  KDE 3.5 at the time provided a good balance, and wasn’t too bad on these machines.  Crucially, I was able to set up a couple of small panels around the sides of the screen, and set up key bindings to perform most operations.  Some of the common operations I needed were:

Key binding Action
Logo + Shift + M Move a window
Logo + Shift + R Resize a window
Logo + Shift + S Shade (roll up) a window
Logo + Shift + X Maximise a window
Logo + Shift + C Close a window
Logo + Shift + I Iconify (minimise) a window
Logo + Menu (now broken) Bring up launcher menu

You’ll note here I use the term Logo to refer to the additional modifier on some keyboards. Apple users will know this as the Command key. Microsoft users will of course call this the Windows key. On my Yeeloong, the key looks like a house in a white circle. FVWM calls it Mod4. I call it the Logo key because it usually has some sort of OS-vendor-specific logo associated with it.

I use this, rather than Control and Alternate, since most applications bind their operations to those keys, and ignore the Logo key. By requiring the Logo key to be used in command sequences, it leaves Control and Alternate for applications. Control and Alternate of course, still get used in combination with Logo to extend the command set. The key bindings in bold get used the most.

One key stroke did change; originally I had Logo + Menu as the key sequence to bring up the launcher menu. I found KDE 4 broke this, I could no longer assign the Menu key (the one that brings up context menus in Windows) to this action. I haven’t really settled on a suitable substitute, and of course, my current Apple MacBook does not have this key, so I use Logo+Launch instead (what shows the dashboard in MacOS X), a little more of a stretch, but it works.

The layout I settled on was to have a menu and task bar up the top of the screen, then status notification and pager down the right-hand side.  Each panel occupied no more than 16 pixels.  I made extensive use of virtual desktops, configuring 12 virtual desktops and assigning these to each of the function keys. So Logo + F5 meant, go to desktop 5. Logo + Shift + F5 meant, move window to desktop 5.

Thus I could juggle the laptop in my hands, launching applications, moving them between desktops, figuring out where I needed to be next and getting things ready on my way between lectures and tutorials.

Over time, KDE became unsuitable as a full blown desktop due to its memory footprint. I found myself looking around and for a while, I was running FVWM. After a bit of research I figured out how to set up the bindings in much the same way. I managed to get FVWM’s BarButtons to emulate the side panel, but have the panel just lurk in the background and be recalled when necessary. And of course, the root menu and icons shown on the desktop mostly removed the need for a task bar.

This worked well, until I got the MacBook. The MacBook’s keyboard does have function keys, but requires you to hold the Fn key to access them. So the “Move to desktop 3” operation which I do so commonly, became Logo+Shift+Fn+F3. A real finger-twister. I’ve just put up with it until now.

What’s replaced it? Well I’ve done some re-working. Icons on the desktop for iconified windows is good and well but you’ve got to be able to get at them. That, and getting at the menu with the mouse in one hand proved to be a hassle, so for those tasks, the task-bar is back with its launcher button.

The BarButtons has been given a title bar, and the EWMH working area has been set so that applications do not cover the task bar, or the BarButtons title bar, allowing those to be accessed with the mouse alone. The BarButtons can be raised or lowered with a new key sequence, Logo+Z.

The application switching was always a chore. This is probably the one exception to the Logo for Window manager command rule; I used the very prevalent Alternate+Tab to switch applications. FVWM does this out-of-the-box unsurprisingly. I found with a lot of applications though, going Alt-Tab,Tab,Tab,Tab just a little annoying.

Logo+A brings up the window list and the window list stays there until a choice is made. The windows are numbered with a digit, and one can use arrow keys to select. Much better.

As for the virtual desktops. FVWM has desktops and pages. What I was using as “desktops” before, were just pages of a single desktop. I decided that once again we’d do proper virtual desktops, but only 4 of them, with 4 pages each. That’s 16 “spaces” in total. But how to switch between them? With new key bindings:

Key binding Action
Logo + 1 Jump to Desktop 1
Logo + 2 Jump to Desktop 2
Logo + 3 Jump to Desktop 3
Logo + 4 Jump to Desktop 4
Logo + Q Jump to Page 1
Logo + W Jump to Page 2
Logo + E Jump to Page 3
Logo + R Jump to Page 4
Logo + T Jump to last page
Logo + Backtick Jump to last desktop
Logo + Tab Jump to last desktop and page
Logo + Shift + 1 Move window to Desktop 1
Logo + Shift + 2 Move window to Desktop 2
Logo + Shift + 3 Move window to Desktop 3
Logo + Shift + 4 Move window to Desktop 4
Logo + Shift + Q Move window to Page 1
Logo + Shift + W Move window to Page 2
Logo + Shift + E Move window to Page 3
Logo + Shift + R Move window to Page 4
Logo + Shift + T Move window to last page
Logo + Shift + Backtick Move window to last desktop
Logo + Shift + Tab Move window to last desktop and page

Then there’s the key binding Logo + Escape, which brings up a Jump To menu, where I can just press one of the numeric keys 1-4, which pops up a menu allowing me to select the page 1-4. So to jump to Desktop 4 Page 2, I just hit Logo+Escape, 4, 2. I’m still working on the move bit, while FVWM’s GotoDeskAndPage is documented and works, I’m having trouble with MoveToDeskAndPage, which seems to be undocumented.

We shall see on Monday how the new arrangement goes.

Accessing applications I think will be the next point to work on. I’m thinking about how to code a suitable launcher that can be summoned by FVWM. There are elements of common launchers such as the Windows Start menu, and its replacement, the Start Screen in Windows 8 that are good. The Program Manager was limited by its MDI interface, but the program groups meant there was a hierarchy that the Windows 8 start screen, and indeed, other contemporary launchers, lack.

The FVWM launcher isn’t bad — but it makes it hard to re-arrange items, there the old Program Manager really does shine. Want a new program group? Choose File, New, select Program Group, click OK, done. Want to add an icon to that group? Similar process. Adding and managing applications really does need to be that simple, so the end user can put things where they want them.

That, and keyboard accessibility is a must. FVWM has a little bug which is evident in this screenshot…

FVWM 2.6.5 as I have it now.

FVWM 2.6.3 as I have it now.

If you look at the menu, you’ll notice two things:

  1. There are multiple menu items with the same access key
  2. Where a menu item contains an ampersand, the space following is treated as the access key.

That’s a minor bug with FVWM’s AutomaticHotKeys. Fixable for sure. That particular menu is generated by a Perl script distributed with FVWM; I have a patch that tweaks it to put ampersands in appropriate places to give all the items access key assignments, but I think there are better ways.

In the meantime, those who are interested, my FVWM configuration is here. This will expand into the .fvwm directory.