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.

Over the weekend, I duplicated the 'Satpack' breadboard, this time using an ATMega644p micro-controller, which offers twice the programming space, EEPROM and, perhaps most important for debugging radio-control software, two hardware serial ports. Bootloading this with my USBTinyISP  was a complete snap, in part because this chip puts all the SPI pins beside each other. I used the Arduino environment to bootload, following the instructions at http://sanguino.cc

I've been breadboard-testing the DS32C35 RTC after soldering this SOIC-20 onto a sparkfun breakout board, and I'm happy with what I've got: for Arduino use, everything 'just works'.

Just as I was about to make my video on qrpTracker, I melted the DS1307 real-time clock. Here's how it happened, and some solutions I found for breadboarding a real-time clock at 3.3v.

Here's a youTube video illustrating the way in which a micro-controller running Plan13 could be used to save power on board a satellite:

As part of my qrpTracker project, I made a morse code signaling library for the Arduino. It uses callback functions so that the person using the library can specify exactly what happens when the signal goes 'on' and 'off'. It foregoes any sort of clever data-packing to store the dits and dahs and just calls functions within a long 'switch statement', an arrangement that I find more readable and just as compact after compiler optimization. This library is more suited for integration into a larger project. For really small beacons, I like Alan VK2ZAY's  code posted in his 80m beacon project page, operating on a ATtiny13V! This was mentioned in a comment to a brainwagon posting regarding Arduino CW code.

Here's a picture of the in-progress Eagle schematic view for Satpack, my altoids-sized, atmega-driven satellite tracking dongle for the FT-817 (or TH-D7A, or whatever). The 20-pin SOIC chip is meant to be a DS3231 or DS3235 Realtime clock. If someone writes a library to access the FRAM on the DS3235, I'll forego a EEPROM chip; likely I'll put one on the I2C bus just to be sure.

The conversation on Ontario Bill 118 continues over at the excellent RACblog .   VA3QF suggests this paper, which in turn makes use of the Jabra A210, a bluetooth cellphone adapter. That device seem to be on the end of its run, but we can likely find others. I consider the audio link side of the equation pretty solved. I think there are two issues that need to be dealt with. An alternative PTT scheme. VOX just isn't always the way to go. Could a flex sensor be used to pick up a unique body gesture that is not considered unsafe? Such as a shrug or a flexed finger?  Automatic repeater handoff on long trips. As I understand the regulations, it would not be permitted to change frequencies, so unless one is willing to pull over each time he or she switches repeaters, a trip from, say Toronto to Kingston could lose contact pretty quickly as the Toronto repeater is lost. A combination of a micro-controller, GPS, CAT radio control and a small database of repeaters could make this pr

Ontario's new distracted driving legislation apparently does not have the exemption for two-way radios that many similar laws include. Indeed, at first glance, it seems that the situation in Ontario is far worse than south of the US border. In my opinion, though, the battle over distracted driving is one that the international amateur radio fraternity probably can't win and in some circumstances ought not to fight. Instead, we should use the Ontario situation to do what we do best: look for technical solutions to this problem and highlight our ingenuity in the face of changing social norms.

Here's a video introducing my Arduino port of Plan13. If you know about Arduino and about satellites, you might want to skip forward to 1:30 or so. If this doesn't appear well embedded in blogspot, here' the link to the blip.tv site. There's a youtube video as well, but the resolution is so poor that you can't read the screen text.

In a previous entry, I mentioned how accurate Plan13 is. Recently, I collected side-by-side data from plan-13 and the respected Predict program and compared their results for satellite latitude and longitude. A day's worth of data regarding CO-57, a low and fast-moving satellite, resulted in a worst-case difference of 39.5 km between plan-13's predicted latitude and longitude and that of Predict. On average, the difference was 14.5 km. 

Before beginning a simple robot project, I mocked this design up in Google Sketchup using components available in the Google 3D Warehouse. The models of the caster, motor pack and wheels for those I had already bought were luckily already in the Warehouse. I added the models of the various layers and, most importantly, of the PCBs I had already made for the picaxe-based CPU and a speakjet board.

The short version of this post is as follows: the 'C' versions of Plan13 all share a bug that make the algorithm unable reliably to track HEO and GEO satellites. To fix this bug find the part of the code that reads something like this: /* Solve M = EA - EC * sin(EA) for EA given M, by Newton's method */ EA = M; /* Initail solution */ do { C = cos(EA); S = sin(EA); DNOM = 1.0 - EC * C; D = (EA - EC * S - M) / DNOM; /* Change EA to better resolution */ EA = EA - D; /* by this amount until converged */ } while (abs(D) > 1.0E-5); and replace abs with fabs . (If you are using the original C port by Edson Pereira this is line 501.) The more in-depth version of the story follows.