Ok programmers and code monkeys, it's time for Programming Challenge 2. Nothing overly complicated this time. I was just messing around and thought you'd like this quick little brain teaser.
It's a "just for fun" challenge. Choose your favorite language for this one. Here it goes:

Part A: Display/print a vertical sin wave using * characters.
Part B: Display same sin wave horizontally using * characters.

Part A should get you going in the right direction (esp. if you've never played with the sin functions in your language), but Part B is a bit more tricky. No graphics libraries, cheater.

Post source in comments (must be logged in to comment).

Winner to receive 1 small shot of self satisfaction of completing trivial problem through useless challenge on obscure blog.

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.

Most people know the important life-saving phrase Di-di-dit da-da-dah di-di-dit (SOS), but that's about it when it comes to Morse Code. Many people know that Morse Code was named after its inventor, Samuel Morse but not much more. Fewer people know that the use of Morse Code still persists (unless, of course, you know someone that uses it on a semi-regular basis!).

Morse Code is the oldest form of telecommunication still in use. It got its start when the legendary Samuel F. B. Morse, an artist by trade, began to experiment with methods to communicate via the relatively new field of electricity. Morse's system of communication was not the first form of telegraphy, nor was his invention the only electric telegraph. But he did invent a language of dits and dahs that, by way of a few revisions, remains in use to this day. (The history of the telegraph, interesting in its own right, is beyond the scope of this outline.)

Ham radio operators are perhaps the most notorious users of this antiquated form of communication, but not the only users. Navy signalmen use Morse Code when manning the Signal Lamp and aviators make use of the Code as a way of identifying directional beacons.

Morse Code has undergone few revisions since its inception. Morse's original code was a bit cumbersome, but the idea was there and several letters have remained unchanged. Morse originally planned the letters to leave imprints on a printed tape, but over time the code was learned by operators and the incoming signal was able to be decoded by ear rather than on paper. In order to speed up transmission, Morse gave the most frequently used letters the shortest signals. (E gets a single ‘dit’ and T gets a single ‘dah’) Identifying the most frequently used letters, Morse counted letters in a copy of the newspaper. The letters with the highest count were most used. Perhaps not the most technical method of finding the letters, but it was an easy and straight forward approach and has proven its validity. These most-used letters are some of the letters that have never changed.

As Morse’s Code and the use of the telegraph grew, operators using the code found ways to improve the characters’ codes. Due to some spacing issues, some letters were slowing down transmission speeds and/or confusing the receiver. (Some letters required a “space” or pause in the middle of the letter rather than sending a continuous series of dits or dahs. A resulting “space” between letters could then be misconstrued as a different letter altogether and throw off the transcription of the message.)

Morse made his code public in 1844. After a few years of use, Freidrich Gerke released his “improved” code alphabet in 1848 which came to be known as the Continental code. Gerke essentially removed the aforementioned spacing errors eliminating much of the confusion for telegraph operators. Finally in 1865, the International Telegraphy Congress standardized the code to form what is now known as the International Morse Code.

Once the International Code was in place, it has not changed in the nearly 150 years since. Telecommunications has changed completely transformed the way mankind communicates. The advent of radio ushered in easy-to-establish distance communications that required no connecting lines like that of the telegraph, yet the code did not change. Even in the advent of digital communications, the code remained a fixture in the telecommunication industry. It was not until the later 1990’s that the international community began reevaluating the use of the code. Mariners, aviators and radio operators worldwide needed to be proficient in Morse Code to perform their duties, but all this changed in the past 10 years. In spite of its fall from common usage, code operators of today would have no trouble communicating with telegraph operators of the railroad era via the code. No other form of communication can boast a 150 year heritage.

In radio communications, Morse Code continues to be a form of signaling that prevails when almost no other form of communication can get out. No other form of communication can go further on the same amount of radiated power. No other form of radio communication is easier to construct circuitry for. It is simple and efficient.

For those curious individuals wanting to hear Morse Code in use, YouTube offers a wide variety of operators making contacts, there’s the famed Tonight Show video showing the text message versus Morse Code race, and there’s always the ham radio bands.
I was unable to ever make real contacts in Morse Code until I discovered the 7.100-7.125 portion of the 40m ham band. For those looking to break into the world of CW operation, tune your dials to the Novice portion of the band and you’ll find other code operators that welcome “slow-code” newcomers.

To say that there is extensive documentation on Apache and its various plugins, including mod_rewrite, is to grossly understate the term. Documentation is voluminous to the point of beginning to wonder if the various authors had a combined total of more than five dates with actual girls in the history of their lives.

Disgruntled, then, was I to discover that on the entirety of the Internet, there was no documentation surrounding what I needed to accomplish. I've since come to realize that this is likely due to the obscurity of the issue or the availability of other commonly known tools to accomplish the task I had before me.

That task: Rewriting and redirecting a URL from my local environment using Apache and mod_rewrite.

Without delving into specifics, I needed to take an HTTP request generated by a page viewed in my browser and direct that request to another location, including a change of domain.

Now, the more seasoned among you may resolve that the very purpose of mod_alias is to perform this task. However, just because I'm a glutton for punishment, in this particular case, I also need to change the value of a query string parameter in the URL having its domain changed. Gaze upon the domain of mod_rewrite, ye mighty, and despair.

While mod_alias is designed to handle the translation of domains, mod_rewrite is designed to handle that and query string parameters (as well as a bunch of other stuff that I have no idea about). Before we can start directing URLs to and fro, we must first setup Apache.

I'll not regale the reader with the riveting tale of that process as it is rather well (and usefully) documented. The mod_rewrite module must be included in httpd.conf and the Apache instance must be configured to run as 127.0.0.1 on port 80. Do be wary of configuring the server value as localhost because sometimes the value does not translate, especially in Windows. My Apache setup is in Windows 7 x64 with OpenSSL.

The next thing to do is to direct all HTTP requests from the domain that needs to be changed to the local instance of Apache. In Windows, this is easily accomplished via the Windows HOSTS file. An example entry would look like this:

127.0.0.1 ihatecake.neodux.com

This entry will override DNS requests for ihatecake.neodux.com and point it instead to localhost. Apache takes over from there.

With that in mind, let us consider an example URL value:

http://ihatecake.neodux.com/serve?feedme=pie

Clearly, no one hates cake and that pesky query string is returning pie instead of cake, which simply isn't fair. This injustice will not stand; we must modify and redirect this request to attain cake righteousness.

In order to engage mod_rewrite, the traditional method is to add rules to Apache's docroot in the .htaccess file. Because we're not actually dealing with anything in Apache's docroot (despite all the documentation examples using only this scenario), these rules need to go inside httpd.conf. Assuming you've got Apache configured and running, this is quite simple. At the bottom of your configuration file, add a virtual host for your localhost instance of Apache and include the rules to enable mod_rewrite's magic. The first step is to turn the mod_rewrite engine on. It looks like this:

NameVirtualHost 127.0.0.1:80

RewriteEngine on

The next step is to write a conditional statement inside the virtual host instruction set looking for the feedme query string parameter. In Apache, mod_rewrite accomplishes this via regular expression. Now before your panties fully bunch, allow me to assure you that this implementation of regular expressions is very simple once you break it down, so don't let the syntax scare you. The conventions are largely the same as those used in perl, so if you're a perl nerd this will not seem out of place. These condition and rule execution statements accomplish our goal of translating ihatecake to ilikecake and the feedme query string from pie to cake:

NameVirtualHost 127.0.0.1:80

RewriteEngine on

RewriteCond %{QUERY_STRING} ^(.*)feedme=pie(.*)$
RewriteRule ^/.*serve.*$ http://ilikepie.neodux.com/server?%1feedme=cake%2 [R,L]

Let's break it down: The first thing I did is to write a RewriteCond statement that evaluates the query string of the URI for feedme=pie. Most mod_rewrite rules follow the basic convention of RuleName Pattern Pattern, so the RewriteCond rule matches the %{QUERY_STRING} Apache variable against the second pattern. The carat tells mod_rewrite that this is the beginning of a string. The (.*) essentially says, "This means everything before feedme, and since I'm wrapped in parentheses, remember my crap for later." You'll see another usage of that after feedme=pie, so that the entire statement reads [everything before feedme=pie]feedme=pie[everything after feedme=pie]. The dollar sign then signifies the end of the string. In this way, mod_rewrite is able to localize on what you actually want to modify. The purpose, and dare I say the beauty, of the RewriteCond statement is that the RewriteRule statement will not execute unless RewriteCond finds what it is looking for.

The second statement is the RewriteRule. where the URL is modified. Based on what we found (and stored) in RewriteCond, RewriteRule starts its search for the end of the URL, /serve. Again, we see the use of the carat to signify the beginning of a matching string, and the use of .* to mean, "Everything before serve." The dollar sign marks the end of the first pattern string. The second pattern string contains the values we want to change the incoming request to. Since I want to go to ilikepie instead of ihatepie, I can substitute the literal translation here, which I find to be incredibly helpful. After server, where the question mark begins the query string, the usage of the %1 variable says, "Put anything that existed before feedme here." Remember, the condition statement only matches against values found in the query string, so this allows you to rewrite requests that have multiple query strings and/or where feedme is not necessarily the first query string in line. We then substitute the feedme parameter value of pie for cake, and use the %2 variable to include anything that came after feedme.

That's it, right? Close, but there is the matter of the bracketed values out to the right, [R,L]. These are mod_rewrite flags that tell Apache to do certain things. All the flags are covered in the regular mod_rewrite documentation, but R and L are fairly common in their usage. R tells Apache that this should be a redirect, not referencing something in Apache's docroot. If you have a specific need to have the redirect be 301 instead of 302, you can specify that as R 301 or R 302, but it defaults to 302.

The L flag, literally translated, means last rule. It is designed to make mod_rewrite stop looking for additional rules if this rule is successful. This is helpful if you have several RewriteRule statements and don't want to risk having a modified request modified again incorrectly. Also remember that mod_rewrite rules are processed before mod_alias rules and other modules, no matter where they are in relation to each other inside httpd.conf. In essence, the rules are not processed serially.

To test this setup, you can write a local page and view it in your browser. Ensure that you view it via Apache and not from the file via the OS. Using an HTTP request logger like HttpFox for Firefox, you can see the redirect and translation occur in real time.

HTTP request rewriting and redirecting is usually something found in the realm of Squid or other proxy servers. While those tools do work well, novice users (like me) tend to have profound difficulty in getting through the initial setup because those tools are so powerful and have so many options. The setup and operation of Apache, especially as a local web server, is far easier and there are a lot of easy to understand tutorials and other documentation available for it. It's also easier in Apache to lock down access to your instance to only localhost or only your LAN subnet that it is in some other tools.

While this may be elementary to a seasoned Apache guru, I am, by far, not a seasoned Apache guru and it took a great deal of time (and some help from an Apache guru) to make this work for me and to build my understanding of it. Because this specific application of Apache and mod_rewrite was not documented anywhere I could find on the Internet, I though it should be included in the annals of Neodux. Hopefully the next poor fool who needs to do something like this can find it via Google search instead of banging his head against the wall for a week like I did.

After the success of the DUX Yagi-Uda post and it finding its way to Hack-A-Day, I decided I should probably go in to more detail with each blog entry when I'm attempting to explain something technical.

In the past, I've tried be as succinct and just-the-fact-ma'am as I can so the article doesn't make the main page a mile long. I always assumed if you wanted to know more you could just ask me. But, more often than not, I ended up with an article that I think was too shallow or too "in-passing". So, for the sake of those that don't know me personally and would like more information, and in keeping with the spirit of information exchange on the web, I think it's best if I link to and explain all relevant information. To keep the main page short I've decided to limit the amount of words in a story that gets shown at a glance.
I've broken up the links to have the "Continue reading..." link on each article if it is longer than a preset length.

I'd really like to know what my core users think of this change. Is it for the better? Should I change the wording of the link? Should I display all information, longer or shorter at-a-glance summaries? You tell me.