Tag: satellite

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...

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.

The fact that there's a space station orbiting above the globe right now has become somewhat passe in pop culture. Not many people are truly wowed at the news of it. Within seconds, a few clicks of a mouse will take you to hundreds of pictures and videos of the International Space Station; but did you know you can see the space station yourself? No binoculars or telescopes needed! I figured I would write up a HOWTO for the uninitiated. It isn't hard, it just takes a little know how.

For starters, you need to know a few terms used when talking about satellites (the ISS is a satellite of the planet Earth).

Azimuth
The first term when dealing with satellites is azimuth. Azimuth is a technical term that means the same thing as heading, bearing or direction. Most people are comfortable with the cardinal directions North, South, East and West. The cardinal directions are fine for general directions, but to know exactly where something is we need to be more specific. When dealing with an azimuth, a number of degrees is stated. 0° is North, 90° is East, 180° is South, 270° is West, and on around to North again. Kinda get the picture? It's a full circle divided into 360 degrees. (Also note, there's technically no such thing as 360° when dealing with Azimuth, because 360° would be the same as North, but that's already 0°.)

Altitude
It's not entirely what you think. Sure altitude means height, but we're not talking in feet or meters here. Remember, we're dealing with observational angles here, so knowing how high something is is of little consequence to us. Altitude in astronomy means "angle above the horizon". Altitude is expressed in degrees, just like azimuth. 0° is at the horizon, 90° is straight up. 45°, you guessed it, is right in the middle. Take a second and hold your arm out parallel with the ground. That's 0°. With your other arm, point straight up. That's 90°. Find 30° and then find 60°. Using these angles as references, you'll quickly be able to find a "close-enough" estimation about most any angle of altitude.

See? Not too hard. Now, let's combine the two.
Point of reference
A good starting point for know where the Space Station will approach from is to first find where North is. If you don't already know which way North is, you can use the Big Dipper to find the North Star which is "true north". Once you have North established, turn and face north. Straight ahead is 0°. Behind you is 180°. To your right is 90°, and to your left is 270°. (Incidentally, the angular altitude of the north star is your latitude on a map.) Now that you have azimuth figured out, you can add in altitude angles to see that you can quickly pinpoint any position in the sky day or night using these two values.

