Archive

Posts Tagged ‘electronics’

BladeRF first impressions

March 19th, 2014 No comments

BladeRFI recently got a pair of the Nuand BladeRF SDR transceivers, and I’ve got about a days worth of experience with them.  Of course, first thing’s first, I had to print the BladeRF Coaster by Piranha32.  This is especially so because there are a few large tantalum-looking capacitors on the bottom.  Before I had this printed, I used some small machine screws with bolts and made a quick set of standoffs.  The package came with a nice blue USB3 cable and a pair of SMA jumpers; I assume these would go to their transverter, which I don’t have, but they’re nice to have anyway.  There aren’t any instructions in the box, but for a product like this the assumption is that the user knows what they’re getting and how to use it.  This is a reasonable assumption, and I had no problem finding all the relevant documentation.

I’m an ardent mac user, and this sometimes poses a problem while using specialized hardware and applications.  It wasn’t until the last few months that the recent versions of GNURadio worked through MacPorts.  Luckily it does now, as does all the BladeRF software.  Going from nothing to a working software environment took minutes.  One thing that you have to make sure and do it download the most recent FPGA code, as you’ll have to re-load it every time you boot the BladeRF.

All software defined radios have an Achilles’ heel.  If the DC offset of the I and Q baseband signals isn’t minimized a constant “tone” at zero Hz will be up-converted to whatever frequency the final spectrum is.  Also, if the relative magnitude and phase of I and Q aren’t matched (and precisely 90 degrees) there will be a image of the desired signal mirrored across the up-converter frequency.  The BladeRF wiki has a short article that shows how to measure the correction factors to use to minimize these effects.  This article documents my attempt of deriving the correction factors for one of the two boards.

To start, I tuned the board to 450MHz.  Then, I decided that a 100KHz sine would be appropriate as a baseband tone.  What happens is that, in software, the 100KHz tone is generated, then it is up-converted to 450.1MHz.  The spectrum below is the result of that test without any corrections applied.  The spur resulting from the DC error is about 25dB down from the desired carrier, and the image is closer to 35dB down.  It’s not really that great.

blade uncal

Playing around with the values according to the instructions, I was able to improve these results quite a bit.  The DC error is now 58dB down from the carrier (ignore the marker table) and the image is almost 63dB down.  This is pretty respectable.  Now, there is another troubling question.  What’s up with the spikes in the phase noise?

cal

I asked on the #bladerf room on freenode, and they agree that it’s not normal.  The spikes are exactly 7.8 KHz apart, so I would start looking for things that happen at that frequency.  I wish I had measured how distant the largest one was from the carrier and zero.  That could have been good to know.

phase noise

Oh, wait, I did :).  The main tone is 63KHz away from the main carrier and 37KHz away from zero.  There was some speculation that it could be artifacts from the quantization of the software-generated sine wave or that the tuning algorithm could be at fault.  For fun, I ran the same test without generating any sine wave at all, so all you’re seeing is a large zero tone from a constant DC offset.  I do think that the quantization explanation makes sense because that would manifest as phase noise, and the spikes are centered about the modulated tone, rather than the zero-spur.

constThe same artifacts should still appear there if there was any kind of a problem with the power supplies of the board, for example.  It seems very clean, and I’m happy with the phase noise performance of the board.  You’re probably seeing the phase noise of the rigol in this plot rather than the BladeRF.

In all, so far, I’m very happy this these.  I’m very excited about their potential.

 

Skyworks 65116 update

January 9th, 2014 No comments

It has been a while since I played with the Sky65116 amplifier boards that I built and wrote about.  Since getting my own spectrum analyzer, I’m now able to make much better absolute measurements.  The DSA-815-TG analyzer is specified as having 1dB of uncertainly across the span, and the SA that I have at work is essentially uncalibrated.

Video modulator output

Video modulator output (click for enlargement)

Not only do I now know that the absolute power out of the video transmitter at the fundamental frequency is about 5.5dBm, I can also see the first and second harmonics.  I don’t know why I didn’t see them with the other analyzer, but they are disturbingly large.  I believe the FCC requirement is that these harmonics should be more than 40dB below the fundamental.  By this criterion, the transmitter should not even be sold in the US.

The SKY65116 amplifier has close to 36dB of gain, and a 1dB compression point of 32.5dB.  The 1dB compression point is specified as the output power level at which the gain is reduced by 1dB.  The easiest way to show this is with the graph from the Sky65116 data sheet, shown below.  You can see that as the output power begins to approach 32dB gain drops quickly.  The goal is to not force the amplifier to operate in this region.  If you do, you’re likely introduce harmonic distortion and other nasty nonlinear effects (i.e. intermodulation products).

