VE9QRP

Reverse Beacon Network: Amazing!

2011-02-22T17:47:00.000-04:00

I've often peeked at http://www.reversebeacon.net/, the Reverse Beacon network that uses a network of observers equipped with CWSkimmer to list the heard stations that are calling CQ on CW. If you can find an observer near you, it gives a pretty interesting view of propagation.

During the IntDX competition this past weekend, I thought I might have been picked up, but as a QRP station, I didn't do any CQ'ing during this contest; consequently, I didn't get added to the mix.

So this morning I tested the network: I made a single CQ on a pretty dead 15m, by hand. Sure enough, I was picked up by the K4TD skimmer!

This is nifty in two ways. First, I think the RBN shows how CW continues to have strengths as a mode. It is digital enough that current computing technology can parse it (and, of course, create it); but it is a digital mode that was created for human production and decoding, so we don't have to have a computer in the middle to play with it. Second, and more practically, this is a beacon network that encourages you to make QSOs. You're only going to be picked up if you call CQ!

Reaction to Codec2 Video

2011-02-02T15:51:00.001-04:00

The QSO with Paul, ZL3IN, has garnered quite a bit of attention, with very positive reviews of the state of Codec2 and the spirit of David's project in general.

Amateur Radio Newsline gave Paul and me some of their airtime.

The ÖVSV (Austrian Amateur Radio League) reported on us, as did Southgate ARC's excellent site. Report #4 of 2011 of the BB-Amateurfunkmagazins put us at the top of their issue, in a piece entitled "Video zeigt quelloffenen Sprachcodec in der Praxis".

The Interessengemeinschaft Amateurfunk Osnabrück notes that "Das Beispiel zeigt jedoch, was heute möglich ist und dass man trotz äußerst geringer Bandbreite akzeptabel Sprache übertragen kann."

And finally, KC4BQK says, "This is what I think Amateur radio is all about."

Python oneliner For Kenwood Kiss Mode

2011-02-01T21:51:00.003-04:00

I'm tiring of using a terminal to put my Kenwood radios' TNCs into kiss mode. Here's a oneliner in python that will do the same thing. Why Python? My experience with Ruby and the satpack code was that its serial library was hard to get going on windows. This should be more portable, and get the job done:

python -c 'import serial;ser=serial.Serial("/dev/ttyUSB0", 9600, timeout=1);ser.write("kiss on\r\n");print ser.readlines();ser.write("restart\r\n");print ser.readlines();'

It should reply something like this:

['kiss on\r\n', 'KISS was OFF\r\n', 'cmd:'] ['r']

ZL3IN Conversation Video

2011-01-21T18:13:00.001-04:00

Here's the video of the ZL3IN c2qso.sh contact. Remember, this is just raw UDP packets over the internet, with no error correction, and you're hearing the Codec2 audio just as it was transmitted in the conversation.

Codec2 QSO With ZL3IN

2011-01-17T19:14:00.001-04:00

Over the weekend I had a half-hour conversation with Paul, ZL3IN, using Codec2. Paul corrected an error in the script I've published, and we were thus able to hear each other.

His side of the conversation encoded in Codec2 is available here; you can get my side here. I've also mixed the two into a wav file.

Details and a video will follow.

Codec2 Call Testing Service

2011-01-17T14:29:00.005-04:00

If I haven't been using Skype for a while, I check that everything is working properly using their 'Call Testing Service'. This service tells you to record a message, then plays it back.

Thinking that this would be great for testing a codec2-over-udp setup, I’ve been playing with a similar service, using this script:


