Hackrf One Project Part I

The Hack Rf One is a sophisticated  software design radio capable of transmission or reception of radio signals from 10 MHz to 6 GHz.. Most importantly  HackRF One is an open source hardware platform that can be used as a USB peripheral or programmed for stand-alone operation..

The designer Michael Ossmann initiated a very successful  Kickstarter project where I bought an emty pcb.
It took about a year until I collected the pcb, in a way Michael became a victim of his own success.
I don't want even to start to think about the pressure to deliver so many devices of this complexity.
There are pitfalls waiting around every corner. Fortunately Mr. Ossmann had the capabilities to manage such a huge and complex project.

Now after I received my pcb (unfortunately I did not buy more), I needed to get my hands on the parts.
Once there is high frequency involved, there are usually some hard to get hf parts, like transformers or matching elements and so on,.. Mr. Ossmann however did a great job, you can buy all parts from only two sources, Digikey an Mouser. At least if you are an American. Digikey does not ship the RFFC5072 mixer outside the US. Immediately my project was on hold again. I tried nearly everything, even contacted the manufacturer of these chips, no luck. The only workaround was to contact an American resident  and ask him to order and ship the part to me. I never im my life had to go this route as an European usually if one company does not want to make business with you you find a dozen others which will step in.

Anyhow, after I received the parts, I started to think about how to build this radio. The components used are super small, f.e. 0402 resistors and capacitors which are a real pain to populate.

The best way to rebuild a complex circuit is to break it into components and test them during the build process if possible.

I split the radio into following building blocks:

a) Power Regulator
b) Controll Logic
c) Analog Logic

a) Power Regulator

I decided to start populating the power regulator section first.
Then I applied power and tested the 3V3 rail which worked.
To test the 1V8 Rail I connected R54 to +5V (see pic) and powered the Regulator over C143.
To power the regulator I used a Kelvin Probe to avoid soldering again.

  Then I measured the output over the terminals P1 and P8 and Ground.


 b) Controll Logic

After successfully completing step a we are ready for the next step, populating the controll logic.
We are about to populate everything outside the fenced area of the board.

Step b is a huge step, which I braked down to about three reflow processes.
I populated the arm chip and its supporting passives and  then reflowed the parts,
afterwards I populated the ics U18 and U19 and the passives sourrounding them,
and the last step is to populate the Cpld and passives, the signal leds and the usb connector.


I decided to reflow the usb connector as late as possible, because it is easily destroyed during the reflow.
For the same reason I did not populate the switches.
After each reflow process it is wise to inspect the components for possible shorts or cold solder joints  and to measure the resistance of the main voltage rails against ground.

After completing the reflow processes and inspections of stage b, we can now connect the board to the pc.

Before we can do that it is important to install the necessary  software as described here.

Nothing should happen, except the 3V3 led should be active.
Then I shorted the dfu switch and the reset switch using two wires.
After releasing the reset wire the board should enumerate over usb.
Using dfu util I tried to program the arm controller.


I typed 
dfu-util --device 1fc9:000c --alt 0 --download hackrf_one_usb_ram.dfu 

I received the following output:

 Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY

Filter on vendor = 0x1fc9 product = 0x000c
Opening DFU capable USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
Device returned transfer size 2048
DFU CRC does not match
Warning: File has no DFU suffix
bytes_per_hash=406
Copying data from PC to DFU device
Starting download: [##################################################] finished
!
unable to read DFU status



In fact I was stuck after this step and searching for reflow errors on my board for quite a while.
But I was not able to figure the problem out.

Luckily I own a lpc_link programmer, which I connected to the P26 connector. Then I fired up the lpc_expresso ide, and created an empty project for the LPC 4320 (as described in the LPCXPresso_Flash_Debug_Tutorial from the doc section of the files from Michael Ossmann) .Then I clicked the flash program button on the tool bar and entered the following settings in the upcoming dialog:

After clicking the ok button I finally was able to transfer the Arm firmware to the board.
After a reset the Hackrf finally enumerated correctly and I was able to program the Cpld code using Michael Ossmans flash cpld program.

To flash the cpld code i used following statement on my computer:
hackrf_cpldjtag -x firmware/cpld/sgpio_if/default.xsvf

Then I executed hackrf_info just to be sure the computer is able to identify the board and it worked.
The tool produced the following output for my board:

Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2014.08.1
Part ID Number: 0xa000cb3c 0x005a4f48
Serial Number: 0x00000000 0x00000000 0x455063c8 0x22574a5f

This ends part I
Stay tuned, there is more to come.

A tale of two scopes and a horrible signal

I hade the chance yesterday to get my hands on a Agilent DSOX3024A in the school lab.
Usually these devices are locked away from the students because they are way to expensive to withstand the daily abuse from not so much caring students. It's a shame but reasonable,...

On the other hand there is the Rhode&Schwartz HMO2024 for which I got a great package deal including all options.

They both are  200 Mhz scopes with 4 channels and have about the same feature set.
The Aglient though is a bit pricier.

Since I own the Hameg of course I am biased for that model so please keep that in mind although I will do my best to stay objective.


The second I sat before the Agilent I must confess it has a huge wow factor.
It is bigger than the  R&S but it has about the same weight.

I love the display it is so huge and has a nice resolution and best of all a great sampling depth.
According to Agilent it also has a lighting fast update rate so it should be a joy to catch glitches.

Unfortunately I could not play with the logic analyser because it is an option which was not installed.
I don't understand why Agilent does not sell a full blown scope to a school or university.
This would have been the best advertisement money can buy. Once the students get used to the features they don't want to miss them any more.And since the scopes are not used in a commercial environment why not add something for free ? 

I really love that every channel had its dedicated voltage divider knob, a feature I miss on the R&S scope. Speaking of the knobs there is one fact I hated on the scope, the layout.
I am used to the Textronix layout which is voltage divider knobs beside the timebase knob.
This layout makes sense because that are the most important knobs and it became an industry standard.Why changing something that works so well and people are used to ? I even did not find the seconds divider knob for quite a while and had to use autoset which I don't like that much because I prefer to be in full control of the displayed data.

I also could not get a trigger on an I2C data signal the data acquisition had to be stopped before the picture stood still. But I assume that was my fault in fact it had to be. Since the I2C signal is irregular according to frequency the displayed waves were all over the screen and the irregularities were interpreted as glitches I assume.
Btw the R&S scope also had a hard time to trigger correctly and I had to tweak the trigger settings quite a bit (like setting a trigger hold off) so in fact the Agilent did quite good.

I was not impressed with the wave auto analysing tough. The auto measure function is somewhat greedy and does not nearly display as much info as the R&S scope does but then again that could also be an operator fault.
To get my hands on this scope was a quick settling opportunity I had not planned for. If I were better prepared I would have inspected the scope way more closely.

The test setup:
I used an LM75 on a breadboard driven by an 500kHz I2C bus.
So the signal should work but it also should look horrible.
The Msp430 was also powered by usb which also should inject quite some noise.

The pictures:

Pretty much the same, huge over/under shooting on the clock channel and massive cross talk

The detail view is interesting, while on the Agilent side the ringing is visible on the Data line the R&S shows the ringing on the clock line.
Which one is correct ?
I tend to believe the R&S version more because it makes more sense imho. Since the clock line over/under- shoot visible on both scopes has to degrade somehow (because there are capacitive and inductive components involved) the dampened oscillation makes more sense on the clock line, while the data line has no comparable over/under shoot so why should it ring ? Any ideas from the reader which might shine some light on the issue is highly appreciated since I am somehow puzzled.

The automeasure function on the Agilent is somehow greedy compared to the R&S but that might be my fault, I will study the manual to check if there is a possibility to get more measurements.


The final verdict:

I could fall for the Agilent, the big screen is a winner no question.
The update speed is insane.

I don't like the knob layout but I think after a while I would get used to it.

The feature set on a first glance is pretty much the same.
But the devil is in the details.

Is the scope worth the higher price tag  compared to the R&S Hameg line, I would say yes.
 
I only had  a few hours playtime on the Agilent scope so I only scratched the surface.
It is an impressive scope but what else would you have expected from such a great company ?

Agilent 34461A Miniseries Part 1 Histogram and Cdf

Today I received a Agiltent 34461A Truevolt multimeter from Xtest.at the Austrian Agilent distributor.
I plan to write some articles about this  multimeter and especially about features which imho separates it from it's competition.

I am a Hewlett Packard / Agilent fan but I will try hard to be as unbiased as possible,...

A very interesting feature for me is the histogram display. I enjoyed the online demo's about this feature and after unpacking the meter I had to try this feature immeadetly.

If you wanted to measure the deviation of a source before you had to collect data via a serial usb or gpib bus and then create an excel sheet to visualize it. Therefore you would do such a cumbersome task only if you really need statistical data badly.

With the new Agilent 34461A you can watch the deviation instantly by pressing a button.
To test this feature I connected a 5V reference and let the instrument visualize the data.

After some 4500+ measurements you get a nice picture with an expected Gaussian distribution form.
You can also see that the Reference drifts about ±10 uV and that the reference is about 283 uV off (not as bad as it looks).

The reference and meter grosso modo  work as expected, since I have not trimmed the reference against a calibrator yet.

The  reference I used is based on the Max6350 chip with an ±0.02% initial accuracy, which translates to ±1mV. That considered it is doing great.It is awfully hard to  get your hands on a reference which is a match to the precision of a modern 6.5 digit meter, unfortunately.

Beside the histogram which is relatively easy to interpret, the meter also offers to show the cumulative distribution function (in short CDF). The CDF is represented by the green line on the picture above.
The y axis represents the percentage, the x axis the voltage.

So what is the CDF good for ? You can use the CDF to determine what percentage of the data falls between two points. The gradient of the function is also interesting.The first 10% have a considerably smaller gradient than the rest of the function, which means that the negative outliers in that sector are more rare than the other ones.
You can also see f.e. that 10% of the voltages  are of in the range of  5.000272 and 5.000279 V.
The position where the function crosses the x axis is the 50% point which in this case is slightly of the origin point on the positive side.
All in all the CDF is a great addition to an already useful statistical feature.

Test setup:

Many thanks go to the Austrian Agilent Distributer Xtest.at for making this test possible.

More mathematical insight on  Gaussian Deviaton and the cumulative distribution function can be found here.

Texas Instruments CC Debugger

Texas Instruments offers great tools to get you started on their zigbee like wireless transceiver line.
CC Debugger and Smart RF studio.
You can buy a CC debugger for about 48$ at the Ti webshop, but where is the fun in that?
Luckily Ti provides the schema files , boot loader and firmware for the CCDebugger, so you easily can build one yourself.
I even found the gerber files for the product on the internet and ordered a batch of 10 pcbs from Itead.
I don't need them all, but this is their minimum order size.

What can you do with this tool?
The debugger helps you to evaluate signal strength , configuring the wireless modules and explore different configurations.
The modern Zigbee devices are incredibly powerful cheap but also very complicated.
A tool which helps you getting started is most welcome. 

The build of the toll was not really challenging but the programming gave me headaches for a while.
After I soldered the components to the pcb, I plugged the board into an usb slot.
Both leds lid up which means according to the manual empty controller.
So I had to load the boot loader into the CC2511 controller chip.
To do so you either need a  (programmed) CC Debugger or some fancy expensive dev board from Ti .
Luckily I own a Goodfet tool.

I fired up the console and connected the CC Debugger to the Goodfet.
The first step is to check if the programmer recognises the module 

> goodfet.cc test


SmartRF not found for chip 0x9104.
Tracing execution at startup.
Verifying that debugging a NOP doesn't affect the PC.
Checking pokes to XRAM.
Done.

Great, success.
Next step programming the bootloader




> goodfet.cc flash ../../../../usb_bootloader_srf05dbg.hex

SmartRF not found for chip 0x9104.
Flashing ../../../../usb_bootloader_srf05dbg.hex
Buffering 0000 toward 000000
Buffering 0100 toward 000000
Buffering 0200 toward 000000
Buffering 0300 toward 000000
Flashing buffer to 0x000000
Flashed page at 000000
Buffering 0400 toward 000400
Buffering 0500 toward 000400
Buffering 0600 toward 000400
Buffering 0700 toward 000400
Flashing buffer to 0x000400
Flashed page at 000400
.....
Flashed page at 001000
Buffering 1400 toward 001400
Buffering 1500 toward 001400
Flashing buffer to 0x001400
Flashed final page at 001400

Done, the rest is easy.
Start Smart RF Studio from Ti , plug in the CC Debugger and Smert RF Studio will program the device for you. Great!!!

Figuring out how to program the device took me a while, I even killed one CC2511 but once you figured it out all becomes so easy,...
Debugging the chips using the Goodfet is also possible, but Smart Rf Studio is way simpler and has a Gui.
I admit I am lazy,...

CCDebugger board top side

CCDebugger board bottom side

Links:
CC Debugger
Smart RF Studio
Goodfet

Meet the Goodfet v42

The Goodfet is a super versatile tool for debugging and programming.

Once you received your pcb from Trevor you practically only need two integrated circuits and few passives.
The FT232 ic is responsible for usb to serial communication and the MSP430F2618 is the "brain" of the tool.

When the build is completed, simply  plug the Goodfet into a free usb port.
Open a console and enter dmesg to find out where the Goodfet is attached to.

> demesg

[ 4225.304042] usb 2-3: new full-speed USB device number 31 using ohci_hcd
[ 4225.610251] ftdi_sio 2-3:1.0: FTDI USB Serial Device converter detected
[ 4225.610327] usb 2-3: Detected FT232RL
[ 4225.610333] usb 2-3: Number of endpoints 2
[ 4225.610339] usb 2-3: Endpoint 1 MaxPacketSize 64
[ 4225.610344] usb 2-3: Endpoint 2 MaxPacketSize 64
[ 4225.610349] usb 2-3: Setting MaxPacketSize 64
[ 4225.623183] usb 2-3: FTDI USB Serial Device converter now attached to ttyUSB0

In this case it is ttyUSB0

Then edit your environment file and add the following lines:

> nano dev/environment

export board=goodfet42

export GOODFET=/dev/ttyUSB0 

The next step is to save your info file (important!) because after programming it is 

gone.

> board=goodfet42 goodfet.bsl --dumpinfo >info.txt

Use -h for help
Use --fromweb to upgrade a GoodFET.
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)

