Debugging Digital Circuits with a Logic Analyzer

While working with digital systems of various kinds, sometimes we face unexpected behaviors from those tiny embedded platforms. Sometimes it can be a hardware defect and sometimes it's just a bug in our code that runs on those systems. Unlike other platforms such as personal computers and smartphones, debugging these embedded systems is very hard and complicated. In this domain, one important tool that helps the developers to look in to the lower level functionalities of a digital circuit is a logic analyzer.

In our lab, we had a very nice logic analyzer tool donated to us by a past colleague who worked here. The tool is Logic manufactured by Saleae. Today I put my hands on it and tried some simple things to get familiarized with the device. First I programmed an Arduino Uno board to blink its on-board LED connected to the pin 13. Then I connected the Logic to the Arduino board. Ground pin of Logic was connected to a Ground pin of Arduino board. Then, pin 1 of the Logic is connected to the Arduino pin 13 using a jumper wire.

Go over to the download page of the Saleae website and download the required software. In my case, I downloaded version 1.1.15 for Ubuntu 12.04. Simply uncompress the ZIP file and there we have an executable file. I ran it from a terminal by issuing the command sudo ./Logic and the software started up. Connect the Logic device to to the computer using the USB cable and then simply clicking on the Start button will capture the data. Having a 1000 millisecond delay between the turning on and off of the LED, I was able to see the output from the software interface as shown below.

Arduino Uno pin 13 switching with 1000 ms delays

Timing seems very precise. Once the pin 13 became high, it took about 1000.872 milliseconds before it switch back to low. In our program code, the delay was set as 1000 milliseconds. As the second test, I removed the delays placed in the code, That means our LED is turning on and off as faster as the AVR microcontroller can perform. Our logic analyzer says that pin 13 stays about 4 microseconds in high state before it return to low.

Arduino Uno pin 13 switching without explicitly placed delays

I think this device will help me in my future endeavors with digital circuits. Let's see what it will bring to me.

Reference:
[1] https://www.saleae.com/
[2] https://www.youtube.com/watch?v=7OCPWCdg2ys

FM Radio Broadcasting with HackRF and GNURadio

Here's a flow graph which can be used for broadcasting some content of a Wav  file over FM radio frequencies. The original flow graph is from here but it created a lot of missing block errors. So I had to edit it a little bit to make something my own which can be downloaded from here. Since it requires a Wav file, I generated it from a MP3 song file using a tool called Sox as follows.

sudo apt-get install sox

sudo apt-get install libsox-fmt-mp3

sox phillip-phillips-home.mp3 -b 16 phillip-phillips-home.wav

Here's how the flow graph looks in GNURadio Companion tool.

GQRX for Quick SDR Jobs

While GNURadio provides very sophisticated capabilities to implement transmitters and receivers using SDR hardware platforms, it is not necessary to create flow graphs and run them in order to view the radio spectrum. For any quick and dirty requirement to view the spectrum, the easiest way is to use GQRX, which is a receiver program based on GNURadio.

Here's some screenshots of GQRX tuned to various frequencies.

Jamming WiFi Channels with HackRF

We can easily capture signals going in a particular frequency using HackRF and also we can retransmit those data back to the air from the file. Here's how we use it to jam some wifi channels. To try this, first I checked what is the specific frequency channel, which is used by my laptop and the WiFi hotspot to communicated. We can find it out by using the following command.

iwlist wlan0 channel

It should list down all the available WiFi channels and at the end, the channel currently we are using. In my case, it was  channel 11 which operated in 2.462 GHz. Now it's time to try jamming. First we should record some data to a file. We can do it with the following command. The parameter -f specify the frequency we need to tune in to in Hz. Similarly the parameter -s specify the sampling rate which I have set to 20 MHz. Finally the parameter -l specify the LNA gain. Reading man files will provide more information about those stuff.

hackrf_transfer -r test.bin -f 2462000000 -s 20000000 -l 40

This command will run for a while and save data to the file test.bin and stop at some point. Still, the reason to stop in that way is mysterious to me. Anyway, now we have some captured data. We can transmit it back. Before doing so, open a new terminal and ping to some public IP address such as 8.8.8.8 so that we can continuously see the ICMP packets going and coming with round trip information. While having the ping command running in that terminal, run the following command from our original terminal. That -x parameter sets the Tx VGA gain.

hackrf_transfer -t test.bin -f 2462000000 -s 20000000 -x 47

During the time period of above transmission going on, we can see that the ping packets are getting disturbed. Either they take a longer round trip delay or completely become unable to be delivered.

Here's a reference I used,

http://k1fm.us/2014/08/i-finally-got-my-hackrf-and-i-have-a-mac-now-what/