Skip to main content

The enemy of any analyzer: Phase Noise.

That looks neat, but it's very, very bad…

If there's one thing that I was blissfully ignorant of before trying to build a spectrum analyzer, that is now an annoyance and borderline obsession, it's phase noise. Phase noise is exactly the same as any other kind of noise, but unlike noise on a DC signal, phase noise is more like tiny variations in the frequency of the signal.

To get a little more specific, think about phase as a quantity that describe show far along the sine wave we are at any given instant. It can be described in degrees, radians, or even if you're a little radical, tau radians. The idea is the same. Phase increases until it "rolls over" at the end of the cycle. It looks a bit like a sawtooth wave, assuming that we're discussing a constant frequency, unmodulated wave. Hopefully you believe me that phase noise looks just like noise superimposed on the sawtooth-shaped phase ramp.

Phase related to sine

I think the graphs above helps to illustrates the relationship between phase(above) and a sine wave (below). I've re-scaled the phase so that it goes from zero to one over the range of one whole number.

In the frequency domain, phase noise is a little easier to understand, and see. The graph at the head of this article is an extreme example of phase noise. Really, there are two kinds of phase noise here, and one of them we can do something about.

PLL example (From a Linear Technology data sheet)

I tried really hard to find some nice graphics to use to describe, simply, the basic operation of a PLL-based oscillator. The best I could come up with is the above diagram. This was lifted from the Linear Technology LMX2326 PLL IC.This is the same (or damn near) as the PLL chip that's used in the analyzer.The bottom left corner is the oscillator. All it does it generate a single frequency set by the voltage coming into pin 6. On the PLL chip, pin 2 is the output from the "charge pump," which is how the PLL sets the tuning voltage.

PLO1 Schematic (by Scotty)

Unfortunately, the PLL in the spectrum analyzer isn't this simple (if you can call a normal PLL simple!). In the center, near the top, notice the Op-Amp.The high-side supply to this amplifier is +20 volts (at least). The reason for this is as simple as that's what the VCO (voltage controlled oscillator)needs. It isn't possible for the PLL to produce voltages like this, so we need this extra supply.

VCO power supply noise

Now, the question is: "What happens when there's noise on the +20 voltage supply" The waveform on the oscilloscope above shows about 20mV of noise on the 20 volt supply. The frequency of this noise is about 20kHz. It's no coincidence that the spacing between the peaks in the comb-like plot is about20kHz. What's happening is that the noise on the 20 volt supply is literally modulating the output. Incidentally, that's exactly what you do if you want to frequency modulate something.

Now that we know what the cause is, what can we do about it? If we eliminate that noise, we can fix the problem. I had made a second 20 volt supply, and used cheap capacitors. Apparently, when using high voltages (relatively speaking) the amount of capacitance decreases in cheap, small, ceramic capacitors. I went back to the first supply I made, and added even more capacitance.

Better +20 volt supply

The lower trace is the new +20 volt supply, and it's peak-to-peak noise voltage is about 3mV. But the proof of the pudding is in the eating, so how does it affect the phase noise?

Much improved phase noise

