Monthly Archives: January 2011

On an LC Bandpass Filter for receivers…

I had some time yesterday, but no enthusiasm for melting solder (hey, some times, you just don’t feel it) so I thought I’d spend some time, well, learning stuff. So, I dusted off EMRFD and looked at the design equations for creating bandpass filters for receiver inputs. On my second printing, these occur on page 3.14 (π!). Rather than laboriously work through the possibilities, I decided to just code up a small python program. Here’s the result.

[sourcecode lang=”python”]

#!/usr/bin/env python

# An simple program to compute the value of components needed for a
# Doubly Tuned Circuit LC filter that can serve as a bandpass filter
# for homebrew receivers. The equations come from the sidebar equations
# presented in EMRFD (I have the first edition, where it appears on page
# 3.14)
#
# Written by Mark VandeWettering

from math import sqrt, pi

F = 7050000. # frequency of operation in Hz
B = 100000 # bandwidth
R0 = 50 # load resistance
L = 0.000001156 # inductance of the two coils
Qu = 250. # "Q" of the coils, approximate

k = sqrt(2.)/2. # I hardcoded the Butterworth filter equations
q = sqrt(2.)

omega = 2.0 * pi * F
c0 = 1. / (omega * omega * L)
c12 = c0 * k * B / F
qe = (q * F * Qu) / (B * Qu – q * F)
ce = 1.0 / (omega * sqrt(R0 * qe * omega * L – R0 * R0))
ct = c0 – ce – c12

print """
CE C12 CE
+—||—+—+—||—+—-+—||—+
| | | | | |
< ( | ( | <
> R0 ) L – Ctune ) L – Ctune > R0
< ( – ( – <
> ) | ) | >
| | | | | |
V V V V V V

"""

print "F = %.2f" % (F / 1e6), "Mhz"
print "B = %.2f" % (B / 1e6), "Mhz"
print "R0 = %.0f" % (R0), "ohms"
print "L = %.1f" % (L * 1e6), "microhenries"
print "C12 = %.1f" % (c12 * 1e12), "pf"
print "CE = %.0f" % (ce * 1e12), "pf"
print "Ctune = %.0f" % (ct * 1e12), "pf"
[/sourcecode]

If you run it, you can find a filter designed for 40m with a bandwidth of 100khz. I haven’t had time to run the results through LTSpice for analysis, but the values computed match the values printed in the table in EMRFD, so I suspect things are reasonably well behaved. My choices of the constant k and q select a Butterworth filter instead of a Chebyshev, which given the application I suspect is just fine. According to EMRFD, the choice of L is fairly arbitrary, They suggested 10. / frequency (in Hz) as a good starting value. I used a Qu of 250 because, well, that’s what they used, and I suspect it’s fairly typical over toroidal coils that you’ll wind yourself.

Hope this helps someone.

DC40B update