This is what my info.txt file looks like

> nano info.txt

@1000
aa 55 ff 3f cd ab aa 55 34 12 ff ff aa 55 ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff 8b 86 fe 16 ff ff ff ff ff ff ff ff ff ff ff ff 

ff ff ff ff ff ff ff ff ff ff 08 10 00 80 01 00 d0 81 ba 0b da 0d 04 82 05 07 

4c 08 fe 08 ff ff ff ff ff ff ff ff 01 08 9a 8f a2 8e 95 8d d2 86 
q
 

Next step program the newest firmware to the device

> board=goodfet42 goodfet.bsl --fromweb

Use -h for help
Use --fromweb to upgrade a GoodFET.
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Checking for info flash...  Saved!
Grabbing goodfet42 firmware from http://goodfet.sourceforge.net/dist/goodfet42.hex
Failed to run curl, trying wget
2013-08-01 09:46:07 URL:http://goodfet.sourceforge.net/dist/goodfet42.hex [55933/55933] -> "/tmp/.goodfet42.hex" [1]
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Program ...
19870 bytes programmed.
Programming info flash...

I also programmed the install info created from the info file, tough I am nut sure this step 

is necessary.

> board=goodfet42  make installinfo

goodfet.bsl --speed=38400 -P goodfet.hex -p info.txt || true  #MSP430F2xx targets only, inelegant.
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Changing baudrate to 38400 ...
Program ...
256 bytes programmed. 