It squashes it like a bug! The above plot is almost textbook for phase noise.The large peak in the center is representing the width of the final filter(I'll get to that in a later post) and the skirt is caused by traditional phase noise. If I zoom in to the center of that plot it's easier to see:

close in phase noise

Here, I've highlighted another common cause of phase noise: PLL loop bandwidth. This is the bandwidth of the filter that smooths out the pulses that come out of the PLL chip.

That's all I have for now… I've tried to make this topic, which is very technical and dry, interesting and accessible to those that haven't spent the last 5 years trying to build a spectrum analyzer. I hope you've enjoyed it.

If you want a much more in-depth and technical analysis, see Scotty's website.

Spectrum Analyzer Aluminum Frame

Beautiful new frame for my SA

I haven't posted for a while. I'm sorry. I was being selfish. I've made fantastic progress on my spectrum analyzer build, and it's so much fun that I haven't had the will to pull myself away and post about it.

Also, completely unrelated to the build, I've experimented with a service called "Cloudflare" as a way to make my site more resilient. It doesn't, it's MUCH worse. I'm not happy with it at all. I've shut it down, so hopefully once the DNS changes propagate it'll be more stable.

Anyway, back to topic. The last post about the analyzer was about the ChipKit digital logic controller. That was going very well, so well, in fact, that I was able to finally diagnose an intermittent connection problem between modules. Intermittent problems are always the worst, especially when you don't trust other components in the system. The reason this is relevant to the discussion at hand is that the problem only manifests when one of the connectors has pressure one one side. I needed a reliable way the hold all the modules in fixed positions.

Since beginning this project, I've been inspired by the way that two people built their analyzers. Hans' is probably my favorite. I took the image below from his photo album in the Yahoo Spectrum Analyzer group.

Hans' analyzer "bottom view"

I love how clean and organized it looks. Much different than most of the others out there. His frame has holes that go all the way through the frame, and he has a back cover that screws on. His coax cabling is made of right-angle soldered-on connectors with what looks like RG-405 hard pipe.

Another inspirational build is Sants. This image is also scraped from theYahoo group.

Sant's build

This build is most probably the closest to mine. The pockets, or wells, for the component side of the boards don't go all the way through the substrate. Notice, in both designs, that there is a small lip around the perimeter of each well. This is there to hold the boards and to electrically connect to the ground vias on the perimeter. This design also uses right-angle connectors and hard pipe.

With these designs in mind, I sought out the things I would need. First, of course, was the aluminum itself. I had looked into McMaster-Carr (hopefully this link works), and a 1/2″ thick 12″ square costs about $40. Then, my brother suggested looking on eBay. I was able to find an equivalent sheet for about $30 after shipping.

Frame block layout

Once I had a cool hunk of 6061 alloy in my hands, I started designing the layout of the frame. I started with OmniGraffle (it's like Visio) because I could lay it out to scale, and the connections move in a natural way.

Once the layout was complete, I transcribed the design, complete with all the details into AutoCAD. By this time, about a month passed, and I was able to find someone willing to machine it for me as a favor. I also got a quote from another friend, which was about $250. This is a reasonable cost for something like this, in case you're looking to duplicate my results.

Close up of one of the wells

It took several weeks to get the parts back from the machinist, but the results are totally worth it! The larger hole was cut with a 1/8″ end mill, and the inner pocket was cut with a 1/4″ mill. With the majority of the modules, the inner radius is fine. There were a few exceptions, however.

Small relief for DDS capacitors

This photo shows some of the rework I had to do to accommodate a few capacitors right at the edge of the DDS module. It's very difficult to take a picture of a small notch in a shiny material, but hopefully you can see the cut into the side of this pocket. I made that mostly by making small, successive cuts using an exact-o knife. The PLO reliefs were a bit more aggressive (there is a power header right in the corner), so I had to use a Dremel cutter bit in my drill press.

Relief for the PLO module

Once important lesson learned in this process is that 1.2″ or 2.4″ set into a PCB specification is more of a suggestion rather than something that you can count on all that much. I had to sand almost every module to get it to fit. Once that was done, however, everything fit like a glove.

Making custom coax jumpers

The final piece in the puzzle is the coax. The perfect jumpers that both the other designs featured were definitely something that I wanted. It's possible to get these right-angle SMA connectors from China for about a dollar a piece, much less than the ~$5 that you'll spend at Digi-Key.

Connector end, ready forsolder.

To make them, all you really need to do is measure the coax sections, strip the ends, and solder…

Soldered center conductor

Soldering around the shield of the coax is the hardest part, and it's not even that bad.

Final product!!

That's all there is to it! I'm really happy with how well things turned out.Certainly something to be proud of. Over the next few days, I'm going to try to keep posting about the other advancements. I have a bit of a backlog, so I should be able to keep them coming…

More ChipKit spectrum analyzer progress

Modifications to the ADC

I've been able to make solid progress on the spectrum analyzer tonight. I've continued using the ChipKit, I'm fairly happy with it at the moment. As I mentioned in the last post, I've increased the baud rate on the serial port to115200 baud. That seems to be the point where the SPI bus speed and the serial port speed are about matched. There's still plenty of room to increase it, however.

I've been progressing in the project by adding one module at a time, and testing as best I can. I've got PLO2 (mostly) working, and DDS1 seems to be rock-solid. I'm able to command it to any frequency I want between almost 0 Hz up to 20 MHz. Tonight, I added the ADC to the list of modules that seem to be working. To accomplish this, I had to make two modifications to the ADC. The first was to change it to work with a 3.3v DC supply. This change was trivial, it's the same as the modification to run off of the power from the PDM. You just remove the old voltage regulator and replace it with a bit of wire. This is necessary because, if it's powered with 5 volts, the minimum voltage required to mark a digital '1′ is 3.8 volts. The PIC32 in the chip kit is powered by 3.3 volts, so there's no way that's going to happen. In reality, it's probably going to work, but it's likely going to give you a headache.Finally, I removed the two transistors that were on the outputs of each ADC.They were there to provide stronger output drivers (the ADCs can only drive their outputs with 500uA). The parallel port requires a pretty healthy amount of current on the status lines. Because it's being connected directly to a micro controller, these drivers aren't necessary. Not only that, but they were acting as it they were damaged. With them gone, everything seems to work great!

Now that the ADC and a DDS works, I can begin to use it as a spectrum analyzer… even if it's only for a very small range of frequencies. For example, I can make a plot of the filter used with the "squarer" in the DDS:

DDS1 squarer response

It's not immediately clear whether this plot makes any sense, I'm hoping thatI can get someone in the panel of experts to weigh in on it. It's reasonably clear that there is a pass band centered around 10.7 MHz, which is what I want. I'm not sure what to think about those steep slopes and the large spike of to the right. None of this may matter, as the DDS will never be tuned out there anyway. It could even be that a harmonic of the DDS output is getting through the passband when it's tuned there. I really have no idea.

The plot below is from the final resolution bandwidth filter (RBW) that's used to set the resolution of the analyzer as a whole. I got this filter from one of the MSA experts (thanks, Sam), and I know it performs better than this.Again, I'm wondering if it has this shape due to some quality of the DDS output, or some other factor.

Shape (maybe) of my final resolution bandwidth filter

Ultimately, I think these graphs are great, and very encouraging. Even if they're a bit confusing, it's nice to be able to put something up on the screen. You might be wondering how I produced them Well, that's the embarrassing bit. My cheesy analyzer program (which is really just a way to test the suite of classes I've written for communicating with the modules)will spit out text that can be used as a CSV (comma separated values) file that can be read by Excel or Numbers. I used Numbers to create these plots. I think they're log-scale plots, because the log detector module produces logarithmically increasing voltage given increasing input power, thus I used linear scaling on the Y axis. The Y axis is the raw value from the ADC, and the X axis is the frequency.

Update:

I got an email back from Scotty about the graphs I got from my DDS sweeps. The first plot, of the DDS squarer, is normal. The reason it has that shape is best explained in the context of the schematic of that part.

DDS Squarer (section of the schematic from scotty's webpage)

Trace the signal from "OUTA," it goes through matching network (I think!),then a crystal filter (XF1), and a logic inverter. Basically, the inverter will "snap" on or off once the sine wave from the filter passes a threshold voltage. Once the signal is attenuated to a certain level by the crystal filter, the inverter will no longer trigger. This is the reason for the sharp skirts on either sides of the passband.

Scotty also thinks that the response plot from the RBW filter is indicative of a mismatched input or output. I'm pretty sure it isn't the actual filter, soI'm going to look into other sources of impedance mismatch.

Update 2:

Not only did Sam agree that the shape of the RBW filter is likely due to the impedance mismatch between the source and the filter, but that I could probably help the situation with an attenuator. I inserted one (with a DC blocking capacitor) between the DDS source and the filter, the plotted it again.

Second plot of the filter shape

My only concern now is that the filter bandwidth looks much much wider than I expected. I don't know what the cause of this is. Because I really have no calibration, I don't know how the "counts" in the ADC map to dBs of signal.Typically, filters are defined by the points to the right and left of the center that are 3dB "down" from the center level. However, I may be able to glean some knowledge from the datasheet.

RSSI voltage vs. input power level (from the Analog devices datasheet)

The slope is ROUGHLY(!) a half a volt per 20dB. I'll do a better calibration when the code is there, but for now let's just continue on. Once we know what the slope is, we need to map the counts on the ADC output to volts. I've converted the ADC to use 3.3volt power, and it's a 16 bit device, so there are65,536 counts (numbers) spanning 3.3 volts, or 19859 counts per volt. In mys preadsheet, I just made a new column that performs this conversion. Finally, because it looks like 2 volts maps to about 10dB. So, I added another column to the spreadsheet, this time subtracting 2 from the volts, divide by .5 and multiply by 20.

Unfortunately, it's not easy to see where the 3dB points are. Looking at the raw data, I can see that the maximum value is -13.0 dB, so the 3dB points are where -16.0 dB is crossed on each side. On the low side, it's 10.6989, and on the high side, it's 10.701360. The resulting 3dB bandwidth is .002 MHz, or 2kHz. This is exactly the published value. I guess this means that it was a very successful experiment.

Spectrum analyzer development with ChipKit

Now that I know that trying to use the BusPirate with the74595′s is basically a non-starter, I've moved on to using the ChipKit. The ChipKit is a arduino-like board with a Microchip PIC32 micro controller.The PIC32 is, as the name would imply, a 32 bit processor, running at 80 MHz.That's pretty impressive, if you ask me. It has a boot loader and software package that makes it more or less compatible with arduino code. I really like that I can just hack something together without all the setting up SFRs(Special Function Registers, or the bane of embedded device programmers existence).

Anyway, I've developed a simple "sketch" (program in arduino terminology) that accepts serial commands and executes SPI transfers using a set of pins through the 74595′s. You can kinda see what's happening in the logic analyzer trace above. The top three traces are the SPI commands to the PLO module. The middle two are the serial in and out of the chip kit. The bottom three are the SPI commands to the 74595′s. I had to zoom out far enough that you can't see what the serial or bottom SPI contents are, but it's basically "$,s,A,B,C,L,DDD…" where A, B, and C are the pins for SPI Chip Select, Clock and Data, L is the length of the transfer in bytes and DDD… is the contents of the transfer. Currently, the limiting factor is the serial communication (by that I mean UART, not SPI),but I'm only using 9600 baud in this example. The ChipKit uses an FT232R USB-Serial converter that is good into the mega-baud. In the future I'll experiment with higher baud rates.

That's basically, all. I just wanted to post and say that it works. By the way, the PLO module happily accepted its commands and tuned to 1024 MHz. :)

Buspirate and shift registers (a tale against publication bias)

As with most "publications," if you can call a blog post a publication, you're much more likely to read about what works than what doesn't. This is not that kind of post.

Experiment setup

For background, I'm still working on my spectrumanalyzer. I don't really like the current control board setup, and the windows only, BASIC software. I'm investigating other options for replacing those components. I'm thinking about using the 74595 shift registers to expand the number of control lines that I can control.

74595 architectural diagram (from the fairchild data sheet)

The basic idea of the 74595 is that it's a shift register with an extra set of output registers. The advantage is that you can load it "behind the scenes,"then apply the output glitch-free at once. Essentially, you can treat it like a SPI peripheral. Load the pin values serially, then you can use the CS with the RCLK pin to load the output registers.

Schematic for 74595 based port multiplication

The schematic I used is included above. The basic model is that these devices can chain together. The serial data (delayed by 8 clock cycles) appears onQH*. This way, if we want 32 pins, we can chain 4 together. Load 32 bits of data onto the SPI bus and pulse the CS pin high. Hey presto, Bob's your uncle, you've got data.

The risk of this approach is that every operation on any of those pins takes32 clock periods on the SPI bus. If the bus is clocked slowly, it can be a major problem. I had assumed that, because I can use a 4 MHz clock with the bus pirate, it would be alright. However, I hadn't anticipated the additional overhead that the bus pirate adds by using the serial port of a PC. Even using the binary scripting mode, you have to use 4 serial bytes for one 8-bit SPI transfer. The problem really stems from the inconsistent and bursty nature of the serial interface.

Logic analyzer capture

The bottom three traces on the above logic analyzer capture are the SPI commands to the registers. The top three are the SPI out from some of the register pins. Every change in the states of the top three requires a full load of the shift register. A SPI transfer out of the register requires 3 *bits + 2. The coefficient 3 is due to the expense of raising the clock pin, changing the data pin, and lowering the clock pin. The extra 2 is from raising and lowering the CS pin. Notice that it takes 1/3 of a second to execute a 40bit SPI transfer. To load a PLL requires several 21 bit loads, so it's about the same. This is unacceptable. That's the moral of the story. The bus pirate simply can't execute fast SPI commands through a shift register. Now you know.:)

USB to RF Transceiver prototype complete!

]

Collection of transceivers

This is just a post to point you over to my new Transceiver page. I took the work that I did on the MRF49XA transceiver, and added an Atmel AVRUSB micro controller. I prototyped is using the AT90USBKey development kit, and designed a custom PCB that includes the transceiver and an AT90USB162.

"Component side" of the USB transceiver

I wanted to design the board such that all the "guts" were on the "back" side of the PCB. The photo above shows the transceiver circuit (surrounded by a strip of track that you can use to solder a "fence" or "can" to manage RF interference), and the AT90USB162 micro controller. This can be replaced by and 2 series USB micro controller, like the ATMega32U2 or the AT90USB82. I recommend using the ATMeta32U2, though the first run of boards have theAT90USB162. I've also included a dedicated 3.3v voltage regulator, because the built-in regulator inside the AVR doesn't have a clearly marked current capacity, and I didn't want to risk it. I've also included every spare pin from the AVR that was practical.

The "top" side of the board

The other side of the board contains all the user facing parts. This includes the status LEDs, the SMA connector, USB port, and the boot loader and reset buttons. My grand idea here was that I could mount a piece of plastic to the component side to protect them, while having access to all the bits I need to use. In hindsight, this means that it's a "double-sided load" which is harder to manufacture. I ended up having to learn a new technique to solder the USB port. Notice that the can of the USB port covers the pads It's very difficult to solder those on. It helps to "tin" the pads first, then set the USB port on top of them. Luckily, the USB port has little plastic pins that keep it aligned. When you're pressing down on it, just hit it edges of the pads with the soldering iron, and it should solder just fine. When that's finished, solder the mounting tabs on the sides.

Also, the buttons I bought aren't "process compatible" which means that you can't wash the board with them installed. To deal with this, I reflow solder the entire board, then put them in my new ultrasonic jewelry cleaner with time isopropyl alcohol and brush them with a toothbrush, finally rinse off the alcohol and dry with compressed air. Once the board is cleaned, then I solder on the buttons.

Lessons (mostly) learned Think about how you would assemble something when you're designing it!! Building the board this way adds 15-20 minutes of assemble time. Bummer.

PDFs of the transceiver PCB artwork.

Sorry it's so ugly, the "high quality"rendering in Gerbv doesn't work in mac os anymore.

Component side artwork

User side artwork

Also, here is are the gerber and eagle design files.

Work on the software is ongoing. Click on the transceiver's main page (link at the top) for updates. Enjoy!

DFU-Programmer tips & tricks

I recently got an AtmelAT90USBKey to play around with. I'm going to use it to prototype a USB controller for the MRF49XA transceiver I made a while ago. Thatpost is still in progress, but I had trouble getting started with DFU-Programmer on the mac, so I thought I'd make a post about those problems so it may help others having the same trouble. I know that I found next-to-nothing when I was googling for it.

I didn't have too much trouble installing DFU-Programmer, the version included in macports works just as well as the version I compiled from source. The first problem I encountered was a weird memory error when I tried to dump the device memory. When I'm just starting with something, I usually don't jump in, guns-blazing, and start erasing and flashing stuff. I start by dumping memories, usually it's not going to break something that already works. In this case, I ran up against a brick wall.

$ dfu-programmer at90usb162 dump -debug 5 > temp
target: at90usb162
chip_id: 0x2ffa
vendor_id: 0x03eb
command: dump
quiet: false
debug: 5
device_type: AVR
---- command specific below ----
Request for 12288 bytes of memory failed.

There is literally no reason I can think of for this error to occur, it's not using very much memory, and I've never seen a malloc fail when there is a reasonable amount requested. I've searched for about 2 days for the answer, and I've still come up with nothing. The only hits I've seen are simply source listings for DFU-Programmer, where the printf for the error is! Getting around it (temporarily, even!) is a multi-step process, and requires a device erase(which makes it just about useless):

  1. Erase: dfu-programmer at901287 erase -debug 5
  2. Reboot into the boot loader (again)
  3. Erase (again, because a write-protect error: see below)
  4. Flash device: dfu-programmer at90usb1287 flash file.a90 -debug 5
  5. Dump flash memory: dfu-programmer at90usb1287 dump -debug 5 > out.dump

Eventually, it worked. I'm not at all happy with the performance of dfu-programmer on the mac. I'm considering forking it and making a proper mac application, but I'm not sure I'm willing to support it at the moment.Ultimately, though, it does work, it's just not as functional as I had hoped.

The write-protect error I mentioned above looks like this:

target: at90usb162
chip_id: 0x2ffa
vendor_id: 0x03eb
command: flash
quiet: false
debug: 5
device_type: AVR
---- command specific below ----
validate: true
hex file: USBKEY-series6-ms_df-2_0_2.a90
Device is write protected.
Error while flashing.

This error is strange (I've never set the write protect flag!), but easy to fix. It is common for micro controllers to clear the write-only flags when the part is erased. That's the solution here, just erase it:

dfu-programmer at90usb162 erase

Now, you should be able to program the device. Even when I hadn't set the protection flags (knowingly, anyway) I got the write protect error.

The moral of the story is that dfu-programmer doesn't work very well on the mac, and the magic fix seems to be erasing and rebooting the part often. Good luck! If you have noticed something stupid I'm doing, I'm all ears. It seems like others haven't had these problems, so I'd love to hear if there's something I'm doing wrong.

Note that the AT90USBKey was provided by Element 14 in exchange for writing this post.

Helical Quad Antenna for Weather Satellites

]

Finished and installed antenna!

It didn't take long after my first successful attempt at receiving weather satellite broadcasts for me to realize that I would need a much better antenna. I had been using a 1/4 wave whip with a 4-wire ground plane. The reperformance out of this antenna was poor. I read up on QFH (Quadrifiliar Helix antennas) from many of the high quality posts from around the world. I took what I could from these implementations, and did my best with the supplies I had available. I ultimately started with whatever PVC pipe I had lying around; it ended up being 1-1/4″ outside diameter garden-variety PVC. Next, I went onto the excellent QFH antenna calculator. This site already has the defaults for a good 137 MHz antenna, and I didn't change them. Next I measured the diameter of my pipe (in mm) and printed out the drilling templates using their drilling template generator.

]

