Linux Mint 18 Has Arrived

Those of you who have followed my blog for a while may be aware that our household has relied upon Linux for years. Earlier on, it was Ubuntu, and then later I migrated to Linux Mint shortly after the Unity environment was released for Ubuntu. I do have a dedicated Windows box for use in my Etherkit shipping station and I have dual-boot Win 10 on my notebook, but I only use Windows when forced. Otherwise, I much prefer Linux Mint, even on my ham shack PC.

Today is an exciting day for us Linux Mint fans, as the newest long-term support release, version 18 (code name “Sarah”) has been officially released! Mint is derived from an Ubuntu LTS release, and the version 17 family was based on Ubuntu 14.04, which dates from 2014. Linux Mint 18 descends from Ubuntu 16.06, so there will be updates to the core software compared to version 17. (You can manually update most of these packages in an older release, but there’s always a risk of corrupting your installation, so it’s usually not worth it if you value stability).

Speaking of corrupting your system, I recently tried to update the kernel on my ham shack PC running Linux Mint 17.3 and messed up the system so bad it wouldn’t even boot. Rather than try to spend the time doing a recovery, I decided to install the Linux Mint 18 beta last week and give it a spin. My initial impressions from working with it over the last week are very positive. The shack PC is very modest, using a cheap AMD Athlon 5350 APU (I guess that’s their name for their integrated CPU/GPU/SoC) with integrated Radeon graphics. Under Mint 17.3, the Radeon graphic support was kind of terrible. The proprietary fglrx driver kind of worked but was glitchy as hell and the open-source driver had absolutely terrible performance. Under Mint 18 with the newer AMD open source graphics drivers, the machine performs as expected, which is a relief. The Mint-Y theme looks fantastic, and I think I much prefer it over the default Mint-X.

Linux has truly come a long way on the desktop. If you are a Windows user who has dabbled in Linux previously but found it a pain to get working, you should try Linux Mint 18 on live OS installation to see how far it has come. Much more “plug-and-play” than just a few years ago. Grab that ISO torrent, image it to a USB drive, and give it a whirl!


VOACAP For Linux

During some discussions with AA7EE regarding a seeming lack of 20 meter propagation between us at any time right now, we both decided to do a bit of research into what was even feasible according to predictive software. Dave went to the VOACAP web service from OH6BG to get some nice plots which showed that indeed it would be nearly impossible for us to make a 20 meter QSO right now.

The web site is nice, but being a Linux nerd, I wanted to see if I could find comparable software for my PC. A small bit of searching led me to VOACAPL from HZ1JW, and the matching package pythonProp, which gives a GUI frontend to the CLI VOACAP interface.

The installation of the VOACAPL software is quite easy if you are using Ubuntu. Just download the .DEB file and install using your favorite package manager. Installing pythonProp is a bit more involved, since there are a fair number of dependencies to install first, but as long as you closely follow the instructions on the website it shouldn’t be much of a problem.

If you are like me and the thought of tackling VOACAP through the command line was a little bit daunting, then the voacapgui tool (in the pythonProp package) is just what you are looking for. The GUI has three main tabs for interacting with the program: one for the site information (transmitter and receiver QTH, antenna, and power), one tab to execute point-to-point channel analysis, and one for generating area propagation maps.

As you can see above, the P2P tab can get you a nice plot of the probability of making a QSO over a certain path with the specified antennae and power levels. And since this is a Linux port of the program that Dave used on the web, the data we got back was nearly identical. No 20 meter QSOs for us right now.

Here you can see an area map showing circuit reliability for 7 MHz at 0300 UTC during Oct 2011 using 5 watts. That doesn’t look very good! (Sometimes I wonder if the predictions for low power are a bit out-of-whack. This software was originally written for VOA, so I wonder if it’s really calculating the reliability for a 5 W AM signal. I am a total novice at this, so I expect some VOACAP expert will probably put me some knowledge on this, as the kids say).

Any way, it’s a neat package to play around with if you have a Linux box. Many thanks to HZ1JW for taking the time to port VOACAP over to Linux in a easy-to-use package.