Previously, I noted that the oscillator on my DC40B kit (supplied by Doug Hendrick’s qrpkits.com was rather sluggish to start. Reading the messages on the Yahoo! groups, it seems that adding additional capacitance to the Colpitts oscillator was the correct fix, so today, I dug some 47pfs out of my junk box and soldered them in parallel to the existing caps on the backside of the board. Now, the oscillator starts right up! I still haven’t the transmitter calibrated, but it seems to work thus far. I just need to put the final transistor in place, and then I can mount everything in the case.


Once the sun went down, I started getting large amounts of short wave broadcast interference (some kind of Christian radio). It appears that this kind of interference isn’t unknown. It appears that I need some kind of bandpass for the input. I remembered that the GQRP had a technical page listing some easy input filters: a few minutes Googling yielded this link which has a bunch of designs which use TOKO inductors. I might even have some of those in my junk box.

First test of Codec 2

I’ve previously mentioned David Rowe’s excellent work on a patent free codec for amateur radio, Codec2, but today is the first time I actually downloaded the code and gave it a shot. You can find the code and the quickstart here:

Codec 2 « Rowetel

My own voice has some fairly low frequencies in it, so I was intrigued to find out how my own voice would do. David’s page mentions that Kristoff, ON1ARF, has a voice where the existing AMBE voice encoder does a much better job, largely because the low frequency encoding of AMBE is much more effective, so I took a short message that I used for some companding experiments I did a while ago, and gave it a try.

The original, as recorded via my iPhone, and downsampled to 8khz using sox.
The same clip after encoding/decoding with codec2.

As you can probably tell, the fidelity isn’t all that stellar with my own voice either. I have nothing to add other than that base observation, but perhaps this will serve as incentive for me to look into this stuff more.

Simulating a (simplified) Ring Oscillator

Okay, simulating the analog parts of the actual physical ring oscillator last night made me ask some questions, so I thought it might be useful to try a very simple discrete simulation. If you looked at the schematic I posted yesterday, you’ll note that the ring is really just made up of single transistor inverters. The capacitors in combination with the resistors implement a delay line. So, that’s what I decided to code up: a ring of simple inverters, each with a “gate delay” of values which are very close to 1 second. Whenever the input to the inverter is scheduled, the output is swapped to its negation at the time in the future plus its gate delay, which resets the clock of the next gate, and so on. I normally would use a priority queue and the like to keep track of which gate should fire next, but for as few stages as I’m likely to implement, I frankly just search for the gate with the lowest time by linear search, and then proceed. To make the “simulation” a tiny bit more interesting, I print the values of the gates in “pseudo-real” time (I spend it up by a factor of 10). Here’s the code.

[sourcecode lang=”C”]
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define N 79

unsigned char val[N] ;
double delay[N] ;
double clock[N] ;

#define BIG 1e6

main()
{
int i, idx ;
double t = 0., soonest ;

for (i=0; i<N; i++) {
val[i] = 0 ;
delay[i] = clock[i] = 1.0 + drand48() * 0.01 – 0.005 ;
}

for (;;) {
/* find the inverter that will trip soonest */
idx = 0 ;
soonest = clock[idx] ;

for (i=1; i<N; i++)
if (clock[i] < soonest) {
soonest = clock[i] ;
idx = i ;
}

/* subtract the clock from all the inputs */

for (i=0; i<N; i++)
clock[i] -= soonest ;

t += soonest ;

val[(idx+1)%N] = 1-val[idx] ;
clock[(idx+1)%N] = delay[(idx+1)%N] ;
clock[idx] = BIG ;

usleep(soonest * 1000000. / 10.) ;
for (i=0; i<N; i++)
putchar("_X"[val[i]]) ;
printf("\r") ;
fflush(stdout) ;

}
}
[/sourcecode]

It’s pretty interesting to watch (at least to me). I’ll have more to comment tonight.

Ring Oscillator Das Blinkenlights

Crap, the original entry I made for this got screwed up somehow. Oh well.

Alan, VK2ZAY, was experimenting with ring oscillators, which make some very nice blinking light displays indeed.

YouTube – Ring Oscillator Das Blinkenlights



Before this post got mangled, I was experimenting with putting the circuit into LTSpice and analyzing it. My brain was too enfeebled to figure out the relationship that governed the selection of the values for the bias and current limiting resistors and the capacitors, so I figured I’d just code it up. Of course, now that this post is mangled, I’ll have to redo the LTSpice analysis, but what I discovered was that under some conditions, LTSpice predicted very long start times for the ring oscillator, or it simply failed to initialize. This is because I typed exactly the same value for the components. If I varied the value of the components by just 0.1%, the oscillator had no problem firing up.

I’ll redo the schematic and the graphs tomorrow. Stay tuned.

Addendum: Couldn’t wait. Redid the simulation using the values that Alan thoughtfully provided on twitter. Here’s the screen dump: commentary to follow at a later date.

LTSpice simulation of a ring oscillator

A few thoughts on D-Star

Some chatting on the #hamradio IRC channel on irc.freenode.net have made me think about D-Star a bit more, and I thought I’d write them down to see what other people thought.

If you don’t know what D-Star is, it’s a digital voice and data technology for amateur radio which can currently be found in radios manufactured by Icom. The Wikipedia page will fill in a few additional details. I’m going to presume that you already know a bit about D-Star, so if you don’t, go ahead and click the link.

A lot of people have what I consider to be unreasonable criticisms of D-Star. Of course, whether they are unreasonable is actually a matter of perspective, so you might disagree. Bitching about the trademarked name is pretty unreasonable from my perspective. Complaining about the “brick wall” of digital performance (either the message gets through and sounds perfect, or it fails utterly) is something I think of as unreasonable: all modes have tradeoffs. Arguing that P25 might be a better choice is rather silly, because P25 equipment is horrifically expensive compared to D-Star radios. And I especially think that complaining that D-Star radios are expensive is unreasonable (with some caveats below).

The single biggest reason that we should all be cautious about wide adoption of D-Star is that it relies on a patented digital voice codec. This is bad on multiple fronts. First of all, the DV (digital voice) protocol that the D-Star network uses to send voice data has no way to select alternative codecs (there is simply no place in the protocol to specify an alternative). This means that every investment in D-Star radios locks us into a product which is unavailable to amateurs for any other use. We can’t legally write a compatible codec to work with voice data on the D-Star network, nor can we substitute a freely available voice codec and carry that traffic on the D-Star network. What we’ve essentially done is guarantee that we’ll be sending $20 or so to the patent holder for every D-Star radio. That doesn’t really sound all that crazy, but there are further problems. As a practical matter, if this company (say) went out of business, we’d have no legal recourse to get new equipment which would inter-operate with our existing investment in D-Star (at least until the patent expires). The current patent holder could just flat out decide to not manufacture the chips anymore, and we’d have lost our investment in D-Star radios.

Think it can’t happen? What’s the average lifespan of a technology company?

But let’s suppose that I am being unreasonable. Maybe DVSI (the patent holders) and Icom (the current single source of radios employing D-Star) are good companies that will continue to sell products at reasonable prices. Isn’t D-Star a good choice then?

I’d submit the answer is still no, and here’s the reason. Since AMBE is currently patented, we are unable to make our own implementations of the digital voice component of D-Star. If we could do that, a whole raft of interesting applications could be created. We could fully integrate D-Star with other VOIP technologies currently in use on amateur radio such as IRLP and Echolink. We could provide free, open source software to send D-Star traffic over the D-Star network, just as we can now for Echolink. We could adapt the technology for links aboard satellites, where the harsh environment may make the chips which currently implement AMBE an unwise choice for use in space.

Our investment in D-Star doesn’t provide us with any of that. In fact, investment in D-Star pretty much precludes any of that.

D-Star does have one huge advantage: it is available today at your local radio store. You go down, you plunk down your money and you can get an HT which provides you all the advantages of digital voice. All of my criticisms aside, I haven’t really got an alternative. In fact, I don’t even know when the alternative will be available.

David Rowe is currently working on an unpatented codec for low rate speech. He thinks he can get a good sounding voice codec running at less than 2400bps, and his early results are promising enough to make me believe him. Surf on over to see what it currently sounds like. Once we have this up and running, I think there will be a whole host of interesting applications that could be developed for digital voice on HF and up. If there is a project that I think needs the help of the amateur radio community, this is it!

The program WinDRM is a program which implements digital voice over HF frequencies (and higher) using COFDM. It uses the LPC-10 codec at 2400bps (which sounds pretty robotic, but is in the public domain) and Speex (which similarly is a bit rough at only 2400bps). It is sadly Windows only, and not open source.

Ditto for FDMDV. Uses LPC-10, and appears to be Windows only, and not open source. It also hasn’t been updated in two years.

I think we need an open source digital voice project using Codec2. I think that in the long run, this kind of experimentation is vital to amateur radio, and will provide a greater lasting benefit than saddling ourselves with single source digital voice appliance.

What do you all think?

Welcome 2011, with some project ideas…

Hope everyone has had a wonderful holiday. I must admit that my own vacation wasn’t productive in the sense of completing projects: I spent far too much time sleeping in, relaxing and playing far too much Epic Mickey on my Wii. But I have also spent some time thinking about the past year and year to come with respect to the kind of fun projects that I like to do.

2010 wasn’t actually a banner year for my outside projects. I did a few smallish programming projects (mostly having to do with generating simple sounds). Tom and I managed to loft a camera on a kite once. I simulated some rainbows. I gathered some parts for a high altitude balloon launch. I bought an FPGA board and got it to blink some LEDs, but made relatively little traction on my ultimate goal of implementing a processor. And I did relatively little amateur radio.

So, here’s my list of projects that I’d like to see completed in 2011.

A high altitude balloon launch. It seems now that everyone is doing these, but I still would like to do one. I’ve got an OpenTracker to provide the APRS downlink, and have radios and cameras that could be used. What’s really required is for me to dedicate time to the construction and testing of the completed payload, and then start working on getting the necessary helium tank rentals and balloons. This would be a great project to fly in the summer when the cloud cover is minimal. Maybe a 4th of July launch?

Homebrew a radio. I did manage to get closer to finishing some of my kits over the vacation, but I’m increasingly dissatisfied with assembling PC boards as an intellectual activity. For one thing, if you make a mistake, desoldering and replacing components on a PCB is annoying, particularly when the PC board has been optimized for area by packing as many components onto a board as possible. But more than that, the PCB approach means that your design is fixed: modifications aren’t there to be explored. Classic fabrication techniques such as “Ugly” or “Manhattan” construction means that you can simply add or change components, and still arrive at RF circuits which perform well.

So, here’s my idea: construct a radio (receiver more important than transmitter) as a series of modules constructed with Manhattan style construction on a number of small boards. Concentrate on learning how each part functions and can be tested. Try to use common, inexpensive components. Make the final radio lunchbox size, rather than Altoid size, because that means we’ll have extra space to make modifications. Concentrate on improving your test equipment and the testing techniques.

Antennas. I live in one of those places with restrictive CC&Rs. In addition, the terrain of my lot presents some significant challenges. Currently, most of my ham radio operation is antenna limited: without better ability to hear signals, there is little point in beaming out more power. I’ve been reading a lot about small antennas (transmitting loops, helically wound verticals and short verticals). Develop and test some of these, perhaps using WSPR beacon operations using different antennas as comparisons.

FPGA cpus. I’ve wanted to learn about FPGA techniques to design a CPU for years. I now have a BASYS2 board from digilentinc, and while I’ve gotten it to blink some LEDs, I’m quite a long way from making a CPU. I have a feeling this project will linger on for quite some time, but I’m keeping it on the list.

Experiment with the Kinect. Carmen got me a Kinect for Christmas. I have a couple of projects that I want to keep under my hat until I make some progress on them, but it is a gadget with lots of hacking potential.

Meta issues. It dawns on me that part of my problem isn’t coming up with project ideas, it’s figuring out how to accomplish them. First of all, there are the usual problems of productivity. Balancing work and home life with the requirements of your hobby activities. I’m not always good at that. But I also think also that I spend a great deal of time working in isolation, and seeking out other enthusiasts, collaborators and mentors would significantly enhance my productivity. I’ll be working on that in 2011 as well.

If you made it this far, what are your projects that you’d like to see done in 2011? Either scribble them in comments, or make a post on your own blog or whatever and link them in the comments.