Drilling template

Pick a point for the top line of the template and scribe a line perfectly parallel with the axis of the pipe. This is easy if you use the "estes doorjamb trick." For those that haven't built a model rocket recently, you put the pipe in a door jamb crease. This right-angle will make the pipe perfectly square and you can mark a line. Also, you can use a piece of angle stock, as this guy did. Make sure that all your template strips line up with this line. Next mark the holes' letter with pen on the pipe. This is your reference for where the wires need to go. Finally, drill the holes. I only drilled the top and bottom holes, and I didn't make them as big as the template said. The template (and the calculator) suggest using 3/8″ soft copper tubing, but I didn't have any of that around, and it costs a lot more than the #10 ground wire that I used.

]

Spacers installed

I knew I would need spacers half-way through the helical loops, but I didn't have any of the tubing that most people were using, so I used some acrylic sheet. I just took the width of the loop and marked those points along a line.In the center I cut holes for the mast. I trimmed off the edges with a(mostly) straight line so it tapers to the end. At the ends, I made little notches to hold the wire, and drilled a hole for some unwaxed dental floss.

]

Loops held in with floss

Once I made a simple knot with the floss, I hit it with some superglue and called it good. I don't have any pictures from forming the loops. This is an often ignored part of building one of these antennas. I understand why so many people leave that part out, though. It's amazingly stressful, and easy to forget about documentation. To do it, I started with long pieces of the copper wire. Use more than you think you need. Once your wire is cut, measure to the center. Measure out from the center one loop radius on each side and mark it with sharpie. Bend one side of the wire as sharply as you can, and slide the longer side of the loop through your lower pair of holes. With what will be the center of the loop in the pipe, bend the other side of the loop. Carefully twist the helix, meeting the spacers on the way. It's probably not a bad idea to temporarily (make sure the copper can be adjusted) attach the wires to the spacer. Measure from the mast one loop radius and bend the wire toward the mast square with the upper holes. Cut the extra wire so that it fits inside the pipe with a little room to spare. Once you're sure it's the right length, bend the wire 45 degrees toward the other loop. Do this for each side of each loop.

]