Sure enough, I made a mistake. Had I read the documentation more thoroughly, I would have seen that parameter Required SNR was set to a default suitable for SSB. At least I was onto the right idea a few paragraphs above. Here’s the same area plot as before, but with the Required SNR set for a suggested value of 24 for CW operation.

That looks better!

Operating, QRP



Like I don’t have enough ham radio interests to keep me busy, but sometimes I have the attention span of a hummingbird and want to try new things that catch my eye. Such was the case when I saw VK2TPM’s blog post about getting WSPR up and running on his Ubuntu Intrepid box (thanks for the tip of the hat on the other post, Peter!). I’ve heard quite a bit of rumbling about this MEPT stuff on the ham blogsphere, so seeing Peter’s instructions finally pushed me over the egde to try it. After a few false starts due to unresolved dependancies (I guess you could call it the Linux version of DLL Hell), I was off and running with the WSPR Python GUI. It seemed to work FB once I got it to execute, but I was having a real hard time reading the font in the widgets that showed the stations spotted. No big deal, since I could open the ALL_MEPT.TXT logfile to read them. I also can’t seem to get the spots to automatically upload to the spotting web page, but I am able to send the ALL_MEPT.TXT file manually.

WSPR Spots - 2322UTC 26 Oct 2008
WSPR Spots - 2322UTC 26 Oct 2008

Since the audio and PTT interfaces to the IC-718 were already in place, it was simple to start transmitting my own beacon packets as well. I set my power for approximately +30 dBm (1 watt) and let the program do its thing while I did other chores around the house. I came back a while later, and lo-and-behold, people were hearing me! I never crossed the pond, but did get across the continent (as you can see to the right). Not bad for a first try, but I’m hoping to haul my signal across the ocean for some DX. I’ll keep running the beacon for the next few hours to wait for the terminator to cross over me. I’m guessing I’ll have a better chance of getting my 1 watt heard in distant lands when I have the gray line working for me. Fun stuff, and easy to do if you already are set up for working digimodes.


First QSO!

WIIGII! Tonight I had my first QSOs with the new station! I was considering CW but I was feeling a bit sheepish about trying because I’m so out of practice right now. So I dragged out my homebrew sound card interface and homebrew CI-V level converter and hooked them up to the IC-718. A bit of fussing got everything working correctly (why is sound still so hard to get right in Linux?). 80 seemed like my best bet at 0200 local, so I fired up fldigi and double-clicked on the 3580 kHz line in the rig control window. I did a bit of tuning up on 3581, then fired off a PSK31 CQ. Right off the bat I got an answer from N4YZ in North Carolina. Not bad for 20 watts into a 70-foot piece of wire tossed up into the tree! It was especially nice since I can’t even remember the last time I had a QSO on 80. The QSB was really bad, so Tommie would be S9 at some intervals and completely gone at others. After a short QSO, I QSYed up to 40 meters and tried again. After a handful of CQs, I got a reply from K5DEY in Bedford, Texas. He had a very strong signal, but there was still some QSB on 40. We still managed to have a nice chat for about 20 minutes before Baxter woke up and started harassing me.

It was a great morning for ham radio and I’m as pleased as punch. Later this weekend I’m going to have to try a few CW QSOs…perhaps I’ll try some SKCC contacts since I haven’t racked up any of those in quite a while either. Since fldigi has a ton of digimodes built-in, I’m tempted to try some others as well. I guess I should also get my fill of operating and try some SSB as well. What madness!

Coding, FPGA

Configuring the Avnet Spartan-3A Eval Board on Linux (Alpha)

As I mentioned on the Avnet Spartan-3A Eval Kit Google Group, I’ve created a C program that will allow you to configure the FPGA via your Linux box. I don’t have a lot of time to elaborate on how to use this program, but the basic steps are listed below. These instructions assume that you are at least moderately familiar with using the shell in your distribution and building a program from source code. This code is in an alpha state and I have only tested this on my Ubuntu Hardy Heron box, so your mileage may vary. I’m sure there’s much I can do to improve it (clean up, refactor, etc.), but it seems to do what it needs to for now.

