Archive

Archive for the ‘Tools’ Category

Compiling GnuRadio 3.3.0 on Mountain Lion

July 25th, 2012 6 comments

Fixing all the little issues with this process took me days, so I apologize if it’s a complicated and multi-step process.  These steps worked for me, hopefully they work for you too, but YMMV.

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.



Using softshell with GNURadio

July 24th, 2012 2 comments

It has been a little while since I released the very early code for softshell (not that the code has advanced much), and I’ve received a few requests for a bit more information about how it’s intended to be used.

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!



Macports compilation problems with CLANG (netpbm)

July 24th, 2012 2 comments

I’ve been struggling with this for a few days, so hopefully this post saves some people from headaches.

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?

 



More ChipKit spectrum analyzer progress

February 1st, 2012 3 comments

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.



 

Buspirate and shift registers (a tale against publication bias)

January 20th, 2012 No comments

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

Experiment setup

Read more…

DFU-Programmer tips & tricks

November 19th, 2011 2 comments

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

Homebrew bubble counter

October 19th, 2011 12 comments

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! :) ).  Read more…

Receiving weather satellite images with Softrock

October 19th, 2011 17 comments

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!

Read more…

SKY65116 Amplifier

September 15th, 2011 1 comment

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. Read more…

QFN Reflow Soldering

July 27th, 2011 No comments

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. Read more…

43 visitors online now
34 guests, 9 bots, 0 members
Max visitors today: 70 at 07:34 am UTC
This month: 100 at 05-08-2013 07:53 pm UTC
This year: 199 at 01-04-2013 06:37 pm UTC
All time: 1081 at 06-12-2011 07:36 pm UTC