Flight log results in Google Earth

I’ve been working on my private pilots license for the last few months.  The primary plane that I’ve been using is the Cessna SkyCatcher.  I’ve included a photo of an example of this plane below.  It’s a fun aircraft, other than the fact that two normal-sized adult males can’t take full fuel.

Cessna 162 SkyCatcher

One of the nice features of this plane is the Garmin G300 “glass cockpit” system.  The days of circular “stream” gauge instruments are fast coming to an end.  This particular aircraft’s system has a SD-Card slot that can be used to update the databases, store flight plans, and the like.  If a card is installed during flight (really all the time) a log is updated every second, or so.  Luckily, Garmin had the foresight to write these logs using standard CSV (comma separated values) files.  The logs contain valuable data including not only the location, altitude, and speed, but engine data, faults, and nearly anything that is displayed on the screens.  This would be very valuable data in an NTSB investigation, that’s for sure.

SD-Card and the G300

Because Google Earth really does not care about exhaust gas temperatures, RPMs, and things like that, the first task is to discard all that data.  The only data we need to keep is local time, latitude, longitude, and altitude.

Unedited flight log data

It’s your choice whether you’d like to use GPS or barometric altitude.  They both have their advantages and disadvantages.  I usually use GPS altitude.

Flight log after removing superfluous fields

The website that converts from CSV files to Google Earth files insists that the altitudes are presented in meters, rather than feet.  Even if you select “U.S.” or “Nautical” units in the interface, it still processes the altitudes as meters.  To execute this conversion, I make a new column that is computed from the altitude, multiplying it by 0.3048 which yields meters from feet.  Then, depending on your spreadsheet program, copy this new column’s values on top of the GPS Altitude column, then delete the computed altitudes.

Converting feet to meters

Next, we need to add a trackpoint column that’s numbered serially.  The easiest way to do this is by using another function that creates this data from the ROW() function.  Also, we can use this time to rename the columns; they need to be named a certain way for the website.

Adding track point IDs to the entries

Processing the log is all finished.  Next, just export it from the spreadsheet program into a new CSV file.

Completed flight log

Almost last step:  We go to GPSVisualizer.com and navigate to the Google Earth KML file form.

Using GPSVisualizer.com to make the KML file.

The important fields to change are the document name (this can be whatever you want, it’ll show up in Google Earth), the Altitude mode (set it to “Absolute”), and finally choose the CSV file that you’ve carefully modified.  When you click “Create KML file” you’ll be presented with a screen that lets you download your new KML file.  Once it’s downloaded, assuming that you have Google Earth installed, it’ll open and you can move it from “Temporary places” to “My Places” and it’ll be saved.  The end result is the nice image at the head of the article.

Share on Facebook

R820t tuner on a rtl-sdr compatible dongle, from eBay seller CosyCave

Relating to the rtl-sdr work that has been done, the E4000 tuner was the standard barer for a long time.  However, Elonics has discontinued this part, and it’s becoming difficult to find.  The popularity, and scarcity, of this part has encouraged sellers to offer products claiming to be built with the E4000 and are not.  Luckily, someone discovered the code for using the R820t tuner in the Linux V4Lin drivers.  They ported this code into the rtl-sdr source maintained by osmocom.

I just finished porting their code into Cocoa Radio.  Now, it’s possible to use my software with both the E4000 and the R820t.  On startup, Cocoa Radio will automatically detect which tuner you’re using and perform the appropriate actions.

It did take a little while to finish this work, and there are several more tuners out there.  If you are desperate for support of a specific tuner, you can donate a device for the cause and I’ll try to support it.  By the way, Softshell uses the same code for tuning as Cocoa Radio, if you recompile softshell, it should include this new code.

All the relevant code and binaries are, as usual, available at github.  Make absolutely sure that you also update the softshell repository!

Share on Facebook

Cocoa radio interface explained (click for full size)

Well, I’m back from vacation and I want to tell everyone about a new version of Cocoa Radio (my application for demodulating radio signals using the rtlsdr dongles on mac os x, written in Objective C).  This version seems to be running really well.  I’ve set the sample rate to 1024000 samples per second for the moment (though this value can be changed in the code), and at this rate everything seems really stable.  Please give it a try and create issues at the github issues page if you find any problems.  I should say that I’m a little tired of working on it, so unless there are major issues I’ll be working on other projects for a while.  I encourage others to take a look at the code if they’re interested in SDR.  It’s not as scary as it looks!

Also, the sliders are a little buggy (especially the bandwidth ones).  Move the a little bit once the app starts up and they’ll work correctly.

Finally, I don’t have any support for AM (amplitude modulation) yet.  It’s an easy modulation type, and I may add it soon.

Share on Facebook

This video shows the basic operation of the user interface:

And this one shows an ‘inside peek’ at what happens to the signal inside of the application. In normal usage, the waterfall display won’t do this, but it’s an interesting effect:

There are still many, many bugs, but it should be enough to play around with. I’ve been able to listen to broadcast FM radio for some time using the app. There is no squelch control, that’s on the list of things to add. Also, it’s possible to get audio buffer underruns. It’s likely caused by slight differences in the clock rate of the rtl-sdr dongle and the audio device that you’re using.

If you notice any bugs, or have specific issues that you would like addressed, please create an issue on the github page.  Also, if you are able to contribute, please let me know.  I’m obviously in need of some GUI assistance!

One word of advice, don’t try to change the modulation type using the drop-down menu, it doesn’t work!

Again, code is available at github, as is an application binary.

Share on Facebook

Share on Facebook

First of all, it is vital that you don’t have the macports boost 1.50 installed.  There is a problem with that version where the x86_64 version of the library isn’t compiled.  This is mentioned in an earlier post, and the mac ports trac entry is here.

The easiest way to begin is to install boost 1.49 then run “sudo port install gnuradio-core” and let macports install all of the pre-requisite packages (you may need to perform the fix I mentioned in that earlier post to fix netpbm) .  When it finally gets to gnuradio-core, it will fail.  Now, what you need to do is:

$sudo port edit gnuradio-core

Follow the instructions, again in that earlier post (update 2).

$sudo port clean gnuradio-core
$sudo port -n install gnuradio-core
---> Computing dependencies for gnuradio-core
---> Fetching archive for gnuradio-core
---> Attempting to fetch gnuradio-core-3.3.0_0+python26.darwin_12.x86_64.tbz2 from http://packages.macports.org/gnuradio-core
---> Fetching distfiles for gnuradio-core
---> Verifying checksum(s) for gnuradio-core
---> Extracting gnuradio-core
---> Applying patches to gnuradio-core
---> Configuring gnuradio-core

THIS IS IMPORTANT!: Cancel (control-c) when it says “Configuring gnuradio-core.”  At this point, we need to hand-edit the configure script in the gnuradio source directory.  The reason for this is because some of the assembler code in gnuradio uses 32-bit only opcodes.  When compiling for 64-bit machines they generate errors.  It’s necessary for them to be compiled differently.  Luckily, when Lion was released, a fix was devised and added to macports.  The same exact fix (in principle) should work for Mountain Lion.  But, in the configure script, the change looks for Lion and doesn’t detect Mountain Lion.  We just need to change the test to detect Mountain Lion.  The difference is only the version of darwin used.  This information is in this trac.

$cd /opt/local/var/macports/build/
$ls
<cd to the long directory that ends with science_gnuradio-core>
$cd gnuradio-core/work/gnuradio-3.3.0
$sudo vi configure

Once editing the configure script, search for “darwin*10*” or “darwin*11*”.  This is easy if you hit the forward slash and type “darwin\*1″:

/darwin\*1

The region of interest should look like this (the numbers are the line numbers):

20154     *darwin*11*) 
20155 # The cast to long int works around a bug in the HP C Compiler 
20156 # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects 
20157 # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'. 
20158 # This bug is HP SR number 8606223364.

Change the *darwin*11* (or *darwin*10*) to: *darwin*12*

Close the vi session by hitting <esc> then : then type wq and enter.

Now, run “sudo port -n install gnuradio-core”.  Make sure that you DO NOT clean the package.  This will destroy our edited configure script.

When that finishes (hopefully it does!) you should be all set!  You’ll probably want to install gnuradio-companion as well as gnuradio-audio-osx.

If you have any problems or questions, let me know in the comments.

Share on Facebook

I admit that I hacked it together very quickly so that I could make some basic use of the rtlsdr dongles on my mac.  To be very clear, Softshell does no actual SDR itself.  You can really look at it more like a driver for the rtlsdr.  Softshell opens a connection to the rtl device, allows you to tune its internal oscillator, and puts the data on the network.

To start, install the rtl device in your USB port, then open Softshell.

Freshly opened

If you see a similar window, it means that Softshell has found your device (the ezcap in this case).  It is, perhaps, a good time to mention that I’ve only ported the tuner code for the Elonics E4000 tuner.  Click the “Open” button to have the program open the connection to the device.  If it detects that you have the E4000 the “Tuner type” field will be filled in with “Elonics E4000.”

Once this is done, changes to the sample rate and center frequency will take effect with the “Update” button is clicked.  The Center frequency is provided in Hz.

Now, that’s all fine and good, but you’re just tuning the device.  To actually get the data out of it, you need to setup the network settings.  Choose a port number for Softshell to listen to, I use “12345,” and click the “Running” checkbox.

Finally, in GnuRadio, you need to use a “TCP Source” block setup as a client with the same port number you used before.

Setting up GnuRadio to work with Softshell (click for full size)

Once that’s done you should be up & running.  Note that, natively, the rtl device actually outputs unsigned bytes and that Softshell converts these to floats centered around zero.  Some GnuRadio examples include the blocks that perform this conversion.  If you come across this, just remove those blocks.

Good luck!  Please feel free to comment with any questions or issues!

Share on Facebook

Some packages in macports fail to compile using CLANG.  The reasons are varied, but inline assembler is a common reason.  The trick to getting them to work is using a different compiler.  LLVM-GCC seems to be a good choice.

The macports guide for choosing compilers isn’t as clear as I would like.  After some googling, I learned that you can edit the port file using macports.

sudo port edit netpbm

This command opens the port file for that package in vi (or maybe your default editor, if different) and lets you make changes.  The compiler is set by the TCL variable ${configure.compiler} which is set thusly:

configure.compiler llvm-gcc-4.2

Once this changes is made, clean and re-attempt the port:

sudo port clean netpbm

sudo port install netpbm

And it should work.  It did for me.  At least, you can use these series of steps to try different compilers out to see which one works.

Update:

To compile the gnuradio-gruel library, it may be necessary to downgrade to boost version 1.49 if you have version 1.50 installed.  For some reason, the x86-64 version of the libraries aren’t build with the new version of boost.  Here is the trac entry.

Update 2:

While compiling the gnuradio-core package, a failure occurs.  The log entry is, unfortunately, not helpful:

:info:build make[6]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/filter'
:info:build make[5]: *** [all] Error 2

