VE9QRP

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.

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

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

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

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.

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

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!

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.

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.

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:

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.

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.