• urJTAG requires a BSDL file for programming. I was able to download a BSDL file for my FPGA from the Lattice Web site.
• urJTAG can only program using SVF files, at the moment. I tried the new STAPL support, but it crashes. It might be something wrong with my build environment.
• Lattice Diamond does not output SVF files. I needed to download the separate ispVM System program.
• ispVM System outputs an SVF file that urJTAG doesn’t like. Use the “Rev D” SVF output option.
• SVF programming of the XP2 flash is extremely slow. I’m not sure, but I think the SVF has a delay that accounts for time required to erase the flash. I eventually realized that, for development, I could load a bitstream into the FPGA’s SRAM far faster.

Here’s what a programming session looks like:

$ jtag
jtag> cable ft2232 vid=0xcafe pid=0xbabe interface=1 driver=ftdi-mpsse
jtag> bsdl path /Users/jboone/src/bsdl
jtag> detect
IR length: 8
Chain length: 1
Device Id: 00000001001010011001000001000011 (0x01299043)
Filename: /Users/jboone/src/bsdl/lfxp2_5e_tqfp144.bsd
jtag> svf <filename>.svf progress stop
detail: Parsing 23450/23458 ( 99%)detail:
detail: Scanned device output matched expected TDO values.
jtag>

This technique should work with the Bus Blaster, too, since it’s based on the FT2232H.

I wrote a quick-and-dirty capture program, starting with a libftdi (“master” branch) example program, stream_test.c. With it, I can sustain approximately 32MBytes/second. It appears my hard drive write speed is the bottleneck, as I get drop-outs periodically, but only if capturing to disk, not RAM.

I haven’t incorporated any low-pass filtering, or finished implementing proper digital downsampling of the raw baseband sample stream, so to test the system, I chose the most powerful signals available: FM broadcast. I captured about 8MHz of the local FM spectrum, centered around 101.9MHz, and was able to play it back and demodulate several channels using GNU Radio.

Up next, proper filtering, and some more interesting wideband signals! And maybe I should clean up my office before I make my next video…

I’m helping out with various tasks along the way. Here are the biggest challenges we’ve faced so far:

• Finding a front-end IC or combination of ICs that will convert 2.4GHz signals to/from baseband, digitize received baseband signals and “analogize” transmitted baseband signals. So far, the best solution seems to be a two-chip combination of the MAX2837 WiMAX transceiver and MAX5864 analog front end (quadrature ADC and DAC). This combination will get signals to/from 2.4GHz to digitized quadrature baseband data streams.
• Moving digitized baseband data between the HackRF device and the host PC — again, inexpensively and using little power. The most conventional, obvious interface is USB 2.0 high-speed. We’ve entertained several options: ARM microcontrollers, FPGAs, XMOS event-driven processors, and dedicated USB interface ICs like the Cypress CY7C68013 and FTDI FT2232H. In reviewing these options, we came across a new breed of ARM microcontrollers that have generalized high-speed interfaces on them. The most compelling so far is the LPC43xx SGPIO interface, which can be configured into arbitrary-width serial or parallel interfaces running at over 100MHz transfer rate.
• Understanding and configuring the Si5351C clock generation IC. Silicon Labs documentation for this part is rather scattered and inconsistent. Mike did a lot of testing with an oscilloscope to identify the true behavior of the IC.
• Interfacing the LPC43xx SGPIO interface to the MAX5864, which has two dual-data-rate (DDR) interfaces that the SGPIO port can’t directly interface to. Our current solution is to use a low-cost CPLD (programmable logic device) to convert bus widths, voltages, and clocking schemes.
• Keeping total power consumption to below USB 2.0 limitations. Mike opted to put a switching regulator on the board, which seems to work well, though we haven’t reached the point in development where we’re drawing a lot of current *and* trying to receive weak radio signals. It’s possible the switcher may produce enough noise to interfere with the radio circuitry.