Programming is now completed and you should now own a working Goodfet tool.

To be on the safe side lets invoke a self test.

>board=goodfet42  goodfet.monitor test

Performing monitor self-test.
Self-test complete. 

Great a new working Goodfet tool is born.

To see what this tool is capable of lets enter

> board=goodfet42  goodfet.monitor listapps full

GoodFET with f26f MCU
Clocked at 0x8f9a
Build Date: 2013-01-23 16:28
Firmware apps:
Monitor
    The monitor app handles basic operations on the MSP430
    such as peeking and poking memory, calling functions and
    managing the baud rate.

SPI
    The SPI app handles the SPI bus protocol, turning
    your GoodFET into a USB-to-SPI adapter.

MAXUSB
    This allows you to write USB Host or USB Device drivers for
     the MAX3421 and MAX3420 chips.

JTAG
    The JTAG app handles basic JTAG operations such as
    resetting the TAP, resetting the target, detecting
    the instruction register width, shifting bits into
    both the instruction and data registers.

JTAG430
    The JTAG430 app adds to the basic JTAG app
    support for JTAG'ing MSP430 devices.

JTAG430
    The JTAG430 app adds to the basic JTAG app
    support for JTAG'ing MSP430 devices.

JTAG430X2
    The JTAG430X2 app extends the basic JTAG app with support
    for 20-bit MSP430X2 devices, such as the MSP430F5xx Family.

