2.4 GHz Spectrum Analyzer w/Chipcon(TI) RSSI

Yes, you can take a Chipcon/TI transceiver that has a register for RSSI measurements and create a low-cost spectrum analyzer.  I have done just such with the CC2420.  Basically all you have to do is cycle through the carrier frequencies you want to measure, stopping at each frequency for at least 8 symbol periods to enable the RSSI to be read, read the RSSI (send to PC or display), and move to the next carrier frequency.  If you are familiar with the transciever, this is a rather trivial task to do and creates a very valuable resource if your resources are limited.  My design can clearly display the spectrum from transmitting Chipcon transceivers as well as the background 2.4GHz traffic from wireless internet services.  It measures both modulated and unmodulated (single carrier) spectrums.

The spectrum analyzer will be limited to the bandwidth and frequency spacing of the chip transceiver that you use.  In most cases, it should cover the entire unlicensed 2.4GHz range with 1MHz spacing.  I did notice that at least one of the newer chips does have smaller carrier frequency spacing, if necessary.  With the design I quickly developed, I can scan from 2048MHz to 2550 MHz at 1MHz spacing with an update rate of about 10Hz.

RFCE,

Can you make your code available?  I don't know how users can upload files to this forum - I've looked and I think you have to be a TI-er to do so (I wonder if they will extend to ex-TI-ers...?) -
so if you don't have a place to post - I can give you a ftp login on my site and I will alternatively post there and then post the URL here.

I think more people than me will be interested in this - and since RSSI is so sensitive on these parts - if all you want to look at is the ISM band at 2.4GHz - this is adequate.

Once upon a time I played with RSSI in a very enclosed space and plotted on a graph - I could tell if someone was just moving their mouse on a PC in a small space!  Yet another application of RSSI - motion detection.

Thanks,
john

I wrote the code within the TinyOS (Open Source Wireless Sensing Operating System) as I set it up on a Tmote Sky node, so it may be difficult for anyone to use it directly if they are not using TinyOS.  The application basically reads the writes the frequency to the control register, then reads the RSSI register and sends to out on the UART (UART-USB chip is on the TmoteSky for VirtualCOM port) .  The main loop though is very simple and looks like:

      U1TXBUF=0xFF;                              //Set as a Start of Frame Byte to indicate beginning of string of RSSI values
      while((U1TCTL & 1)==0);            //Wait for UART to be ready
      for (freq=2048;freq<2560;freq++){
        call RadioControl.TuneManual(freq);
        RSSIm = (call HPLChipcon.read(CC2420_RSSI));  //on first call, the RSSI is almost always not valid yet, so we read the register again
        RSSIm = (call HPLChipcon.read(CC2420_RSSI));
        U1TXBUF=RSSIm;    //send out measurement to the Virtual COM Port
      }

I developed a LabVIEW interface to parse the incoming data and plot it on a graph against the frequency.  The application also stores the max value received across all frequencies and plots it on the background of the graph, which is very helpful in defining the shape of modulated spectrums.

I have essentially dropped TinyOS and have begun developing strictly with CCE, so I will likely have a code more people can use soon.  As a Civil Engineer by trade, I found TinyOS to be a good starting point a few years ago, but now I am at the point that I want to write all the code by myself so that I know exactly what/how everything is being done within the MCU.  I anticipate developing a new CC2420 or CC2520 platform, and when I do I will write the code for the spectrum analyzer in CCE and uplaod it.

RFCE,

I also used TinyOS to do the RSSI experiment that I mentioned above.

Thanks for posting - that is simple enough.  I modified the Oscilloscope app that TinyOS has to plot the graph I spoke of previously.

As you know - it isn't straight-forward to get new drivers done for TinyOS - this is one reason why I dropped it - plus it isn't really 'real-time' either if that is what you need.
Adding a SPI Interface for a peripheral isn't straightforward in TinyOS - at least that is my latest understanding.  I haven't looked into it lately - you used to have to request something like that to be added and then 'hurry up and wait' - it was quicker for me to write it myself since I thought keeping control of the 'physical layer' by those in charge of TinyOS was a bit silly.  I don't want to give the impression that I think TinyOS is trivial - I think it is a great idea and I commend those that have worked on it and have spent so much time on it - but there needs to be an easy way of adding new drivers.

I am an EE - what state are you in if in the US - in California - Civil's reign supreme.

I will also take a look at what I have and I think it will be somewhat easy to develop something that plots out a 2.4MHz spectrum.

Thanks,
johnw

RFCE,

Also - looks like the CC2500 is an ideal choice for this application - I have several of these 'in stock' - I will work on this since I am interested to see how well it works - it also has a resolution that is sub-1MHz - 427kHz according to the datasheet.

I'll post what I come up with as well.

Regards,
johnw