Wiring of the feed point

The picture above is skipping ahead a little, but this way you can see what I mean about bending the wires inside the pipe. As you can tell, I had a very hard time soldering the feed point. The copper ground wire is a hard to solder with an iron because it conducts heat readily, and has a lot of thermal mass.I usually use a torch to solder it. In this case the solder point is inside the tube almost an inch. The first time I tried to solder it, I set the end of the tube on fire. Later, I insulated the coax and tube with aluminum foil.Though the foil provided sufficient protection, I still charred the sides a bit. The cable was adequately protected.

]

Balun

Though the feed for this antenna is technically 50 ohms impedance, it's a balanced design. Fundamentally, coax is unbalanced. By coiling the cable around the mast a few times you're able to implement a simple balun. I'm not sure how many times to do it, I've seen different numbers different places, so I chose 6; because, why not It seems to work fine.

]

finished antenna

This is the antenna all finished up. I've received several quality satellite images with it so far, but this is certainly not where I'm going to keep it.First of all, my house is to the north-west of it, and seriously degrades the signal, secondly my wife wouldn't like that very much, I don't think.

]

Spider-proofing

I decided to keep it outside (some people put them in their attic), so I had to take some measures to spider and wasp proof the mast. I epoxied all the openings for wire and cable at the top of the antenna, including capping the pipe, then I stuffed the bottom with some pipe-wrap foam.

]