Keep up with HackRF developments on the GitHub repository and Wiki, or join us in IRC (freenode.net #hackrf), or on the HackRF-dev mailing list.

Every package we shipped had a little bit of Piper fur thrown in, for good luck. Perhaps you still have your Chronulator box laying around somewhere? Look for little 2 cm (0.75 inch) strands of straight, stout black fur, the mark of quality!

Share/Bookmark

I’ve given some thought to my relationship to blogging and social media, and why I seem to be so bad at it. I think it boils down to modesty:

• Modesty about wasting people’s time sharing things that aren’t finished. Until I make something work, end-to-end, I assume it’ll never work, or that people will criticize me for doing it wrong. And I don’t want to let people down.

Modesty about my writing abilities. My dad’s a journalist, so at some level, I have come to view writing as a professional activity. And I’m no professional writer.

Looking at these reasons for not blogging, I realize they’re a bunch of baloney.

When I read other hardware-oriented blogs (Dangerous Prototypes and Hack a Day come to mind), I don’t have the same expectations I do for my own blog. There are always quick little truffles of ideas and progress, posted all the time. I enjoy seeing the creativity and the process. Yes, finished products are nice (have I mentioned recently how awesome the Bus Pirate is?). But even the Bus Pirate is a work in progress. It’s gone through three major revisions since it was first announced. And these revisions were done with public input, which certainly made it a better product. And public involvement, to a great extent, made the Bus Pirate possible in the first place. I doubt Ian could’ve developed the Bus Pirate to such a degree, all by himself. He has dozens of people contributing. The process is what people want to hear about and participate in. And I could use some people pushing me and keeping me focused on what’s truly important about my projects.

As for my writing skills, I write just fine, thank you. The most important thing is that I communicate, not that my grammar is flawless. And I don’t need professional training or experience to communicate successfully. Ironically, in other fields of endeavor, I’m notorious for being anti-professional. I staunchly believe you don’t need to go to school to learn engineering skills, or hold down an engineering job to feel qualified to build things. What’s most important is passion. With passion, and some patience, you can acquire the skills to do most anything you want.

In the end, I’m taking this blogging stuff all too seriously. So I shall redouble my efforts to share what I’m doing and what I’m thinking. In the process, I hope to accumulate a crowd of smart and curious people who are interested in the same things I am, and will help turn some cool ideas into reality. Yay!

More to come, soon!

What Chronulator case designs would you like to see in the ShareBrained store? Leave a comment, a Tweet, Facebook/Google+, e-mail, it’s all welcome!

Share/Bookmark

Come out to ADX this Saturday (December 17, 2011), from 11am to 5pm, and load up on great gifts. ShareBrained will be there, along with friends Curious Terrain and Platemark X.

Alternative time-telling devices are compelling, but only if they’re easy to read. Building a kit can be satisfying, but only if it leaves room for creativity. The Chronulator clock kit fits the bill on both counts.

Check out the Ultimate Kit Guide online, or buy a paper copy at your nearest magazine vendor.

A quick overview of the board’s design:

• SMA connectors for the baseband quadrature input signal. There are two differential inputs, so four connectors total.
• Two-channel high-speed ADC from Linear Technologies. I designed with the 16-bit, 125MHz LT2185 in mind, but Linear offers many pin-compatible devices that are cheaper, with the attendant trade-offs in sample rate and resolution.
• Sampling oscillator in a standard 7mm x 5mm footprint. I’m planning to use a low phase noise oscillator like the Connor-Winfield CWX813.
• Lattice XP2-5 FPGA for sample rate conversion.
• FTDI FT2232H high-speed USB interface.
• Configuration and FT2232H pin breakout so I can experiment with USB-based FPGA code updating.
• JTAG interface for initial development.
• Power input — approximately 3.7V minimum.

USB 2.0 high-speed performance is a bottleneck for software radio. On a good day, you can get 35 MBytes/second. Assuming 12-bit quadrature signals, that gives you a complex sampling rate of about 12 MSamples/second, and a theoretical bandwidth of 12 MHz. Usable bandwidth will be more like 10 MHz.

Because of this USB-imposed bandwidth limitation, I chose to use a faster ADC to oversample the input and simplify the analog filtering going into the ADC. I’m expecting to oversample the baseband signal by 4x to 8x. With that amount of oversampling, simple four-pole Butterworth or Bessel filters should be plenty. The FPGA will do sample rate conversion, using CIC or FIR filters.

There’s almost no filtering on the ADC input. I’m planning to attach a separate baseband filter or use an RF band-selection filter to severely band-limit my target signals and avoid unsightly aliasing. Here’s one approach for an 80 MHz sampling rate and a 10 or 12 MHz output rate:

The great thing about oversampling is you don’t have to design your analog filter for the final sample rate’s Nyquist frequency. Instead, you can push that stop-frequency up to the sampling rate minus the final bandwidth. In the example above, it’s 80 MHz minus 6 MHz, or 74 MHz. So my filter can gracefully tail off across more than a decade of frequency (74:6 = 12.3x). Of course, with oversampling, I’ve made a lot more work for myself in the digital domain. But FPGA CIC and FIR filter implementations are plentiful and well-understood, so I’m not too worried…

The board should be back from Laen in a couple of weeks. I can’t wait to solder it up and see what happens!

Share/Bookmark