However, if you navigate to that folder and run make (as sudo, because the files are owned by macports) you get a more helpful result:

libtool: compile: /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../../.. -I/opt/local/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/runtime -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/general -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/gengen -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/filter -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/missing -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/reed-solomon -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/viterbi -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/io -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/g72x -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/hier -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gnuradio-core/gnuradio-core/work/gnuradio-3.3.0/gnuradio-core/src/lib/swig -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -pipe -O2 -arch x86_64 -MT float_dotprod_sse.lo -MD -MP -MF .deps/float_dotprod_sse.Tpo -c float_dotprod_sse.S -fno-common -DPIC -o .libs/float_dotprod_sse.o
float_dotprod_sse.S:57:2: error: unknown directive
 .version "01.01"
 ^
make[1]: *** [float_dotprod_sse.lo] Error 1
make: *** [all] Error 2

It’s about here that you realize that you’re dealing with assembler.  Ick.  Apparently, the .version directive isn’t supported.  I tried commenting them out, but when gnuradio is finally built, I get SEGFAULTs from the filter methods.  I don’t think it’s a coincidence that we’re in the filter directory and this is the dotproduct source file.

Here, again, I tried the compiler ‘trick’.  No dice.  This time, however, the error changed:

float_dotprod_sse.S:63:suffix or operands invalid for `push'
float_dotprod_sse.S:163:suffix or operands invalid for `pop'

A quick google later, and it turns out that when you compile assembly code designed for a 32 bit machine on 64 bit, the assembler doesn’t know what to do with some of the instructions.  The solution is to add -m32 to the compile command line.

Unfortunately, all this code is compiled with -arch x86_64 (the opposite of the -m32 flag!).  If I removed -arch x86_64 and added -m32 it worked.  Now what to do?  Unfortunately, I’m stuck for now… ideas?

Share on Facebook

“Well, there’s your problem!”

This is waaay out of left field for this blog, but I’ve spent the last week or so working on this project, so I figure I should describe it.

In the list few weeks, my engine in my ride-on power has been burning tons of oil.  It would smoke a bit all the time, but after a while, it would bog down and unleash a massive cloud of blue smoke.  I read some forums and things online to try to get an idea of what was happening.  Many people said that it was caused by the crank case breather.  I figured this would be an easy thing to try.  When I went to the small engine store (Willamette Saw) they said that it was almost guaranteed to be the head gasket.  Bummer.  I came back the next day with the engine model number, and got a new gasket.

You can see the tons of oil swirling around in the air filter housing.  What I think was happening is that the head gasket leak was pressuring the crank case, which was causing the blower to expel lots of air and oil into the housing.  When it overflowed, it would pour into the intake causing the huge smoke cloud.

It doesn’t get much clearer than that!

Once I got all the covers and stuff off of the engine, the cylinder head came off very easily.  It’s painfully obvious that this was a blown head gasket, and that the combustion gasses were leaking into the crank case.  It’s bizarre how thin the gasket is in this location, and that it’s really far away from any bolts.

Visible oil in the cylinder.

In addition to the obvious gasket leak, there was a ton of oil in the cylinder.  There had to have been at least a table spoon of oil just sitting there in the cylinder.  I mopped most of it up before taking the picture, unfortunately.  Changing the gasket was really easy.  It’s important that you clean off all the old gasket and make sure that the mating surfaces are clean and smooth.

AAAAAARRRRRRGGGGGGHHHHHHH!!!!!

I know that it’s fairly important to correctly torque the bolts when installing the cylinder head, and I attempted to find information online about the proper torque value.  I read somewhere that it was supposed to be set to 55 ft./lbs.  It’s not.  Don’t do it.  That is a TON of torque.  In attempting to install the bolts I realized this, and kept backing it off.  However, one of the bolts broke anyway.

Hellooo down there!

I friend of mine insisted that I try to remove the bolt (yes, I was going to leave it), and lent me his ez-outs.  It can be very difficult to drill  into a hardened bolt, especially deep in a hole without destroying the threads.  I saw a cool technique somewhere on the internet for drilling down the center of a bolt, so I used the opportunity to try it.

Center drilling a bolt

The trick to drilling down the center of a bolt is using a drill-press and a well-secured vise.  Chuck the bit into the drill chuck, but upside-down, then lower it into the vise.  It’s easiest if you have an x-y stage type of vise. With the bit in the jaws of the vise, secure it.  Now, chuck the bolt into the drill press and drill the hole.  It’s a kinda fun process.   I did my best to keep the bit clean and lubricated.

Successfully center-drilled bolt

It should work great, it did for me.  I also used a counter sinking bit to de-burr both sides of the bolt.  Also, before starting this whole process, I ground off all the markings on the top of the bolt so the drill bit didn’t wander around the surface.

Drill bit through the bolt spacer

Spacer installed into the bolt hole

As expected, the spacer fit the bolt hole perfectly, and the bit fit perfectly as well.  I was ready to go!  What could go wrong?

D’oh!

Well, crap.  I hadn’t anticipated that.  There was no way I was going to get the drill chuck into that space.  This sucks.  I was hoping that I could get the bolt out without taking the head back off the block.  But it became clear that there was no other way to do it.

Well, that’s a bit easier to get.

With the head off, getting the bolt was trivial.  That’s nice.  However, I had to buy another head gasket, so that was a bummer.  Once the bolt was replaced, I was able to find the proper torque (220 in/lbs.) which is about 18 ft./lbs.  This turned out to be just about perfect.  The engine has some serious compression now!  I also had to adjust the valve rocker clearance.  Now the mower’s running like a champ!

Share on Facebook

Keynote time!

I’ve never been less impressed by fo-hawks than I am right now.

The Stig!?

Share on Facebook

2012 Solar Eclipse

During this solar eclipse, I was lucky to be near the path of the full eclipse.  Sky & Telescope have a really nice graphic showing where in North America the eclipse was visible.

Eclipse path (click image for source)

I’m just north of the ideal path.  Anyway, it was cloudy here in Oregon, so my pictures aren’t great.  I hope you enjoy them.

Solar eclipse 2

Share on Facebook

Also, if anyone wants to design a logo, it would be much appreciated!

Softshell-alpha

Share on Facebook

Apple was kind enough to give me a scholarship to WWDC this year!  I’m pretty freaking excited!  Just wanted to share.

Share on Facebook

Softshell works!

Basic functionality of Softshell works!  In the image above, you can see the app (Cocoa-rtl-sdr is the old name) on the right.  I didn’t even have the text boxes wired in yet for the sample rate and center frequency, because I was so excited that it was working.  The samples from the receiver are transported into GNU radio over TCP where a simple FFT is being performed.  Notice that all the extra blocks needed for the original rtl-sdr aren’t needed, because I’m doing all of the uchar  to float conversion inside of Softshell.

The code that’s available on GitHub was hacked together with some network code that I can’t release right now, but I’m going to move it over to code that I can use soon.

Update:

Here’s a pre-compiled application for those that don’t feel like compiling it:

Softshell-alpha

Share on Facebook

Link to the comparison spreadsheet.

Share on Facebook

Most of the active discussion about rtlsdr appears to be happening at the RTLSDR subreddit.

RTL SDR compatible dongle

The idea behind Softshell is to port the osmocom rtl-sdr code into a native Cocoa application that doesn’t need libusb.  I’ve published the code to github, but it’s still very early in the development process.

This post is just meant as a heads-up for anyone with Objective-C experience and an interest.

Share on Facebook

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 mode like tiny variations in the frequency of the signal.

To get a little more specific, think about phase as a quantity that describes how 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 an 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 about 20kHz.  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.

Share on Facebook

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 the Yahoo 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 for solder.

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…

Share on Facebook

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 to 115200 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 that I can get someone in the panel of experts to weigh in on it.  It’s reasonable 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, so I’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 are 65,536 counts (numbers) spanning 3.3 volts, or 19859 counts per volt.  In my spreadsheet, 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 2 kHz.  This is exactly the published value.  I guess this means that it was a very successful experiment.

Share on Facebook

Chipkit with 74595's connected to PLO2

Now that I know that trying to use the BusPirate with the 74595′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 megabaud.  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.  :)

Share on Facebook

Experiment setup

For background, I’m still working on my spectrum analyzer.  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 on QH*.  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 takes 32 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 40 bit 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.

Share on Facebook

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 AVR USB 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 the AT90USB162.  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. transceiver-top transceiver-bottom

Component side artwork

User side artwork

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

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

Share on Facebook

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.

Share on Facebook

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.  There performance 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 door jamb 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 an 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 feedline.  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 feed line 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!

Share on Facebook

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 tutorial about 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! ). 

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 photogate 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 the RRD 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 the 14,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/hour is (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 is 12 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

Share on Facebook

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 Tony Parks.  (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, or Quadrature 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 or USB) 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!

Softrock Ensemble Receiver (click image for source)

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 at 11,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 source WXAPT 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 1260 pixels)

(lightly) processed image from NOAA 15 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!

Share on Facebook

Tuned for 2 meters

To begin the testing, I tuned as best I can to the 2M band.  The filter shape isn’t as flat as I would like, but it’s the best I could do.

Tuned for NOAA APT transmissions

It was a little easier to tune the front end for NOAA APT transmissions.  I got a better filter shape, and about 5 dB better average insertion loss.

Tuned for weather radio

Tuning for weather radio wasn’t that bad either.  The average insertion loss is about equal to what I got for 2 meters.

Compromise tuning

Finally, if you’re interesting in receiving signals from throughout the band, it’s possible strike a compromise.  You’re just about always going to get a peaked response, so I placed the lower peak at 137 Mhz and the upper at 165.  The 2 meter ham band is somewhere in the middle.  The peaks at 137 and 165 are 5-10 dB below the baseline.  The 2 meter band is a little worse at about 20 dB below the baseline.  So, it’s possible to get a somewhat broadband response at the fronted at the expense of some signal strength.  It may be possible to mitigate some of this if you use a low noise preamplifier.

Share on Facebook

Amplifier breakout board

I’ve finally gotten around to assembling a breakout board for the Skyworks SKY65116 UHF amplifier.  It’s really amazing how the state of the art in RF ICs has advanced.  They can still be on the expensive side ($6 at digikey), but still relatively cheap when you consider the cost of all the support parts that it takes to build an amplifier from a RF transistor.  This particular amplifier has a 50 ohm input and output, and 35dB of gain.  It works from 390Mhz to 500Mhz, which means its perfect for the 70cm ham band.  The breakout board is stupid simple, copied directly from the evaluation board schematic in the datasheet,  but I’ll include schematic and design files anyway.

Source for the amplifier test

This is the video transmitter from my first person video experiments.  The performance was pretty terrible, even after I tested it using different receive antennas.  I’ve even purchased a receive-side amplifier to try, but haven’t done anything with it yet.  Anyway, the transmitter had a built-in antenna, so I wasn’t sure how I was going to add an amplifier.  I ended up assuming that the output would be roughly compatible with an 50 ohm load.  I unsoldered the antenna and installed a bit of thin coax to the antenna port.  I scratched off some of the solder mask on either side of the board near the antenna port to make sure I had a solid electrical and mechanical ground connection.  The transmitter is pretty crappy, and the prices you can find online are COMPLETELY RIDICULOUS!  I wouldn’t pay more than $20 for it.  I think that’s about what I paid, it was on clearance.