Installing on the barn

I ended up settling on the barn roof as a home for the antenna. There was a small gap in the plywood below the metal roof cap that I think I can exploit for the feed line. I unscrewed a section of capping, found an existing hole in the tar-paper backing and went to work affixing the tripod.

]

Feedline routing

It's really important to think about water infiltration whenever you do anything to a roof, especially in Oregon. For a while, I did some contract work installing antennas for a cell phone company, and we installed outdoor antennas on almost any kind of roof you can think of. For metal roofs like these, the easiest way to make it water-tight is to clean the metal surface off, then cover the place where you're going to screw the mast to with silicon sealant and screw through it.

]

Mounting the tripod

This way, water doesn't have a chance to wick through the roof through the screw threads (or that's the idea… I explicitly disclaim any responsibility for roof damage if you follow these instructions).

Feedline inside the barn

Here, you can see the ultimate goal: Antenna on the roof of the barn and feedline inside!

Receiver ready for the next NOAA satellite pass!

Finally, I screwed the receiver to a joist and routed some wires. I don't know what I would do without my insulated staples! :)

Homebrew bubble counter

Counting bubbles during secondary fermentation

For a while now, my friends and I have been brewing beer at my house. I was inspired by an old Sparkfun tutorialabout a bubble logger for Nate's terrible wine. I figured that while logging bubbles is interesting and all, wouldn't it be more useful to have real-time information on the fermentation process I basically copied the optical gate method of counting bubbles, added a sensitive pressure sensor, and an AVR development board (Yes, Arwen, that's your old TekBots board! :) ).

Just like the Sparkfun tutorial, I used an IR photo gate sensor on an S-shaped airlock. One thing that I thought was really interesting is that the water in the airlock doesn't block the IR path, it actually improves it. I ended up needing a potentiometer to adjust the LED brightness on the photo gate, this is because it has to be just the right brightness to detect bubble transitions.

] Counter closeup

