Sending Packet Radio beacons with ax25 ‘beacon’

The ax25 app ‘beacon’ does what it says, it sends beacon packets, by default every 30 mins, e.g.

beacon -c KK6DCT-6 1 "Hello from KK6DCT-6 node!"

By default the callsign will be what you’ve configured for your node/tnc, but you can change that with the -c param. The next param is the ax25 interface number from /etc/ax25/axports, followed by your beacon message.

Working Packet Radio with a VT132 and a AEA PK-232

I’ve posted before about using a VT132 terminal board to control a PK-232 packet TNC. Here’s a few more specific steps and commands.

On first startup after doing the * auto-baud detection, the first thing you’ll see is the “cmd” prompt. If this is your first time setting up, or if the internal battery is low and it’s not preserving your settings since last time, the first thing you’ll want to do from the cmd: prompt is set your callsign (set your own callsign here):

my KK6DCT
MYcall was PK232
MYcall now KK6DCT

If you’re working VHF packet, turn on VHF mode, with:

VHF ON

If it was off, now it’s on.

Set baud to 1200 for VHF packet:

HB 1200

Now enter D to disconnect, and we’re ready to send some packets. To re-enter this command mode, press Ctrl C.

By default the PK232 has a MPROTO value of OFF which doesn’t display any received packets other than those sent to your callsign. Set MPROTO ON and you’ll display other packets heard.

Additionally, the default value of MON as 4 will show some but not all packets. Set MON 6 to display all packets decoded. If you’re hearing other packets but they’re still not being decoded, enter WHYNOT ON to get an explanation.

At this point you’re ready to go. C NODENAME to connect to a nearby node!

Revisiting Packet Radio on a Raspberry Pi using Direwolf

It’s been a few years since I last played with Packet Radio on a Raspberry Pi, but I have been playing with the uz7ho soundcard software recently and have some packet APRS via the International Space Station.

Looking back at the Direwolf and ax25 setup I was playing with before, I couldn’t actually remember what the order of commands was to get things started up, despite still having it all still configured and installed on the same Pi that I used before. Assuming ax25 and Direwolf are installed and configured (see here and here), the steps to get ax25 up and running and connected are:

  • Start direwolf with: “direwolf -t 0 -p”
  • Note the /dev/pts/x value it returns on startup
  • Run: “sudo kissattach /dev/pts/1 1” (where /dev/pts/1 matches the same value from direwolf startup)
  • The second 1 is the network name from your axports file, like:

1 KK6DCT-5 19200 255 2 2m packet

Ensure direwolf.conf has the same callsign-ssid value, in my example here, KK6DCT-5

Ensure alsamixer has volume around 3/4 for your audio card

To find what audio card device you’re using, use: “axplay -l”. With a Signalink, this shows up as:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: CODEC [USB Audio CODEC], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0

The Signalink is card 1, subdevice 0, so the corresponding config in direwolf.conf for this device is:

ADEVICEĀ  plughw:1,0

To summarize:

  1. Start direwolf, grab the /dev/pts/x value
  2. Start kissattach with the same /dev/pts/x value
  3. Now you should be able to “call 1 nodename” and get a packet connection out via Direwolf to your radio.

The single most valuable advice I can offer to new software developers

When starting out in software development or even learning a new language as an experienced developer, the most likely cause of most ‘I don’t know why this code isn’t working’ type questions is pretty simple:

What you think your code should be doing is often not what it’s actually doing.

This seems like an obvious observation, but it’s easy for even an experienced developer to get caught up in what they think their code is doing, and they forget to look at what it’s actually doing.

Next question: “ok, so how do I find out what my code is actually doing at runtime?”

Answer: you use a debugger. You step through your code and you compare what you think each line should be doing with what it’s actually doing. At some point you’ll find a line where you assumed the code was doing one thing but it’s actually doing something else. It could be the variable of a value that you were assuming to be a particular value but actually it’s something different and it results in a result that’s different from what you were expecting. It could be a condition you were assuming to be true is actually false. It could be a block you were assuming would always get executed but never is. There’s many reasons.

Learn how to use your debugger:

  • Practice stepping through your code
  • Learn how to set breakpoints
  • Learn how to set conditional breakpoints (break when a certain value or condition is met)
  • Learn how to inspect value of your variables
  • Learn how to change values at runtime – what happens when this value is 1 instead of 2?
  • Learn to break on an error
  • Learn how to step backwards to a previous statement (not all debuggers do this but it’s a useful feature)
  • Learn how to change code while you’re debugging

Knowing how to use a debugger is an incredibly valuable skill. It’s seems a given that as a developer you would learn to use and use a debugger as an integral part of your development, but all too often though when asked ‘why is this code not working’, if you ask ‘have you stepped through in a debugger to see why it’s not working?’ the answer is ‘no’.

Learn to use your debugger!