Testing configuration

This image is the testing configuration I used.  The camera, power board and transmitter are in the top of the image, and are exactly as I used them for first person video.  The added coax can be seen going into the amplifier on the left.  Coming out of the amplifier is the cable going to the oscilloscope or spectrum analyzer.  The amplifier wasn’t inline all the time, though.  I measured the output power from the transmitter at about 25mV into 50 ohms using the oscilloscope.  Using Minicircuits’ handy table that comes out to be about .01 mW, or -19 dBm. A measurement from a spectrum analyzer verifies the -19 dBm measurement from the o’scope (see below for image).

NTSC modulated spectrum (click for source)

I’ve attached a very nice graphic from wikipedia that describes the components of modulated NTSC video.  There is something happening here that isn’t obvious, so I’ll explain it.  In the spectrum analyzer image, below, you’ll notice that I’ve labeled the luminance and chrominance carriers.  The luminance carrier is really the main carrier for the entire signal.  It comes from black and white TV era.  There are significant DC components in NTSC video, so this carrier is very important.  Notice, in the graphic above, that the luma carrier is 1.25 Mhz above the lower edge of the band.  This is because NTSC video uses what’s called VSB, or vestigial side band, which means that the lower half of the signal is attenuated.  This reduces the spectrum necessary to transmit video.  The choice was made to include the carrier and 1 Mhz with of lower sideband while removing the rest.  Later, when color TV was added, they needed a way to encode color.  This is done by adding another carrier and encoding hue and saturation by modulating the phase and amplitude of this carrier.  All this is explained at length, and probably much better, in the wikipedia article on NTSC.

Source spectrum

In the spectrum image I’ve included above, it’s clear that the little transmitter uses AM rather than VSB.  You can tell because AM modulated signals are always symmetrical with respect to the carrier.  If it was VSB, the spectrum on the left side of the carrier would be suppressed.  You may notice that the left and right side don’t look 100% alike.  This is because it takes time for the analyzer to sweep the band (it does this 30 times a second), and it will be analyzing the spectrum of a different part of the image as it scans.

Source signal through unpowered amplifier

Well, that was an unexpected tangent!  Back to the amplifier…  In the above image I have the amplifier in the signal path from the source to the analyzer.  It’s disconnected from any power.  I’m a little off on the “-60 dBm” text, it’s closer to -64 dBm.  I was interested in seeing how much RF would leak through an unpowered amp.  It appears that the amp provides a little more than 40 dB of forward isolation between the input and output when it’s unpowered.

Amplifier powered on

Finally, this is the spectrum when the amplifier is powered on.  I had to install 40 dB of attenuation on the analyzer to capture this image.  The peak of the carrier is almost 5 dB lower than the top line, so it’s about 36 dB stronger than the input.  This is inline with expectation, as the amp specifies +35 dB gain.  The resulting signal is +15 dBm, which is a modest 32 mW of power.  The hope is that through a better antenna and some amplification I can get better performance from the video link.

A word about the legal implications.  Ham radio people are notoriously concerned with the rules of everything they do, so I feel obligated to mention them.  In the U.S., at least, 434 Mhz is a commonly used ATV (amateur T.V., or “fast scan TV”) frequency.  There is some concern due to the proximity to the  ”satellite only” frequency band of 435 Mhz to 438 Mhz.  This means that the carrier is sometimes shifted to 433.92 Mhz, as this transmitter is.  Some of the sidebands still end up in the satellite only band, but with much lower power.  Because this amplifier only outputs +15 dBm I’m very unlikely to upset anyone with its use, though I should think about adding an overlay with my call sign to the video at this power level.  Maybe I’ll have a new 8-bit microcontroller project…

eagle files

gerber files

Share on Facebook

My, my... Than's TINY

I decided to try my hand at QFN soldering yesterday.  I was really nervous about it, it just seemed like the kind of thing only a robot or an expert can really pull-off.  I’ve seen it done many places online and everyone said that it was doable.  Well, here’s another voice in the chorus: It is possible with hobby-grade equipment.  I’ve written about reflow soldering before, so I’m not going to re-hash that discussion, but that is the technique that I used.  As you can see in the image above, I used a professionally manufactured PCB of a design of mine.  This is a breakout/prototype adapter for a Skyworks RF switch.  The circuit is remarkably simple, there are two control lines that select which inputs are routed to the common (RFC on the silkscreen).  There are a few DC blocking caps on each of the RF lines, and that’s it!

Solder paste quantity

In this image, I’m showing how much solder paste I used.  As you can probably see, I made no attempt to keep it contained to any particular location.  I assumed that surface tension and the solder mask would help out in this regard.  This is the first board I did, I used somewhat less solder on the second one.

Solder bridges

Here is the result of the first board.  You can see some serious solder bridges on the chip there.  They were easily removed with solder wick.

Near perfect solder

This is the second board I tried.  This time I used a little less solder.  You can see that there aren’t any bridges (you’ll have to take me at my word that there aren’t any on the other side).  I used some solder wick to clean up the solder anyway, as I don’t like that they’re bulging out a little.  As a final note about this image, you should be able to see a very small solder ball on the left side of the chip.  This is very common with reflow.  The extra solder paste under the IC was squeezed out by surface tension.  I usually remove these with a razor blade.

Trying another kind of QFN package

I had another board and IC that I’m working on, also a QFN, that I thought I’d try.  In this case, it’s a 3×3 package with huge spacing between pads.  This one was much easier to handle.  You can see that I still have some solder overflow.  The solder ball on the right was removed with the razor blade, and the near one was removed with solder wick.

Soldering QFN is actually kinda fun!

Now that I’ve tried it a few times, I can say that soldering QFN isn’t nearly as scary as I thought it would be.  A steady hand and some method of soldering other than an iron is all that’s really necessary.  I imagine this would work with the skillet or any hot air method.

The last image is a skyworks 1.2W RF power amplifier breakout/prototype board.  This will be the subject of a future post.  Stay tuned!

Share on Facebook

I just finished building a frame for some resurrected LED panels from a decommissioned super computer.  The computer was a CM-5 by Thinking Machines.  It has been used at the College of Oceanography and Atmospheric Science at Oregon State for a fairly long while.  A few weeks ago, its time came, and we surplussed it.  I was able to get the light panels and built a frame for them at my house.  This post describes a little about the process and includes some trivia about the CM-5 and the panels themselves.The CM-5 in name alone probably doesn’t resonate with many people, but hopefully you can recognize it in the background of this photo from Jurassic Park:

Now, I don’t want to slide my glasses up my nose an snort, but the way they’re setup in this image is not at all like how would they be setup in real life.  The installation engineer that setup ours had to leave half-way through to setup the Jurassic Park set.  These are simply the empty chassises with the light panels.  The CM-5 was also 3rd in this list of Top Ten Coolest and Most Powerful Supercomputers.  The previous link has an image that shows how it would actually be setup.  On top of the machine there are huge bundles of wires.

Anyway, I’m not writing this post to discuss the history of the CM-5, at least not that much, so I’ll get on with the LED panel build.  It’s a really simple idea; I laid them out on the floor and measured the dimensions of their perimeter.  Using these measurements, I built a simple wooden frame out of 1×2″ maple.  The width of the panel is considerably less than the width between studs in my wall, so I had to secure it to a single stud on the top and bottom of the frame.

Bottom of frame and backside of one module

The location I chose for the frame covered an outlet; This not only made it easier to route the cord (I didn’t have to make a cutout), but it also looks much cleaner.  Of course, I would need a way to turn it on and off.  To do this, I chose an X10 transciever/switch.  I covered the antenna with shrink-wrap to avoid shorting anything out.  Also, I had to turn the outlet in the wall upside down because the X10 module has the plug coming out on the bottom.

X10 module installed in a reversed outlet

The next challenge was securing the power supplies into the frame.  The frame was just thick enough to accommodate the supplies, but it left me little room to attach it.

Power supply against frame

There were mounting holes and a small recess in the heat sink, but the holes were far too large to thread to the hardware I was using.  I tried to drill and tap new holes for 4-40 hardware.

It broke my tap!

Unfortunately, the heat sink is made of some bizarre metal that really doesn’t like to be tapped.  It felt very gummy, if that makes any sense.  When I tried to unscrew the tap it broke right off.  I tried a few different things, including sharpening the other, broken, end of the tap into a new tip.  Really none of these things worked.  I was practicing on a bad supply, and I decided to just take it apart and see if there was anything else I could do.  When I did, I discovered that they used some strange self-tapping 4-40 screws.

Self-tapping 4-40 screws

These screws mostly did the trick.

Mounted power supplies

Once the power supplies were mounted, I attached the frame to the wall, and began wiring.  Notice, in the image above, that the output ends of both supplies are near each other.  This is because I wanted to use the factory wiring harnesses from the CM-5.

Low voltage DC wiring

Everything on that machine was overbuilt.  Each of those supplies can source 30 Amps at 5 Volts.  Each panel requires in the neighborhood 5-7 Amps, so there is almost 3x over provisioning.  Not only are the supplies overbuilt, but the cabling is also a little over-the-top.  It’s really a testament to the scale of the whole machine.  While talking about it to those that used it, I often heard “when something costs $20 million, you expect a certain level of quality.”

Testing

Here I am testing the final wiring for a single LED module.  The bottom rows are dark, not because they aren’t on, but because they’re painted black.  When it’s installed in the computer, you can’t see these rows because they’re covered up, so for some reason they just painted them black.  If you look close, you can see though the paint a bit at and see the lights.

Narrow margins

Here, you can see just how tight the fit of everything in the frame really is.  There is barely enough room for the power connectors and cables, let alone the power supplies and X10 module.

installing modules

The modules install simply and cover up all the wiring and electronics.

All finished!

Finally, we’re all done!!  The whole system looks amazing.  One factoid that I find pretty interesting is that the “random and pleasing mode #7″ produces exactly the same “random” pattern on every module!  Next on the docket: reverse-engineering them to display messages and designs!  Also, make sure to see my gallery of the process of surplussing the computer.

Share on Facebook

Share on Facebook

Transciever enclosure

It has been a while since I finished the transceiver modules, and I how now used them in an actual application.  But, before I talk about that, I’d like to show some pictures of the process I used to put them into enclosures.  I had some of these cast aluminum enclosures lying around, so I thought I’d use them.  They’re a little on the heavy side, as the completed weight is around half a pound, but it’s well within the carrying capacity of my Kadet.Before diving into the process of cutting the holes, I want to show some images of the transceiver board with the RFI fence installation process.

Cutting copper sheet