The programming on the microcontroller was really simple. All it does is keep a clock, and when there is a rising edge of photo gate signal (bubble passed)it prints the time and a bubble count to the serial port:

01:20:16:16,01646
01:20:16:18,01647
01:20:16:20,01648
01:20:16:22,01649
01:20:16:24,01650
01:20:16:26,01651
01:20:16:28,01652
01:20:16:30,01653
01:20:16:32,01654
01:20:16:34,01655

I chose to use whole seconds as the time step. That was certainly an oversight. When I designed the software, the brew was in second fermentation.There was a bubble once every 20 seconds or so. I thought "It couldn't be that much more during primary fermentation, right" Wrong. During the beginning of primary fermentation, there can be 3 or 4 bubbles a second. I made up for this oversight in the Ruby script I wrote on the server:

# Get an interval from the last to this bubble in seconds
interval = seconds - last_record_seconds
last_record_seconds = seconds
if interval == 0
    bubbles_per_second += 1
else
    # if, in the last second, we counted more than one bubble
    # find the frequency by multiplying the bubbles per second
    # to bubbles per hour
    if bubbles_per_second > 0
        frequency = bubbles_per_second * 3600
        bubbles_per_second = 0
    else
    # Convert the interval into fractions of an hour            interval = interval / 3600.0
    # Convert the interval to bubbles per hour
        frequency = 1.0 / interval
    end
    printf("%f bubbles per hour\n", frequency)
    RRD.update(rrd_name, "N:#{frequency.to_s}")