ncat –udp -l \$LOCAL_HOST \$LOCAL_PORT –sh-exec ‘netstat -nu | grep
\$LOCAL_HOST:\$LOCAL_PORT | head -1  | cut -c 45-57 > /tmp/out.ip ;
timelimit -t10 -T1 cat > /tmp/out.c2 ; cat /tmp/morig.c2 /tmp/out.c2 >
/tmp/out2.c2 ;  ncat –udp \`cat /tmp/out.ip\`  \$LOCAL_PORT < /tmp/out2.c2'

This copies the first 10 sec. of a streamed udp transmission to our local host, then plays back a canned message (morig.c2) followed by the stored 10 seconds. The only difficulty is if more than one person connects at the same time, I'm not sure netstat will properly report each persons' IP address. If there is a way to ensure that netstat prints the connections in chronological order, then this script's concept will work. My guess is that I'll have to write this up in a programming language like Ruby to make sure the right connection gets the right message.

The major difference between this concept and the Skype service, is that this using this approach the service will only transmit once transmitted to. This is because plain UDP connections have no way for the server to 'know' that you want to listen to it until you actually transmit. Yes, it is possible to add additional information over the UDP session, but I think it will profit us to keep the data on the net as light-weight as possible, so as to emulate data streaming over radio channels, too.

Codec2 One-way Contact

2011-01-13T13:43:00.000-04:00

Simon took me up on my offer in the last post, and after a bit of fiddling, I could hear his codec2-encoded voice reach across the Internet from Crowsnet Pass in Alberta to the Bay of Fundy. Great fun!

I noted that at first his voice had a sort of 'auto-tune' effect, locking on a given tone unnaturally, until I asked him to reduce his audio gain a bit. I'd observed this effect in our home-based experiments, too. It might be useful to put some audio gain profiling code in the input pipeline so that we can manually optimize this.

Second, I think some sort of UDP NAT traversal code is going to be needed. I still want a very lightweight, tool-based approach that I think will port easily to small linux devices, but it took Simon and me quite a while to get the UDP ports worked out, and even then we couldn't get my packets to him.

It looks like nat-traverse, a perl script, will do the job. I'd rather not add a dependency on perl, but it's a good start, and cleanly separates out the task of nat traversal from the UDP packet handling and decoding.

Finally, c2qso.sh takes a half-duplex approach to communications: it doesn't perform transmit and receive across the same UDP link, because I wanted a client with low computing power to be able to safely close its transmitting port and then open the receiving one. But this is probably an unnecessary complication, and seem likely to make nat traversal more difficult.

CQ Codec2, Calling CQ Codec2

2011-01-12T13:15:00.004-04:00

Over the holidays, I developed a bash script that allows to computers to communicate with codec2-encoded audio using UDP packets.

The script, called c2qso.sh, doesn't do any of the firewall-punching magic that Skype etc. perform. But it should be useful in testing lightweight linux contexts, especially those without a GUI, since it comprises pipelines built from pretty standard Unix tools.

Who'd like to arrange a QSO?

c2qso.sh works the following way. It pipes the audio-in through gstreamer to change the sample rate and format, pipes this through c2enc, and sends the resulting data out to the other machine as UDP packets, using a default port of 20002. Input is even simpler: a ncat process listens to the 20002 UDP port, and, if it gets a connection, opens a shell command that pipes the data through c2dec and pipes the resulting audio out through 'aplay'.

(I wasted a great amount of time trying to put the audio out through gstreamer, even writing gstreamer plugins for codec2. I kept getting choppy output, which was solved by using aplay. Unfortunately, although the rest of the toolkit is available for OS X, the OS X audio player doesn't seem to provide for streaming data in at 8000.)

There is no metadata or error correction in the streams.

Some helpful bits to get you started:
1. You need 'ncat', which is a souped-up version of 'nc'. ncat comes with nmap, so on a Fedora system do 'yum install nmap' and on a Debian system do 'apt-get install nma

2. Download and build codec2. This requires the 'svn' package installed. Then run 'svn co https://freetel.svn.sourceforge.net/svnroot/freetel/codec2 codec2' From a bare Fedora you'll need to do 'yum install gcc'.
Do 'cd codec2' then './configure' and 'sudo make install' (or su, then 'build all').

3. Configure your firewall to allow incoming UDP packets on port 20002. On Fedora, go to 'Administration/Firewall' and use the 'Other Ports' tab to make this exception.

In any case, the philosophy here is to use extremely simple networking tools to get the job done, and as a result, it should be easy to port this approach (if not the code) to platforms like the iPhone and android.

More on the TH-D72 USB Port

2010-12-10T16:18:00.001-04:00

The TH-D72 USB port is configured as a CDC device, using the CP2102 USB UART bridge. On Windows, presumably you should use the drivers provided by Kenwood. I accessed the port on my Ubunutu 10.04 desktop just by using /dev/tty.USB0, which popped open when I connected the device. CP2102 support evidently is built into recent kernels. Looking around, it seems that MacOS support is more dicey, so I'll probably experiment with it using a linux box or a virtual linux machine on my MacBook.

For the person like me, who is hoping to connect this to an embedded device, there's some particularly bad news: this chip doesn't communicate using the plain CDC-ACM; I'm told it has a proprietary communication system to the host. The best bet is to port the software from the linux kernel, alas.

Commanding the TH-D72

2010-12-10T14:31:00.000-04:00

The new TH-D72 is a dandy radio, with APRS and a built-in GPS engine. But I was a bit dismayed to see that the CAT commands are somewhat different from those for the TH-D7G, since I'd put quite a bit of time into programming for those. Guessing that Kenwood wouldn't rewrite this software for each rig, I took a look at this list of commands for the most recent similar radio, the TM-D710, and sure enough, it seems they work. Phew.

In addition, if we want a micro-controller to talk to this thing, then I suppose it will need to have USB host mode on it, since the rig acts as a USB device, of course. The CUI32 apparently provides the hardware for this connection, so we'll see how that works.

Improving Codec2 Decode Speeds with Alternate FFT Algorithms

2010-11-24T13:38:00.002-04:00

Codec2 operates nicely in real-time on a modern-class laptop, but I've been trying to push it into other devices. Real-time encoding and decoding on PIC32s will need to wait for a 16 bit integer version (which can make use of Microchip's DSP library), but how about ARM hardware? I ported the code to a Nokia N800 (400MHz ARM11), and it works nicely, but the decoding is choppy after a while because it just can't spit out audio in real time. Decoding will need about a 2x speed up. I've been able to get pretty close to that by swapping out Dave's Fast Fourier Transform function with a different one licensed under the GPL.

Codec2, being a sound codec, makes frequent use of FFTs. Here's the result of gprof running over c2dec:

%   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 83.52      3.65     3.65    28116   129.82   129.82  four1a
  7.78      3.99     0.34    11246    30.23   160.05  aks_to_H
  3.43      4.14     0.15     5623    26.68   156.50  aks_to_M2
  2.75      4.26     0.12   599720     0.20     0.20  sample_log_amp
  1.37      4.32     0.06    11246     5.34   135.15  synthesise
  ...

You can see that four1a, the FFT routine, is taking up 3.65 seconds, and the total turns out to be 4.37! So the FFT is a great candidate for improvement, and happily the current code uses a very slow FFT, the one from Numerical Recipes in C.

With a bit of work, I swapped in the kiss FFT code. This is by no means top-notch in the speed derby, but it should be better. It has the advantage of being small and simple. Here's the same process, on the same machine using that code:

%   cumulative   self              self     total           
 time   seconds   seconds    calls  us/call  us/call  name    
 49.43      1.30     1.30    28116    46.24    46.24  kf_work
 15.97      1.72     0.42    11246    37.35    92.12  aks_to_H
  9.13      1.96     0.24    28116     8.54    54.77  four1
  6.46      2.13     0.17     5623    30.23    85.01  aks_to_M2
  6.08      2.29     0.16    11246    14.23    69.00  synthesise
...

Total time turns out to be 2.63 sec. We have to be careful to charge both kf_work and four1 against FFT, because the 'four1' routine is my bridging code. Still, this is quite the improvement.

On decode, anyway, FFT remains the big time-hog. We can improve it further, by about another 50%, if we treat all transforms as entailing real numbers. kiss FFT has a real number routine on board, but I'm having trouble interfacing this with Dave's existing code. Something's just not aligning properly.

Finally, the gold standard in C code FFT speed appears to be the FFTW library. Implementing this should improve matters greatly again, although its interface seems a bit hairy. After that, it's hardware DSP code. The N800, for example, actually has a DSP engine which could be engaged to this purpose quite well, but I can't find if or where a FFT routine is exposed usefully. In any case, the N800 is a pretty old machine: what barely works on it should do just fine on more recent hardware.

Codec2 across the network

2010-11-19T14:48:00.001-04:00

Using a recent version of Ubuntu, we can use netcat to glue together some network transport of Codec2, preliminary to getting it on the airwaves. (Since Linux makes ax.25 <-> TCP/IP doable, we're theoretically half way there if we can get c2 within the network context.)

Here's a command to set up a quick and dirty listener on port 20000. Note that I've changed the source code for c2dec so that it inputs from stdin and outputs to stdout. 'pacat' is the pulseaudio cat command that pipes sound into the pulseaudio system.

ncat -l -k 20000 | /home/brucerob/Codec2/codec2/src/c2dec | pacat --channels=1 --rate  8000

ncat likes to die when it has dealt with a single transfer, so we use the -k command to 'keep' it alive.

What about the source side of our network? We just pipe c2-encoded data into a netcat command, like this:

pacat -r --rate=8000 --format=s16le --channels=1  | ./c2enc | netcat localhost 20000

Again, the c2enc command has been altered to do the right thing.

The result is pretty good, but with about 12 seconds of lag. Some buffers are taking their time getting filled, and I'll have to look into that.

Festival Speech Synthesis and Codec2

2010-11-15T12:30:00.000-04:00

Here'a a bash script that takes as its first argument a string of quoted text. It then passes this through the festival text-to-sound processor and plays two versions of the result. The first version is unprocessed; the second version has been encoded with codec2 and then decoded.

The results are generally impressive. But I hope this might be some help in improving the codec. For instance, the roughening of sibilants like 'sss' in English (which becomes something like a 'sh' under codec2) is easily reproduced with festival.

To use this script, change the first line to point to the directory in which your c2enc file resides, save the script as, say, 'tts-codec2.sh' and then issue the command 'chmod a+x tts-codec2.sh' so that the script is executable. Then run it on the command line with 'tts-codec2.sh "Salmon steaks grill beautifully."' You'll hear the non-codec2 version, then the codec2 version.

CODEC2_HOME=/home/brucerob/Codec2/codec2/src
TFILEA="/tmp/$(basename $0).$$a.tmp"
TFILERAW="/tmp/$(basename $0).$$.raw"
echo $1 | text2wave | sox - -r 8000 -t raw -s -2 $TFILERAW 
play -r 8000 -t raw -s -2 $TFILERAW
$CODEC2_HOME/c2enc $TFILERAW $TFILEA
$CODEC2_HOME/c2dec $TFILEA $TFILERAW
du -sh $TFILEA
play -r 8000 -t raw -s -2 $TFILERAW

Codec2 Bash Scripts

2010-11-13T11:52:00.001-04:00

Here's a bash script to round-trip a 8000Hz, 16-bit signed raw audio file through codec2. It takes the input file name and output file name as arguments:

CODEC2_HOME=/home/brucerob/codec2-2010-11-11/src
TFILE="/tmp/$(basename $0).$$.tmp"
$CODEC2_HOME/c2enc $1 $TFILE
$CODEC2_HOME/c2dec $TFILE $2

Here's a sox command to get a wav file (or whatever) into the proper raw format for codec2:

sox input.wav -r 8000 -t raw -s -2 output.raw

Codec2 Improvements

2010-11-12T22:40:00.000-04:00

David VK5DGR is actively improving Codec2 in a process that he describes on his website. Until I became interested in this process, I hadn't realized how developing a codec is a pretty qualitative and subjective process.

Anyway, some recent patches to the alpha code aim to get rid of crackles from the encoding, and I think I can provide evidence that they have done just that. Last weekend I recorded myself describing my QTH, etc. in typical long-winded ham fashion. I then encoded and decoded this raw audio file to see how intelligible it was after being passed through Codec 2. The result was quite impressive. I think the greatest criticism could be the clicks that appear on my name, 'Bruce' and when I draw my breath in early in the QSO.

After reading that the recent changes aimed to eliminate those noises, I updated my repository, rebuilt the code, and then round-tripped this same file. Listen to the new file, and you'll hear that it has fewer distracting clicks, especially in the two sections I mentioned.

If you are testing Codec2, consider recording your audio files with a boom mike or something similar, not with a mic that will pick up echos and ambient noise. Currently the codec suffers quite a bit if such distractions are around. This is interesting, of course, and important, but unless you are planning to test these problems, you might want to have them set aside for now.

Fun with Codec2

2010-11-08T19:27:00.001-04:00

Here's a uuencoded, 511 byte message in Codec2. It is a full sentence!

begin 644 hello.c2
M&]&*F(K<H"O0CJB;_^`ATN[HOOK@L)#.[YYJX+*RQ.V>:F"YDLS*GFK@`=:L
MJ;9;8.UQCJFV2>#M4XJIMLC@XU:,N;++8*56KJN>R^"[]J[.MLK@MI3D[YKN
MX!-2K.Z?_6`+4:SJGMS@K=>.[Y;L0"-1K.R^U*`I$>[L_^7@)Q&,[I[%(*,1
MK.R[YL##$83N_^;@1_&,[)KF0`/1C.Z;<F#%4(3NO^)@'9&,[)KCX,.0BNZ>
MX^`(].KKFM-@!+"N^8K1($C\C.N*P4`,-8[IOE#@6?&.V8Y'P`_PCLB&5.!H
MEH[.AEU@T/*.SX9.X/+RCLV&SF#R](K+ADI@\MR.Z8;*X/+]BJF&RN#TMXB9
MA\M@_I&+^X_I8/_PB_^.Z6#_T(N]NDE@^=:/_;II8.GTC_6Z:V#KO.G]BDE@
MZ9RO_XYK8.N<K?J.RV#MG.N:CTM@Y+Y+F8=*8.K*QYJ+;^#JSN::C^[@YD+'
MF8YM8.1"0XFO[>#J0,6ZB^S@`,V[N_)<X++J[?^V3<":E*2)BL[@;["LZ+O?
MX(7PC$JJS^"!\*Q.BDW@AY"FROK-X)22XFRWS>"YEL(D_\W@\][B!+?,P`"V
MP":W5"`8EL(,F]3@`M3"+X_4X`I\PBZ/5>`F?L(DI5?@/`K")*]6H`P^P"2/
0UF`8?.(OCM)@&%3";H_2X```
`
end

Codec2 on Pic32: First Steps

2010-11-08T12:52:00.001-04:00

In the dynamic field of digital ham radio projects, Codec2 just might be the most exciting one of all. A very low-bandwidth voice-to-digital codec has any number of uses: in fact, it is so important to future digital radio infrastructure that the D-Star architecture ended up using a proprietary codec for this purpose. Of course, D-Star's black-box chips are not most ham's style; we like to tinker; and in some contexts, like SDR radios and satellite communications, it's very difficult to work with locked-in hardware and code.

Enter David, VK5DGR. He is using his Ph.D. research to produce a patent-free voice codec for radio amateurs, with loud cheering from Bruce Perens, who has long championed this idea. The code is recently out in alpha , compressing to 2500 bps. It built quite happily on my Linux box, and the c2enc and c2dec applications will convert from and to 8000 bps, 16 bit signed RAW audio, producing very intelligible results.

Since I had a PIC32 chip on the bench, I decided to set aside work on the qrpTracker and see how far I could get in porting Codec2 to the PIC32. It isn't working yet, and I think we'll need integer math to get there, but I've made some progress.

The short story is that I can get the PIC32 to pass the tquant.c unit test (which I rewrote slightly to remove the need for a filesystem), and I can get it to produce decodes, but these are not the same as what is produced by my linux box. Moreover, the PIC32 stops decoding after about 8 7-byte frames, and I'm not sure why.

Finally, although my code is all ready to pipe the decodes to a speaker attached to a PWM output, I don't think the current implementation (which does all the math with floats) will be fast enough for real-time decoding at the PIC32 current maximum speed of 80 MHz. However, there is a PIC32 DSP library (integers) whose functions are very much like some that David bases his work on, so once David's architecture moves to 16 bit integers instead, we should see some great speed-ups.

Here, in no particular order, are some of the issues that I faced. First, the build process does some code generation, producing a 'codebook.c' file, which later gets compiled into the library. Thus, I needed to build the code on a linux box first, and copy over this file with the others. Second, the code does two malloc calls, and these need about 1200 bytes of stack. In PIC32, you need to tell the linker about this. Happily, David's code uses many asserts, which compile nicely and print out to UART2, so this was quite clear. Thirdly, I wasted a few hours trying to get this all to work on the PIC32 simulator and being beset by obscure errors which I'd ascribed to the heap and stack. After reading that the Sim was buggy, I decided to try the code on silicon, and sure enough none of the errors appeared (at least not in the first few decodes).

Lastly, since I'm using the CUI32 board, which has a PIC32 with 32kB of RAM, I'm terribly short on space. There's just enough to run the code alongside a serial port, interrupt and timer, so that some day we can make sounds. I'd started out hoping I could use a MMC/SD with filesystem, but I'd need at least 64kB for that. Because I'm so short on space, I can't compile in the debugger, making some of the issues above into little mysteries.

Still, the code does convert 7 byte frames into 160 16-bit signed integers, it just appears they are the wrong ones, and it does pass a unit test. I'm hoping some of the other unit tests will be rewritten so I can get closer to the issues, especially if they were to be rewritten with no need for a filesystem.

SGP4 on PIC32 Observations

2010-10-26T20:29:00.000-03:00

Because I'd like to move to the SGP4 tracking algorithm for QRPtracker (and failed to port it well to the 8-bit ATMega644) and because there's no substitute for real programming power, I'm playing around with the PIC32 processor, as conveniently provided in the CUI32 experimenter's board. My goal is to milk this for all its SRAM and flash, but keep the power down to the single-digit mA level so that I can use a pair of AA batteries to power it.

Here's some power observations to get things going:

Program	Speed	Other	Power (mA)
Switch	80MHz	Both leds on	75
		Only red led on	72.7
'Picdict'		Waiting input	57.7
		Running calculations	60.0
	7.5MHz	Waiting input	21.7
		Running calculations	13.5

('Switch' is a program that just continually makes the state of the green led equal to that of a push-button. 'Picdict' uses the on-board realtime clock to calculate the state vectors of satellites and to determine their az/els from a given ground station.)

I think this is pretty good news. The red led, which is always on, probably uses about 2.3mA, and the net power consumption for the 7.5MHz clock running predict-style is 11.2mA with no other power-saving going on. We can put this to sleep for most of the time, dropping into the microA level. If during the brief necessary bursts, we are up in the low 10s of mA, I think it will be ok.

Of course, assuming that the processor is going to spend the vast majority of its time in idle, the real question is how low we can go with sleep and idle modes. Other power concerns are the LCD display and optional GPS engine, but the MCU was my concern.

'Sat in Sun' satpack feature?

2010-08-12T09:48:00.000-03:00

My current iteration of the Satpack full doppler tuning device has about 30k of code space still available in the target hardware, a atmega 644p. Some of this will be eaten up with error checking around the tle loading and clock-setting, but there's still a fair bit of open space there.

PC-based tuning programs will often tell you if a bird is eclipsed or in the sun, a feature that is even more useful these days as the aging AO-51 is not transponding in eclipse. Similarly, the AMSAT-UK video entitled 'FUNcube part one' states at its end that FUNcube will have a high-power telemetry mode while in sun (roughly when school is in session), and a low-power telemetry + transponder mode when it is in eclipse (roughly when school is out). This scheme fits the FUNcube KISS principle, but won't be ideal for the small but important number of students who live in Arctic regions.

So a 'sat in sun' indicator on the LCD is going to be more important than ever, but I wonder if we can go further and include insolation in our tracking logic. A HT user in the field really doesn't want his HT to start automatically tuning AO-51 if it isn't in the sun, so we might as well exclude AO-51 if it is in eclipse. Same thing with AO-7. FUNcube is a bit harder case, since they plan to be more clever with the schedule, keeping the transponder on all the time during weekends and school holidays.

Finally, there's the schedule of AO-27. I'd love to include some 'FM transponder on' code inside satpack so that it also only was tuned in when it is in transponder mode. Right now, it hogs the tuner pointlessly far too many times.

Less Well-known CAT Controlled Radios

2010-08-07T06:41:00.000-03:00

Recently, I asked the amsat-bb list if its members knew of any obscure CAT controlled radios which I might doppler tune with my satpack project. Sergej, UZ2HZ, kindly pointed out to me the FT-727R. According to the previous link, "All serial data consists of single byte binary codes sent at 4800 baud, TTL levels, with two INVERTED stop bits and one INVERTED start bit." Yikes. Still, the price might be right for this HT.

Another possibility is the Yaesu FT-5100. It can be controlled at ttl levels with a modified mike interface.

Satpack TLE Burner

2010-07-25T20:42:00.000-03:00

The utility of a portable full doppler tuning device will depend on how easily it can be updated with new Keplerian elements, so I've put some considerable work into the program that does this through a USB/serial connection. Here's a GUI version demonstrated:

Check those cables

2010-04-19T11:32:00.000-03:00

The performance of my 435 MHz AA2RX lindenblad has not been quite as good as the simple vertical that it replaced, leading me to take the assembly down and debug it. I don't have an antenna analyzer, so I relied on a good ole' 70cm SWR and power meter with a two-carbon-resistor 5w dummy load.

My suspicion rested on the 4m cable running from the antenna to the preamp. Sure enough. To test it, I set the TS-2000 to 5w output, put a 1.5m patch cord of LMR-240 with N-connectors between the radio and the meter, and terminated the meter with the dummy load. Sure enough, the measured power was just shy of 5w, maybe about 4.8w. A longer run of LMR-400 gave the same result; however, the cable that had been out of doors gave me only 3w of power, meaning that 2 of the 5w in were gobbled up in the cable. This is about a 2dB loss, and absolute murder for an omni antenna setup because we have no gain from the antenna pattern. Moreover, all losses before the preamp go straight into the noise figure. No wonder the vertical was winning out.

Trying other cables around the shack led to other alarming facts. I had a similar run of LMR-400-like cable that was producing something like 8 dB loss! I'd love to know why these failed.

Satpack hardware part 2

2010-04-16T12:55:00.000-03:00

The pcbs shown in the previous posting have mated very nicely with the Arduino Mini Pro. The first photo shows the side with the Arduino.

This photo from the side, and shows the hardware on the top of the pcb. From left to right these are, two pushbuttons, a piezolectric speaker for CW, a battery for the realtime clock and a mini-din 8 connector to connect to the FT-817 radio through a standard mini-din 8 cable.

Here, finally, is the underside of the pcb without the mating Arduino Pro Mini. You can see that the realtime clock chip is thin enough to sit under the Arduino .

Satpack PCB version 1.0

2010-03-14T13:42:00.001-03:00

PCBs for the satpack project arrived from BatchPCB.com about three weeks ago. These are designed to mate with the appropriate pins on a Arduino Mini Pro, and to provide that Arduino with access to the realtime clock, piezoelectric speaker, buttons and mini-din 8 connector required to control a recent Yaesu radio. To the right is one side of the design, the critical side that mates onto the Arduino. The boards are made from this design, but it ought not to be used, due to the errors described below.

First, I have to say I was quite pleased with BatchPCB. Their website keeps you informed of the progress of your project, which in my case took about 25 days from order to arrival at my mailbox. If you can keep your project small, as this one is, it will be very affordable. My happiest surprise with BatchPCB was that the shipping charges -- indicated, as usual right at the end of the check-out process -- were very reasonable, especially for a destination outside the USA. I'm really tired of companies overcharging shipping, and I think it eventually lowers the impression of the business. Second, others have said that they tend to send you twice as many boards as you ordered, and that was my experience. I ordered three and received six. As far as I can tell, all are properly manufactured.

Moreover, the design of this board was not an easy one. The Mini Pro puts the I2C SLA and SDA lines on those two connectors that are inset from the main row of them at the bottom middle of the photo above. They're also offset horizontally an odd distance. Nevertheless, the connectors mated perfectly.

This being my first pcb design, it was not without flaws. The picture to the right, of the top of the pcb, shows one of them quite clearly. The three square pads in the middle right of the board are to be soldered to the coin battery holder for the realtime clock. the dots beside the middle pad are 'vias', means of sending a signal from this side of the board to the bottom. However, if I put the coin cell in that space, its bottom would connect to these vias, putting the battery's voltage on those signals: not good. Eagle, the PCB design software I have, has a way of making a region no-go for vias, and I've fixed that in the second revision of the board. Fortunately, I bought some batteries with connected leads and soldered one of those to the pads.

My second error was harder to fix: I had accidentally swapped the SDA and SCL lines between the Arduino and the DS3232 realtime clock. I had to carefully dremel out the old lines and do a 'green wire' fix. Of course, I attempted to do this past midnight using wire that was about 10 gauges too thick! (Recommendation to new pcb designers: buy yourself some really fine insulated wire in preparation for the arrival of your first design. I wrote BatchPCB and told them I thought it would be classy to put a foot or so of the stuff in the box for new customers!)

Against all odds, it worked. The serial and power lines from the radio were all in the right place, and the result is a small dongle that doppler tunes my FT-817 very nicely indeed.

KML to Lat/Long Array in Ruby

2010-02-12T16:01:00.002-04:00

Several of the next applications of the qrpTracker codebase will require me to draw rudimentary maps on an LCD screen. I've been using Google Earth's polygon tool to make polygons that roughly correspond to, say, Prince Edward Island (in the small scale) and North and South America (in the large scale). Google Earth will allow you to copy the corresponding kml fragment. The following code snippet will turn that kml polygon into a C array of two point arrays, suitable for storing in your Arduino as Progmem.


foo = File.open("maritimes.kml")
foo.each {|line|
line.scan(/([-]?[0-9]+\.[0-9]*),([-]?[0-9]+\.[0-9]*),0/).each {|matching|
puts "{#{matching[0]},#{matching[1]}},"
}
}

Obviously, you want to store the kml in a file and change the file name in the above when necessary.

When using this, be sure your selected object doesn't have multiple polygons, because the above code will blithely join them together, making a mess.

Building the AA2TX Parasitic (Or 'Passive') Lindenblad for 70cm

2010-02-10T13:04:00.000-04:00

The AA2TX parasitic lindenblad, which was published in Feb 2010 QST (and has been available online for some time), is proving to be an enjoyable project. I have modified some components because I could not find them here in Atlantic Canada. The #8 aluminum wire for the passive elements is not in our big box stores (different wiring regulations?), and the PVC ferrules require a special order, at least at this point in the year, when no sane person would be installing eavestroughing. So I made do with what I had, and the results are encouraging.

I used 1/2" wood dowling for the horizontal members and #12 copper wire for the parasitic elements. I used exactly the same measurements as in the published project. I'm sealing the wood to ensure that it survives the weather, and I fixed the elements in their holes in the wood using a glue gun.

I'm getting about a 1.5 SWR at 435-436 MHz, which I consider acceptable. Moreover, the SWR drops as I tune higher. I believe this is a good situation, since ice and rain tends to drop the resonant fequency of an antenna.

One tip for anyone who is testing this as they build. Before you take any SWR measurements, make asbolutely sure that the feedline is tightly affixed to the vertical element and has its ferrites properly placed. With the feedline hanging loosely and about 1/2" away from the vertical element, I got very different results. Moreover, in my experience, the vertical element without the 'hub' will produce an extremely low SWR over a large part of 70cm. If you aren't getting that, don't fiddle with the hub; look into if your cable is correctly attached to the elements and if the coax is properly choked at the bottom of the lower element.

I will finish this version by using the Marine Goop recommended by Tony to seal and glue. I expect the doweling will survive nicely, even when affixed to the PVC hub with hot glue or epoxy: there just isn't much force on them.

Video: qrpTracker At Work

2010-02-05T00:41:00.002-04:00

More on Linear Transponder Calculations

2010-02-04T11:25:00.011-04:00

In my last post on the subject, I'd concluded

The result is that for non-inverting transponders, the equation is this:
`up_o = (dl_o - bc_d + bc_u)/(1-v_r/c)`
For inverting transponders:
`up_o = (bc_d + bc_u - dl_o) / (1 - v_r/c)`

Soon after, I received a kind email from Tony AA2TX, with an offprint of his 1997 Space Symposium paper that describes the object-oriented computational approach that is built into the InstantTune code.[1] Since I've been happily pillaging the IT code for some time now, I'd noticed what this article confirms, namely that instead of using `(up_x) / (1- v_r/c)` to get the value of the origin signal from the received signal, InstantTune uses `(up_x) (1+ v_r/c)`.

I was still flummoxed by this until I tried a bit of algebra, like this:
`(up_x) / (1- v_r/c) = (up_x)(1+ v_r/c)/((1- v_r/c)(1+v_r/c))`
`= up_x(1 + v_r/c)/(1 + (v_r/c)^2)`
So now all that's left over is the `(v_r/c)^2`. How can InstantTune safely ignore that? Well, compared to `c`, the speed of light, `v_r` (the observed speed of our satellite) is always really, really small, so the ratio comes out to a max of around 2E-5. That means that the embarrassing `(v_r/c)^2` is vanishingly small and has virtually no impact on the calculation.

How little impact? Well, I ran some spreadsheets, and concluded that an average LEO satellite (the closest to the earth, and therefore the ones with the highest sustained `v_r`) operating in the C-band (a very high frequency, which therefore makes doppler worse), would be miscalculated by only 6 Hz or so.

This is all great news for the satpack project, since the original formula was going to require some 8 byte variables and all the math libraries that go with them, adding 2kB of program size which I didn't have to offer. Now I can do the calculations through multiplication and shifting variables around, keeping everything down to 4 byte (unsigned long) integer math.

Monteiro, T. "An Object Oriented Approach To Automatic Radio Tuning." Proceedings of the AMSAT-NA 15th Space Symposium, and AMSAT-NA annual meeting : October 17-19, 1997, Toronto, Ontario Canada. (Newington CT: American Radio Relay League, 1997). pp. 46-55.

Satellite Audio Analysis

2010-02-02T20:27:00.000-04:00

In a recent posting to amsat-bb, I asked if anyone knew of a way to grab the loudest-frequency and s/n data from an audio stream, thus saving for further analysis the data that Spectran shows in realtime over its waterfall. It seems this isn't an easy question to answer, so I did some more digging and came up with the following candidates.

Sonic Annotator appears to create metadata on audio files, using the vamp plugin architecture. There is a libxtract library that can be used in this architecture to grab spectral peaks, their amplitude and frequency. Wiring all this together, one could get a bunch of spectral peak data from a satellite's beacon and correlate the data to real-time. Then, we can use the realtime info from that to generate az/el values for the satellite in question.

Now, we have the spectral peak info correlated with az/el, and we can plot the signal amplitude against the position of the satellite in the sky. All this works best with beacons that are always-on, like VO-52's, for example, but I think one could make it work with CW, too, or perhaps the FM from CO-66, received in CW mode.

Calculating Linear Transponder Uplinks

2010-02-01T23:25:00.027-04:00

As previous posts show, my sattrack code is working fine with uplinks and downlinks that do not have any interdependence, such as beacons and FM satellites. For linear transponders, I used a simplistic approach that was not giving good results, so I hit the books over the weekend to derive formulas that will determine the source uplink frequency (at the radio) for a given downlink frequency. In the following, I'm using the definitions of Davidoff, chapter 8.

Downlink origin (at satellite) `dl_o`
Downlink observed (at radio) `dl_x` (Davidoff uses dl*, but I can't get my math code to make the subscripted star)
Uplink origin (at radio) `up_o` (Davidoff uses ulo, but 'ul' means 'underline' in my math markup)
Uplink observed (at satellite) `up_x`
Speed of light `c`
Relative velocity of signal origin (in same units as `c`) `v_r`
Band center for downlink `bc_d`
Band center for uplink `bc_u`

Since `dl_x = dl_o - (v_r/c)dl_o` (Davidoff formula 8.2)
then we can determine that
`dl_o = (dl_x)/(1-v_r/c)`

Now, in the tuning code of satpack, we already have both `dl_o` and `dl_x`. In fact, when the user tunes the radio, it is `dl_o` that the code changes, then feeds that value into the next set of frequency calculations and tunes the radio accordingly. The impression is that one is tuning the radio normally. However, we want to work out what frequency we should transmit on, that is `up_o`, based on this information. By the same reasoning as above,
`up_o = (up_x)/(1-v_r/c)`

All we have to do now is derive `up_o` from `dl_o`. To do this, we need to take into account the shifting that takes place due the transponder being inverting or non-inverting. First, remember that at the satellite we have the origin of the downlink and the observed frequency of the uplink: our formulas here should relate to `dl_o` and `up_x`.

According to this helpful pdf, for a non-inverting (or direct) transponder,
`dl_o = K1 + up_x`, where `K1 = bc_d - bc_u`, so
`dl_o = bc_d -bc_u + up_x`
`up_x = dl_o - bc_d + bc_u`
The result is that for non-inverting transponders, the equation is this:
`up_o = (dl_o - bc_d + bc_u)/(1-v_r/c)`
For inverting transponders, it states that `dl_o = bc_d + bc_u - up_x`, so
`up_x = bc_d + bc_u - dl_o`

`up_o = (bc_d + bc_u - dl_o) / (1 - v_r/c)`

These formulas pass one important dummy test. If `dl_o` is at the center of the downlink band, then `dl_o = bc_d`, and in both formulas this means that all that is left is `bc_u`, and so the uplink will aim for the center of the satellite's uplink passband, too. Put it another way, these formulas work for FM birds, and it doesn't matter if you stipulate that these are non-inverting or inverting.

Playing around with a spreadsheet, I can convince myself that these are right in the case that `bc_d > bc_u`, or Mode V/U. I'm not sure if there is additional work that's needed when `bc_u > bc_d`, such as in Mode U/V.

1. Martin Davidoff, The radio amateur's satellite handbook, 1st ed. (Newington CT: American Radio Relay League, 1998).

qrpTracker 'satpack' First QSO

2010-01-28T21:06:00.002-04:00

10 minutes ago, my qrpTracker project passed its acid test, a real satellite QSO. Hearing rather good sigs from SO-50, I decided to reply to KC4KMY's call. My side was hampered with using a 1/4 wave vertical as an antenna, causing his sig. to be heard only about 1/3 of the time, but it was good enough for the log. This means that the following automated functions of the latest 'satpack' code are working well:

Downlink tuning
Periodic uplink tuning of the FT-817, with switching VFOs. This is in the manner of instantune, HRD and SatPC32
CTCSS tone encoding to ensure access to SO-50 and similarly equipped radios

CTCSS was only completed this weekend, so I'm delighted that the whole package is in place.

'Satpack' Arduino tracker PCB

2010-01-28T13:52:00.001-04:00

Lots of progress with 'satpack', my Arduino-based full-doppler-tuning satellite tracking application. On the right, you see a cardboard mockup of the pcb. On the software side, I've checked a fully working version of the code into the SVN repository.

The first photo shows the back side of the PCB. The parallel header strips running along the top and bottom of the photo are going to mate with a Sparkfun Arduino mini pro using snap connector headers. The only component mounted on this side of the board is the realtime clock, which will be soldered onto the soic-20 pads. There appears to be just enough clearance provided by the snap-together header connectors to allow space for the IC. My plan is to solder the IC, solder on the connectors on the Arduino mini, snap on the mating ones for the satpack and then, with everything in place, solder to the satpack. That way, if a bit of space is needed, the pins will be soldered at the right level.

After this, I will solder a 90 deg. male header onto the mini-pro to provide serial communication between a computer and the tracker. The tracker is meant for stand-alone use, but from time-to-time it needs to have its keps or real-time clock updated.

This second photo shows the top side of the pcb. On this side, we don't need to worry about the height of the components. On the far left will be a mini-din 8 connector to communicate with the FT-8*7 radio and to get 12v power from the radio, too. To its right are the pads for a battery to keep the RTC alive without power. The large circle to the right is the small speaker that will announced the location of the bird in morse code. Finally on the far right are two buttons and, between them, a two-colour led. The code only makes use of one button right now, but I have some ideas for the second one.

This design is now in the hands of batchPCB, from whom I ordered three copies.

Quadrifilar Helix Antenna for 2m

2009-12-29T12:15:00.002-04:00

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.

First, use the article as linked above and note the change in dimensions of the shorter loop. The dimensions published in QST are too short. Secondly, you should note that the dimensions given in that article are for the loops as laid out in the manner provided. They are not linear lengths, which are not provided in the article but should be several inches longer due to the curves of the loops.

You can see in the picture provided here that I had to splice in some smaller-diameter lengths of tubing because I had made everything too short the first time around. Because everything was shorter on the first go-around, I ended up cheating on the horizontal run of the loops at the top of the antenna. Moreover, I had to re-shape the whole antenna several times.

The good news is that 3/8" flexible copper tubing works just fine in this application. I was concerned that it would sever when crimped to form the 90 degree bends, but it didn't. I wouldn't want to bend them many times, but one single bend does not introduce a dangerous level of flexibility.

I found that bowing out the loops had a great effect on the tuning of the loop. A greater bow tuned the antenna to a lower frequency.

One further note: the diagram in the article shows the loop connected to a pcb board as a means of electrically connecting the feed cable and the antenna elements. As far as I can tell, this board must be on top of the elements, not underneath as shown in the diagram.

If I were to build this again, I would use a direct soldering technique on the elements and feedline. Or I would have the main tube split with a coupling for final assembly. I'd have a short length of tubing at the top so that I could get a nut on the underside of the tubing to hold the pcb to the elements by means of a bolt. I used self-tapping screws and found they were happy to strip from time to time. I would also use a large-diameter former for initially curving the elements. I wasn't very good at eyeballing the helix.

Finally, note that if you follow the design in the article above the result will be RHCP. This should mean that the downlink for VO-52, which is LHCP, is attenuated considerably. My experience suggested that it is, but that the signal is so strong in general that it makes up for this.

'Compiling' Ruby Applications For Windows

2009-12-21T10:44:00.001-04:00

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.

XW-1 In Linear Transponder Mode

2009-12-20T08:39:00.001-04:00

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.

Ruby serialport on Win32

2009-12-17T00:26:00.005-04:00

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.

New Amateur Satellite, XW-1

2009-12-15T10:00:00.004-04:00

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.

I didn't start hearing the satellite until it was 5 deg. above the horizon according to my tracking program. However, from there on the signal was quite strong. I had one big fade around 5 deg. above setting. But then, the signal continued even after the satellite should have passed behind my horizon! Obviously, the keplerian elements I used:
~~OBJECT A~~
~~1 36121U 09072A 09349.15640464 -.00000045 00000-0 00000+0 0 19~~
~~2 36121 100.5046 046.2483 0006436 232.0630 127.9902 13.18995687 00~~
were a bit off, and the satellite is probably audible roughly horizon-to-horizon. Update 2009-12-20 Don't use these keps. They were off when I posted this, and they are really off now.

This is impressive because I have a very meager receiving system right now, just a 1/4 wave vertical made from house wiring attached directly to a N-connector. That, in turn, connects to a 3m length of LMR-400 coaxial cable, which attaches to a low-noise preamp. With this arrangement, I can hear all the CW beacons I want, even the 80mW ones from the cubesats. According to the AMSAT news service, the beacon of XW-1 is 200mW. The result was a signal that didn't necessarily seem stronger, but rather seemed less subject to fades.

In a situation like this, where we don't know exactly where the satellite is in the sky, an omni-directional antenna like my vertical is really quite a bit more fun than big yagis. A highly directional antenna might well be pointing only 20 deg. off from the bird and therefore receiving nothing. I've had that experience, where I'm trying to manually adjust the antenna array and the doppler-shifted frequency at the same time, looking for two needles in a haystack at the same time, as it were. With an omni, there's less hunting.

That said, the ideal to which I am aiming is to have omni-directional antennas and a highly directional array at the same time, with coaxial switching between them, providing the best of both worlds.

Further thoughts on 160m with a 50' vertical

2009-12-09T14:27:00.000-04:00

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?

2009-12-09T14:09:00.000-04:00

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!

Progress in 160m

2009-12-08T08:28:00.000-04:00

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.

I didn't bother with a transformer tap, hoping that the SMC autotuner would deal with the rest of the matching. While initially I did get a good match, I was disappointed to see that this did not prevail across the band. The tuning was very touchy, indeed.

However, when I got transmitting during the contest, the coil had obviously made a difference. Running QRP, I could work anyone with a S9 or greater signal, and even snagged my first DX on this band, a QSO with Turks and Caicos.

Obviously, what's happened is that I've improved the SWR on the feedline (RG-8) from an absolutely rediculous value to something terrible, but not so terrible that the RF is lost in the feedline. Since feedline losses are comparatively low on 160m, I still get some RF into the antenna.

I have three improvements in mind. First, for contesting, it would be great to be able to switch this coil in and out of the circuit remotely. A micro-controller with RF link or XBee would do just fine. Secondly, a more perfect match would improve things more. But I think realistically I'd need an antenna analyzer to do this well. Perhaps the greatest improvement in performance might be gained by replacing the feedline with LMR-400. This would better my signal on all bands, after all.

Make Blog Posting

2009-12-04T10:59:00.002-04:00

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.

As previous posts here note, I am targeting the '644p as well, in part because it offers me the overhead to run debugging code alongside the stock, and because it has a second hardware serial port so I can work on CAT command of the radio without worrying about software serial port timing issues, if any.

But the near-term goal is a small 'shield' or daughterboard for the Arduino Pro Mini that will provide the realtime clock and battery, and expose the right pins to a mini-din 8 cable for the ACC port on the '817 radio, while allowing the user to update keps through the usual port.

Satpack compilation numbers

2009-12-02T17:36:00.001-04:00

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:

Using internal EEPROM and no GPS: 27964 bytes
Using internal EEPROM and GPS (with software serial port): 30498 bytes
Using external EEPROM and no GPS: 28144 bytes
Using both external EEPROM and GPS (with software serial port): 30678

So, GPS costs 2534 bytes (much of this in the software serial port, of course) and external EEPROM costs only 180 bytes! The latter is because we've already initialized the I2C line for the realtime clock.

We still have a bit of work to do, even for minimal functionality. 1. The location has to be stored in EEPROM and accessed from there. This shouldn't take too much memory to do. 2. Clearly, then the target application for the ATMega328 is the first scenario.
I wonder if we could win back much of the GPS losses by using the GPS for time as well as location, leaving the realtime clock and I2C EEPROM out of the picture. This would be especially practical on the '644p chip, where memory concerns are not a concern (it has twice the EEPROM, up to about 20 satellites), and we have access to a hardware serial port for the GPS.

RTC Crystals and Breadboards

2009-12-02T12:54:00.001-04:00

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.

Satpack Video

2009-12-01T18:03:00.000-04:00

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.

Porting to the Sanguino (ATMega644p)

2009-11-30T09:37:00.000-04:00

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

The only snag I ran into, besides the usual wrong pin counts, etc., was that the reset pin, connected to the serial DTR via a 0.1 microfarad capacitor, really does need a pull-up resistor, despite the presence of an internal one. Without it, I had unreliable uploads.

On the whole, it was amazingly easy to port code: just recompile (which the Arduino IDE does automatically), and load. One quirky difference between this chip and the ATMega328 was the speed with which it did EEPROM writes. Developing on the ATMega328, my code to store satellite elements in EEPROM basically just threw the data in as fast as it could. This resulted in bad communication on the '644p, so I introduced a delay variable. This needed to be as high as 50ms per character to get reliable writing. Over 2kB of data, that's a pretty bad delay. Unless I can somehow get rid of this, it will be a strong argument for just using the DS32C35 as a RTC and memory chip.

DS32C35 Real-time Clock Chip Success

2009-11-16T22:17:00.001-04:00

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

The beauty of this chip and its siblings in the Maxim line is that it comprises its clock crystal and it has some intelligence on board that keeps the clock highly accurate. This particular version includes 8 kB of FRAM, which unlike EEPROM can be read written an unlimited number of times. Both the RTC and the FRAM are accessible through the I2C line.

First the RTC. Not being interested in anything but the date and time, I was able to use the DS1307 library to access this RTC, since its I2C address is the same one used by other Maxim chips like the DS1307. You don't need to seed the RTC for it to start going, so it's easy to see if the oscillator is working or not.

Here's a short program I used to test the above library and to seed the data.

#include <Wire.h>

#include <DS1307.h>
#define TIMEOUT 30 * 1000

void setup() {
  Serial.begin(57600);
}

void loop() {
  if (Serial.available() > 0) {
    char value = Serial.read();
    if (value == 'T') {setTime();}
    if (value == 'R') {sayTime();}
    if (value == 'A') {Serial.println("Hi there");}
  }
}

boolean setTime() {
   //9:55:12 am on Christmas Day, 2009 //09122509065512
 Serial.println("TZ");
 long startTime = millis();
 while (Serial.available() < 14) {
    if (millis() - startTime > TIMEOUT) {
      Serial.println("F");
      return false;
    }
}
  char  twoDigits[2];
  readTwo(DS1307_YR,twoDigits);
   readTwo(DS1307_MTH,twoDigits);
   readTwo(DS1307_DATE,twoDigits);
   readTwo(DS1307_DOW,twoDigits);
   readTwo(DS1307_HR,twoDigits);
   readTwo(DS1307_MIN,twoDigits);
   readTwo(DS1307_SEC, twoDigits);
      Serial.println("T");
      return true;
   

}
  
  void readTwo(int value, char * twoDigits) {
  
    twoDigits[0] = Serial.read();
    twoDigits[1] = Serial.read();
    twoDigits[2] = '\0';
    Serial.println(twoDigits);
    
    RTC.set(value, atoi(twoDigits));
 
}
  
  void sayTime() {
    Serial.print(RTC.get(DS1307_YR,true));
    Serial.print(" ");
    Serial.print(RTC.get(DS1307_MTH,false));
    Serial.print(" ");
    Serial.print(RTC.get(DS1307_DATE,true));
    Serial.print(" ");
    Serial.print(RTC.get(DS1307_HR,true));
    Serial.print(":");
    Serial.print(RTC.get(DS1307_MIN,true));
        Serial.print(":");
        Serial.println(RTC.get(DS1307_SEC,true));
  }

Second, the FRAM. This, too, I was able to access through pre-existing code which I'd used for a 24LC512 chip.

The DS3232 is a clock-only version of this chip in a SOIC-16 format.

Real-Time Clocks for Breadboard Projects

2009-11-09T09:35:00.002-04:00

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.

My problem, which apparently others share, was that I had a 3.3v power supply (off the USB FTDI device), and the DS1307 is rated at 5v. No probs, I thought, I'll use a battery pack. Four fresh alkalines seemed a bit too punchy so I dropped it down to three (with no regulation). This worked for a while, and then the DS1307 started to act strangely. I could set and read the time, but the clock would not advance. Clearly the on-board oscillator was not running. Back up to four alkalines, with nominal power of 6v.

A few minutes later, and I began to be concerned that our wood-burning stove had come in contact with some plastic: there was a funny smell. As the penny dropped, I put my finger on the DS1307, and was rewarded for my stupidity with an immediate blister. Turns out, the DS1307 operates at 5v and only at 5v. Don't give it 4.5 or 6, or it will stop and melt respectively.

My immediate solution was to use the DateTime Arduino library. In my setup() function, I called the following routine to seed the DateTime clock:

void initTime() {
  Serial.print("Enter @Seconds since Jan 1, 1970: (unix command 'date +%s'):");
  if (getNumbersFromSerial() == false) {
    Serial.println("error");
    delay(500);
    initTime();
  }
}

boolean getNumbersFromSerial() {
 while(Serial.available() <  TIME_MSG_LEN ){ ;} // time message consists of a header and ten ascii digits so here use '11' in a #define 
    if( Serial.read() == TIME_HEADER ) { // #define TIME_HEADER '@'
      Serial.print("good");      
      time_t pctime = 0;
      for(int i=0; i < TIME_MSG_LEN -1; i++){   
        char c= Serial.read();
Serial.print(c);        
        if( c >= '0' && c <= '9'){   
          pctime = (10 * pctime) + (c - '0') ; // convert digits to a number    
        }
      }   
      DateTime.sync(pctime);   // Sync Arduino clock to the time received on the serial port
      Serial.print("syncd");
      return true;   // return true if time message received on the serial port
    }  
    return false;  //if no message return false
  }

As the message says, you can get the right value to enter into this by running the unix command 'date +%s'. Of course, as soon as the power is removed from the Arduino, you have to re-seed the clock, but for some of my tracking work it is handy to be able to start the clock at a set point again and again. (For this, '1234567890' is a pretty handy seed value.) Incidentally, I found that this clock, running on my 3.3v ATMega328 at 16 MHz with an external resonator, lost about 30 seconds in a day.

So back to single purpose chips. I have 3.3v regulated through the FTDI, so what are the 3.3v equivalents of the DS1307? Again, I'm not the only one who was frustrated to find that there is no 3.3v RTC chip with battery back-up and I2C communiction available in DIL packaging. At least none that has code written for it in a widely-used library.

The closest thing is the DS1337. In fact, I ordered some of these from Digikey and only when they arrived did I realize that there is no Vbatt pin on which to put a backup battery. Without that, the situation wasn't much better than using the DateTime library . In the same Digikey order, I purchased some 10mm 3v lithium batteries, and a really nice holder that plugs firmly into my breadboard, as shown in the image. As you can see, the 10mm cells don't take up too much space on the breadboard. Yet how was I to provide backup power for the chip?

It's possible, of course, to rig something up with diodes to ensure that the Vcc doesn't charge the battery, but my solution was simply to run the DS1337 entirely off of the battery. I2C doesn't seem to mind the separate power supplies. As it turns out, the DS1337 is much more efficient than the DS1307, so the capacity even of a 10mm cell should allow the chip to run for several months, if not over a year. That's good enough for a breadboarded project, as far as I'm concerned.

For permanent projects, I think the DS32C35 or DS32B35 is a better chip, especially if I can find a way to get at its FRAM memory storage. I have one soldered onto a breakout board and will experiment on it in the coming weeks.

Video: Satellite Mode-Switching Through Self-Tracking

2009-11-04T11:13:00.000-04:00

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:

Generating Morse (CW) with Atmel Microcontrollers

2009-11-03T16:30:00.000-04:00

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.

Satpack schematic progress

2009-10-30T14:35:00.002-03:00

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

2009-10-30T14:16:00.003-03:00

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

Ontario Bill 118 Musings

2009-10-28T11:11:00.000-03:00

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.

The Ontario legislation is frustrating to amateurs because they have been trying to draw a distinction between cellphone use and two-way radio use, but I'm not sure that distinction will hold water for very long. For instance, the ARRL has pointed out in a letter to the US National Safety Council that there is a substantial difference between two-way radios and other kinds of distractions. The reply to ARRL from the NSC is more carefully worded than most hams have noted (italics mine):

"We are not aware of evidence that using Amateur Radios while driving has significant crash risks," Froetscher wrote in her August 24 letter. "We also have no evidence that using two-way radios while driving poses significant crash risks. Until such time as compelling, peer-reviewed scientific research is presented that denotes significant risks associated with the use of Amateur Radios, two-way radios or other communication devices, the NSC does not support legislative bans or prohibition on their use."

Amateurs seem to assume that no such research will be forthcoming, but there is a big difference between 'not proven' and 'not true'. As far as I know, the lamp of research has not shone brightly on the use of two-way radios while driving because researchers have naturally focused more intently on the far more pervasive habit of speaking on a cell-phone while driving. Of course, until the research is done, neither I nor you know what will result, but my guess is that it will be found that use of a two-way radio is to some degree risky. At that point, I imagine the NSC will happily recommend that mobile two-way radio be conducted hands-free, just like the Ontario legislation.

If that is the case, the amateur radio fraternity needs to decide. Do we want to suggest that we are a breed apart, specially careful with our use of radios so that they don't distract us whereas they do others? The ARRL's letter seems to suggest this when it says,

"The ARRL is aware of no evidence that [mobile] operation contributes to driver inattention," the Policy Statement asserts. "Quite the contrary: Radio amateurs are public service-minded individuals who utilize their radio-equipped motor vehicles to assist others, and they are focused on driving in the execution of that function."

Surely it is research that determines if amateurs truly are focused on driving when they use their radios. Many a public-minded person who imagines that he or she drives completely safely with a cellphone in hand has been caught up with distracted driving legislation; they won't accept that amateurs should be exempt if research shows that two-way mobile use poses a risk. If we persist in arguing this, we will undercut the very theme of public safety that provides an very important basis for the amateur radio service.

Instead, let's use the Ontario situation as a testbed for hacks and homebrew solutions that might need to be used across the world if research shows two-way mobile communications present a safety risk on the road. Remember, Ontario does not say you can't talk on the radio; it just says you can't twiddle knobs. Can the common activities of a mobile amateur radio operator be conducted in a wholly hands-free way? Obviously bluetooth audio connections and the like solve the voice link. What about switching between repeaters as one drives in and out of their ranges? In a future post I'll outline a possible solution to that problem.

qrpTracker Introduction Video

2009-10-24T16:37:00.005-03:00

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.

Testing Plan13

2009-10-23T12:16:00.005-03:00

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.

(The actual results might be better than this. Since both programs were called independently and each refer to the system real-time clock, it is likely that occasionally the real-time clock turned over a second between one program running and the other. ) Here's the worked spreadsheet file in OpenOffice format.

Robot plans In Google Sketchup

2009-10-21T10:08:00.002-03:00

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 servo is intended to rotate a Sharp IR range-finder, which is modeled as a black rectangle with some white dots.

The white pillars represent bolts which run through the layers held in place by locked nuts on either side.

This was largely to ensure that the battery packs would still allow clearance for the bolts and everything else. Some of the components are somewhat out of alignment, as you can see from the diagram, but even this level of accuracy was very helpful in ensuring that the final project would work.

A Correction For Plan13 in C

2009-10-20T16:30:00.003-03:00

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.

Plan13 is a long-standing algorithm for predicting calculating satellite locations. Its original incarnation is found in a typically delightful 1990 article by James Miller, G3RUH, which AMSAT has wisely archive for anyone to read. Even if you don't speak BBC Basic, you'll probably understand what is going on in the code, and you can find BBC Basic interpreters to run the code. (Though in my experience when I compiled the Linux version of brandy it crashed on Miller's Plan13, and I couldn't get the MacOS version to compile. That leaves Windows, and it works well in both XP and Vista.)

In early 2000's Edson Pereira PU1JTE made a C port of the BBC basic code, which has proved to be very useful to many people, myself included. It retains the clarity of Miller's code, while adding some useful features from POSIX-compliant systems.

I have been empirically testing the reliability of this algorithm by comparing its output against that of Predict when using the keplerian elements of AO-07 and other low-earth orbit (LEO) amateur satellites. While doing this, a letter came to the amsat-bb list from Mark K6HX noting that he'd been using the Plan13 algorithm with Python, but had been disappointed to find that it was inaccurate when dealing with high earth orbit (HEO) satellites. This struck me as strange, since Miller's original article uses AO-10, a (now defunct) HEO satellite, as its example!

Nevertheless, I ran AO-10's current keplerian elements through my testing suite, and, sure enough, the results were disastrous. Plan13 in C wasn't even close to Predict, whose results I confirmed with SatPC32 for good measure. Something was up. I returned to the G3RUH code, which has the keplerian elements hard coded into it, and put in some recent AO-10 keplerian elements. Sure enough, the result of this 1993 program, running through a basic emulator, was spot-on with Predict and SatPC32.

Now was the time for a good ol' fashioned bug-hunt. I'm very new to C, but I know how to keep adding print statements until something fishy raises its head, and it was after the loop listed above that things seemed to go bad. The value EA is supposed to be iteratively calculated in that loop, but at the end of the loop the C version had a very different figure from the BBC basic version. One more print statement, and I found out why: the C version never takes more than one trip around the loop; but the BBC basic version was doing three.

The bug is in the use of the abs function. Unless specially called, it takes an integer as its input and returns an integer. EA is a float, so C helpfully casts it as an integer, rounding to 0. The absolute value of 0 is 0, so the loop figures it is good to go. In BBC Basic, of course, abs can take and return floating values, so it properly optimizes the value of EA.

The solution is to call the C function that provides absolute values for floating numbers, fabs. Once I did that, the output of my C code concurred with Predict et al. I'll run it through the test bed soon, but I'm pretty sure all will be well.

It will be interesting to see if this improves the performance of Plan13 with the usual fleet of LEO birds.

(Since doing this, I found that Howard G6LVB has properly implemented a floating point abs function in his port of Plan13 C to the PIC platform for the LVB tracker.)