JTAGARM7
    The JTAGARM7 app extends the basic JTAG app with support
    for JTAG'ing ARM7TDMI based devices.

OpenOCD
    The OpenOCD app handles the OpenOCD bitbang protocol.

CHIPCON
    The CHIPCON app adds support for debugging the chipcon
    8051 processor.

AVR
    The AVR app adds support for debugging AVR based devices.

NRF
    The NRF app adds support for the NordicRF register
    interface.

If that is not a powerful tool I don't know what is.

I will add some future blogs showing in detail how to use this swiss army knife of 

programmers debuggers and tools. 

Goodfet42 and Goodfet41

Links:

Goodfet42 

Goodfet hardware developing tools

Trevor Goodspeed is an amazing hacker and hardware designer.

In the moment there are three pcbs available.

First the Goodfet Trevor's signature module.

The GoodFET is a JTAG adapter,  based upon Texas Instruments MSP430 FET UIF
The Goodfet can not only be used as a programmer, but also as an universal serial bus interface.

Second the GoodThopter

The GoodThopteris an opensource Can bus monitor.
The main purpose of this board is to explore Automotive communication buses, currently supporting only the CAN bus. In addition to the Goodfet a high-speed CAN Transceiver and a Stand-alone CAN Controller with a SPI Interface was added. The GoodThopter also allows users to purchase the cheaper OBD2 cables from SparkFun.

And third the Facedancer

The Facedancer is a hardware revision of the GoodFET except unlike the general-purpose GoodFET boards, the only purpose of this board is to allow USB devices to be written in host-side Python, so that one workstation can test the USB device drivers of another host.

I received pcbs from the above modules and will post a more detailed blog entry for each of them soon.



Trevors hardware and software are available under the BSD license, and free-as-in-beer boards will be given to those who ask politely.

Goodthopter Facedancer and Goodfet pcbs

Links:
Goodfet further information
Goodfet Homepage
GoodThopter Homepage
Facedancer Homepage
Ordering blank pcbs 

Complex Programmable Logical Devices

I already gave an small introduction about CPLDs in part III of the 3 Ghz counter build.
Cplds and Fpgas are very interesting devices for those who ever wanted to design their own integrated circuit but could not afford a million $ to let your prototype actually build.

A Cpld consists of the following elements:
Programmable And/Or matrices the macro cells
Programmable feedback
Input blocks
Output blocks

They distinguish themselves primarily in speed and the amount of programmable cells and pin count .
Unfortunately if you need many programmable macro cells the designers assumed you probably need many in out pins too. But many in out pins mean very small footprint and very home brew unfriendly.

So the hobby engineer is restricted to low cell count packages and therefore only small designs.

What are the advantages of a Cpld over a micro controller.
A Cpld can work massively parallel a  lightning speed.
The I/Os don't need a higher level control structure they work just by the logic assigned between an input and an output. They are often used for data capturing and collecting then they transfer the data to a high speed ram and then a micro controller  analyzes the data. Fast oscilloscopes would be unthinkable without high speed logic, micro controllers are ridiculously slow compared to Fpgas.

How to get started ?
Unfortunately programming and designing code for Cplds is completely different to program a micro controller and full of pitfalls.So the best way is to start small and use a simple low cell count target chip.
This is where Dangerous prototypes comes in, they designed two breakout boards based on the Coolrunner II series.One has a macro cell count of 72 and the other of 64.So you wont be able to run an Arm chip design on them but you could use them as multiplexer, inverter, ... You could reproduce the basic logic design blocks with them and combinations of them. You also get used to Verilog the programming language.
Later one if you decided you like the environment you could easily transit to the bigger high cell count Cplds.

To get started I would suggest the CoolRunner II XC2C64A CPLD with 64 macro cells and an Altera Usb Blaster programmer clone from Ebay.

As a first step I would work trough the Dangerous Prototypes tutorial section.

Cpld devboard and programmer

Links:
Dangerous Prototypes Cpld Board
Cpld Forum
Tutorials