I've left out the parts where I initialize the serial port and theRRD database and parse the messages. I've attached the whole script, including the script that generates the graph, at the end of the post.

Chocolate porter brewing record (primary fermentation)

Here is the bubble record from one of our beers. I was very surprised by the14,000 bubbles/hour rate achieved a half-day after pitching the yeast. I adjusted the graph many times to make everything visible. I absolutely had to use a logarithmic scale on the value access, there is just no other way to be able to see a 14k+ value while still being able to see where 60 bubbles/houris (this is about when the brewing is finished). These graphs are always updated, and are available online.Of course that is only meaningful when there's a brew going at the moment!

Sensitive pressure sensor

I had grand plans of adding a pressure sensor to try and measure the volume of co2 escaping out of the airlock. I figured that if I subtracted the pressure after the bubble from the pressure before I could use the ideal gas law and measure the moles of co2 that escaped. This was all fine and good during secondary fermentation (when I first tried it).

Pressure delta during slow fermentation

During slow fermentation, when bubbles happen less than once per 15 seconds or so, it's easy to see and measure the pressure difference before and after the bubble. In the image above, there is about 40 mV of swing before and after.The time represented in this image is a full minute, so you can see the slow buildup of pressure.

Pressure measurement during fast fermentation

During very fast fermentation, on the other hand, individual bubbles don't contribute to much difference in pressure. In the image above, you can see general trends of pressure. Sometimes, i assume, due to surface tension there aren't bubbles for a while. When pressure builds up to a sufficient level bubbles begin. The pressure drops again and the cycle repeats. I'm not really sure how much I can do with this data. The time represented in this graph is12 seconds, and the bubbles per hour is about 18,000 bubbles per hour (5 *3600).

Close up of a bubble during fast fermentation

This is just a close up of a single bubble. There isn't really any measurable difference in pressure before and after the bubble. Ultimately, the pressure measurement stuff is on hold for the moment. If someone reads this that's really good with the ideal gas law has ideas let me know!

The next step for me is to figure out an elegant way to support many brews.We've got a wine, apple cider, and a beer going at the moment, so I would like to have 3 channels. Oh well, another project for another day.

Supporting files:

firmware

ruby script

Development board schematic