Right now, the program is controlled by three command line switches. I’ve created these options with a mind for expansion in the future (at least the serial flash part). Here’s the help printout from the program:

Usage: avs3a [options]
  -b, --bitstream=BITSTREAM	Bitstream used to configure FPGA
  -p, --port=SERIAL-PORT	Serial port connected to eval board
  -s, --slaveser		Configure FPGA in Slave Serial mode
  1. Download the source code here.
  2. Unpack the archive in the location where you intend to use the program.
    tar xzvf avs3a.tar.gz
  3. Change to the avs3a directory.
    cd avs3a
  4. Build the program from source.
    make all
  5. Make sure that your eval board is plugged into a USB port.
  6. If you don’t know the serial port of the eval board, then find it. I’m not sure what you will see, but on my Ubuntu Hardy box, my board enumerates as /dev/ttyACM0 or /dev/ttyACM1
    dmesg | grep tty
  7. Make sure you have a bitstream file to use.
  8. Issue the command to program the board
    ./avs3a -s -p /dev/ttyACM0 -b sample_bitstream.bit

If you try this and find it useful, or find a problem with the program then please, please, let me know in the comments below (or e-mail me). Thank you for testing this!

Coding, Microcontrollers

Programming AVR Microcontrollers in Eclipse

Lately, I have been using my Ubuntu Hardy Heron box for coding and programming my AVR projects using the simple combination of gedit, the avr-gcc toolchain and the USBtinyISP. It’s a little bit of a pain to get set up correctly, but it works very well once it’s up and running. I’ve been pretty happy with editing code in gedit then compiling and programming the AVR via command line. It’s pretty easy to quickly make changes to the code and save the C file in gedit, then use the command history of the terminal to re-run make and avrdude.

However, I recently ran across this posting when browsing the AVR Freaks forum. The author kindly gives instructions on how to set up the Eclipse IDE for use in AVR development on the Ubuntu platform. This looked really promising, since I’ve always been a sucker for nice IDEs (yes, I know that probably lowers my geek cred a few notches). So I gave it a go and found that the instructions worked nearly flawlessly. The only hiccup I encountered was at the very end of the build process when Eclipse was waiting for the sudo password for avrdude (oddly enough, you have to run avrdude as root to access the USB programmer, unless you implement a little workaround that I’ll show you in a second). I didn’t see any way to enter the root password into a terminal, so I had to cancel the whole process.

A bit of thought and much more searching brought me to the answer to the problem. There is a way to get non-root access to the USBtinyISP. You have to create a udev rule to tell the kernel to change permissions on the USBtinyISP. The documentation on the ladyada website tells you to do this, but it only gives you half of the story. First of all, it doesn’t mention exactly where to place the new rule that you are creating. Her documentation stated that I needed to put the rule in a file in /etc/udev/rules.d/. The problem is that this doesn’t state whether I need to place the rule in an existing file or create a new one. After a bit of trial-and-error and yet some more Google searching, I found out that I needed to create a new file for the USBtinyISP. So a new file named 50-usbtinyisp.rules was created. The other problem is that the actual rule given on the ladyada site seems to have a typo in the MODE parameter. Comparing this rule to some other rule examples, it appears that the correct rule is:

SUBSYSTEM==”usb”, SYSFS{idVendor}==”1781″, SYSFS{idProduct}==”0c9f”, GROUP=”users”, MODE=”0666″

Once you get the udev rule set up correctly, you no longer need root to access the USBtinyISP, and the entire build process in Eclipse works flawlessly.

So far, using Eclipse as an AVR development platform has been a real pleasure. There’s a lot of nice little touches, like having quick access to all of the special function registers of each device and easy configuration of the build parameters via GUI. If you are like me and like the convenience that an IDE gives you, then the AVR/Eclipse environment is an excellent choice, and may even be better than WinAVR.