Author: Tommy

This is a continuation of a two part series about how to configure hamlib for Linux ham radio users.
To get started, be sure to read through Part 1.

In the last post, I pointed out that hamlib was create to simplify the once fragmented world of computer control for amateur radio. With hamlib in place, developers can interact with hamlib which serves as an abstraction layer of sorts for software development. Developers don't need to worry that you're running a particular model of radio, so long as you get your radio working with hamlib, your radio is supported.
I'm going to assume you have /dev/radio and /dev/rotator already configured (since we did that in the previous post). Now, we're going to configure the daemons (servers) that allow a myriad of radio related applications to interact with your amateur radio equipment.

Daemons
Hamlib centers around two core daemons: rigctld and rotctld. The daemons receive commands from applications via TCP. It is possible to have these daemons controlled via the network if you so wish. That functionality is a bit beyond the scope of this article, but the concepts below are exactly the same and just requires the correct ports be opened. Speaking of ports, rigctld and rotctld use ports 4532 and 4533, respectively. Also note that there is no security built into these devices. Should you need external connectivity, you should create an SSH tunnel.

Find your equipment
The first step in configuring rigctld is to find if your particular radio (and rotator for rotctld) is supported. Here is a list of all supported radios for rigctld (chances are, if it's a modern radio with computer interface, it's supported). For rotctld, things get a little more difficult. In order to see if your rotator controller is supported, you need to identify which protocol is supported. As I stated before, my rotator is a Yaesu G-5500 and my interface is the ARRL Satellite Tracker Interface. I know from prior experience and documentation this uses the EasyComm 1 protocol. Armed with this information I can proceed with configuring each daemon independently.

Gathering Radio Settings Information
Now that we know our radio is supported, we can determine all of the command line options necessary to setup rigctld. My radio is a Yaesu FT-847, so I'll be using that for my examples - adjust accordingly. For starters, we need to be on the command line so open Terminal or a shell. This whole time I've been referencing rigctld, but for initial configuration and testing we're going to use rigctl. The two programs are essentially the same except the daemon is "headless" (no uder interface) listens for commands via a TCP port. rigctl gives us an internal command line wherein we can issue commands to check communication with our radio. Both rigctl and rigctld require 3 pieces of information, although you can get by with only 2 (we'll give it 4 just to be specific and safe).
The first information rigctl wants to know is what kind of radio are you using. You can find rigctl's list of radios by issuing the following command