For use with the spectrum analyzer project, I found some sheet copper at the craft store.  It was sold at a local crafts store, and I think it was for etching.  I chose the thickest one they had.  So far, the best way I’ve found to cut it is using an exact and straight edge.  I tried scissors, and it didn’t really work.

RFI Fence

Once I had a strip of copper cut, I cut openings for the power and control traces and soldered it onto the PCB.  I also soldered it onto the SMA connector.  Once all that was finished, I soldered on a lid.  Lots of solder flux helps here.

Once the board was prepared, both by soldering on a fence and replacing the pin header with a right-angle one, I began to prepare the enclosure.  I was intending to drill a hole for the SMA connector, then cut a hole for the digital connection.  The SMA connector hole was trivial to make, though the connector I soldered onto the board was a little short.  I ended up having to use an O-Ring from the hardware store (look in the plumbing section) to hold it in.  When an antenna or cable is screwed on the O-Ring compresses, having the nice side-effect of sealing it.

DB-9 template

For the digital connection, I decided on using a DB-9 connector.  I figured it was a prolific connector, so I should have lots of connectors laying around.  That didn’t turn out to be as helpful as I had hoped, but I’ll get into that later.  To create nice holes for the DB-9 connectors I decided that I could use an old PCI bracket as a template.  I lined the bracket up against the side of the enclosure and traced it.  On the black box, I traced it using a knife, and on the grey box I used sharpie.

DB-9 template using sharpie

Once the outline was traced onto the box, I drilled holes for the retention screws.  Then, I drilled out as much as I could of the trapezoid shaped interior.  I most used the drill press, then the dremel with a router/cutter bit.  I made sure to leave a margin inside the perimeter to remove with the files.  I had avoided purchasing a set of jewelers files for a while, I think I assumed that they were expensive.  They’re not, you should get a set.

Finished penetration

In the photo above, you can see the finished penetration for the DB-9.  I beveled the inside edge to make room for the fillet on the connector that I had.  The black box got a male DB-9, and the grey box got a female one.  The holes need to be about the same size, as the male shroud always has to fit over the female connector body.

DB-9 connector installed

In addition to the RF and digital connectors, I needed a way to securely mount the internal circuit boards.  The way I chose to do this was first to drill holes in the bottom of the box, then “countersink” some screws into it.  I have countersink in quotes because I don’t have a countersink bit, so I used a larger drill bit.  You can see the results of this in the headline picture of this post.  Though I think it looks pretty good, I still decided to buy a drill & tap for 4-40 screws after building the black box.  For the grey box, I used the tap and screwed directly into the box.  This requires slightly less hardware and looks pretty good, I think.

Breadboard transceiver circuit

