Has any one worked with CC1101

hi...
what do you want to know?

regards
roshni

Thanks for the response.

I would like to know what was the maximum transmission distance you were able to achieve with this.

Hi,
CC1101 868MHz with monopole antenna we got around 400-500mtrs( with case and LOS).

regards
roshni

Thank you very much.

I am also working with same band,868.

what about if there is no LOS and a worst case scenario.?

Have you used external Power Amplifiers and LNA?

hi,
worst case we can achieve about 300mtrs with 10dBm power. i have not used any of PA and LNA. If u are looking for longer range use CC1190 range extender which
has bulit in LAN and PA.

regards
roshni

Take care about one important parameter that is the data rate/freq deviation (and the relative receiver bandwidth).
Working with low data rates the RX sensitivity varies a lot, so the achievable range is very different if you have 1kbps or 250kbps.

Which kind of application are you working on?

Mazz

Hello

The RF environment and required reliability of the radio link has large influence on useful range.

When you are in a static multi-path situation with omni-directional antennas, you may have to include a 30 dB margin to have (for example 99% connection).

When you use a polarization or space diversity scheme you can reduce your margin.

In a mobile environment in combination with retransmission you can also reduce the margin (increase useful range).

Interference from other source may reduce useful distance (think of a high efficient SMPS chip on the same PCB). In case of point-to-point links, directivity (antenna gain) helps to increase the useful range.

I am seeing just what you said. I have not found a proper combination of Deviation/RX Bandwidth/Data Rate that gives me anything like the receiver threshold numbers they post in the data sheet. I am actually getting 10 to 20 dB worse thresholds than expected (see attached data). Is there some magic set of parameters that work best with the CC1101 firmware to achieve those low specified receiver thresholds, or is the data sheet really that far off! I am getting thresholds in the -72 dBm range when the data sheet says I should be seeing -95 dBm!

I guess you also asked your TI FAE about the issue but didn't yet get a response?

The expected sensitivity numbers seem reasonable, according to the datasheet and also related to competitor's specifications. Im planning to use CC1101 for a design, but didn't yet start it. Thus I can't compare your results with own tests, but they are valuable for me in any case.

Yep, they blew me off bigtime! Would think they would be interested in a 20 dB discrepancy.

I got some more RF boards in yesterday, and will test them on the slim chance that I damaged the two boards I had been testing. At these threshold levels, I can not use this chip in the application I was planning, and will need to find something else.

The test I was doing involves the Chipcon evaluation motherboard, where you program the Master board to run the packet error rate test for a given set of parameters, and it sends that info in a header to the slave board, and then begins minute long 2 way packet error rate test. I was wondering if this header information programming of the Slave board is what is hanging me up. Maybe if I ran my own PER test, instead of the canned one, where I have Master and Slave boards hooked up to two different PC's (via the USB cable) if I can get better RX threshold values?

Those are about the only things I can think of right now. I'll let you know if either of them helps.

I guess the problem is:
Test1: I guess the data rate is 250KBaud/s, not 250KBaud. i.e. 250KB/s=250K*8bit/s=2Mb/s.
For GFSK, the freq spectrum effiency is 1bit/s/Hz, so the signal bandwidth should be 2Mb/s/1bit/s/Hz=2MHz. Try to increase the RX filter bandwidth to 1M, 2M, 2.5M etc. to see whether the sensitivity changed or not.

---------- Post added at 00:39 ---------- Previous post was at 00:31 ----------

I never used CC1101, I don't know its software protocols. But according to my experience on Microwave point to point equipment, both terminals should config separately.

---------- Post added at 00:51 ---------- Previous post was at 00:39 ----------

And the transmit spectrum bandwidth should be checked, measure the 99% energy bandwidth?

tony_lth

for this device kbaud means kbit, so biff44 is using correct settings.

biff44

I have the smartRF development kit with cc1101 and I know this device.

Do some test outside the EMI: usually it is not needed to isolate the device. You can understand if it is affecting the measurement.

The master does not tell anything to the slave about the test to be done (at least in SmartRF04, the one I have), as the two eval board are not connected together.

See what happens during test in RX display. It can help you understand.

I didn't understand very well if you have done tests using SmartRF studio or the eval board joystick.

I hope it can help.

Mazz

The comment is inappropriate in many ways.
Baud is always measuring a rate, not only in this specific case. (see Baud - Wikipedia, the free encyclopedia), so kBaud/s would be an incorrect term anyway. As Baud is referring to a symbol rate, strictly spoken, it may convert to a multiple bit rate with specific protocols, but not in this case. Finally, no license free sub GHz radio protocol is able to achieve Mbit/s rates, because the available bandwidth isn't sufficient.

Sorry, I should have been more clear in that attached memo.

For GFSK or 2FSK, 250 KBaud/sec=250 KBit/sec data rate.
For the 4 FSK, 125 KBaud/sec/=250 KBit/sec.

The memo was aimed at a TI app engineer's understanding, and that is how the list the data rates in the CC1101 specification sheet.

Just an update. I have set up the Packet Error Rate test a different way, and am happy to report that the CC1101 chip is now performing much more like the data sheet says it should. I am getting somewhere in the -91 to -95 dBm (have to calibrate more carefully to be sure of the value) threshold for 1% packet error rate at 918 MHz, GFSK, 250 kbaud=250 kbps rate.

Apparently, the "canned" 2-way PER test that you can program into a master board, and that board wirelessly sends the test info to a slave board, using the Chipcon EVAL boards, is the culprit. That software works poorly for some reason. If you ran that test, you would erroneously get worse thresholds than the data sheet says you should.

You need to do a one-way only test to get better data.