(That's a lowercase L, by the way - short for "list") That's going to be a long list though. You could scroll and find your radio or you can pare it down with grep
:
That's more like it. Now I only see the line of info for my FT-847. The key information we're after is the number on the left. In this case, 101.

The other pieces of information rigctl wants are the device name and the speed at which we'll communicate with the device. For the name, we created the symlink /dev/radio using udev in the previous HOWTO. For the speed, you'll need to check your radio's menu settings. It should be be something like CAT rate, COMM rate or Serial rate (refer to your manual for assistance). I currently have my FT-847 set to 9600 baud, though it's capable of 57600 and 4800 as well. rigctl takes our pieces of information in the form of command line arguments which are -m for model, -r for device (rig) and -s for speed. Another argument we'll pass to rigctld later on, just to be specific, is -t for TCP port. note: you Icom users will need to specify the CI-V address of your radio using the -c argument.

Running and testing rigctl
To establish a connection with the radio, we'll issue the following command:
Once rigctl is up and running, you'll be able to issue commands to the radio directly to either read a setting or set a setting. If you have successfully started rigctl, try issuing the "read frequency" command. To do this, simply enter f by itself and press enter. The radio should respond with it's current frequency in Hertz.
To set the radio's frequency, enter F followed by the frequency in Hertz. (In hamlib, capitalized letters set, lowercase letters get)

Switching over to rigctld
If everything has checked out thus far, we can now quit rigctl (enter q) and begin moving over to rigctld.
Essentially, you can run rigctld with the exact same settings as rigctl. For safety, I also issue -t 4532 to specify the port I want rigctld listening to. This is the default port and is unnecessary, but it's nice say exactly what you mean even when it's implied. :)
So, to start rigctld, we run something like the following:
(You can run the command above with an ampersand at the end to "background" the process, but for the time being it's unnecessary.)

With the daemon running, you should now be able to interact with your radio with you program of choice. If you do not yet have a program installed, check out grig which should have come with hamlib. grig is a Graphical Rig that gives you a generic radio graphical interface where you can change frequency on the screen and see the frequency change on the radio and vice versa. It's nothing special and you probably will get a more useful interface with your application of choice, but this is a good testbed.

To keep things tidy (and so I don't have to manually run rigctld everytime I boot up, I created an entry in rc.local (found in /etc) to run with the same settings I used above. (Just remember to "background" the process by putting a & at the end.

Now with rotctl...
Configuring rotctl and rotctld isn't all that different from rigctl. Refer to the man page for rigctl for specific command line flags for it, but you should have no difficulty if you already know the rotator controller's protocol. It's very satisfying to issue a command to rotctl and hear the rotator turning and see the indicator needles moving.
My setup looks like this:
Once you have rotctl setup how you like, create an entry in rc.local using rigctld, configure your application for the appropriate settings (remember rotctld likes port 4533 by default) and enjoy the fruits of your labor. (Again, don't forget to background the process with & at the end of the line in your rc.local entry.

Final Overview
So, with everything working correctly, I shouldn't have to do anything to get the functionality I want. udev detects our device connecting our radio and rotator and creates the symlinks of our choosing. rc.local, after the OS has mounted the devices, will startup rigctld and rotctld with the settings specific to our radio and rotator. All that's left is to run our application of choice (CQRLog, gpredict, fldigi, etc) and configure the application to talk to our daemon running on localhost.

Overall, the whole process is not too terribly complex. It's a few new steps you may not have done before, but in the end it all works out nicely. 73 and good DX!

Linux and ham radio, where two of the geek worlds collide. Fortunately, with so many geeks involved in both pursuits, a lot of great tools have emerged. Unfortunately, documentation on how to configure some of it was hard to come by. (At least, it seemed that way to me.) Here, I hope to layout as quickly and easily as possible the steps required for other hams to configure hamlib on their linux computers. I'm going to assume you're running a modern version of linux and have a USB connection to your radio and/or rotator.

What is Hamlib?
First of all, Hamlib is a set of ham radio control libraries that allows amateur radio operators to control their radio and antenna rotators via their computer. Hamlib abstracts many device-specific control issues from application developers, allowing for a more robust user experience across several programs. Prior to hamlib, there were several different tools and libraries. None of these tools provided a common API for programmers to interface. As a result, the application landscape was fragmented and functionality suffered. Now, with hamlib, programmers can utilize hamlib to interact with a whole range of devices.

Interface
To use hamlib, you must first have a computer interface cable from your radio to your computer. Without this, everything else here is pretty useless. If you don't have a cable yet, look on eBay for cables tailored to your radio. (It's where I found mine.)
My radio is a Yaesu FT-847 which has a DB9 serial port for CAT computer control. To interface with my computer, I use a cheap USB-to-serial adapter - nothing special. My antenna rotator is a Yaesu FT-5500 with the brilliantly simple WA8SME Satellite Tracker Interface from the ARRL.

USB, Linux and udev
Most modern distributions of Linux include a subsystem to handle when USB devices are inserted. This system will detect the device, query what sort of device it is then attempt to mount the device (commonly in /dev). For my setup, I'm running Ubuntu 12.04. When I plugin my radio interface (the USB-to-serial adapter), the devices gets mounted as /dev/ttyUSB0 or /dev/ttyUSB1 (depending on whether or not my satellite tracker is plugged in and the order in which they are connected, etc.) Herein lies the problem for most linux-using hams. Unless you want to manually determine (ick!) which port your radio is connected to and which one your rotator is connected to every time you reboot or reconnect the device, you need to have a device name you can count on. Thankfully, we have udev.
udev is a tool created just for such a need. udev allows you to specify a device based on it's manufacturer and device ID and give the device a name (symlink to the actual device) and/or launch a program upon insertion (a lot like AutoPlay in Windows). In Ubuntu, you specify these rules in files found in /etc/udev/rules.d/, other distros will have udev rules located in a similar directory. When you locate your udev rules, I would recommend you create one titled hamlib.rules.

Device identification
There's a lot of ways to specify a device in udev, but I'll cut to the chase. I discovered this great guide from Hack-A-Day while configuring my setup and it helped me get started. In the Hack-A-Day tutorial, he's configuring a thumbdrive, whereas we're trying to configure a /dev/tty device, so we'll diverge a bit. The steps we need to follow, at least initially, are the same.
First, we need to identify the device we want to use:
From this screen, we're looking for the device ID. If you have more than one serial interface, you may need to unplug one of your devices, run lsusb again, see what disappeared then reconnect, and run lsusb. The information we're looking for are the two 4-alphanumeric strings immediately after ID on the row associated with your device. Here's a line for my USB-to-Serial adapter:

In this case, I'd take note of 1a86 and 7523. (The number on the left of the colon is known as the idVendor and the number on the right is the idProduct.) Your numbers will almost certainly vary, so don't use these numbers find the id numbers associated with your device.

udev Rules
Armed our device ID, we can now proceed to build our udev rules. udev operates by running a series of checks which are defined by rules. These checks are "equal to" (==) and "not equal to" (!=). There are others, but these two are all we'll use.
To define our rules, open the hamlib.rules file we created earlier (in /etc/udev/rules.d/ or someplace similar). I want to show you the file I created, then explain what each piece does. Here are the contents of my hamlib.rules file:
The first line essentially says "System, if the device isn't a tty device, jump down to "hamlib_end", (which, surprisingly, is the end of our file). This is just a way to have the system skip running any checks that aren't associated with our tty device needs.
The second line is a comment and helps differentiate which rule is associated with which device.
The third line starts with checking the idVendor field of the attributes for a device. If that checks out, it looks to the idProduct. In effect, it's saying "if the idVendor is _____..." and "if the idProduct is ____..."
The next part of the third line checks to see if a device named /dev/radio already exists. If it doesn't exist (not eual to), then move on to the next part of the statement. (One thing I didn't mention: if any one part of this statement fails, the rule fails and it moves on...)
The final part of this statement (SYMLINK) creates the symbolic link with the name we specified. Notice we're using a special += to assign the name of the symlink.
The last line creates the label "hamlib_end" so the first line can skip to the end.

Now, with this rule in place, whenever the system encounters a device that has been plugged in, it will not only mount the device but also create a alias /dev/radio that points to the device, whatever it is actually mounted as.
One last thing you'll need to do in order to enable this rule is to reload the udev service or reboot. To reload in Ubuntu:


That's it, your device should now showup when you check for it. Run the following command to see if it checks out:

Group Permissions
Permissions, permissions. If you notice the permissions on /dev/ttyUSBx, you'll see it belongs to the group dialout. (This is a throwback to the days when tty devices were used to dialout to BBSs and other services via modems.) In order to use this, simply add yourself to the dialout group. You can do this with usermod, groupadd, or by using your favorite text editor to open /etc/group and append your username to the end of the line for dialout:
Once you're part of the group, you're device is now available for you to access with rigctl (or rotctl if it's a rotator).

Continue on to Part 2 to configure rigctld and rotctld...

This is something I thought today during a meeting...

I recently learned we have had several students not report *all* institutions they've attended before. (Ex: One student "forgot" to mention they had taken courses with Univ of Phoenix for ~70hrs and stopped attending. Univ of Phoenix is holding that student's transcript until they settle up on their bill. [Transcripts are the one thing a school can hold over a student for failure to pay.] It came to light when the student's Financial Aid was processing...)
School's usually require this because prior scholastic work is taken into consideration when placing the student in courses, academic standing, etc. and ensures a students will make good on their financial obligations - like a gentlemen's agreement among institutions. I asked in our Registrar's office what happens if a student doesn't divulge all schools they've attended, "What's the worst that could happen to them?" "It could get them suspended from our school." In the grand scheme of things, so what? They could move down the road to another school and take classes there. It would be a huge headache for the student, but a driven and motivated student could navigate the system and get their degree one way or another from some institution. (especially from certain schools that are willing to do anything to get money and could care less about the other schools down the road...)

So. What's the big deal? The trouble is Financial Aid fraud.
Unscrupulous individuals will solicit the school for financial aid, scholarships, grants, etc. in hopes the grants and loan money comes to them directly and/or any overage in scholarship/grant money gets sent to them directly, all the while never intending to *actually* take classes. Before any financial aid is disbursed, the student will usually sign a short-term loan with the school to cover the courses in the meantime. Once they're counted "present" in class, the Financial Aid will pay out, the short term loan is dissolved and federally backed funds cover the expenses. If those funds get intercepted by the student somehow, (I'm no expert on FA fraud.) the school has loaned out money for books, living expenses, etc, expecting to get the federal money. However, that money never materializes and the school is left holding the bag.
The fraudulent student will repeat this process at one school after another for quite sometime, never reporting their prior enrollments for obvious reasons.

If there was a way to report a student's enrollment, I believe part of this fraud and waste in the Financial Aid system could be cut.

It seems to be that there should exist some sort of central database wherein schools can mark that a student was enrolled for X semesters at their institution and if they are in good standing or not. (Almost like an academic credit reporting system.)

The Academic Records office at each school would submit to the database the student's name, social or ID number, place of residence and status.

This could be beneficial in several ways:

1. A student would have a tougher time "gaming" the system as stated above.
2. A graduate of a school could easily verify their degree and alma mater without submitting transcripts. (At the click of a button employers could check where/when an individual attended.)
3. students looking to claim residence to avoid "out of area" tuition would be flagged for the residences on record.
4. Law enforcement/immigration officials would have another easy-to-access paper trail to follow.
5. colleges would have a snapshot view of a student's academic history with contact info for each of those record-keeping institutions.

It would definitely require a joint effort by all institutions for this to work, much like credit reporting; but it would be for the betterment of all higher education, across the board. Perhaps the Department of Education could organize it? Maybe accrediting bodies would require their schools to submit to this federal register. Or they, themselves, could own databases which are shared among the accrediting organizations as stipulated by the US DoE.

Most people are aware that every day weather satellites pass overhead to get a glimpse of the nation's weather patterns. Many people, especially those outside the ham radio community, are unaware that the signals these NOAA weather satellites transmit are readily accessible with a minimum amount of equipment. These satellites use a technology known as APT, or Automatic Picture Transmission. NOAA-19 is perhaps the easiest APT satellite to receive because it provides the best, strongest signal for visual satellite imagery. Because of this, we'll focus on NOAA-19 for this post.

Hardware
All you really need to receive the satellite's signal is a radio receiver like an old police scanner (found at thrift stores) or a simple 2m ham radio handitalkie (like the Baofeng UV5R). An external antenna is usually better, but not a requirement for casual reception of the image. Other than the radio, the only other pieces are a computer with sound input and an audio cable (to get the audio out from the radio to the input on the computer).
If you would like to get the best images possible from every pass of the satellite, use an outdoor antenna connected to your radio. Discone antennas for scanners work well, as will any 2m amateur radio antenna. These antennas do suffer from "fades" where the gain of the antenna is weakest. To minimize these anomalies, eggbeater antennas or the very common quadrifilar helical antenna are used by serious hobbyists and weather professionals.

Software
Once you have the required hardware, download the free WxToImg software which is available for Windows, Mac and Linux. There are other features and enhancements to the software if you upgrade, but it's still not a requirement.
Once the program installs, the first time you start the program you will be prompted to enter your Latitude and Longitude. This information is vital to synchronize the timing of the satellite pass. To locate your longitude and latitude, you can use a web tool like iTouchMap, Google Maps, a weather site or any other means. A help menu will appear showing the calibration steps which I'll cover later.

With the software installed, there are a few settings to change to prepare for our first APT satellite pass. Below is a listing of the various settings I've found that work best for the NOAA 19 satellite.



Keplerian Elements
With these settings in place, you can now download the latest Keplerian Elements within WxToImg. The "Keps", as they're known, are mathematical values that are used in formulas to calculate the exact position of a satellite in relation to a given point on a map. Keps are sometimes referred to as TLEs, which is short for Two Line Elements, because of the two lines of values that represent a satellite's orbit. With this information, any satellite's relative position can be determined by simply providing the latitude, longitude, altitude of the observer and the keps for the satellite. You already gave the software your latitude and longitude, now provide the latest keps and the computer will have all the data it needs to predict the next pass.
To update the Keps for WxToImg, click on File then choose Update Keplers

Doing this action will download the latest elements from CelesTrak which hosts large lists of all the latest elements for many, many satellites as published daily by NORAD.

Audio
Now that the software is configured, there is really only one last piece of the puzzle and that involves setting the audio level. WxToImg requires the volume of the incoming signal to be within a particular range. Too low and the computer can't hear all the tones. Too loud and the computer can't discern between the various tones being sent by the satellite. Thankfully, to aid in this balancing act of getting the audio set "just right", WxToImg provide an audio level indicator in the bottom right corner of the screen. This feature is only active when the Record process is activated. Under File, click on Record, then at the bottom of the screen you will see "Manual Test". Click the Manual Test button to tell the software to begin listening. You can then adjust your microphone or line-in audio level. In the right corner you will see a yellow, green or red colored bar with the text vol: 50.2 or similar. Adjust your volume so the audio level color is green (this will be somewhere in the 45 - 80 range, give or take).
Once the audio level is set during the Manual Test, click on File > Stop. You may then clear the screen by clicking File > Clear. Your audio is now setup and ready to record the next pass.

Satellite Pass
To learn when the next pass of NOAA 19 will be for your location, click on File > Satellite Pass List. The date of the pass will be shown along with the number of passes per day (usually 2) for a given satellite. (Because we selected NOAA 19 as the only active satellite, our pass list will only show NOAA 19 passes.) Included in the pass list is the direction of the pass (N = northbound, S = southbound) along with the Maxium Elevation, shown as MEL. MEL will show how many degrees from the horizon, East or West, the pass will reach its maximum perceived altitude. The duration of the satellite's pass (anywhere from 11-12 minutes) and the time of the start of the pass (both UTC and local time). The table will also show you the operating frequency the radio should be tuned to. (In the case of NOAA 19, it shows 137.100 MHz.)

Radio
Of course, none of the process will work without a radio tuned to the satellite's downlink (transmitting) frequency. As noted previously, the NOAA 19 satellite transmits at 137.100 MHz, so it is vitally important that your radio be capable of tuning this frequency. It is also important that the radio selected for this project be capable of "Wide FM" and not the "Narrow FM" used for amateur and commercial radio services. APT Satellite signals are 34kHz wide, which is wider than the 6kHz and 15kHz of Narrow FM. Wide FM is most commonly used for FM Broadcast stations which are very wide at 230kHz. Ideally, the radio chosen will have the ability to filter somewhere in between these extremes - wider than Narrow but narrower than Wide - however, few radios offer adjustable filtering. Because of this, for practical purposes, overly wide is better than not wide enough. (FYI: receivers like the Hamtronics R139 offer 34kHz width IF specifically for receiving APT signals.)
Once an adequate radio is selected and tuned to the proper frequency, it is not necessary to set the squelch on the radio. Because the audio will be going directly from the radio's headphone port into the computer, leaving the squelch fully open is perfectly acceptable. The computer will not record the audio (thus ignoring all signals) until the satellite is within range. It's better to leave the squelch fully open to begin with so the radio receives even the faint signal of the satellite while it is near the horizon. Once the receiving technique has been mastered, it is possible to fine tune the radio's squelch but, again, this is not necessary as the computer will reject all unexpected radio signals until the satellite is within range.
With the radio tuned and ready to go, all that remains is to connect the audio output of the radio to the computer's input via an audio cable (typically a ⅛"-to-⅛" stereo cable). It may be necessary to further adjust the radio's and computer's audio levels during a live pass to ensure a good copy. (to get the volume level in the green) However, once the audio is set it should seldom if ever need further refinement.

Finally...
The final piece of the puzzle is to set the recording options. Click File > Record to open the Recording menu. Check the box next to Create image(s) then click Auto Record. Doing so will send WxToImg into a "monitoring mode" where it will await the next satellite pass (displayed in the bottom left corner of the application window).
When the time arrives, it may be a good idea to physically monitor the screen as the image is downloaded to ensure a good copy. The big thing to check as the pass begins are the audio levels, especially on your first pass.
Do not expect to get a pristine image your first pass, this is merely a "tuning" pass to ensure everything is in working order.
After the pass completes you may need to adjust the Slant Correction or Move Image Overlay which are both available under the Image drop-down menu. You can later configure other features to automatically upload your images to an FTP server for archiving and alter the Image Settings from within the Recording menu.

Good luck with your recordings!

update: For much more in-depth information, check out NOAA's User Guide for Building Receive Stations or one of the countless other APT Satellite guides online.

Last week I got my newest toy in. It's a USB DVB RTL Receiver featuring the Realtek chipset beloved by radio enthusiasts. The chip functions by receiving radio signals and converting them to audio streams which the computer can decode/demodulate using software. The software tells the chip what frequency to tune to, and demodulates the signal. This concept is known as a Software Defined Radio or SDR for short.

The Realtek is cheap and agile enough to tune a wide range of frequencies (52 MHz-2200 MHz). Thanks to free (as in beer) software like SDRSharp, the "work" of setting up this complex sounding setup is almost trivial. (Especially if you use the install script in the downloads section of SDRSharp. Other websites can show you how to setup a trunking radio scanner for police/fire/EMS in your area. [So long as your local fire responders don't use a trunked P25 Phase II system])

If you're looking to get started, check out this USB DVB Dongle (any RTL2832U receiver should work). I would also recommend getting an antenna pigtail so you can use a bigger/better antenna for whatever frequencies you want to receive.