Tuesday, December 29, 2009

Quadrifilar Helix Antenna for 2m

I've built the QFH antenna recently published in QST. The result is very omni-directional, as advertized; but I found the construction rather difficult. Here are some notes on the process.

Monday, December 21, 2009

'Compiling' Ruby Applications For Windows

In my qrpTracker satellite tracking project, I've written an Arduino library that stores and retrieves compacted information for satellite tracking. This is suited for the EEPROM memory aboard the arduino's chip, or memory chips accessed through the I2C bus. But the Arduino needs to get this data from somewhere, and so I'm also writing a server program for PCs that compacts the information and sends it to the Arduino through a serial connection.

My first version was written in C, not because I'm comfortable with C -- in fact this Arduino stuff is my first full-blown C or C++ programming, but rather because the datatypes on the Arduino are all defined in C terms and I thought it would be easier to get that right in C. However, I soon found that it was nearly impossible to write serial code that could work on multiple platforms, Win32 being particularly difficult.

Since I've been enjoying programming in Ruby lately, I decided to see what could be done on that platform. As it turns out, the careful datatyping can be done with Ruby's Array.pack() command, and with some difficulty, I was able to get a cross-platform serial port library working for me on Windows. Finally, I used wxruby to start a GUI for the program. But the last, and crucial, step was to see if I could make an all-in-one executable, especially for Windows, out of all this.

Enter OCRA, the one-click ruby application builder. I was really impressed with this. gem install ocra, then ocra ruby_file.rb and you have an application. The --console switch will force a console application; and the --window switch will make it a GUI. One caveat: if you make a window application, comment out any puts or other statements that print to the command line. If you don't your program will exit unceremoniously.

If you'd like to try them out, you'll find them at my public DropBox folder. The commandline version should actually send bytes up your serial port, and will play nicely with, the corresponding Arduion example code. The GUI version just emulates the satellite chosing window in SatPC32 and provides some menu items to specify TLE, modeline and subtone files.

Sunday, December 20, 2009

XW-1 In Linear Transponder Mode

Last night, or 2:30UTC Sunday, North America had its first run at the linear transponder aboard XW-1, the new Chinese amateur satellite. I had just finished mounting the quadrifilar helix antenna published in November's QST, so I was able to transmit to the uplink for the first time in ages.

The 'mood' on the satellite's passband was amazing. some people were apparently having trouble finding their downlink and sending morse dits up and down the band. But the most fun was to listen in to conversations as NA amateurs were amazed at their conversations continuing down to the horizon. I made two QSO's, very briefly, with N9KQQ and AA5PK. One of these lasted below 1 deg azimuth. At that point, I had considerable difficulty hearing my own downlink because the power needed for the 2m omni's transmissions was wiping out my 70cm downlink. But that has nothing to do with XW-1, which is a very exciting new addition to the fleet and a worthy successor to FO-29, my favorite satellite.

Thursday, December 17, 2009

Ruby serialport on Win32

Building native extensions is difficult in any scripting language. Having rewritten my TLE encoding and transmission code from C to Ruby on the MacOs, now I'm trying to get the same code to work on Win32, which is likely to be where most people want to use it. Trouble is, Windows doesn't come with a standard build environment. Here's what eventually worked:

1. Install one-click Ruby here: http://rubyforge.org/frs/download.php/66871/rubyinstaller-1.8.6-p383-rc1.exe
2. On command line do gem sources -a http://www.gemcutter.org
gem sources -a http://gems.github.com
3. Now do gem install hparra-serialport

If you use most of the other serialport forks, or the 1.9.1 rubyinstaller, you'll be out of luck. With the method above, you do not need to add a devkit or a devkit-based one-click installer. The Ruby build above is based on mingw, so you'll need MingW to do Win32 building. To test if it will work, try the command 'make' in your command window. You should get the error: No targets specified, not the error 'make' is not recognized.

Now it's time to test it on Win32 ...

Update: it works! The only oddity I found was that under Win32 a getc call would produce a nil object if there was nothing available from the port. Not sure if this is the most elegant way to deal with it, but I just looped around to ignore those.

Tuesday, December 15, 2009

New Amateur Satellite, XW-1

I just finished listening to the morse code beacon of a new amateur satellite, XW-1, made by amateurs in China and launched by the Chinese government. This is going to be an excellent communications satellite. It has a 1200 km high orbit, meaning that it sees more of the earth than a lower satellite, and therefore people at a greater distance can talk to each other through it. Also, judging by the beacon, it provides a very steady signal, not terribly subject to fades.

