This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LPRF Spectrum Indicator

Other Parts Discussed in Thread: CC2511, CC2520, MSP430F2618, CC2500, EZ430-CHRONOS, CC1111EMK868-915, CC2540


Part of my summer internship at Texas Instruments LPRF in 2009 was to develop a spectrum analyzer using the CC2511 and CC1111 as a low cost ($49 or $99 depending on what hardware is needed) alternative to the expensive professional spectrum analyzers out there. This resulted in the LPRF Spectrum Indicator, with the name Indicator chosen to emphasize the inaccuracy of the measurements, which you can find below. Although not perfect in any ways, this little tool can prove worthy for many RF developers out there.

For the CC2511it supports the entire 2.4 GHz ISM band and for the CC1111 it supports 877-973 MHz. The PC side was developed using Qt (

Here is a screenshot of the application:

Download the application here:

Remember to read the instructions in ReadMe.txt

To be able to run this you will need either a CC2511EMK or a CC1111EMK to run the application. You will also need a CC debugger or SmartRF04EB to program the spectrum indicator firmware onto the USB dongle.

The full source for the PC application can be found here (includes notes on how to get started and more documentation):

To compile this you will need Qt, QWT and Microsoft Visual C++ 2008 Express Edition:

Although I’m not considering a lot more development on this, questions, suggestions for improvements or general comments are more than welcome!
Want to develop this further? Feel free to post it here on the community. Known issues and improvements to be made are:

  • There seems to be an offset of 1-4 khz per channel, to the real frequency. Thus, a known peak at 2440 MHz will have an offset of around 150-500kHz when this accords to channel 150 (a little right of the center of the plot). This could be verified by applying a known signal then move the plot so that this peak is drawn at different positions in the plot. At the far left the frequency is correct.
    • Suggested solution:
      Find the connection, a mathematical expression of the offset, and compensate when filling the x-axis, GraphPlot::setTraceData().
  • Start Frequency - RF bandwidth - Channel Spacing
    There are only a discrete number of values valid for the above mutually dependent variables. When the user interacts through zooming, or direct control through the advanced menu, these values are set to the closest valid value in DataManagement. Currently there are internal function calls within DataManagement to keep dependencies valid, as well as signals sent back to the user through adjustments in GraphPlot. These internal calls and signals have a structure which should be improved. The adjustments finally applied might not always appear logical to the user. For example, centering on cursor, as well as zooming, does not always give the intuitive result.
    I've tried to encapsulate as much as possible, but might have ended up with a too complicated structure.
    • Suggested solution:
      Turn the requested change from user into one signal, with only one response. Or keep essential variables, such as Start frequency - End frequency - Channel spacing shared between GUI and DataManagement.
  • In TraceControl::MaxHold when zooming, the first set of samples is not captured by the break argument. This might be because the x-axis is altered, but not fed with new RSSI values. This causes an eventual peak to remain until it is no longer amongst the last TraceControl::m_nofMaxHoldSamples. You'll notice this when zooming on a peak. The problem is that this peak is no shown in the right place.
    • Suggested solution:
  • Only pdf is currently supported as an export format.
    • Suggested solution:
      Change the GraphPlot::export() to find the fileformat from the incoming file name. According to this, do the exporting, f.ex. use QSvgGenerator.
  • A curve's properties can not be changed after being chosen. That is, the properties set when adding a trace.
    • Suggested solution:
      Include a button calling the OptionsCurve dialog.
  • It should be automatically found which virtual serial port the CC2511 is located at.
    • Suggested solution:

Hope you like this.



  • Hi,

    you did an excellent job. I know it is not easy to manage system architecture, signal processing and computing in a single project.

    I am new to ZigBee, I work on a project whose goal is to restore the physical signal at the receiver.
    This work is done by manipulating the MSP430F2618 to program the CC2520, to extract the received signal before the decision on the samples is made.

    I'd like to know if you got to work on this idea to recover the signal, and if you can help me. If you have any idea to suggest it to me.

    Can you send to me your probation report and the documents that helped you with your project.
    Thank you

  • Torbjørn,

    Great work, as you know I am a big spectrum analyzer fan

    When I checked the official release, I noticed that the frequency span of the CC1111 was changed upward. The most interesting ISM bands are around 863-870MHz (Europe) and 902-928MHz) in the US, please make sure that those frequency bands are covered.


  • Hi Svein!

    Will do, it's a minor change, but requires a new build.  

    Considering the current maximum bandwidth coverage of 93.6MHz, what do you think should be the upper and lower limits?


  • Sorry for the delay.  Here's an updated version with the covered bandwidth changed.


  • Hi Torbjorn,

    Thanks for sharing this with us. I just got it all working and it looks like it will be very handy for us working on LPW development projects, even though we have a couple of real spectrum analyzers. Sometimes it's useful to have this little spectrum indicator at our desks without having to bring the big spectrum analyzer over from the lab.

    I am wondering if you are making the firmware source code available somewhere? I don't see it in any of the links you posted above.



  • How do you communicate with the chip?


    Also is it possible for u to make the code used to program the chip available?







    Thank You.

  • Would also really like the source code for the cc1111 if possible.



  • All,

    Will try to locate and post the dongle source code once back from vacation.
    It's really just a tweak of the existing CC1111 USB example code from using the RF_Modem as a starting point.


  • Hi Kjetil,

    It's been a few months since you posted this. Are you back from vacation? Any luck finding the source code for this project?

    Best regards,


  • Sorry..completely forgot about this one.

    Attached the FW. Please note that this is a mess and was never intended for distribution (little effort was put into commenting and documentation), but hopefully you will find it useful anyway.

    If you have questions you can try posting here, but I did not write this so might not know the answer.

  • Thanks, Kjetil.

    I just thought it might useful for us to port the code to a different platform, like one of the msp430/CC2500 eval boards that has an SMA connector on it so that we have the option of connecting with a cable. It isn't a high priority so I am not sure when we'll get to it but if we have the source code then maybe when we have some spare time we could work on this.




  • Hi,

    Dear Torbjorn Sorby,

    bug report: LPRF Spectrum Indicator software i testing with CC1110 

    CC1110 default working: 868 and 433 Mhz


    Please LPRF Spectrum Indicator software USER INTERFACE OPTIMIZING and recompiling for 868MHz and 433MHz. 

    (i testing LPRF Spectrum Indicator software in 868Mhz RF range = software user interface view area not good 868Mhz RF range)

    Please correcting the software user Interface for beter working: CENTERED VIEW AREA: 868 or 433 Mhz (default RF ranges)


    Hortobágyi Gábor







  • Hi Gábor,

    Thanks for noting this. Would not expect this to be fixed and re-posted anytime soon, but the full source and explanation on how to re-compile this yourselves is contained in  previous post. Feel free to give it a shot yourself


  • View adjustable LPRF Spectrum Indicator II. (433MHZ - 2,4GHZ)


  • Hallo,

    I flashed the spectrum indicator firmware onto my CC1111 usb dongle I got with the EZ430-Chronos 433MHz. But the usb dongle will no longer recognized.

    When I flash back the Access point firmware or the sniffer firmware it will recognized, so the hardware is all right.

    Is there a bug in the firmware or does it not work with this usb dongle and I need the CC1111EMK ?

  • Hi Harald,


    I'm afraid the CC1111 that comes with the EZ430-Chronos kit is using a different pin-out for some GPIOs. Hence one has to update the firmware.

    The source code for the firmware has been made available as of November 17th 2010 in a post in this thread. What has to be changed is the ioCC1111.h and any other io config file.

    When I have the time, I'll have a look at it. Please post a reminder if weeks pass.


    Best regards,


  • Hi Torbjørn,

    thanks for you reply.

    But now I have a bigger problem. My CC1111 access point don't work any more. I can't get flashed back the access point firmware. Now I think the device is damaged because a few days before I re-programmed the access point firmware several times without any problems.

    Do you know where I can order a new CC1111 access point 433Mhz?


    kind regards


  • If you have not been using the CCDebugger to reprogram your device, please see section 4.3 of Or read one fifth down the page.

    Unfortunately the CC1111EMK 433MHz does not exist. This exact dongle is only available in the EZ430-Chronos kit.



  • yes I just used another programer. But what do you want to tell me with these links? that I have to use the CCDebugger? Even if it works before with the other programer.

    I'm confused what's my next step to solve this problem. If I buy a cc debugger and it turned out the cc1111 is truly damaged, I have no more usage the cc debugger. If so I'm better in buying a second watch which includes a new CC1111 433Mhz.

    If I had known this before, I never bought the 433Mhz model. Maybe TI has any plans on building a CC1111EMK 433MHz?



  • Hi Harald,

    If you have another programming solution that works reliably, you don't need the CC Debugger.

    So what exactly stopped working? The programming of the device itself?

    I'm not saying that this has happened, but it might be that the CC1111 device has been damaged (e.g. due to ESD or something else). You can get free CC1111 samples from TI and try to replace the device on the dongle.

    You could of course get a new kit. There are no plans to make a CC1111EMK at 433 MHz, but if it had existed, the resale price would most probably be $49 (just like all the other dongles we have) - which is exactly the price of one Chronos kit.

    BTW - as someone else has noted already - the only difference between e.g. the dongle in the CC1111EMK868-915 kit and the Chronos Access Point dongle that has any impact on software, is that the former uses P1.0 as D+ pull-up, whereas the Access Point dongle uses P1.1. So the software fix should be quite straight forward.

  • Hi,

    the programming of the dongle stopped working. I programmed the dongle several times without problems and from one day to the other the programer can't detect the device any more. The Chip ID is allways detected as unknown. I've tested the dongle more intensely and I'm pretty sure that the mcu device is damaged.

    But thanks for your advice to the free sample order possibility. I will replace the mcu device on the dongle.

  • Hello,

       I'm putting together a simple manufacturing test system whereby I'd like to measure the transmitted power level from a 2.4GHz RF module. It will be transmitting carrier only, so any 2.4GHz IC should be able to see it. Would the firmware here be able to give me the RF output at a particular frequency that could be parsed by a PC application?




  • Hi,

        Was anyone able to make the Spectrum Indicator to work with the FW source code posted here? I was able to use the precompiled .hex file. When I use the firmware generated from the source code, all I could do was to open the port. No further communication between the host and the dangle was working. I could not get ACK for calibration. It seems that the communication on EP0 was OK, or I wouldn't be able to open the port. I'm not sure about all the other EPs.

        If anyone made it to work, could you please share your experience?

        Thanks in advance for any information.



  • Hi George,

    It doesn't work because this firmware enables flow control. If the windows host driver is setup correctly it will respond correctly to the 0x22 class request. If the setup value is non zero RTS will be set TRUE and the green LED lit. This doesn't happen on my current Win7-64bit platform, so I have the same experience as you with this firmware.

    You can disable flow control in the firmware. Go to the function usbUartProcess() in usb_uart.c and comment out as follows:

    void usbUartProcess(void)
        // Process USB events

    //    if (cdcCTS && cdcRTS) {

            // Process USB OUT data (USB -> RF)

            // Process USB IN data (RF -> USB)
    //    }

    Doing this makes the firmware work without flow control enabled on the host side.

  • Hi Torbjorn,

        Thank you very much for your answer. It solved my problem. Can I assume the precompiled .hex file was also compiled with the flow control disabled?

    Best regards,


  • Hi George,

    That may very well be the case. I developed this software as a summer intern a few years ago and can't remember the details.

  • Torbjorn,

    Nice project!

    Its been a few years, some of the info is old, and some of the MS suggested build-packages are outdated et cetera. Can you update this?

    The driver install method for the dongle do not work with win7 (x86_64)  but happily the OS found a way to install a driver.

    Some features in the program could make it behave more like a typical spectrum analyzer, max hold infinite, removal of markers possible, even resolution intervals (possible?), start-, stop-, center-frequency, sticky port setting, no crashing when changing to ridiculous settings, and a waterfall plot would be nice.

  • Hi
    Fantastic job !
    Don't you have a firmware to use a CC2540 USB dongle rather than CC2511 ?

  • Hi Jerome,

    I don't have bandwidth to do just that. However, I'm tempted to create an interface to our new CC26xx device. Maybe something will pop up there in a couple of months!

    The serial protocol is described in the documentation for the tool. So, if you want to create one yourself you could start with any CC2540 project that implements the USB-CDC driver.

  • Dear Torbjorn Sorby,

    You have done an extraordinary work making a spectrum indicator. I really appreciate your effort and sharing the knowledge with us. Exceptional Job mate!!

    I need to know one thing is it necessary to install and run qt and qwt if the application ( already runs and it shows the spectrum between 877-973 MHz for cc1111 usb dongle. 

    If no then please tell when is qt and qwt needed in making of the spectrum indicator.

    Hope you reply. I totally new to qt and qwt stuff...




  • Hi SIB,

    The installer should install necessary Qt .dlls to execute the application, and it sounds like it works for you. However, if you want to continue development of the Spectrum Indicator, then you'll need the full Qt and the Qwt extension.
  • Thank You for your reply! Torbjorn!
    You mean that if I want to develop and edit the LPRF Spectrum Indicator Application that shows the spectrum itself only then I should go through Qt and QWT installations?
    For instance if I want to apply this GraphPlot::setTraceData() so will I be needing anything else other than the app itself like qt and qwt??