Gain vs. Pout curve

Gain vs. Pout curve

So, knowing that the output is +5.5dBm, and we want about +30dBm out of an amplifier with a gain of 36dB, we need to introduce 11.5dB of attenuation (30dBm – 36dB – 5.5dBm = -11.5dB) between the transmitter and the amplifier, at a minimum.  It’s easy to make 14dB attenuators with standard value resistors (4×150 ohm and 1×120).  I’ve been playing around with QUCS a lot lately, so I’ve provided a model for the attenuator.  It’s just about the most boring S-parameter model you’ll ever see…  Perfectly flat response at -14dB, but that’s what we’re after.

Simple 14dB attenuator model

Simple 14dB attenuator model

A while back, I had a bunch of these simple 5-pole filter PCBs made up.  I just left them blank until I needed them, and I made two of them into 14dB attenuators using the circuit above.  I had two extra poles, so I filled one with a 0 ohm resistor and the other with a 1uF DC-blocking capacitor.  The capacitor reduces the low frequency performance, but only less than about 1.5MHz.  It’s worthy the trade-off in my mind.

Constructed attenuators

Constructed attenuators

I went ahead and covered one of the attenuators with copper sheet just to make it more of a completed package.  I’m sure I’ll need to use it many times in the future.  I left the other open so I could unsolder it and make it something else if needed.  An interesting thing happened when I installed the cover.  The small ripple in the attenuation (around 500 MHz, see below) occurred only after I installed the cover.  I assume this is due to parasitic capacitance between the components and the copper covering.  It’s still only about 1dB of ripple, so I’m satisfied with it.

14dB attenuator performance

14dB attenuator performance

Anyway, back to the amplifier.  I’ve now got about -8.5dBm going into the amp ( +5.5dBm – 14dB), so with its 36dB of gain, I should expect to see +27.5dBm out of the amp.  That’s getting very close to the maximum input power on my SA (+30dBm).  It’s always better to be safe with these things, so I used the other 14dB attenuator between the amp and the SA.  Now, I should expect to see +13.5dBm on the input.  I maxed-out the input attenuation on the analyzer (another 30dB) and gave it a shot.  Note that the internal attenuation is calibrated out of what’s shown on the display, and I told the SA about the other 14dB of attenuation, so the power values shown on the display are referencing the amplifier’s output.

Transmitter after amplification

Transmitter after amplification

In the above image, you can see that we’re getting 27.5dBm out of the amplifier!  I love it when a plan comes together!  This is the value I calculated, right on the nose.  I promise that I didn’t work the math backward! :)  Again, it’s so painfully obvious that the transmitter is AM, rather than the VSB signal that it should be.

Close-up of the signal

Close-up of the signal

Now, just for fun, let’s dive back into the video signal coming out of the transmitter.  In the image above, I’ve put some markers on the various carriers present in the signal.  The luma carrier is in the center at 433.85MHz, which is where we expect it to be.  Marker 2 is at 437.45MHz, which is 3.6 (let’s call it 3.57) MHz away, matching exactly where the chroma carrier is supposed to be.  There’s no audio carrier, which isn’t a surprise because there’s no audio, though I wouldn’t be surprised to see the carrier.  Marker 3 is 19 MHz away; I have no idea what this is or why it’s there.  It’s not supposed to be.  Same with marker 4.  Oh, well…  that’s what you get with a shitty transmitter.

amplifier gain v. frequency

amplifier gain v. frequency

Now, what about those pesky harmonics?  The Sky65116 is a 390-500 MHz amplifier, so my hope is that the reduced gain by the first harmonic will attenuate the harmonics enough to bring them into compliance.  The graph above is the gain v. frequency graph from the data sheet.  It’s neither encouraging nor discouraging.  It’s difficult to infer what’s going to happen at 800 MHz when the graph stops at 500 MHz.  In the image below, it appears that I lucked out.  The first harmonic is 42dB down from the fundamental.  If I were selling a product, there’s no way I would send this out for compliance testing.  It would just be too risky, I’m not that confident in my measurements.  By my math, it would cost less than $2 in parts (single unit quantities) to make a decent low pass filter.  That’s the right thing to do.  When I modeled it (in QUCS, again), I calculated that the harmonics would be within compliance even without the rolloff of the amplifier.  With the rolloff, the harmonics would be well below the noise floor.

Harmonics after amplification

Harmonics after amplification