Finding our target
To be able to track the ISS, we need to know it's current position which is constantly changing as the station is in orbit. (It's moving at ~17,500mph!) Fortunately for us, there are several free websites that provide second-by-second positioning of the ISS. The main website that I use for celestial tracking (and perhaps the easiest to use) is N2YO.com. Open up the ISS link in another window or tab and let's look at the interface. N2YO tries to estimate your position based on your internet provider's geographic data. (Which something to be aware of, so make sure it's pinpointing your location correctly! As long as it's within 30-40mi, that's close enough for causal viewing.)
The N2YO screen should show you a table of information with varying degrees of yellow. The brighter the yellow, the brighter the ISS will be during a pass (known as magnitude. These yellow boxes are not the only times the ISS flies over. In fact, the ISS passes over about once every 90 minutes. (Yep, around the world in 90 minutes.)
To see all of the passes over your location, you can click on the grey button labeled "Show All Passes". Quite a few right? They are not yellow, because you will not be able to see the ISS during those passes. To hide the ones we can't see, click the grey button "Show visible passes only".

Reading the Information
To understand the table, read the columns left to right. The first column shows us the date of the pass along with the time you will first be able to see the ISS as it's coming into view, as denoted by the green UP arrow. (The satellite is said to be rising at that time) Times are expressed in military time. Numbers less than 1200 are morning, numbers greater than 1200 are afternoon/evening. To convert to the "normal time", if the time is greater than 1200, simply subtract 1200 from the number. The number next to time/date is the beginning azimuth. At the time/date stated previous, at the azimuth stated, the ISS will begin flying over your position at 0°.
The next column is the highest elevation of the pass, stated with a time and azimuth. Then, finally the end of the pass will be at the time and azimuth in the last column. Using this information and your newfound understanding of azimuth and elevation, you should be able to string along the three key points of the pass to determine the general direction of the entire pass (just connect the dots).
Brightness
Oh, yeah, a note on brightness. In astronomy, brightness is referred to as magnitude, as stated previously. The lower the magnitude, the brighter the object. The greater the magnitude, the dimmer the object.
I also suggest trying to spot the ISS on a clear night with little or no cloud cover, as few visual obstructions as possible, and pick a pass where the maximum altitude is greater than 45° and magnitude is -1.0 or lower. You may be able to see it lower altitude or higher magnitude passes, but you may easily miss it on the lower, fainter passes.

So, what am I looking for?
Phew! - you made it. Hopefully, I haven't scared you off. It really isn't as complicated as it may sound and you'll soon discover that casual viewing of the entire pass does not require you to pin point and measure angles. Once you see it, you'll be able to visually track the brightest and highest flying spacecraft ever. So what will it look like? The ISS will look like a quickly moving star. At times it'll be the brightest object in the night sky, flying very quickly. You'll know it's not a plane because its light does not blink. It also may appear to be going much faster than any plane flying so high up.
Those with binoculars might be able to barely make out the outline of the shape of the ISS as it passes directly over your position (>70° passes).

I hope you've found this helpful, I'll gladly update to clarify anything that may be confusing. Clear skies!


Reference: N2YO - ISS link

A local ham recently asked me the best way to talk on ham radio satellites using what he already has on hand. It doesn't take much, although some more specialized equipment does make it much easier, but the point is - you don't need much beyond what you may already own if you have a basic VHF/UHF station. The following is my email to him:

Which birds to target and how to track them
"The best satellites to start with are AO-27, AO-Echo and SaudiSat-1C. (Satellites go by different names depending on where you're getting your info.)

I usually direct people to Heavens-Above to get the latest pass information. The exact time and angle of each pass varies from day to day, so you either need tracking software or a website to tell you when the next pass is over your location. With Heavens Above, you need to enter your longitude and latitude, so it can figure out the information for you.

I've put in the longitude and latitude in for my QTH here in Longview on this link:
http://www.heavens-above.com/main.aspx?Lat=32.5560&Lng=-94.7474&Alt=365&Loc=N5DUX&TZ=CST
(change the location by editing the link or click on the link under Configuration at the top of the page)

When you go to the website, you'll be shown a lot of different links. For our purposes, we're interested in "Radio Amateur Satellites". Click on that link.

Now you'll be presented a table of all the various satellites that Heavens Above is tracking. I usually find the satellites I'm interested in working, then look over at the "maximum elevation" - this is how high in the sky the "bird" will get. Generally the higher the pass, the better chance of hitting the satellite you'll have. If all you're using is a vertical, 45-degree passes will give you a good shot. But anything greater than 30-degrees should be doable. Because you're not on a directional antenna, you don't need to really worry about the azimuth of the pass. Someday, you may find that you'd like to get a yagi and then direction of the pass will matter.

(edit: Heavens-Above is a good reference, but since most people have to jump through a few hoops to enter their Longitude and Latitude, I've been recommending N2YO more and more. Heavens-Above will show a good table of information so you can see everything at a glance, but if you know the satellites you're wanting to work, check out the table at N2YO's Amateur Satellite listing.)

What frequency?
So, now you know when the passes are occurring, now you need to set the frequency. Here are the uplink and downlink frequencies for these 3 satellites. Note the tone. Remember, you talk on the uplink, receive on the downlink.

name	uplink	downlink	PL
AO-Echo	145.880	435.150	-
AO-27	145.850	436.795	-
SaudiSat-1C	145.850	436.795	67.0
Int'l Space Sation	144.490	145.800	-

Doppler
Ok, so there are your frequencies. Those are the "actual" frequencies. Remember, Doppler shift does play a part in satellite communications. You will need to go UP a few kHz as the satellite is coming TOWARD you and DOWN a few kHz as it goes past you. (When it is perpendicular to your position, the frequency will be right on the actual frequency.) If that makes your head hurt, just know to start about 15-20kHz above the actual. As the signal gets more "scratchy" sounding, you'll know it's time to drop ~5kHz.

Listen first!
Listen, listen, listen. Just because you can't hear it, doesn't mean it can't hear you! It's a repeater in many respects, and if you're calling and calling and calling, you're tying it up so others can't use it. If you plan to operate chiefly during daytime hours, you'll hear A LOT of guys crowding onto the satellite each pass. You'll hear quick, rapid-fire exchanges. "N5DUX Echo Mike-22" "Ok, N5DUX, EM22 - this is W1AW, FN31" "Roger W1AW, FN31, 73." - and that's all it is usually. A quick exchange of grid squares, seldom a signal report and rarely much conversation. That is, during the day. At night it's a different story. When all the "sane" people are asleep, you can get on an FM satellite and have a full QSO for the duration of the pass, sometimes up to 15 minutes - always remember though, you have an entire continent of hams that may be wanting on the satellite too, so keep some space between exchanges.

So, tune your radio to the downlink frequency, find the next pass and see if you can hear the satellite.

Recording
A tip I've picked up along the way: The operators are going to be throwing out their info very quickly, so you may need to make a recording of the pass, so you can go back and replay the whole thing to get a second chance of copying their info.

Once you know you can hear the signals, throw out your callsign and see if someone comes back. It's just a really busy repeater, so don't give up. Also, realize that since you're only using a vertical, you won't have as strong of a signal as others will, so you may get stepped on or not heard. Don't give up - try later in the evening when not many are on.

CW telemetry
If you have a dual-band antenna, that would be even better for working sats from a vertical. A mono-band 70cm will work fine for receiving, but for transmitting the uplink you'll need a resonant antenna on 2m.

That's not to say you can't have fun with the 70cm alone. If you have a multimode 70cm radio, you can also copy telemetry data from other satellites that is sent down in CW. It's not the most exciting stuff right away, but copy one satellite over a period of a few days and you can monitor how it's on board temperature swings as it passes in/out of the sun/earth's shadow and stuff like that. It's just fun to copy CW from a little satellite 200+ miles away. The one I copy most often (when I do try to copy) is RS-30 Yubileiny. Unfortunately it isn't tracked on Heaven-Above, so I have to use this other website that's pretty handy, N2YO.com
Yubileiny's track: http://www.n2yo.com/?s=32953

After you decode the info, check out how to "decode" the info by Googling for "RS-30 telemetry", or use a tool like those found here for free: http://www.dk3wn.info/software.shtml Check out the telemetry hypothesis section here to decode the seemingly random strings of info: http://www.ne.jp/asahi/hamradio/je9pel/yubilein.htm

So there you have it, a beginner's guide to getting on the birds with stuff you probably already have. For further reading, check out this page from AMSAT and, of course, scour Google for all it's worth!

update: It should be noted that as of sometime in Spring 2011, AO-Echo began experiencing difficulties with its onboard batteries. The command team cannot keep the control system loaded effectively taking AO-Echo offline. AO Echo is as good as dead until further notice.

update #2: AO-Echo is back online now. Thanks for the heads up Schrockwell. Echo is online running at 2/3 her input power and running 1W output. Note the changed frequencies. These are not the same frequencies Echo has been using since launch. There are the "QRP" frequencies.

update #3: AO-Echo is dead, so long little guy.