I agree, the CC2500 would be optimal as it provides the best frequency resolution.   I had much of the same issues with TinyOS that you enumerated.  Arbitration of the communication interfaces was a hassle and seemed to me to only be a benefit if you didn't want to get your hands dirty and actually look into the microcontroller peripheral functions and registers.  I needed real-time in my applications, so it got to the point that I was writing register level code for just about everything I did, so eventually I figured why use TinyOS basically as just a compiler/environment, when I could use CCE to compile and debug, and I could also just use straight C programming rather than nesC.

BTW, I'm in NY, where Civil is popular, but no where near like in CA.

RFCE & JohnW,

Check out the Spectrum Analyzer we have added to the latest CC2520 SW Examples. This can give you some ideas for a port to the CC2500 and RF2500 etc. (Have seen this?)

• CC2520 Software Examples (Rev. A)(swrc090a.zip, 692 KB )
             19 Sep 2008 zip

I subscribe Circuit Cellar, and they had an article on a spectrum analyzer with CC2500. We just need to replace the Atmel AVR micro and the Silicon Labs (UART to USB) with an MSP430 and TIUSB34xx. You can actually use CC2511 even maybe.

    Article from Circuit Cellar:

    http://www.circellar.com/library/print/0406/Armitage-189/Armitage-189.pdf

LPRF Rocks the World

LPRF,

No - I haven't seen it but I will take a look now that I know.

Yes - I saw the design in Circuit Cellar too - had similar thoughts as yours regarding this design.

Thanks!
johnw

JohnW,

Excellent, your ideas are always welcome here.

LPRF Rocks the World

[:D] spectrum_analyzer v1.0  use CC1111 or CC2511

http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=3240297&bbs_page_no=1&search_mode=3&search_text=qingwei_cui&bbs_id=9999

example[base on CC1111 dongle]:

cui,

Cool. That spectrum analyzer looks like a nice demo application. I am not able to read Chinese, but from the screenshots you seem to get quite good frequency resolution. I like the simple demo which allows you to toggle the LED too :-)

Posts 67: thanks [:)]

That Spectrum Analyzer looks really nice. Great work!

Also see http://metageek.net/ 

Dear RFCE,

I am very interested in your work of using LabVIEW to parse the incoming data. In fact I have tried it but the reading process is not stable (there is a data loss in every 5 times). When I tried to use "instrumentation assistant" function, data appeared to the PC after timeout. Then I have tried using seiers port funtions to read data, but it is not very stable. Could you please help with your LabVIEW codes?

Best wishes,

Alex      

Use the LabVIEW VISA library functions for the serial port to read the incoming data.  Make sure you follow the proper Labview use of these funcitons, ie. with regard to opening and closing the port access, port configuration, buffer handling, reading data, etc.  The function to read the number of bytes in the serial port buffer is very nice to use as well so that you can tell the read data call to only read data that is available.  Then you will have to build a loop to parse the data from the packet/message format you built in your application to pull out and convert the measurements (use the string library).  It helps to frame your packets and use a length field so that you can perform this loop on individual packets.  Good luck

Thanks for your quick reply.

My LabVIEW codes include open, close and error checking (sorry for could not manage to paste in this box). The question is, when I write from LabVIEW to the USB, it is error free while when I read from the USB there are some data missing. The reason I think maybe when you write from LabVIEW to the USB, the USB dongle receive the data in the real-time mode and when you read from USB dongle the LabVIEW running under Windows operating system is not working in real-time and cased data missing.

I can arrange re-reading in LabVIEW after I get error message, but I am just wondering if you suffed from the same problem. If not, can you provide your email address so I can send my LabVIEW codes for a quick check?

Best wishes,

Alex

The USB dongle is actually implementing a Virtual COM port, which like a traditional serial port has a FIFO buffer, so you don't have to read the data with Labview at the exact instant that it is being sent from the dongle.  When the data is recieved from the dongle, it is placed in the buffer and the Labview serial com read call just pulls the data from that buffer, so it does not matter that Windows is not a real-time OS.  Either the dongle is not sending all of the data you are anticipating, or something is configured wrong in your Labview app so that the data is discarded or the port is not configured correctly.

What are the details of the error message?

Have a look at the following:
https://community.ti.com/forums/t/12043.aspx

Spectrum "Analyzer" running on the CC2511 or CC1111.

hey i can't seem to access the link u gave in this thread. Can you give me a link that is currently working or some design information used in this project, I am looking into making a spectrum analyzer with the cc2511 dongle and wanted to have a look at your code and design notes. Thank you.

Here it is:

http://e2e.ti.com/support/low_power_rf/f/157/t/17252.aspx

Can you please make your code avaiable for other users like myself who are very interested, your help will be greatly appreciated.

Adrian, the link above contains full source. Only thing missing is the code running on the CC2511 itself, but it does not do anything special. All intelligence and computing is done at the PC side. The CC2511 use the CDC / RF Modem example of the CC2511 USB Library and example code as a basis.