Evaluation Type: Independent Products
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: Melexis, Nordic Semi and Rigol products
What were the biggest problems encountered?: No major issues at all; a rapid response from Keysight helped work through some small bugs
This review is for a “RoadTest Plus” covering a and a . The wireless kit allows for neighbourhood-wide device communication, and the spectrum analyzer allows the solution to be tested. It was a very well thought out combination of products to road test together.
The review covers them both from an Internet of Things (IoT) requirements point of view. The review examines how the development kit and spectrum analyzer will help software and hardware developers to build wireless connectivity into designs. The review starts by looking at what kind of devices IoT projects may require.
Then the wireless offering from Texas Instruments is examined including how to develop hardware and software for it. Finally, the spectrum analyzer is examined to see how useful it is for working with wireless connectivity solutions.
The RoadTest Plus also included a blog-writing portion that can optionally provide more detail into various topics.
First, a quick look at the equipment. The from Texas Instruments is very comprehensive. It contains two main battery-powered boards called Transceiver Evaluation (TrxEB) boards, and 4 small radio boards that plug on top. These small boards are called RF Evaluation Modules (EMs).
The spectrum analyzer is the from Keysight, formerly known as Agilent, originally a part of Hewlett Packard. The analyzer came with CD documentation, USB cable and a calibration certificate, and some ancillary parts shown in the photo below.
The Internet of Things will result in many tens of billions of devices able to communicate on the Internet within this decade. They will be able to be monitored, controlled and configured from anywhere in the world. In many cases the communication will be between devices themselves, with no need for human interaction.
To achieve this there are many wireless technologies that will be used, such as 3G or 4G access for wide area networks but also Bluetooth Low Energy (BLE), 802.11 WiFi and ZigBee for short range communication. The communication will still most likely be packet based, and routers will provide for the packet forwarding to the Internet.
There will be manageability, security and upgradeability problems, and there is work underway to resolve these issues.
The reasons for the IoT to occur are many, and from an endpoint and technology point of view it has only recently become possible to realise low energy compute-capable sensor-rich wireless nodes. At the hardware and physical layer level there have been some important advances in the wireless connectivity space. Radio technology has become highly integrated, greatly reducing the number of components needed to construct IoT devices. This has reduced costs and eliminated manual trimming of circuits. There are internationally well-defined frequency bands available for operation in many countries and this further reduces costs. Radio technology has sufficiently advanced that extremely impressive receiver sensitivity and range has become possible.
Texas Instruments took great advantage of the wireless technology revolution when it purchased Chipcon in 2006 and today it offers an impressive range of wireless connectivity solutions.
The requirements for test tools for IoT are in some ways different to the requirements for earlier wireless technology based products. Back then, technologies like zero-IF and low-IF were considered unfeasible for any reasonable performing devices. Zero IF was relegated to pagers. High performance radio devices were based on a more classic superhet topology. Very low performance devices for control of home devices or toys use utilized cruder methods, such as tuned RF – not really suitable for high performance solutions. In general it can be summarized that the design and test of radio solutions often involved work with analog filters, oscillators, phase locked loops and mixers. It was complicated enough that there was (is) a market for entire modules, to perform the radio function for products.
Today for receivers for digital data, the majority of the radio technology can be part of the integrated circuit. There are no external oscillators or mixers to measure or align. Furthermore it turned out that low-IF technology offered a very good approach for IoT type applications; no high-speed, expensive ADCs are needed and the lower sample rate results in reduced power consumption. The integrated approach means that the tools that are needed in IoT development and test can focus on specific areas of radio technology such as antenna matching and power measurement, if integrated circuits such as the CC110L are used.
Yet it is still possible to obtain quite crude designs today, such as the one shown here; it’s a 2-transistor receiver followed by an op-amp for converting the recovered signal into a digital data stream. This is clearly intended for the hobbyist nowadays, but just a few years ago super-regenerative SIL-packaged receiver modules were commonplace.
The particular board shown above does not have any programmed intelligence and so electrical interference may be converted into a logic level spike, and it is the responsibility of the software developer to implement appropriate algorithms in the connected microcontroller to work around this. In its favour, such a board is still cheap and may be useful for extremely non-critical scenarios like a toy. Beyond this limited scope it has no benefits and would be considered a very low performance receiver that is not suitable for IoT. Often the transmitters are not appropriate either; the example one above can only operate on one frequency because it consists of a just an oscillator (there is no frequency synthesizer here) and no attempt to reduce or remove harmonics. The underside has one transistor as part of the oscillator, and another to perform the on-off keying corresponding to data input.
There is a set of wireless options that are IoT ready (such as the CC110L which will be now discussed) because they are designed to support usable spectrum available today, are low power and provide packet handling features such as buffering and checksum capability built-in.
TI’s CC11xL series offers a low-cost transceiver with good performance, ready to be paired with a microcontroller for IoT applications (TI also offer combined microcontroller and radio devices on a single integrated circuit in their portfolio, but the separate approach can still be attractive depending on needs). The CC11xL series actually includes multiple devices (for example a dedicated transmitter and a dedicated receiver) and the CC110L is the transceiver in the family. In the discussion below, the CC110L can be replaced with just the transmitter or just the receiver if your application does not need the combined capability.
If you did want to deploy a CC110L in your designs, it needs very few additional components (the majority of components you see on the right in the circuit diagram below are for the conversion from differential output to a single-ended output). This circuit was taken from the CC110L datasheet. The connections on the left go to the microcontroller; the interface is SPI as well as a couple of optional outputs intended to be connected to interrupt pins.
The circuit maps to the reference design PCB like this:
As a side note, the circuit above can be contrasted with a circuit using an old (obsolete) integrated circuit which relies on a traditional superhet architecture; the circuit requires an additional 21 components. The circuit below (from a Melexis datasheet) is just to show an example of older technology, not to compare contemporary designs.
As mentioned earlier, the CC110L offers packet handling capabilities. It means that a small 20-pin MSP430 microcontroller is sufficient to run a small radio stack, and this is exactly what is offered by a company called Anaren. However for critical scenarios that require security in the IoT, a larger microcontroller with the resources for the required security protocols could be paired with the CC110L.
In terms of performance, the CC110L offers transmit power capability up to 12dBm, and receive sensitivity of -116dBm at the lower supported bitrates. There are higher performance devices in TI’s portfolio but the CC110L performance is still staggeringly exceptional. In real life tests in a built-up area I could easily maintain connectivity from another street to a CC110L inside my home. It is 16dB higher sensitivity than the Nordic Semi nRF905 which has a similar price.
So, we’ve established that the CC110L is low-cost, high-performance and easy to use in terms of it requiring very few components and having an SPI interface. How would one go about using the CC110L in terms of next steps?
The quickest would be to make use of TI’s development kit and the LaunchPad and BoosterPack ecosystem. They are essential tools for moving forward with the CC110L. The Development Kit provides the reference design hardware for the CC110L on small daughter cards known as RF Evaluation Modules (EMs). This allows you to perform tests knowing that you have a good board layout. If you look closely at the board, you’ll see that it is peppered with holes spaced a certain amount and that certain traces have a particular width. These are considerations that the designer will take into account to have a suitable board capable of operating at the frequencies that it needs to. During prototyping, you won’t initially need to take this effort because it is already done for you with the reference design.
The photo below shows some more detail. The Development Kit has a main board also known as the SmartRF Transceiver Evaluation Board (TrxEB) and you can see one of the Evaluation Modules on the right.
The development kit has enough features (user interface with keypad and graphic LCD, battery powered and general purpose I/O pins) to allow you to test the radio link and create or test protocols before your prototype PCB has been developed. If you already have a development board for your desired target microcontroller then the same radio EM boards can be used by soldering wires onto them (i.e. for SPI connectivity, power suppl, etc). I did this as an exercise to connect one of the supplied daughter boards to a different microcontroller as shown here:
If the target microcontroller happens to be available on a Launchpad anyway, then as another option an EM Adapter board can be used.
The photo below shows the RF Evaluation Module interfaced to a LaunchPad using the EM Adapter.
It is clear that the flexibility is immense, and the CC110L prototyping options further benefit from third party products. Anaren offer a stamp-sized blue-colored module that contains the CC110L and any required components. This is available on a BoosterPack too so it can be used with a LaunchPad, or optionally connect wires to the BoosterPack to use any desired microcontroller development board. The photo below provides some idea of the size of the Anaren module, and the BoosterPack is in the photo too.
To get prepared to develop wireless solutions with the CC110L there should be no hesitation to purchase the development kit and some of the Anaren BoosterPacks and LaunchPads, even if the final target microcontroller is likely to be a different device. The software developers will want to be able to examine and run the demo code before implementing their own code, and so the Development Kit and LaunchPads are still useful. If you are on a budget that does not extend to the Kit, or are initially developing as a hobby project, then the BoosterPack and LaunchPad combination should be purchased, but get the Development Kit too if you need the speediest prototyping option (time to develop may be of the essence in IoT and many other spaces).
Other things that may be needed (such as RF connectors or antennas) are discussed in the blog posts and really depend on how far the intended design strays from the reference designs. Note that the recommended antenna for the 868MHz/900MHz ISM band is usually a PCB antenna if there is space; it offers good performance and is low cost. TI has gone to extraordinary efforts to make life easier for the designer. As well as providing a PCB antenna in the reference design daughter board, not reviewed here, there is a kit from TI that has another 8 antenna designs for these bands. The level of technical information supplied by TI for them is high. This kit too will be near mandatory for those planning to put CC110L projects in production and are serious about performance.
Looking in more detail at the hardware on the Development Kit, for the user interface it contains a 128x64 SPI-controlled LCD display, buttons in a navigation arrangement and some LEDs just above them. The LCD has no backlight fitted, but an optional one can be installed (and a few components need to be soldered in – I may do this, in case I test outdoors into the evenings. What may not immediately be apparent is that there are some on-board sensors available too; there is a 3-axis accelerometer and a light sensor.
The TrxEB is controlled by an on-board MSP430 microcontroller underneath the LCD:
Some more detail:
Note that there is also a mode where you can disable the on-board MSP430 microcontroller, and pass commands from an external PC (connected via USB) to the RF Evaluation Module, through the TrxEB (and for incredible flexibility there is a third mode too, which allows an external microcontroller to be connected up if desired).
The development board has a number of power options, and the one that might be used most often is battery power; the batteries are on the underside of the board:
Through several weeks of testing I have not needed to replace the batteries. It is possible to measure current consumption of the MSP430 and the Radio EM separately, by connecting measurement equipment (such as a multimeter) to jumper pins on the TrxEB. The CC110L itself consumes about 16mA at 3V when transmitting at 0dBm as an example.
This completes the look at the hardware; next, the software aspect is investigated.
The source code for the Develoment Kit, and for the Anaren BoosterPack running on the MSP430 Launchpad are both available. The DK source code is easier to examine; the Anaren code is intended to be a complete framework for projects so will take a little longer (but not much longer) to get up-to-speed. Be aware that the Anaren module has a different frequency crystal inside it compared to the development kit daughter cards, so some of the register programming values will be different.
Like many configurable devices, the CC110L internally has a set of addressable registers. The procedure to operate the CC110L from software is to issue an SPI command to first reset the device, and then additional commands (i.e. addresses and values) to program the registers. That completes the set-up procedure and then finally you can transmit data at any time by writing to a buffer inside the CC110L (again over SPI) and then a single-byte SPI transmit command.
The setup procedure is summarized in the table here; the square brackets  signify the CC110L chip-select line becoming asserted or de-asserted (going low or high respectively), and the SPI bytes while the chip select line is asserted are separated by commas. The red values are fixed values that are register addresses or command instructions.
The register settings define the modulation method, frequency and so on. These values will be specific to your application and can be obtained by plugging in parameter values into Smart RF Studio, TI’s PC software application designed to support development for TI’s wireless connectivity range of integrated circuits. Finally the desired transmission power is programmed into the PA table as shown above. This completes the setup. The above is a very basic configuration but sufficient to get results; it is possible to do a lot more, such as configure some optional output pins on the CC110L to provide information to the microcontroller using (say) interrupt pins. It is definitely advised to make use of the output pins. In my case I configured one output pin to let me know during transmit mode when an entire packet has been successfully transmitted, and another output pin to let me know during receive mode when an entire packet has been successfully received. Once I know that a packet has been successfully transmitted, I can switch to receive mode or transmit another packet for example. Once I know that a packet has been successfully received, I can read the FIFO inside the CC110L to retrieve the entire packet.
So, just to summarize so far, the device needs to be configured as mentioned above, and the process is quite painless because PC software (SmartRF Studio http://www.ti.com/tool/smartrftm-studio ) provides the register values.
Once the device is set up, sending data is simple:
Again this is a simple example and if your packet size is larger than 64 bytes then a procedure needs to be followed to re-fill the buffer during the transmission, when space frees up.
For the simple scenario, the first byte in the packet contained the length of the remainder of the packet.
Receiving data is straightforward too. In this case, a command sets the CC110L into the correct mode:
At this point, it is possible to monitor one of the outputs (e.g. via an interrupt) from the CC110L to know when an entire packet has been received. Once the interrupt is seen, you can read out the entire receive FIFO inside the device. This assumes that the packet length had been transmitted in the first byte, so that you know on the fly how many bytes to read after the first byte has been received. To read the FIFO, the following command is issued, and then dummy writes (e.g. 0x00 as shown below) are issued until as many bytes have been read as were transmitted, and two more for received signal strength and checksum.
Note that there are additional ways of transmitting and getting the data out, for example if the packet size will be larger than the FIFO size. The method described above is the simplest and will work for packets up to 61 bytes in length. Periodically a command needs to be sent to calibrate the CC110L, but this can be automated so that it self-calibrates.
Here is a demo (10-second video) where the Development Kit was used to transmit packets that were received by two CC110L devices on Anaren BoosterPack boards (in this example a Tiva LaunchPad is used instead of a MSP430 LaunchPad). Since they are receiving the same information, they flash their green LED synchronized:
To summarize, it turned out to be a straightforward affair to establish reliable communication using the CC110L modules (RF Evaluation Modules and the Anaren modules) using SPI connectivity to the microcontroller.
Agilent/Keysight offers spectrum analyzers in ranges they have designated HSA (Handheld Spectrum Analyzers, BSA (Basic SA), PSA (Performance SA) and X-series (and there are some older ranges too, still offered). The X-series offers models with higher performance, speed, upgradeability, many built-in measurements and the option to run an on-board software suite known as VSA as well as third party applications, with the in-built x86 based processor.
More than other test instruments, the ability to have in-built measurements capability is highly desirable for spectrum analyzers because RF measurements are complex and unless they are performed by a user regularly there is a high risk of making a mistake. A significant body of knowledge went into developing the algorithms (more than 60 years of built-up knowledge in the case of Agilent/Keysight). These built-in measurements cannot always correct for user error but definitely reduce the risk and makes users more productive; more on this later.
The N9322C BSA is intended for general-purpose spectral analysis but its architecture is far from basic. Older generation spectrum analyzers known as “swept spectrum analyzers” internally looked similar to a superhet receiver, and had selectable intermediate frequency (IF) filters in order to select the bandwidth for power measurements (also known as the resolution bandwidth). These filters were analog, very expensive and were often limited to around 300Hz bandwidth which because a bottleneck for improving the performance of the spectrum analyzer, in particular the noise floor. Then in the 1990’s Agilent (then HP) innovated and implemented the resolution bandwidth filter digitally using ASICs to perform FFT calculations. It provided improvements in noise floor, speed and a better filter shape to allow resolving small signals close-up to large signals.
The N9322C uses a combination of swept and FFT capabilities internally and it results in good to excellent speeds and good performance. It is not as fast as some high-end spectrum analyzers but that’s relative; it’s definitely no slouch. It will wipe the floor compared to pure swept analyzers of course. However for the lowest displayed noise level, as with other spectrum analyzers, expect the update rate to drop.
To get some of the negative points on the table first, in terms of specifications, the dynamic range is not spectacular; it’s very average. The 1dB compression point is -5dBm which is very low compared to other spectrum analyzers, but on the plus side the displayed noise level is around -135dBm (at 10Hz resolution bandwidth) across a good portion of the supported frequency range. The dynamic range is further reduced of course by enabling the built-in preamplifier. Furthermore, the resolution BW filter shape factor, although good at 5:1, is just average nowadays.
For many IoT scenarios the negative points described above are small. Where it would matter is if (say) you were designing PLLs and were interested in measuring close-in noise, or were trying to measure phase noise and needed good dynamic range. Even in these scenarios there are some workarounds although they would involve a more complex workflow and additional equipment such as filters to notch-out the oscillator frequency. However for those use-cases, a PSA or X-series spectrum analyzer should be considered.
As part of the road test a number of measurements were taken using the N9322C. One unusual capability which pushes the N9322C beyond conventional spectrum analyzer functionality is the ability to directly perform reflection measurements. This is a task that would normally either require a vector network analyzer (VNA) or a reflection bridge or directional coupler, cabling and by the time you have everything connected and calibrated, half a day has been consumed. With the N9322C, there is internal hardware to perform the reflected power measurement and it doesn’t require as much time or additional cables. There are lots of uses for reflection measurements and in particular it is useful for measuring how much power is being transferred from the radio device to the antenna.
Other bits of test equipment have also been swallowed up by the N9322C; it can perform modulation analysis that ordinarily would have needed dedicated radio test equipment.
In general the N9322C is straightforward to use. It can be controlled from the front panel or remotely from a PC using the excellent supplied software. The remote software is extremely good, and I found myself using it most of the time. The spectrum analyzer runs cold but does have a very noisy fan; it is quieter than very old HP era spectrum analyzers but then those sounded like a rocket about to take off. In use, if you’ve ever used an older HP or Agilent spectrum analyzer then the display may be near identical in layout since it is almost classic HP style; the screenshot below shows the N9322C display compared with a HP analyzer display.
A screenshot from the PC software is shown below:
A few bugs were spotted, they have been reported to Keysight and they were very prompt at responding personally and promising a resolution.
The PC software allows for the generation of hand-off reports for a customer:
The N9322C has a preamplifier option, and it allows for a displayed noise level extending down to -152dBm (at 10Hz resolution bandwidth) across a good portion of the spectrum. This is great to see; it is extremely competitive compared to other basic spectrum analyzers. The N9322C makes a good radio spectrum monitor with an antenna. It has a built-in speaker for listening to demodulated sound as a quick audio check.
Another good option to consider is the tracking generator (it is mandatory if you require the reflection measurements feature mentioned earlier anyway). A tracking generator allows the ability to provide stimulus into the component or system (i.e. device) under test (DUT). Passive or active circuits such as filters or amplifiers can be analysed for frequency response. The wide range of uses means that a tracking generator is a highly desirable option. One of the blog posts shows how the tracking generator was used to test an amplifier circuit before applying it to a CC11xL series transmitter.
The reflection measurement capability mentioned earlier allows you to perform the main task required when integrating antennas into your design; it allow you to test for a good match for transmitting as much of the available power as you can, and for ensuring that for the receiving circuit as little signal is lost as possible on reception.
There are additional features possible with a reflection measurement capability and the N9322C provides the ability to test cables for faults.
I originally didn’t think I’d use it much, but I was happy to be proven wrong. The spectrogram view is great for seeing dynamically changing signals and frequency drift. Normally one would turn on ‘max hold’ to see the overall envelope of signals that drift or change, but that doesn’t tell you when or how frequently the drift occurred; the spectrogram view does. You can change the color scheme depending on whichever is easier to follow. This is the “finger on the oscillator” test showing temperature dependence of crystal oscillators:
Here is an interesting spectrogram with a track-like pattern:
The spectrogram above is for a frequency modulated (FM) signal, where only a single tone was transmitted at any time but the tone was changed repeatedly. A single tone (800Hz) was transmitted briefly, followed by 1200Hz, and then switched back to 800Hz and so on.
It was also useful for examining the spectrum from the CC110L; here the upper half of the spectrogram shows a 38.4kbps bitrate transmission followed by a 1.2kbps transmission in the lower half.
In many cases you may be legally restricted to transmitting in bursts and leaving the channel clear at other times, so the spectrogram view is useful to examine. The spectrogram update rate is adjustable from 100msec upward.
Where it will be particularly useful is examining solutions that can frequency-hop or operate on multiple frequencies simultaneously. For example, a particular CC110L project is intended to relay packets from one node to another, and the relays could occur on completely different channels. Troubleshooting such a solution will be greatly simplified with spectrogram capability.
Both analog and digital data modulation schemes can be analyzed with this spectrum analyzer. Check out the blog posts for examples of amplitude and frequency modulation analysis and FSK analysis.
The modulation analysis capabilities allow for time-domain views of the demodulated content. The image below shows FM demodulation of a sine wave from a frequency synthesizer, and an eye diagram of a variant of FSK (Gaussian FSK) signal from a CC110L device. A large number of modulation parameters can be directly read off the spectrum analyzer display and an FSK decode capability is possible in the spectrum analyzer too, revealing the bit pattern.
The N9322C has in-built measurement capabilities, some of which are excellent for confirming the bandwidth and power spectral density of a transmission (i.e. a modulated transmission, not just a carrier). There are legal requirements that need to be met for radio transmissions and the spectrum analyzer is extremely valuable here.
Here is an example of occupied bandwidth where the CC110L was transmitting at 250kbps; the display shows (through integration) in a green box 99% of the amount of the power captured in the entire display (it might look like there is still a lot of power outside the green box, but the y-axis is logarithmic of course).
Once you know the bandwidth of the transmission, you can find out the power contained within this channel with a few button-presses:
As you can see, when it comes to measurements (and modulation analysis) the displays can look very different from what is usually expected from a spectrum analyzer. The two images above show the information in two different ways. The display on the right would be useful to see dynamically changing power as the transmitted content is changed. I was expecting to see a power of just under -10dBm (I had set the CC110L for +10dBm output but then passed the output through two 10dB attenuators) and the figure is close (I did not measure attenuation through the system first, each attenuator had an tolerance of +-0.5dB each). To summarize, the measurement features are extremely useful to ensure that data transmissions meet specifications.
Some of the measurement capabilities which will be exceedingly useful for IoT scenarios are the multiple-channel measurements available in the N9322C. This provides a way to test out many simultaneous transmissions. For example, the trace below shows two transmissions (from two CC110L devices) spaced 32kHz apart (to make the measurement clear). It is possible to define the transmission bandwidth and channel spacing and then select one of the transmissions and investigate what the adjacent channel power is.
Another excellent feature is the Channel Scanner feature. It provides the ability to auto-select (e.g. top N) or to statically define channels and then observe the channel power in a bar graph. The example in the graph below shows just two channels configured.
With dozens of devices in a lab this could be useful for immediately viewing what people are working on. A real-time dynamic heat map of channel power can be generated too; the CC110L antenna was detuned by hand to show the heat map capability in the graph above, on the right.
Hopefully this review has provided a useful tour of the Texas Instruments CC110L, its development kit and the N9322C spectrum analyzer.
The CC110L is an easy-to-use high-performance and low cost device that I have been extremely happy to have experienced. The CC110L is ideal for packet based communications at up to 600kbps in an area that could cover a neighbourhood and can be paired with any microcontroller of choice due to the SPI interface; source code is available to directly use it with MSP430 devices and the development kit source code is easy to follow and adapt to other devices if needed. The development kit too is nothing short of spectacular and I found myself using it regularly to test out additional CC110L nodes as they were constructed using the LaunchPad and BoosterPack ecosystem from TI.
The Keysight N9322C provides very valuable features for design and test engineers. The automated analysis and measurement capabilities will be extremely useful when building wireless connectivity into projects, and when scaling up a solution for testing into tens or hundreds of devices then these capabilities will be near-mandatory for rapid solution testing. The tracking generator capability again is a highly desirable option that will find many uses. The built-in reflection measurement capability is a huge time-saver and saves having to create complex setups with external hardware and cables. The remote control options are very good and I found myself regularly using the analyzer in this manner.
Lots of thanks to Element 14, TI and Keysight for their support, and if you’ve made it all the way to the end of this review then I hope you found it useful. Also check out the blog posts for some additional information on the various RF topics, and I hope the road test has provided some solid confidence to move forward with CC110L and N9322C activities if your requirements demand it.
I intend to look at trying out some CC110L after the Forget-me-Not Challenge
I like your helper ...perhaps us minions need to be concerned that you may have gone to the 'dark side' or were you…
I see they called that PCB antenna an Helical antenna is the fact "squashed and is basically the same dimensionas as the depth of the PCB ...Does this make much difference to it's efficacy?
In one of the waterfall figures you change from one bit rate (38.4/1.2? )to another. Can you do that on the fly or do you need to reprogram the registers and do a reset or something similar ?
so CC110L or nordic nRF or eRIC? Bang for the buck wise?
Excellent review Shabaz; I am impressed by the quality, clarity, and neat organization.
Oh, : ( I'm sorry to hear that. The CC3200 has way more configuration and software as I understand. Are you using Windows or Linux?
Also, are you using IAR or CCS?
I too have a CC3200, but I have not started with it yet. I'll send you a contact request, please accept and we can work together on it if you like - it may
help both of us.
By the way I like IAR, but it's too expensive for personal projects (and possibly the free limit may get exceeded with the CC3200 code), so CCS may be
a good option. I have installed the CC3200 tools/SDK in CCS, but not tried it yet.
You put me to shame.
Here I am unable to follow the directions to get my cc3200 up and running and you put together this great post.
Thanks! I enjoy reading through your material too.
The channel scanner in the heat map mode (I called it a heat map, but is referred to by Keysight as a Time Display mode) shows the channel power in color (bright red for high power, blue for low power) over time (alternatively it can do it over distance for a GPS-enabled HSA model analyzer so that it could actually be plotted onto a road map).
In a lab, perhaps this mode could be used by inserting all the channels planned to be used into the N9322C table, so that you can immediately see who is using what. And if you see a continuous high level of output, you know to suggest to someone to keep it inside coax : ) It is much like the spectrogram display, but per specific channel rather than a frequency view which is not channel-aware, and so it doesn't have to cover just a particular part of the spectrum, and also it will show the channel power regardless of the bitrate which may be different per channel, which on the normal spectrogram view would be harder to examine.
Also what could be super-interesting, is if nodes are relaying data (and possibly swapping channels and bitrates) to get it from one location across multiple hops to another, then it should be possible to see that ripple across the channels over time (i.e. near-immediately, unless an artificial delay is added to the processing time in the software, for test purposes). And a response back would be a ripple in the other direction. I'm hoping that idea works out, once I have the CC110L nodes able to swap frequencies and be multi-hop-capable.