I’ve had a ton of fun redoing this experiment with my new spectrum analyzer.  I’m going to write lots more about the analyzer in the future, and I’m really looking forward to it.  Coming soon is an exploration of the skyworks low noise amplifiers.  Between these two products, I expect to have a solid video link over 1000 feet or so.

3D Printering

January 6th, 2014 No comments

Ok, confession time.  I succumbed to the 3D printing fad thing.  I know.  I made fun of 3D printer fanbois in the past, but we got one at work.  Using it for a bit forced me to realize that they’re actually pretty cool.

My kit of reprap parts!

My kit of reprap parts!

I asked my whole family to chip in for a RepRap Prusa i3 kit for my birthday (in September, to give you an idea of how behind I am).  It came relatively quickly, but there were certainly some issues.  For one, everything smelled –very strongly– of cigarette smoke.  Luckily, it was mostly isolated to the outside of the packaging.  Once I unpacked everything, it went away.

Aaaarg!  Two sets of threaded rods!

Aaaarg! Two sets of threaded rods!

Then, I discovered that I got two sets of threaded rods!!  That wouldn’t be so bad, except that I didn’t get any smooth rods!  I emailed the company, and they got a replacement set of smooth rods in the mail right away, but I still had to wait a while.  In the mean time, I figured that 5/16″ is awfully close to 8mm.  I bought some 5/16″ stainless steel rods from the hardware store to keep working on the printer.  The 5/16″ rods are undersized for the LM8UU linear bearings (they’re designed for 8mm rods), so there was extra slop in all the axes.  Eventually, the 8mm rods came in the mail, and I installed them.

There were a few other minor issues.  For one, the melamine material that was used for the main frame was thicker than the laser-cut slots.  I had to carefully trim the tabs so that they would fit.  It may be difficult to understand what I’m talking about without photos, but all that’s important to understand is that there were some attention to detail issues.

After printing for a while, I noticed another problem with the melamine.  It’s also used in the frame that holds the build platform to the Y axis bearings.  The frame material wasn’t strong enough to level the platform.  When I lengthened the screws on the low sides, the frame would just bend downward rather than moving the platform.  I found a place in town that sold me a sheet of 3/16″x1′x2′ aluminum for $5, from which I cut out a replacement frame with my scroll saw.

Other than those problems, everything went together smoothly.  One interesting thing about RepRaps (the models that I know about, anyway) is that they don’t really include something to hold your spool on.  I almost think it’s to give people something to design and print out of the chute.  My solution was to build a frame using aluminum channel stock.  I started with just the upright part of the spool holder.  Then, the spool spun a bit too easily, and it would unspool and catch on things.  The angled portion holds a dry sponge with a hole in it.  This has the dual purpose of wiping the dust off of the filament and providing a small amount of friction.

The reprap is all finished.

The reprap is all finished.

The green adapters on the spool ends are just bearing holders that help the spool turn more easily.  It was the first thing that I printed.  Here’s a very short video of it working:

 The final issue I had was with the GFCI circuit in my office.  I can’t figure out why I have GFCI there, but I do.  To add insult to injury, my firewall/router/server is on the same circuit.  So, every time the printer trips my GFCI, it takes down the internet and generally causes havoc.  I pulled my hair out over this one.  I replaced my (very expensive) GFCI circuit breaker and the printers power supply.

Trying to measure GFCI current

Trying to measure GFCI current

In the photo above, I’m trying to measure the peak ground current from the printer.  The fluke is on the mA setting with peak hold.  This is the highest reading I ever got, and the circuit didn’t trip.  It’s my understanding that GFCI trips when there’s about 30mA on the ground circuit.  My assumption at this point was that the shunt resistance in the DMM was limiting the peak current, therefore no 30mA spike and no trip.

The problem persisted for sometime, and I began to suspect the GFCI breaker.  I went to an electrician store, and the guy said that they can wear out.  After I replaced the circuit breaker, and $50 later, the problem got worse!  It would trip even when the printer wasn’t plugged in!  At least then, it was no longer an intermittent fault.  Now that I could reliably cause the fault, I at least had hope for isolating it.  I unplugged everything on the circuit and plugged in things one-by-one.  I turned out that a cheap power strip (the same kind as in the above photo) was the culprit.  Boooo.

Any way, I’m now a 3D printing convert.  But I promise I won’t be annoying about it. :)



Support for the Rafael Micro R820t tuner in Cocoa Radio

October 26th, 2012 2 comments

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!



Softrock application available

May 11th, 2012 2 comments

Here’s a compiled executable, including the rtl-sdr library, for those that don’t want to get the source on github and compile it.

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

Softshell-alpha