Wednesday, December 9, 2009

Further thoughts on 160m with a 50' vertical

Following up on my thoughts in yesterday's posting, I should note the following. First, AD5X had success with getting an autotuner apparently to tune the range of 160 with the same coil arrangement as I have. I suspect my coil doesn't present quite enough inductance and that with some more I would have better luck.

Secondly, I guessed that an improved feedline would be a good first move. This is incorrect. Playing around with the coax calculator, I note the following losses. With 100' of RG-8 matched loss is 0.23 dB; at a 5:1 SWR, it is an additional 0.3. Changing the cable to LMR-400, we get a .16 mached loss and 5:1 SWR additional loss of 0.24.

For the same factors, this time just changing the freqency to 28 MHz, we find a LMR-400 matched loss of 0.64; and additional .811 for the 5:1 SWR. Switching back to the RG-8, matched loss is 0.95 and an additional 1.1 comes into play with a mismatch.

However, it is very easy for the tuner to match a vertical at the higher frequencies.  We can therefore ignore the mismatched losses for these, and only consider them at 160m. And at that frequency, the improvement from matching is minimal, even with a mismatch, and a higher ones the matched losses are minimal for RG-8, too.

Based on this, I'm not spending money on a better cable; that money is going into the antenna analyzer piggy bank. For now, I'm going to add turns to my coil for 160m and see if the autotuner can pull it down to a reliable 1:1 SWR across the band.

Yak sya mayesh?

Pryvit ('hello') to fellow QRP'rs from the Ukraine, whose national club's website linked to this blog. My Ukrainian colleague gave me these phrases, promising me that they are friendly!

Tuesday, December 8, 2009

Progress in 160m

This 50' aluminum vertical with auto-tuner at its base has served me reasonably well in QRP contesting, even on bands like 15m where its pattern should be poor DX. However, while it tunes nicely from 10-80m, 160m has eluded me. Two years ago, I rigged a wire up to the top of it and make a sort of parallel inverted L, but the Winter winds soon make short shrift of this. The snow and ice loads down the wire, and that, being horizontal, pulls down the entire vertical.

This time around I settled for base loading. Not having an antenna analyzer, I used the demo mode of EZNec to guess the capacitive impedance of the vertical. Finding an unused water bottle to use as a former, I wound about 20 turns of about #14 enamel wire over its 3.5" diameter.

Friday, December 4, 2009

Make Blog Posting

Hi to everyone who might have come here from the Make Blog posting on satpack! It was very kind of the author there to summarize this project and provide the links to the code and this site. Allow me to provide one small clarification to some of the postings around the web: the chip being used in the demo is the ATMega328, standard in current-generation Arduino boards. You can run the satpack code on a AtMega328 with a realtime clock and nothing more.

One caveat: at present, the C code that uploads Keplerian elements to the satpack only compiles on MacOS and Linux. I plan to move the serial communications part of this code to a scripting language with cross-platform serial support, like Ruby.

Wednesday, December 2, 2009

Satpack compilation numbers

The challenge with the satpack project is to fit as much functionality into the 32kB of the ATMega328 without resorting to taking the main functions out of libraries or other hard-to-read things. The current version has some precompiler conditionals that provide a good idea of the cost of some of the functionality:

RTC Crystals and Breadboards

A quick note on working with realtime clocks on breadboards. The leads from your typical clock crystals are very thin. In my experience, these don't make reliable contact with the teeth of the breadboard, and that can stop your RTC from running, or make it unreliable. My simple solution was to solder the crystal onto the RTC's xtal pins. It's not as if I ever want the RTC chip to operate without a crystal, and it ensures that the connection is solid. The goal is to solder the crystal so that it is sticking up about the chip and is soldered onto the top, wider part of the chip pins. Aim to get no solder on the narrower part of the pin that will engage the breadboard. As always, tin both parts, and flux them beforehand to ensure that the solder flows nicely.

Tuesday, December 1, 2009

Satpack Video

Here's a video of the Satpack code tracking a few satellites. Note that the tone of the cubesat drifts a bit. The keps were a bit old, but in a addition, I just got a letter from James Miller, the author of Plan 13 who recommends some constants that are more in keeping with the earth model used in today's GPS engines.