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.

Monday, November 30, 2009

Porting to the Sanguino (ATMega644p)

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

Monday, November 16, 2009

DS32C35 Real-time Clock Chip Success

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

Monday, November 9, 2009

Real-Time Clocks for Breadboard Projects

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.

Wednesday, November 4, 2009

Video: Satellite Mode-Switching Through Self-Tracking

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:

Tuesday, November 3, 2009

Generating Morse (CW) with Atmel Microcontrollers

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.

Friday, October 30, 2009

Satpack schematic progress

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.

Two Bill 118 Technical Responses

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.
  1. 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? 
  2. 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 process pretty seamless. 
On this last point, the hardware would be very similar to what I'm putting together for the qrpTracker satPack, an altoids-sized 'dongle' for the FT-817 that does doppler tuning.

Wednesday, October 28, 2009

Ontario Bill 118 Musings

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.

Saturday, October 24, 2009

qrpTracker Introduction Video

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.

Friday, October 23, 2009

Testing Plan13

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. 

Wednesday, October 21, 2009

Robot plans In Google Sketchup


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.

Tuesday, October 20, 2009

A Correction For Plan13 in C

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.