I just updated the shack PC to Ubuntu Karmic beta and I’m impressed. Nothing earth-shattering, but lots more polish compared to Jaunty, and seems quite a bit snappier. I think it’s worth the upgrade if you’re already an Ubuntu user. If you are not, then download the ISO and try it in live CD mode. I think you’ll be pleasantly surprised.
WSPR-EEE Python GUI
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
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.
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!
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] 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
tar xzvf avs3a.tar.gzcd avs3amake alldmesg | grep tty
./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!
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.
Recent Comments