For whatever reason, the board I built for the black box using some veroboard-style construction didn’t work the same as the breadboard.   Because I was under time constraint (I was planning on flying one of the transceivers over the weekend.  I decided to put it back on the breadboard and use it as the base station.  This version uses an FTDI cable to connect to my computer.

Flyable transceiver module

For the grey box, I used an extra ATMega48 breakout board I had.  This one worked just fine in the enclosure, so I flew it.  I also built a power regulation/distribution board, seen on the right of the photo.  This concludes this article.  Now that I’ve got at least one flight worthy transceiver I can test them in flight.  That’ll be detailed on a future post.

Share on Facebook

Mud Bug flying

I maiden’d my new plane, the Mud Bug, last weekend!  I was a ton of fun.  Now, I’ll tell you all about building it, and converting it to use brushless motors.

Laser cut parts are a joy to use

All the parts in the kit are laser cut, and fit perfectly.  The design of the plane is such that the shape of the wing is created almost exclusively by bending the wing’s top skin into shape.  There are only a few ribs, and no bottom skin at all.  It’s remarkably light.

Motor stick mount

The kit calls for a stick-mount geared, brushed motor.  These are getting pretty out-dated, and aren’t very efficient.  I really like working with brushless motors, so I had to devise a way to mount it.  I chose the E-flight park 250 motor because it was pretty inexpensive and only a few dollars and grams more than the park 180.  It’s possible to mount it inside of a carbon fiber tube (using glue), but you need to use their tube, and it wasn’t in stock.  I just decided to use the cross-mount adapter and make a plywood plate that mounts on the stick.  Where the stick mounts, I added another, smaller, piece of ply to help support it.  It ended up working perfectly.

Front scab plate

I cut a pair of sheets of 1/64″ ply to use as scab plates on the balsa firewall and fuselage parts.  I had read online that those pieces of the original kit were somewhat weak.

back scab plate

This is the scab plate on the back of the fuselage portion of the motor mounting.  These are only there to spread out the loads transmitted from the stick to these parts.

Park 250 mounted

The motor mounting process went beautifully.  At first everything fit so tightly that I didn’t need any glue.  Half way through the first flight it had vibrated enough to polish the wood parts that they could slip.  I just put a few drops of thin CA, and it was fine.

In flight

The flights went great.  That park 250 has waaaaay more power than you need with a 7×6 APC Slo-fly prop  (which is the only prop I’ve tried).  The plane flies easily at 1/4 throttle.  At full throttle it gets very small very fast.  When flying slowly, it’s also very agile.  It’s possible to complete an entire circuit in 1/3 the length of the runway.

first landing

Even though it sports GIANT tires, it’s still easy to nose-over during landing in even short grass.  Given that it has almost no mass, no damage was sustained.

I give it 2 thumbs up!

Share on Facebook

Finished puzzle box

This project was inspired by the “Reverse Geocache Puzzle Box“, an idea that has been duplicated a few times.  For Christmas this year, I drew my brother-in-law, Scott.  I know that he appreciates hand-made gifts, and my idea of hand make is almost always electronics related.  I thought for a while about a gift I could give that was hand-made, but appropriate to his interests.  While I wouldn’t say he’s interested in Geocaching, per se, but I know he will appreciate the destination.  

That said, I began by designing the electronics.  In the original puzzle box, the designer used a commercial Pololu “soft” switch and an Arduino.  I decided to make everything custom, including a custom soft power switch.  When I say soft power switch, I mean a button you press to turn the system on.  When it’s time shut the system down, the controller can turn the power off.  The circuit I found was listed on this forum.  It was an O.K. start, but left something to be desired.  The given resistor values were all wrong for my application.  I think it was intended for a lower current applications, and the servo powering the latch draws a lot of power, relatively speaking.  Also, I’m not sure whether it it was an error on my part, but when the PIC shuts down, the output pins go into “high impedance” mode, as if they’re disconnected.  I had to add another resistor from the control wire to ground to hold it low while the system is off, otherwise it would never shut down.  In the future, I think I’ll approach it another way.

Reverse Geocache schematic

The remainder of the circuit is pretty straightforward.  There is a connector for the GPS, servo, programming header, and LCD.  I decided to use the 4-bit interface to the LCD to save some pins.  I designed a PCB from the schematic with home fabrication in mind.  While I don’t think the through-hole construction is necessary for homebuilding, it’s easier for some people.  I caution you that the sparkfun outline for the 16×2 LCD isn’t quite right.  The mounting holes didn’t line up.  Also, I didn’t have the pins for the servo correct, I had to move them around on the connector (5v and Ground are reversed).  Finally, another error in the design was that I didn’t notice until after I made the PCB that the 4-bit interface to the LCD is on pins D3-D7, not D0-D1.  I used a few wires to bridge over to those pins to fix it.

Reverse Geocache PCB

Once the design was complete, I made the board using the toner transfer method and etched it using ferric chloride.  I’ve refined my toner transfer technique recently, and I’ve been having really good luck.  I’ll write a post about it soon.  Drilling and assembling the PCB was otherwise unremarkable.

Prototyping and programming

It took a few days to program the microcontroller and test the electronics.  There was one significant stumbling block that wasted an entire day.  Hopefully google indexes this so other people don’t have the same pain I did.  Here it is:  If you’re having trouble with the USART on a PIC microcontroller, whether you’re using PICC, Microchip C, or Assembler, the Overrun flag stops the USART dead in it’s tracks.  I recommend that every time you poll the port, check the flag and reset it.  This is likely the problem if you can receive 2 bytes, then nothing.  Also, the transmitter will continue working.

Latitude/Longitude distance equation (r means radians)

This was the first time I used floating point math on a microcontroller, and I have to say I was a little impressed.  I use the distance equations from the aviation formulary.  I think it is an interesting equation because it accepts latitude and longitude in the form of radians, does a little trigonometry magic, and away you go!

Clasp design

With the code finished, I focused on the enclosure.  I started with a weird suitcase-looking wooden box from the crafts store.  Then, I measured it carefully and designed the clasp.  The main idea is that there is a rotating disk with a notch cut in it.  The screw fits within this notch and holds the lid closed.

Clasp

With the measurements derived from the dimensional drawing, I drew a few circles.  The inner one is the diameter of the servo control arm shaft, the next circle out is the location of the screw.  The last circle is the desired maximum outside diameter.  Using these circles as a guide I drew the clasp.  The tongue has a little bulge to make sure you can’t wiggle it open.  I drew it over until it was nice and dark, then traced it onto a notepad sheet.  I cut this out and traced it to light-ply.  My Dremel with an end-mill made short work of cutting it out.

Completed clasp and pin

Clasp tolerances

As you can see, the final tolerances are really tight.  I’m very happy with this mechanism.  In fact, later in the process, I accidentally locked the box with bad software.  Luckily, the hinge is screwed on from the back and I could remove them.  However, the clasp was so tight, I still took several minutes to open it.

Measuring the LCD

With the clasp done, I moved on to the LCD.  In this case, I measured it and traced it onto the lid.  There are two rectangles.  One is the location of the mounting holes, and the inner is the outline of the black LCD frame.

LCD Module test fitting

Here you can see the LCD module installed in the case.  It was a tight fit.  In additing to cutting and drilling the case, I cut some acrylic to use as a window.  I’ve been trying to figure out how to hide that ugly black bezel for a while, now.

Acrylic window

I traced the outline of the display part of the LCD module.  I used this to mask out the clear part.

LCD Window

As you can see the bezel is hidden.  Unfortunately, some of the red paint leaked behind the masking tape.

Controller assembly

This is an image nearing final assembly.  I use 4-40 hardware through the front of the lid.  On the back side of the LCD I installed a nylon and steel washer, then a standoff.  On the Standoff threads, there is a nut on the top and bottom of the mainboard.  These are to set the spacing of the LCD and mainboard and hold the package securely.

Mainboard installation

With the mainboard installed, the GPS was installed.  I just used double-sided foam tape.  It is behind the lid, and the satellite signal simply travels through the lid.  It looks nice and still works great.  The wood is so thin, in fact, that the light from the LEDs shines through it.

Arm switch

Going back to the problems I was having with the soft power switch, I noticed that when I left the battery plugged in over night it drained somewhat.  It’s kinda cheap, but I had to hack-on a power switch in addition to the pushbutton.  I use an ancient RC airplane trick where you stick a control rod through the wall to access a switch on the inside.

Power switch outside

Now, you can hook a fingernail onto the wire.  Pull to enable, push to disable.  This also prevents from attempts being wasted during shipping.

Final programming

This is an image of the final time I programmed the controller.  Complete with the puzzle coordinates!  It was important to remember to not let the lid close unintentionally, as the target almost 1000 miles from here!

A note about the provided code.  It isn’t high quality.  It’s a little embarrassing, but I did it in a hurry.

Resources

code.zip

Eagle files

Share on Facebook

Transceiver breakout boards

I’m just finishing up my last class ever!!!  (for credit, anyway.)  It was a really fun, mostly because I decided to have fun with my last class, and make it a 4/5 (undergrad/graduate).  This meant that it was much easier and less theory-heavy than those that I’m used to.  Anyway, as a grad student, I was expected to do something extra, and I decided to make a RF transceiver module.  I looked around for a little while, and I settled on the Microchip MRF49XA.  In general, it’s a nice chip.  It has about the same capability as the Micrel MICRF6xx modules that I’ve used in the past.  The Micrel modules cost $20/ea. and the Microchip IC is around $3.  I was able to make the whole breakout board for the MRF49XA for less than the Micrel module alone.  One of these days, I should dig out my notes from the Micrel project and post them, but I digress.  I noticed a distinct lack of programming information using the MRF49XA, so I’m posting not only my schematic and PCB, but the software library I wrote for the Atmel AVRmega.

Breakout board schematic

The schematic I created for the breakout board is, in large part, copied from the reference schematic from the datasheet.  There are a few parts that make up the complete schematic, including power regulation, microcontroller interface, RF balun, and the IC.  Everything but the balun is really easy to understand, the power input can be +5 volts or more (probably up to about 14 volts) while using the LM317, or if the LM317 is omitted, +3.3 volts.  The MRF49XA is really a 3.3 volt part, and expects 3.3 volt I/0.  Originally, and on the PCB I had made, I had 2 ground pins.  Since then I realized it would be useful to output regulated 3.3 volt output, so I changed one of the grounds for that.  The only other major portion of the circuit is the balun.  This is used to transform the balanced RF input/output from the IC to the unbalanced antenna connector.  This circuit also provides power to the RF power amplifier inside the IC.

Breakout board top

The PCB designed from the schematic is also fairly straight-forward.  A few things are worth noting, however.  I’ve added some silkscreen between 2 of the pins on the LM317.  These are to indicate where you could jumper if the breakout board is supplied with regulated power.  I used a 0805 0-ohm resistor (see the image below).  The voltage output of the LM317 is selected with R1 and R2.  I decided not to include the “stop” layer on this image so as to not clutter it, but near the word “Fence” there is a strip without solder mask over the vias.  If you wanted to isolate the RF from the outside, you could build a fence out of copper foil (or something).  The Antenna connector is a end-launch SMA, though it could also be raw coax if you want to save some money.

Close up

The only pins necessary for complete functioning of the device are the standard SPI set (MOSI, MISO, SCK, !CS), and IRO (interrupt request out).  The IRO pin is not strictly necessary, but HIGHLY recommended.  The MRF module uses the IRO pin to notify the microcontroller of a few time-sensitive events, such as FIFO full/empty conditions.

MCU interface while transmitting (click to enlarge)

The diagram included above (from the MRF49XA datasheet) provides a useful overview for the transmitting process.  The take-away message is that you first send the “Transmit data enable” (TXDEN) command, which loads 0xAAAA into the transmit FIFO.  You can either leave this in there, as a preamble, or replace it with data of your choice.  Then, you send the “Transmit carrier enable” (TXCEN) command.  At this point, the PLL starts, and the PA turns on, then transmission starts.  When the first full byte leaves the FIFO the IRO asserts.  Hopefully this forces the MCU to jump to your interrupt service routine.  Once there, if the CS pin is held low, the MRF will bring SDO (MISO) high.  This is a clear signal that the FIFO needs attention.  You can continue this process for as long as you have data.  Once you’re done, you need to load a “dummy byte” into the FIFO so your last data byte makes it out.  Finally, on the next interrupt, shut down the transmitter by sending TXCEN and TXDEN = 0.

Receiving FIFO usage (click to enlarge)

This diagram illustrates another detail of the interface to the MRF.  Also borrowed from the datasheet, it describes the way to access the receive FIFO using SPI.  Typically, SPI interfaces don’t have a notion of registers quite like I2C does, but the MRF does.  To get access to the receive FIFO you initiate an SPI transfer to the MRF module with the contents equal to the address of the receive FIFO.  In this case it’s 0xA000.  Once the first byte of the transfer is complete, the MRF begins outputting the FIFO value on the SDO pin.  It is also possible to gain access to the receive FIFO using FSEL (FIFO Select, called “Data” on the schematic) pin.

Baseband Bandwidth calculation (click for full size)

Before going into some details on the implementation of the library, I’d like to talk briefly about the RF frequency, deviation, and bit rate determination.  I’ve attached another snippet from the datasheet (hopefully the last one), and I’m going to go through the math quickly with numbers for my application.  I’m using 434 Mhz band, with 9600 baud, using a 10ppm crystal.  This means that fxerror = 10 * (434000/1000000) = 4.34 Khz.  Then, our deviation must be 9.6 + 2*fxerror + 10 = 28.28; the closest modulation is 30 Khz.  Therefore, BBBW = 30*2 – 10 = 50 Khz.  The closest BBBW is 67 Khz.

Spectrum plot from alternating 1s and 0s

I recently gained access to a spectrum analyzer courtesy of the OSU Robotics Club.  This is a spectrum plot of 0xAA, or alternating 1′s and 0′s.  It’s a little strange that the distance between peaks is about 90 Khz, as it should be more like 60 Khz.  The comb-like appearance on the flanks is probably from the transceiver switching from 1 to 0 across the scan.

Transmitting '1'

This plot is while transmitting all 1′s.  It’s obvious this is much cleaner, but very little information is actually being transmitted here.

With respect to the Atmel AVR library that I wrote, it includes a header file devoted entirely to defining the registers and bits as defined in the datasheet.  Each section includes a comment block description, and in the cases where some bit values need to be calculated, the equations used.  On the occasions where a bitfield is used for some integer value, I include a mask to ensure that if the derived values overrun the width of the bitfield they don’t pollute unrelated settings.  Below, I’ve included an example.

/*******************************************************************************
 * Convenience definitions for band setting
 *
 * These defines are provided for use configuring the MRF49XA module.
 * Select the frequency band for the given hardware by uncommenting the
 * appropriate line.  Set the crystal load capacitance using the MRF_XTAL_LD_CAP
 * value.
 *
 * The load capacitance is given by the following equation:
 *
 * Cap pF = 8.5 + (LCS / 2)
 * LCS = (10 - 8.5) * 2
 *
 * For 10pF: LCS = (10 - 8.5) * 2 = 1.5 * 2 = 3
 *
 ******************************************************************************/
#pragma mark General Configuration Register
#define MRF_GENCREG		0x8000		// General config. register
#define MRF_TXDEN		0x0080		// TX Data Register enable bit
#define MRF_FIFOEN		0x0040		// FIFO enable bit
#define MRF_FBS_MASK		0x0030		// Mask for the band selection
#define MRF_LCS_MASK		0x000F		// Load capacitance mask
// 10pF Crystal load capacitance
#define MRF_LCS			3		// Crystal Load capacitance
// Frequency band settings
#define MRF_FBS_434		0x0010		// 434 mHz band
#define MRF_FBS_868		0x0020		// 868 mHz band
#define MRF_FBS_915		0x0030		// 915 mHz band

All of the files in the library depend on a “hardware.h” file that defines the qualities of the hardware.  The hope is that this file is the only place that implementation-specific code lives.  There are some holes still, however.  Finally, the mrf49xa.c and mrf49xa.h files behave the way you would expect.  The module requires a total of 5 pins and one interrupt.  Some of those pins may be shared with other SPI devices.

void MRF_init(void);

uint8_t MRF_is_idle();
uint16_t MRF_statusRead(void);

// Packet structures
// the maximum payload size
#define MRF_PAYLOAD_LEN 40
// Space for preamble, sync, length and dummy
#define MRF_TX_PACKET_LEN	MRF_PAYLOAD_LEN + 5

typedef struct {
	uint8_t	length;
	char		payload[MRF_PAYLOAD_LEN];
} MRF_packet_t;

// Packet based functions
void MRF_transmit_packet(MRF_packet_t *packet);
MRF_packet_t* MRF_receive_packet();

I’ve included a snippet of the header file above so I could mention the basic process for using the MRF module.  The MRF_init function expects the SPI bus to be configured, and it performs the basic initialization of the device.  Once it’s started, the interrupts on the AVR must be enabled.  In the main loop (or at least as often as a packet can be transmitted) you should call MRF_receive_packet.  This function will return NULL if no packet was received, and a pointer to a packet structure if it was.  MRF_transmit_packet takes a packet structure and transmits it.  This is an asynchronous operation, and you may use the packet structure (or it’s memory) once it returns.  This is useful if you want to use a packet structure created on the stack.  It is possible to get yourself into trouble with MRF_packet_transmit, as it spin-loops on a lock set in the ISR.  If for whatever reason that lock isn’t unlocked at some point you can hardlock.  I’ve done my best to ensure that it doesn’t happen, but beware.

And, finally, links to the files.  If there seems to be sufficient interest, I’ll open up a SVN (maybe Google Code, who knows) with these files and a main program useful for telemetry and the like.  Post in the comments if you’re interested, or send me a line.

hardware.h

MRF49XA_definitions.h

MRF49XA.c

MRF49XA.h

spi.h

spi.c

Also, the PCB is available as a public design from BatchPCB.  I’ll include a bill of materials if necessary, though the components are clearly printed on the silkscreen.

Oh!  before you ask: No, I don’t know what the range is.  The longest I’ve tried is about 20 feet, and there weren’t any errors, but it was only about 100 bytes.  The chip is rated to 7dBm, I think, so go from there.

Update:

Here is a simple bill of materials, I used the Eagle export feature, and attempted to place digikey part numbers for each part.  I’m not saying they’re all right, you may want to make sure you’re getting what you think is correct.

partlist.txt

Also, here are the eagle files.  They aren’t necessarily finalized

eagle_files.zip

Share on Facebook

Asteroid Trajectory

Well, I’ve been investigating how one goes about finding the azimuth and elevation of an asteroid pass.  It isn’t easy, but the JPL Horizons system has the answers.  It isn’t an easy program to understand, and you access it by telnet (how 1992), but it’s also pretty cool.  I ran the system for the asteroid that will pass within 1/5 of the distance to the moon to us.  I’ve posted the system output below.  This data is for 122º W Longitude and 45º North Latitude.  The columns you probably want to use are the Azimuth and Elevation.  I’ve cut the portions of model output that have less than 0 elevation.  (Click “Read More” for the data)

Update:  Guh.  I hate Matlab.  Anyway, I added an image of the trajectory as seen from Oregon.  North is to the right, west is on the top.  I know, it sucks…  I don’t know enough about Matlab to fix it.  Also, 90º overhead is 0, and 0º is 90.

*******************************************************************************
Ephemeris / PORT_LOGIN Wed Sep  8 09:40:43 2010  Pasadena, USA   / Horizons    
*******************************************************************************
Target body name: (2010 RF12)                     {source: JPL#6}
Center body name: Earth (399)                     {source: DE405}
Center-site name: (user defined site below)
*******************************************************************************
Start time      : A.D. 2010-Sep-07 00:00:00.0000 UT-07:00
Stop  time      : A.D. 2010-Sep-09 00:00:00.0000 UT-07:00
Step-size       : 10 minutes
*******************************************************************************
Target pole/equ : No model available
Target radii    : (unavailable)                                                
Center geodetic : 238.000000,45.0000478,-0.000347 {E-lon(deg),Lat(deg),Alt(km)}
Center cylindric: 238.000000,4517.59088,4487.3484 {E-lon(deg),Dxy(km),Dz(km)}
Center pole/equ : High-precision EOP model        {East-longitude +}
Center radii    : 6378.1 x 6378.1 x 6356.8 km     {Equator, meridian, pole}    
Target primary  : Sun                             {source: DE405}
Interfering body: MOON (Req= 1737.400) km         {source: DE405}
Deflecting body : Sun, EARTH                      {source: DE405}
Deflecting GMs  : 1.3271E+11, 3.9860E+05 km^3/s^2                              
Small perturbers: Ceres, Pallas, Vesta            {source: SB405-CPV-2}
Small body GMs  : 6.32E+01, 1.43E+01, 1.78E+01 km^3/s^2                        
Atmos refraction: YES (Earth refraction model)
RA format       : DEG
Time format     : CAL 
Time zone       : UT-07:00
RTS-only print  : NO       
EOP file        : eop.100907.p101129                                           
EOP coverage    : DATA-BASED 1962-JAN-20 TO 2010-SEP-07. PREDICTS-> 2010-NOV-28
Units conversion: 1 AU= 149597870.691 km, c= 299792.458 km/s, 1 day= 86400.0 s 
Table cut-offs 1: Elevation (-90.0deg=NO ),Airmass (>38.000=NO), Daylight (NO )
Table cut-offs 2: Solar Elongation (  0.0,180.0=NO )                           
*******************************************************************************
Initial FK5/J2000.0 heliocentric ecliptic osculating elements (AU, DAYS, DEG):
 EPOCH=  2455446.5 ! 2010-Sep-07.00 (CT)         Residual RMS= .51054         
 EC= .1790426100393394  QR= .8185988097139194  TP= 2455532.390114616        
 OM= 165.5596199702477  W= 284.0221727285949   IN= 3.599336147379268        
Asteroid physical parameters (KM, SEC, rotational period in hours):
 GM= n.a.               RAD= n.a.              ROTPER= n.a.                 
 H= 28.298              G= .150                B-V= n.a.                    
 ALBEDO= n.a.           STYP= n.a.                   
*******************************************************************************
Date_(ZONE)_HR:MN     Azi_(r-appr)_Elev  r-ObsEcLon  r-ObsEcLat
****************************************************************
$SOE
2010-Sep-07 18:50 *r   88.0837   1.2209 345.2093905   8.7187668
2010-Sep-07 19:00 *    89.9485   2.7959 345.1984220   8.5009369
2010-Sep-07 19:10 *    91.8184   4.4307 345.1623414   8.3374745
2010-Sep-07 19:20 *    93.6971   6.0909 345.1133871   8.1983984
2010-Sep-07 19:30 *    95.5881   7.7611 345.0566579   8.0711552
2010-Sep-07 19:40 C    97.4951   9.4329 344.9944504   7.9500074
2010-Sep-07 19:50 C    99.4218  11.1011 344.9278998   7.8320371
2010-Sep-07 20:00 C   101.3720  12.7617 344.8576092   7.7156172
2010-Sep-07 20:10 N   103.3495  14.4114 344.7839147   7.5997670
2010-Sep-07 20:20 N   105.3582  16.0471 344.7070087   7.4838547
2010-Sep-07 20:30 N   107.4022  17.6657 344.6270009   7.3674481
2010-Sep-07 20:40 A   109.4855  19.2644 344.5439515   7.2502357
2010-Sep-07 20:50 A   111.6122  20.8400 344.4578897   7.1319808
2010-Sep-07 21:00 A   113.7864  22.3893 344.3688247   7.0124955
2010-Sep-07 21:10 A   116.0124  23.9090 344.2767525   6.8916239
2010-Sep-07 21:20     118.2942  25.3957 344.1816604   6.7692317
2010-Sep-07 21:30     120.6361  26.8455 344.0835297   6.6451990
2010-Sep-07 21:40     123.0418  28.2546 343.9823378   6.5194157
2010-Sep-07 21:50     125.5153  29.6189 343.8780594   6.3917785
2010-Sep-07 22:00     128.0600  30.9340 343.7706675   6.2621879
2010-Sep-07 22:10     130.6790  32.1954 343.6601341   6.1305470
2010-Sep-07 22:20     133.3748  33.3983 343.5464307   5.9967602
2010-Sep-07 22:30     136.1495  34.5378 343.4295284   5.8607319
2010-Sep-07 22:40     139.0041  35.6087 343.3093985   5.7223661
2010-Sep-07 22:50     141.9390  36.6059 343.1860127   5.5815653
2010-Sep-07 23:00     144.9532  37.5240 343.0593427   5.4382308
2010-Sep-07 23:10     148.0445  38.3579 342.9293609   5.2922613
2010-Sep-07 23:20     151.2093  39.1023 342.7960402   5.1435535
2010-Sep-07 23:30     154.4428  39.7524 342.6593537   4.9920011
2010-Sep-07 23:40     157.7382  40.3033 342.5192754   4.8374948
2010-Sep-07 23:50     161.0876  40.7509 342.3757795   4.6799221
2010-Sep-08 00:00     164.4813  41.0914 342.2288406   4.5191669
2010-Sep-08 00:10     167.9087  41.3217 342.0784338   4.3551094
2010-Sep-08 00:20     171.3578  41.4393 341.9245343   4.1876259
2010-Sep-08 00:30  t  174.8162  41.4425 341.7671175   4.0165884
2010-Sep-08 00:40     178.2708  41.3306 341.6061590   3.8418648
2010-Sep-08 00:50     181.7088  41.1035 341.4416343   3.6633181
2010-Sep-08 01:00     185.1175  40.7621 341.2735185   3.4808067
2010-Sep-08 01:10     188.4850  40.3080 341.1017867   3.2941841
2010-Sep-08 01:20     191.8006  39.7435 340.9264134   3.1032984
2010-Sep-08 01:30     195.0545  39.0718 340.7473726   2.9079923
2010-Sep-08 01:40     198.2387  38.2962 340.5646376   2.7081031
2010-Sep-08 01:50     201.3463  37.4208 340.3781809   2.5034621
2010-Sep-08 02:00     204.3724  36.4499 340.1879742   2.2938945
2010-Sep-08 02:10     207.3130  35.3880 339.9939882   2.0792195
2010-Sep-08 02:20     210.1660  34.2399 339.7961928   1.8592497
2010-Sep-08 02:30     212.9301  33.0101 339.5945573   1.6337915
2010-Sep-08 02:40     215.6053  31.7035 339.3890504   1.4026444
2010-Sep-08 02:50     218.1925  30.3245 339.1796409   1.1656015
2010-Sep-08 03:00     220.6934  28.8777 338.9662985   0.9224495
2010-Sep-08 03:10     223.1103  27.3674 338.7489949   0.6729691
2010-Sep-08 03:20     225.4459  25.7977 338.5277061   0.4169354
2010-Sep-08 03:30     227.7033  24.1724 338.3024153   0.1541195
2010-Sep-08 03:40     229.8858  22.4953 338.0731180  -0.1157099
2010-Sep-08 03:50     231.9970  20.7700 337.8398293  -0.3927832
2010-Sep-08 04:00     234.0404  18.9996 337.6025971  -0.6773244
2010-Sep-08 04:10     236.0198  17.1875 337.3615226  -0.9695419
2010-Sep-08 04:20     237.9386  15.3366 337.1167965  -1.2696129
2010-Sep-08 04:30     239.8004  13.4500 336.8687648  -1.5776535
2010-Sep-08 04:40     241.6087  11.5309 336.6180543  -1.8936630
2010-Sep-08 04:50     243.3668   9.5829 336.3658318  -2.2174072
2010-Sep-08 05:00 A   245.0779   7.6106 336.1143867  -2.5481574
2010-Sep-08 05:10 A   246.7451   5.6213 335.8686046  -2.8840315
2010-Sep-08 05:20 A   248.3714   3.6299 335.6402501  -3.2200863
2010-Sep-08 05:30 A   249.9595   1.6739 335.4622419  -3.5420167
$EOE
*******************************************************************************
Column meaning:

TIME

 Prior to 1962, times are UT1. Dates thereafter are UTC. Any 'b' symbol in
the 1st-column denotes a B.C. date. First-column blank (" ") denotes an A.D.
date. Calendar dates prior to 1582-Oct-15 are in the Julian calendar system.
Later calendar dates are in the Gregorian system.

 The uniform Coordinate Time scale is used internally. Conversion between
CT and the selected non-uniform UT output scale has not been determined for
UTC times after the next July or January 1st.  The last known leap-second
is used over any future interval.

 NOTE: A time-zone correction has been requested. See header.

 NOTE: "n.a." in output means quantity "not available" at the print-time.

SOLAR PRESENCE (OBSERVING SITE)
 Time tag is followed by a blank, then a solar-presence symbol:

 '*'  Daylight (refracted solar upper-limb on or above apparent horizon)
 'C'  Civil twilight/dawn
 'N'  Nautical twilight/dawn
 'A'  Astronomical twilight/dawn
 ' '  Night OR geocentric ephemeris

LUNAR PRESENCE WITH TARGET RISE/TRANSIT/SET MARKER (OBSERVING SITE)
 The solar-presence symbol is immediately followed by another marker symbol:

 'm'  Refracted upper-limb of Moon on or above apparent horizon
 ' '  Refracted upper-limb of Moon below apparent horizon OR geocentric
 'r'  Rise    (target body on or above cut-off RTS elevation)
 't'  Transit (target body at or past local maximum RTS elevation)
 's'  Set     (target body on or below cut-off RTS elevation)

RTS MARKERS (TVH)
 Rise and set are with respect to the reference ellipsoid true visual horizon
defined by the elevation cut-off angle. Horizon dip and yellow-light refraction
(Earth only) are considered. Accuracy is < or = to twice the requested search
step-size.

Azi_(r-appr)_Elev =
 Refracted apparent azimuth and elevation of target center. Corrected for
light-time, the gravitational deflection of light, stellar aberration,
precession, nutation and approximate atmospheric refraction. Azimuth measured
North(0) -> East(90)-> South(180) -> West(270) -> North (360). Elevation is
with respect to plane perpendicular to local zenith direction. TOPOCENTRIC
ONLY.  Units: DEGREES

r-ObsEcLon r-ObsEcLat =
 Observer-centered ecliptic-of-date longitude and latitude of the target
center's apparent position, corrected for light-time, the gravitational
deflection of light, stellar aberration and atmospheric refraction. The
ecliptic plane is the Earth's orbital plane at print time.  Units: DEGREES

Computations by ...
 Solar System Dynamics Group, Horizons On-Line Ephemeris System
 4800 Oak Grove Drive, Jet Propulsion Laboratory
 Pasadena, CA  91109   USA
 Information: http://ssd.jpl.nasa.gov/
 Connect    : telnet://ssd.jpl.nasa.gov:6775 (via browser)
 telnet ssd.jpl.nasa.gov 6775    (via command-line)
 Author     : Jon.Giorgini@jpl.nasa.gov

*******************************************************************************

Share on Facebook

I needed an app that I could use to test XQueries. I couldn’t find a free one online, so I figured I’d just write it. Put the XML source that you want the query in the bottom window, your query in the text field, click the button and away you go!

I haven’t tested anything about it other than those things. Your milage may vary.
Released under the GPLv2.

Source code (zip, 41kB)

Intel binary (zip, 45kB)

Share on Facebook

Share on Facebook

Share on Facebook

Unsuspecting security camera

Well, as a (perhaps welcome ) deviation from the spectrum analyzer posts, I’ve spent a little time working on repairing a security camera I’ve been hanging onto for a while.  I’ve been toying with the idea of installing it near the radio control flying field as someone in the club knows the owner of a nearby business.

The problem with the camera is that it has trouble switching from nighttime mode to daytime mode.  At night, it is sensitive to Near Infrared light (such as what is transmitter from your remote control).  During the day, however, this sensitivity makes the colors look strange.  To cope with this, they have a filter that slides in front of the lens for the daytime.  This filter binds, and because of this, the camera is always in nighttime mode.  I decided to go ahead and disassemble the camera to try to fix it.  My motto:  If it’s broke and out of warranty, take it apart!

Removing the lens

You can (kinda) see in this photo the image sensor.  This metal mount can move forward and back to accommodate different lenses and adjust their focal length.

Bottom cover removed

Removing the bottom cover reveals the power conversion board.

Removing the top cover

Removing the top cover reveals the PCMCIA slot.  This camera is kinda cool in that it can accommodate either a memory card or a wireless LAN card in this slot.  Also, there is an ethernet port on the back.  It has an embedded web interface that allows the control of camera functions and viewing live video.  Apparently, there is the ability to get some information from the serial port, but I haven’t found any information about it.

Front lens mount

Like I mentioned before, the front lens mount can be adjusted front-to-back.  The black screw near the top of the frame is used to secure the mount.  More to the right of the frame, the spring is used to press the mount against a set of wedges that control the depth setting.  The 4-pin connector goes to the lens iris, which is kinda like the aperture of a still camera.

Lens mount disassembled

This is the front of the camera disassembled.  The image sensor is still attached to the camera frame.  The black piece of plastic is the filter module, and the other piece is the metal frame for mounting the lens and adjusting the focal length.

Filter module

This is the device causing all the trouble.  The slight green tint in the left frame is the IR block filter, and the right is clear.  The motor is a small gear-head motor attached to a worm gear.  The worm gear has very shallow cuts in it.  The spring pushes down on a small plastic follower.  The whole system is intended to allow the worm gear to continue turning even if the system is jammed.  I think this is so that limit switches aren’t necessary.  I figured that the problems I’m having are due to excessive friction, which would cause the frame to remain static while the worm gear turns.  My first thought was to place a little petroleum jelly on the sliding surfaces.  I re-assembled the front of the camera and found that the problem remained.  However, I noticed that when the lens mount was all the way against the camera it would stick.  I could then solve the problem by keeping the lens not-quite against the camera.

Lens mount disassembly

Before re-assembling the camera, I decided to lubricate the adjustment assembly.  The black plastic ring on the right includes the adjustment wedges.  The middle ring is the precision-machined lens mount with a channel for the plastic ring.  The punched metal piece on the left completes the assembly.

Anyway, I put the camera back together.  It works great now.  I’m a little embarrassed to admit that the problem was simply that the lens can’t be in the closest setting for the filters to work.  At least everything went back together without a hitch.

Share on Facebook

IF Amplifier cooling down

I’ve decided to hold off posting spectrum analyzer modules until they’re complete.  I’ve been collecting tons of pictures along the way, so hopefully the post for each module will be interesting and visually appealing.  With that in mind, I can’t post about any of the modules with the exception of this one.  For whatever reason, my kit didn’t come with any voltage regulators, and this is the only module besides the mixers from my last post that don’t use any.  The IF Amplifier, as the name implies, amplifies the Intermediate Frequency on the analyzer.  I made a simplified version of the block diagram from Scotty’s site.  I’ve also indicated the modules I’ve finished in green.

Block diagram, green modules are completed as of this post.

As you can probably see, there’s a lot to be done.  Luckily both DDSs, the Log Detector, ADC, Control Board, and one PLO are done once I get some parts to replace the missing ones.  I also need some parts for the Master Oscillator.  Once that (actually quite small) order comes in, I’ll be almost finished with the boards.

Anyway, back to the amplifier.  I was one of the first people on an order of boards back in August ’08 because I agreed to look-over a new revision of the design files.  Of course, by having me look them over essentially guaranteed that there would be errors.  As it happens there was an error on this board.  The engineering change order (ECO) is luckily quite simple, the only problem was that a short section of the border was missing.  Here is a photo of the completed fix:

Fix for the slight error,

You should be able to see that along the border there is some solder wick saturated with solder bridging the gap, and connecting to the capacitor.  Also, on (at least) the 2 resistors (R3 and R4) there are tiny balls of solder.  These happen during the reflow stage when a bit of solder squeezes out from underneath the device.  I haven’t gone over the board picking all these out yet in this photo.  I think it’s important to remove all of these because they may cause shorts.  Also, you may be able to see a slight, shiny, residue around everything.  This is the solder flux that’s included in the solder paste.  I remove this later with some 99% rubbing alcohol.

Completed IF Amplifier

This is the completed amplifier board.  There are actually 2 amplifiers here, mirrored.  In practice, the output of one will be the input of the other.  This serves to roughly double the gain.  Finally, notice on the right side, that many of the parts have been omitted.  On the schematic, Scotty simplified this section.  Technically, he has 2 zero-ohm resistors (basically jumpers) in addition to the capacitor.  I chose to just jump the capacitor across and leave the resistors out.

Anyway, I enjoyed building this one.  I hope you’ve enjoyed reading about it.  I can’t wait to finish the other ones!

Share on Facebook

Mixer 2 completed and verified against schematic

I’ve verified each of the 3 mixers that I need for the spectrum analyzer.  The one above is mixer 2.  The schematic for this mixer is available from Scotty’s site.

Mixer 1 verified against schematic

I’ve also verified mixer 1 against the schematic.  There have been 2 optional revisions posted that aren’t included on mine.  I’m going to add them later, but only if necessary.

Mixer 3 verified against the schematic

Finally, mixer three is complete, and verified against the schematic.  This one isn’t strictly needed for the spectrum analyzer, however it is necessary for the tracking generator.  A tracking generator is a module that generates a signal that matches what the analyzer is tuned to.  This is useful for tuning filters, or other passive devices.

I’m missing some parts that I need to complete the control board.  I hope to get replacements soon, so I can begin testing some of these modules…   Stay tuned!

Share on Facebook

A while back I bought a spectrum analyzer kit.  It can display waveforms in the frequency domain from 0 to 1000 Mhz.  I haven’t worked on it for a while, but I’ve decided to start working on it again.  If you’re interested in more information, there is a webpage for the analyzer by the guy who designed it, and there’s a Yahoo group, also. If you’re really-really interested there is a group buy open (until the 28th of march 2010) here.  Anyway, I’m sure it’s of limited use to my usual readers (thanks, friends & family! [oh who am I kidding, most of my family doesn't read this ]), but it may be useful to others working on the kit.  I’ll post the “annotated” CAD images for each board here, and add images of the completed boards when I finish them.  Who knows, it may be interesting for someone.  Also, I’ll include my thoughts and observations while building these boards.  Finally, not all the boards that come with the kit include annotated layouts, so I’ll have to dig around and figure out what they do and what to put on them

Log Detector:

Master Oscillator:

Analog-Digital Converter

Control Board:

Direct Digital Synthesizer:

Phase-Locked Oscillator:

Mixers:

Share on Facebook

Picture in picture video

In this video, I’ve tried to synchronize video from a camcorder with the in flight camera.  I think it turned out really well.  I wish I knew how to make the canvas larger in iMovie so I could put the video side-by-side.  If you select the highest quality (480, I think) and make it full screen, I think it looks pretty good.

This video is from Tom and I trying to fly in some kind of formation so I could record his plane in flight.  It was very challenging because my plane is a lot faster than his.  I was flying on the brink of a stall most of the time while he was full-throttle.  There’s a moment where we almost had a midair.  We didn’t, so no harm.

Share on Facebook

Comparing antennas

I’ve finished building the first (and my first) Yagi antenna for the Kadet video downlink.  I mentioned in the first video post that a new, and better, antenna would help greatly. I was able to find some designs online that fit my needs.  The major constraint that I had to deal with is the impedance issue.  Nearly everything amateur radio related is 50 ohms, and nearly everything video related is 75.  The cheap Yagis paper written by Kent Britain, WA5VBJ, has a 75 ohm 421 Mhz antenna intended for amateur television (ATV).  My transmitter is 434 Mhz, but I figured it would be close enough.  The great thing about these designs is that they can be built using supplies from a standard hardware store.  The elements are made from #10 bare copper wire, and the beam is wood.

Completed antenna

An interesting characteristic of antennas, and RF in general, is that to get a stronger signal you often have to make compromises.  A Yagi works by increasing the directionality to increase the signal.  Unfortunately, because my plane is going to be flying around, I can’t be too directional.  To get better results, without making things worse, I decided to only use the reflector and “driven element”.  By  eliminating the “directors” I hope that I can get the best possible results. (If you’re confused by this “director”, “reflector”, and “driven element” gibberish, the best place to look is the wikipedia article.  But all that is necessary for this discussion is that the reflector is behind the driven element [which connects to the transmitter or receiver] and reflects the signal forward, and the directors go in front and focus the signal into a narrower beam).

Feed line soldered

There were some problems during construction that I should mention to help others wanting to try something like this.  The antenna designs specify that the feed cable should be soldered directly to the driven element.  This should work great on traditional 50 ohm radio cabling, such as LMR or RG-type cables.  These cables have copper braid shield around the circumference.  With the 75 ohm cable used in video, often made as cheaply as possible, a loose aluminum braid is used as the shield.  This is a major problem that I had to deal with.  It took me a while to even understand why the braid wasn’t soldering.  I think I assumed that the braid was made of tin.  After a few hours of searching, I discovered it was aluminum.  Aluminum oxide forms almost immediately and can’t be soldered to, so even sanding the wire doesn’t help.  There are solder pastes and fluxes that help, but I wasn’t interested in waiting for something to be shipped.  My solution, if you want to call it that, was to mechanically attach the braid to some other wire that can be soldered.

In the first image of the post, I’m comparing the new antenna versus the others I used earlier.  When the Yagi was installed, I rotated the antenna 360˚in azimuth to get an idea for how directional the antenna really is.  There wasn’t much of a change in signal quality, so it isn’t very directional.  If the transmitter were further away it may have been more dramatic.  I am motivated to build a few more antennas, maybe with 1 and 2 directors to see which is better.  With that said, I’m pretty satisfied, and I’m hoping for good weather this weekend.

b.t.w: Just to dispel any fears that the shield is shorted to the center conductor, as it appears in the above photo, it was, and I fixed it.  Here is a photo of the feed point as it was when I tested it.  Also, notice that I got my driven elements and directors confused when I wrote on the board

Another view of the feed point

Share on Facebook

Flying video

The weather sucked, but I was able to get out the the field this morning. I recorded about 17 minutes of video in total.  In the embedded clip, I edited out the majority of the static.  I’m a little disappointed that the signal quality is so poor.  I found a site that has some cheap Yagi antenna designs in 50 and 75 ohms.  I’ll probably try to build one this week and see how it goes.

More information about the camera is available in these posts, if you haven’t already seen them.

Share on Facebook

Painted to match

Taking advantage of the crummy weather, I decided to paint the camera module to match my plane.  I didn’t just do it for the aesthetics, no really, I swear.  Actually, the real reason I painted it was to prevent stray light from making annoying reflections on the inside of the window.

Masking the window

The first thing I had to do was get an idea of the size and shape of the opening that would be needed.  I was able to measure it by looking at the video output and marking with a sharpie just outside of the camera view.  Once I had all the sharpie marks, I tried to make the shame smooth and symmetrical.  Since I had to mount the camera low in the module, as discussed in this post, the opening is low, and very parabolic.  I then covered the whole top of the window with masking tape and by shining a light through the bottom traced the sharpie line with a hobby knife.  Removing the excess tape left a nice mask for the opening.

Prepped for painting

With the opening masked, I sanded the window to give the paint the best chance at adhering.  It is apparently a little hard to find plastic spray paint (like Krylon fusion) in silver, so I had to use some general purpose kind.

Outside paint

I think the paint on the outside of the window turned out O.K.  There is a little dust and lint marring the finish, but it turned out not to matter much.  I also wanted to paint the inside with a matte black finish to minimize the chance of reflections from light that is still able to get in through the smaller opening.  I used a similar approach to the technique for the outside.  I placed masking tape on the inside of the window and shined light in from the other side.  I again traced the outline with a hobby knife.

Inside painted

For some reason, I really like the way this turned out.  It’s all pretty dark in there, and should minimize reflections.  I also painted the base of the module to match.

Camera module base painted

I think everything came together nicely.  I really like the finished look, even though I was pretty sure that it was going to look weird.  As I mentioned earlier, the lint on the outside paint didn’t matter.  I put masking tape on the front of the window to protect it while I painted the inside, and it lifted part of the paint when I removed it.  This gave it a strange effect, and I’m not sure whether I like it or hate it.  Katie says it looks cool, so I’m leaving it for now.

There should be good (enough) weather this Saturday, so hopefully I’ll have some video to post!

Share on Facebook

Camera installed with Transmitter

I’ve just finished building a camera module for my Kadet.  When I was building the plane I knew that I was going to try and put a camera and transmitter approximately where the pilot’s head would be in a real plane.  That means a couple of things:  First, it’s pretty cramped up there with the flight pack, speed control, and motor.  Second, it’s a bit of a dirty secret, but forward visibility is usually not so great in most planes.  I tried to mount the camera as high as possible, but the front of the lens keeps hitting the glass.  I was able to get most of the view clear, but there is a margin on the bottom of the frame that is obscured by the wooden frame.  I will probably install some LEDs there to monitor battery charge, current, etc…

Outer frame of camera module

To build the outer frame of the camera module, I traced the shape of the wooden windshield onto a piece of acrylic.  After cutting it out I traced the inside of the fuselage onto balsa.  I cut out two side pieces and just glued them onto the acrylic.  I had to cut a notch into the back side of it to make room for the dowel that the wing rubber bands stretch over.  You can see how it fits in the first photo that I posted.

Camera mounted on bottom plate

I made a bottom plate by tracing the outer frame onto a piece of balsa.  Then, I took some balsa stick and made some uprights.  After drilling holes for the screws I soaked some thin CA into the sticks to keep them from splitting.

Camera module complete

The image above is the completed camera module.  At this point, there aren’t any electronics other than the camera module.  If you look really close, you can see the hole in the top of the windscreen on the top-left (the plane’s right).  This is for the video transmitter’s antenna.

Camera module schematic

The schematic for the camera/transmitter circuit is pretty straightforward.  The main consideration is that the camera and transmitter require different voltages.  The camera works best around 12 volts, and the transmitter uses 9 volts.  I only wanted to use one battery, so I had to make a voltage regulator.  I used my old standby, the LM317.  I also wanted to be able to adjust the transmitter voltage, so I added a potentiometer.  The transmitter came with a RCA plug and the camera had a BNC plug on a long cable.  I wanted to get rid of all this extra bulk, so I cut them off and connected them using the circuit board, also.

RCA Bunny ear antenna

The transmitter works on 433.92 Mhz, which is surprisingly hard to find in consumer products.  The obvious reason is that it’s in the amateur radio band.  But, 433.92 is actually channel 59 on cable.  This means that you can use a commercially available USB TV tuner to receive the video.  With that in mind, I gathered a few antennas to try.  The above photo is an antenna I bought to try.  It’s a VHF/UHF type from radio shack, I think.  I just went for the cheapest available.  I also looked for some antennas with “preamplifiers”, but I haven’t found any that amplify the 400 Mhz band.

Whip antenna

I also tried a whip antenna from an old 900 mhz wireless video system.  It’s not tuned anywhere near 400 mhz, but I’ve been lucky before.

I embedded a YouTube video of me walking around the house using each antenna.  The bunny ears are much better than the whip antenna.  The good thing about the whip is that I may be able to make another whip that is tuned correctly.  If the weather’s good tomorrow, I’ll probably try it out.  I’m pretty excited!

Update:  There have been a few successful flights recorded with the downlink.  The first video was pretty static-y, then I made a new antenna, and now the videos are much better.

Share on Facebook

Ready to fly at the BCRCC Polar Bear

I’m back from the third (and fourth) flight, and it keeps getting better!  On Friday (New Years Day) I went to the BCRCC (Benton County Radio Control Club) “Polar Bear” event.  Basically, the idea is: On new years day, rain or shine, everyone comes and flies something.  There is a raffle for all those that fly.  I brought the Kadet, mostly because that’s the only plane I have, and the tiny Blade mSR that I got for X-mas.

Micro-heli flying

The Kadet’s second flight was somewhat uneventful.  Flying during an event invariably leads to crowded skies, because I didn’t have the runway to myself I just tried to stay out of people’s way.  I was still pretty unfamiliar with my plane so it was nerve-wracking.  Luckily I did a good job landing with all those people watching .

Today, I went back to the field with my Kadet, and a new plane that I got at the BCRCC auction for $20 in November.  It’s a “Funtana Mini” made by E-flite that has since been discontinued.  Since the auction, I’ve been slowly getting the parts I needed to complete it, including a receiver and servos.  I reused the motor from another plane that is no longer with us.

My new sport plane

I piloted it on its maiden flight today.  It is extremely twitchy, even on low rates.  Also, something I didn’t expect was how hard it would be to land it.  It requires a fairly high airspeed to maintain altitude, and there isn’t much frontal area to slow it down, so the landing was fast.  I wasn’t able to stop it by the end of the runway so it spent some time in the mud.  Nothing was damaged, but the mud at the airstrip is very stinky.  The second flight was more fun, I actually did some aerobatics.  I still had trouble bringing it down, though.

I wasn’t satisfied with the prop I was using in the first flight test, which was an 11×7 APC E-series.  I bought 2 more, one with higher pitch speed (for the uninitiated, “pitch speed” is the number of inches a propeller would travel forward in one revolution in an ideal fluid) and the same thrust (which how hard it “pulls”), which I think is an 11×8.5 E-series, and one with the same pitch speed and more thrust; a 12×7 E-series, I think.  I tried the one with more pitch speed first, and I’m not rushing to try the other one.  I’m quite happy with the performance as it is.  At full-throttle I can climb-out at 45°, and at 1/4 throttle I can maintain altitude and speed.  I’m also very happy with the observed endurance.  I ran the stop-watch on my radio during the second flight of the day while doing non-stop touch-and-go’s, and after 12 minutes of flying called it quits.  The resting battery voltage on my 3S 2100 mAh LiPo was 11.4 volts.  This roughly corresponds to 20% of the pack power remaining.  With this knowledge in hand I know that I can set the count-down timer on my radio to 12 minutes and not stress-out my batteries too much.

Altogether, it was a good (long) weekend of flying!

Share on Facebook

PCB ready for module

This is the starting point.  I cleaned the surface with isopropyl alcohol (IPA).

Solder paste applied

I applied the solder paste as normal, and cleaned the module with IPA as well.

Module seated, waiting for heating

This is just before heating the pads with a soldering iron.  I heated each one until the solder melted, but it didn’t bond with the module.  Before I got too far, I removed the module and examined the results.

Results of the first attempt

I cleaned all the surfaces with solder wick and IPA, and tried again.

Results of attempt two

This time, I held the soldering iron on each pad for much longer.  The solder bonded to the module and the PCB, and it held tight.  However, I took a multimeter to it, checking for continuity.  Nearly every pad was shorted with it’s neighbor.  This sucks.

Another view of try two

With the module throughly bonded with the PCB, and no way to remove it and try again, I decided to try the hail-mary.  I figured that at this point, unless I could think of something, the whole thing was ruined.  With that in mind, I decided to try to reflow the whole thing.  I really had no idea if it was going to screw everything up, especially the FTDI chip on the bottom of the board.

During reflow

The reflow went well, I’m pleased with the look of everything.  I also confirmed that the pins are electrically isolated.  Also, on first glance, everything seems to work.  The microcontroller and USB-to-serial chip still work.  I really just need to verify that the transceiver module works, and it will be a complete success.

The moral of the story is:  Don’t attempt to hand-solder the Micrel module.  It probably won’t work.  On the other hand, if you do get it to work, drop me a line, I’d like to know how.

Share on Facebook