Receiving weather satellite images with Softrock

](http://alternet.us.com/p=1398) One of my first NOAA APT satellite images! (click to learn more)

The National Oceanic and Atmospheric Administration (NOAA) manages a few satellites in low earth orbit. There are three actively transmitting APT signals at the moment, NOAA15, 17, and 18. Each of these satellites passes overhead a few times a day. I've been interested in learning how to receive their signals for a while now, and I've finally succeeded!

A bit ago, I bought a "SoftRock"SDR (Software Defined Radio, read the excellent 3-part article by Bob Larkin at the ARRL site) receiver kit from TonyParks. (A note about his site, he puts a few kits up for sale a few times a month, so he's almost always sold out.) I think SDR is really, really interesting. I don't want to get too bogged down in the details of it, because it's not the point of this post, but I'm going to briefly discuss it. Basically, the idea is that you want to have some minimum amount of electronics to deal with the antenna; letting your computer handle the rest. This can take a variety of forms, but the simplest is the QSD, orQuadrature Sampling Detector.

Source: Gerald Youngblood's article "A Software-Defined Radio for the Masses,Part 1." Click image for source

It sounds complex, but it's quite like using a strobe light to look at a spinning wheel. The bright light of the strobe "samples" the world at a given interval. If it strobe rate matches the speed of the wheel, the wheel appears still. Stretching the analogy a bit further, imagine that information is written on the wheel. Using the strobe you can read it, even if it's spinning.While that is an awful analogy, but the idea is that we can sample the radio signal at (nearly) the same frequency as the carrier of our desired signal.When we do this, the signal we want magically appears at the output. If we're using AM (or its derivatives such as LSB orUSB) we can even listen to it directly. It only gets a bit more complex when we consider the quadrature part. Quadrature just means "90 degrees out of phase." Using another copy of the radio signal, and a sampling clock in quadrature, we can cancel out some noise and interfering signals. Sorry for the tangent, if you read this far (without falling asleep), I recommend you read the linked articles at the top of this paragraph. The math isn't too hard, and it's sooo powerful!

Dead link

This isn't an image of my SoftRock, it's a slightly different version, but I don't have an image handy. It's a really easy kit to build, and it's fairly inexpensive. More than that, it's really easy to use. Once it's all setup, you just attach it to your computer, power it, and install the antenna!

Once you've attached the receiver hardware to your computer, you need some software to use it. This is an image I took of a very well written SDR program on the Mac called DSP Radio. On the left side of the spectrum window, there is the live radio spectrum coming from the satellite. The green box around it represents the bandwidth of my software radio receiver. In a traditional radio, this bandwidth would be set by a filter circuit. Most communication radios only have about 15 kHz of bandwidth.This makes them unable to properly receive satellite weather images.Traditionally, you would have to build or buy a specially-built satellite receiver. With SDR, I can move a slider to scale the bandwidth way, way up! In this case, I'm using about 37 kHz of bandwidth! Notice that there's all this empty space on the right, this is radio spectrum that I'm receiving, but there's nothing there. Maybe you can notice the shadow of the satellite data on the right; this is an "image." These images are the bane of all radio designers. The true test of a receiver (other than sensitivity) is how well these images are suppressed. In this case, they're suppressed rather well, notice how bright the lines are on the left compared to the right.

Signal flow from RF to weather image

The DSP Radio program takes the signals from the Softrock through the audio input of the computer. When you have something tuned in through its interface the demodulated signal appears at the audio output. I've been recording these signals as well as passing them to another program called WXtoIMG. This program is not great, I'll be honest.It's barely maintained, and you can tell it's an ugly cross-platform mess. To even get it to work is tricky. But, what it does, it does well. The image at the head of this post was generated using it. When I made that image, I literally had to connect the audio out of one computer to the audio in of another. I'm not sure how I'm going to get around that issue. It can accept data in the form of wav files, provided that they're linear PCM sampled at11,025 Hz with at least 16 bit samples. The problem is that the nice political boundaries, lat/lon lines and ground image comes from the program. It does this by computing the location of the satellite and where on the earth its photographing. It has to decode the audio in real time for this to work, which means that I can't use an audio file. For you to play around with, if you wish, I've included a sample wav file. It starts before the satellite pass and ends after, so if begins and ends with static.

NOAA15-baseband.wav (large file warning: 28 MB)

The included audio can be used to create the image below. I used WXtoImg to generate it, though the open sourceWXAPT could be used under Linux.This image was taken when the satellite was traveling south-north, so I had to flip it vertically and horizontally. On the right side of the image is the A channel, which is visible light, and the left side is the B channel, infrared.Normally, these channels are reversed left-to-right. The stripes and color bars help the decoder line up the image and adjust brightness, contrast, and gamma. (Right-click here to download full-size image: 2080 x 1260pixels)

(lightly) processed image from NOAA15 audio file

My next step is to write some shell scripts on a Linux box to automate this whole process. My goal is to have a page that has the latest satellite image and an archive available at all time. But first, I have to write a post about the antenna I built to receive these signals. Stay tuned!