CC1101 RF Transceiver Chip Issue

[Mechatrommer]

I bought several RF boards from ebay which is RF Transceiver Module. http://cgi.ebay.com.my/433MHz-RF-Transceiver-CC1101-Module-Antenna-/110498332778?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item19ba36c06a.

After weeks of coding i managed to transmit some binary/wave out of it. Using the same register setting in Receiver as the Transmitter, i think there should be no problem receiving the data by another RF module (same board), but... NO. i'm not receiving anything. some interrupt pin should go high when there is data, but it wouldnt do that, while data is transmitted from the next board.

So here i seek help from people who are familiar with RF system if there is/are issue i'm missing out. I saw alot of RF jargons in the CC1101 datasheet that disturb my brain so badly... such as  balun, synchronizer, RSSI, CCA, FEC etc. But i dont think i'll need the detail description on all those jargon. The only thing that i want to know... What is more likely goes wrong in my code/register setting? Is there any Frequency mismatch issue? timing or whatever? i dont know!

FYI: The RF Chip is using the same analog circuit (L and C) (balun?) to transmit and receive (Johanson Technology? i dont know, another jargon), so 2 same boards should have no hardware issue right? they should compatible and communicate as transmitter and receiver. And i'm interfacing the RF Module with pic16f690.

Any idea?
pls help.
thanx

[TheDirty]

When I was going through RF transceivers I tested the CC2500, but I used TI's SimpliciTI stack.  Like you've found out, these are not simple transceivers.  They're meant for more advanced mesh networks.  If you want a nice RF transceiver that's much more simple to use, you should try out the HopeRF RFM12B's.

Nobody can help you since you didn't post your initial register setup for the CC1101.  Even then, I doubt I can help.

Try TI's SmartRF Studio.
http://focus.ti.com/docs/toolsw/folders/print/smartrftm-studio.html

[mikeselectricstuff]

I recently did a project with the CC2500 - one thing that caused some confusion is the config data generated by the TI software puts some not-very-sensible default values in some of the registers - not the frequency/channel/datarate   stuff, but the operating modes, fifo config etc. - I don't recall the details, but check all the register settings very carefully against the datasheet.

They work fine as simple transceivers, although they also have some extra bells & whistles, and things get somewhat more complicated if you want to send packets longer than the fifo depth.
One thing that impressed me was the tx output power was completely constant down to a battery voltage of about 2.2v

[Mechatrommer]

@mike.
i'm currently in early phase where i want to make the RF comm working properly. i only want to send a single byte. and i dont even bother about the data yet. even the receiver cannot detect any incoming preamble and synch word. (interupt pin should go high upon receive of preambles)

@dirty
even some registers jargon are strange to me. i only fine tune some register that i understand... others, i leave to SmartRF Studio to generate default value based on the 433MHz for the board design (by hardway i found out its actually 434MHz) its up to the point where i think i need the SmartRF04EB development board to test the signal out and in to see what RSSI level is at (another evil jargon i think). But the dev. board is nowhere to be found except from TI... and they are not selling it as single, they sell in one package ie 2 dev. boards, 2 rf boards etc at $499. enuf to make my eyeball start to fall from its socket.

ok here is my setting (value from SmartRF Studio). i've try GFSK, MSK, ASK/OOK, but the behaviour is still the same, i only change the Base Frequency from the existing template. this is one of the setting:

[Mechatrommer]

default SmartRF Studio Setting:
refer to setRadioReg MACRO:

;////////////////////////////////////////////////////////////////////////////////////////////////
;// setRadioReg CC1101_@RN@, 0x@VH@
;////////////////////////////////////////////////////////////////////////////////////////////////
;// Deviation = 47.607422
;// Base frequency = 433.999969
;// Carrier frequency = 433.999969
;// Channel number = 0
;// Carrier frequency = 433.999969
;// Modulation format = ASK/OOK
;// Manchester enable = false
;// Sync word qualifier mode = No preamble/sync
;// Preamble count = 4
;// Channel spacing = 199.951172
;// Carrier frequency = 433.999969
;// Data rate = 249.939
;// RX filter BW = 203.125000
;// Data format = Synchronous serial mode
;// Length config = Infinite packet length mode
;// CRC enable = false
;// Packet length = 255
;// Device address = 0
;// Address config = No address check
;// CRC autoflush = false
;// PA ramping = false
;// TX power = 10

optimizeRF1100SE:
    call        optimizeSleep
    call        optimizeNonSleep
    call        optimizePatable
return

;saved registers after sleep
optimizeSleep:
    setRadioReg CC1101_IOCFG2, 0x0B
    setRadioReg CC1101_IOCFG1, 0x2E
    setRadioReg CC1101_FIFOTHR, 0x07
    setRadioReg CC1101_SYNC1, 0xD3
    setRadioReg CC1101_SYNC0, 0x91
    setRadioReg CC1101_PKTLEN, 0xFF
    setRadioReg CC1101_PKTCTRL1, 0x04
    setRadioReg CC1101_PKTCTRL0, 0x12
    setRadioReg CC1101_ADDR, 0x00
    setRadioReg CC1101_CHANNR, 0x00
    setRadioReg CC1101_FSCTRL1, 0x12
    setRadioReg CC1101_FSCTRL0, 0x00
    setRadioReg CC1101_FREQ2, 0x10
    setRadioReg CC1101_FREQ1, 0xB1
    setRadioReg CC1101_FREQ0, 0x3B
    setRadioReg CC1101_MDMCFG4, 0x8D
    setRadioReg CC1101_MDMCFG3, 0x3B
    setRadioReg CC1101_MDMCFG2, 0xB0
    setRadioReg CC1101_MDMCFG1, 0x22
    setRadioReg CC1101_MDMCFG0, 0xF8
    setRadioReg CC1101_DEVIATN, 0x47
    setRadioReg CC1101_MCSM2, 0x07
    setRadioReg CC1101_MCSM1, 0x30
    setRadioReg CC1101_MCSM0, 0x18
    setRadioReg CC1101_FOCCFG, 0x1D
    setRadioReg CC1101_BSCFG, 0x1C
    setRadioReg CC1101_AGCCTRL2, 0xC7
    setRadioReg CC1101_AGCCTRL1, 0x00
    setRadioReg CC1101_AGCCTRL0, 0xB0
    setRadioReg CC1101_WOREVT1, 0x87
    setRadioReg CC1101_WOREVT0, 0x6B
    setRadioReg CC1101_WORCTRL, 0xFB
    setRadioReg CC1101_FREND1, 0xB6
    setRadioReg CC1101_FREND0, 0x11
    setRadioReg CC1101_FSCAL3, 0xEA
    setRadioReg CC1101_FSCAL2, 0x2A
    setRadioReg CC1101_FSCAL1, 0x00
    setRadioReg CC1101_FSCAL0, 0x1F
    setRadioReg CC1101_RCCTRL1, 0x41
    setRadioReg CC1101_RCCTRL0, 0x00
return

;not saved after sleep
optimizeNonSleep:
    setRadioReg CC1101_FSTEST, 0x59
    setRadioReg CC1101_PTEST, 0x7F
    setRadioReg CC1101_AGCTEST, 0x3F
    setRadioReg CC1101_TEST2, 0x88
    setRadioReg CC1101_TEST1, 0x31
    setRadioReg CC1101_TEST0, 0x09
return

optimizePatable:
    call        openCommCCRadio
    sendRadio   CC1101_PATABLE | CC1101_BURST
    sendRadio   0xC0
    sendRadio   0xC0
    sendRadio   0x00
    sendRadio   0x00
    sendRadio   0x00
    sendRadio   0x00
    sendRadio   0x00
    sendRadio   0x00
    call        closeCommCCRadio
return

[Mechatrommer]

later in the code, i further fine tune the parameter to suit my needs:
and FYI, i believe i got no issue with the errata:


;-----------------------------------
;fine tunning radio parameter
;-----------------------------------

;complete transmission interrupt notification
setRadioReg     CC1101_IOCFG2,      0x06

;close in rx = 18dbm, fifo threshold tx=33, rx=32
getRadioReg     CC1101_FIFOTHR
andlw           b'11000000'
iorlw           b'00110111'
setRadioRegW    CC1101_FIFOTHR

;our unique synch word
setRadioReg     CC1101_SYNC1,       0x57 ; 'W'
setRadioReg     CC1101_SYNC0,       0x52 ; 'R'

;maximum allowable packet length
setRadioReg     CC1101_PKTLEN,      0x01

;disable crc autoflush, no append status, no address check
getRadioReg     CC1101_PKTCTRL1
andlw           b'11110000'
iorlw           b'00000000'
setRadioRegW    CC1101_PKTCTRL1

;whitening off, FIFO RTX mode, CRC disabled, fix packet length
setRadioReg     CC1101_PKTCTRL0,    b'00000000'

;dc blocking, no manchester, 30/32 preamble synch word
getRadioReg     CC1101_MDMCFG2
andlw           b'01110000'
iorlw           b'00000011'
setRadioRegW    CC1101_MDMCFG2

;disable FEC, min preamble=8
getRadioReg     CC1101_MDMCFG1
andlw           b'00001111'
iorlw           b'01000000'
setRadioRegW    CC1101_MDMCFG1

;back to idle after complete TX/RX
getRadioReg     CC1101_MCSM1
andlw           b'11110000'
iorlw           b'00000000'
setRadioRegW    CC1101_MCSM1

;autocal from idle, pin ctrl disabled, xosc force sleep on
getRadioReg     CC1101_MCSM0
andlw           b'11001100'
iorlw           b'00010000'
setRadioRegW    CC1101_MCSM0

[Mechatrommer]

if asm is a problem for you. just consentrate on some friendly macro:
setRadioReg(a,b) = set the CC1101 register a to value of b
getRadioReg(a) = get CC1101 register a and put in W (pic)
setRadioRegW(a) = set the CC1101 register a to value of W (pic)
sendRadio(a) = send a byte of value a through SPI to CC1101
and these macros are working properly as it should be. ie get and set registers in the CC1101

[TheDirty]

Maybe Mikeselectricstuff can see something.  I'm looking at it, but it's been too long for me, and I never got too far into it because TI had their big supply problem at the time and the CC transceivers were all out of stock.

Since you are using the PIC, if you want full mesh or serious P2P network ability the MRF24j40 would have been a good option.  Microchip offers a Zigbee stack for it, or the much more manageable MiWi stack.  The MiWi P2P stack is actually quite nice for low resource uC's.

Otherwise the RFM12B's have been really nice with a simple custom P2P network.

[Mechatrommer]

Since you are using the PIC, if you want full mesh or serious P2P network ability the MRF24j40 would have been a good option.  Microchip offers a Zigbee stack for it, or the much more manageable MiWi stack.  The MiWi P2P stack is actually quite nice for low resource uC's.
Otherwise the RFM12B's have been really nice with a simple custom P2P network.

full mesh? serious p2p net? i dont know. i just want to send a byte on the air and received at another end of cc1101. but thanx for d info, i'll look into that later.
i just wanna know what issue(s) might cause incompatibility on the receiver side. is there some RF specific issue that i'm missing. so far, all i know is try and error by changing registers value, i've made several setting and changing, but the problem still remains. i'm clueless right now.

[Mechatrommer]

hmm ok. after fooling around. i found out this got to be something to do with dBm gain, antenna touching, take out and put in back etc etc. i managed to get some data into RX CC1101, but still not 100%. i have to move the transmitter around, waving my hand on it etc etc to get some data. or else, i will not get any data. currently the setup is to position both TX and RX at some precise distance (around 20cm) and take out the TX antenna, farther or closer distance, the will be no data into TX. what a load of sh*t!

the first picture is the setup. the 2nd picture showing data transmitted (blue low) at around 532 Hz and data receive "successfully" (yellow low).
if you think this is funny, then laugh it up and tell me whats so funny? 

[Mechatrommer]

...if you want full mesh or serious P2P network ability the MRF24j40 would have been a good option.  Microchip offers a Zigbee stack for it, or the much more manageable MiWi stack.  The MiWi P2P stack is actually quite nice for low resource uC's.

i found it on ebay, but... it is 2.4GHz radio and only effective up to 10 meters. I want to be able to send data from 100m distance.

[Mechatrommer]

Otherwise the RFM12B's have been really nice with a simple custom P2P network.

this one looks pretty nice. its on ebay as well. have you make it works? whats the maximum distance it can send data?

[marianoapp]

i'm just speculating, but since removing the antenna (less gain) you manage to get some data, did you try to separate the transmitter from the receiver further away? i've read some datasheets about other wireless transceivers were the receiver won't work if it receives the signal with too much gain

[TheDirty]

I'm not certain where you got 10meters from, but the effective range of the MRF24j40 is much greater than that.  My ported version of MiWi P2P worked fine on it and traveled the range of my house without any problem, but I never took it any further than that and haven't used it since I played with it in testing.

I've never really tested the full range of the RFM12B; I know it will go from basement corner to top floor corner of my house.  The rated range says 300m in open air.  If you want distance, though, the RFM12BP is the high powered version.  I've never used it, but it looks like the same thing, but with a greater output.  One big drawback is that it requires a 12V source as well as the 3.3V.
http://www.futurlec.com/Radio-433MHZ.shtml

The guy at Jee Labs does a lot of work with the RFM12B's and writes a lot about it.
http://news.jeelabs.org/

If you don't care about cost, you can just get an XBee module and have it do all the work for you.  Just talk to it over the UART.

EDIT:
P2P means Point to Point.
Mesh means that it is a 'smart' network and will create bridges between nodes and figure out routing to get data from one node to another.

[MyZirconia]

Hi.
have you used a scanner or someting to listen to the frequency you whant to transmit on there can be an interference on that frequency just in your neighborhod or
from an other device that is blocking the signal its quite common on UHF frequencies.

//magnus

[Mechatrommer]

i'm just speculating, but since removing the antenna (less gain) you manage to get some data, did you try to separate the transmitter from the receiver further away? i've read some datasheets about other wireless transceivers were the receiver won't work if it receives the signal with too much gain

yup i did. just as i said, even if i put it further away, Rx wont detect. it only detect when there is movement... my body position, when i open/close the door to put the Tx on the next room. move/rotate the Tx up and down. for the CC1101, there is documentation regarding close in reception where we should lower the Tx power when transmitting to the Rx nearby. i changed to different Tx dBm output, Rx dBm sensitivity... but no improvement.

I'm not certain where you got 10meters from, but the effective range of the MRF24j40 is much greater than that

i read in ebay posting for the module. typed MRF24j40.

The guy at Jee Labs does a lot of work with the RFM12B's and writes a lot about it.
http://news.jeelabs.org/

thanx, i'll look into this if i cannot solve this CC1101. an interesting option.

If you don't care about cost, you can just get an XBee module and have it do all the work for you.  Just talk to it over the UART.

i think CC1101 is more complex already than i ever need, with some hopping, addressing, crc, fec etc etc, i just want to send some simple binary data

have you used a scanner or someting to listen to the frequency you whant to transmit on there can be an interference on that frequency just in your neighborhod or
from an other device that is blocking the signal its quite common on UHF frequencies.

i dont have a spectrum analyzer , but i have an elcheapo camera flash remote radio trigger which happen to operate at the same frequency. the trigger will detect when i send some data through CC1101 (by probing the trigger's receiver output pin using my DSO), meaning the CC1101 is really sending out something. when i dont send anything, the trigger wont detect anything, meaning there should be no interference from another source. i also made a custom code to read Rx byte value when the Rx CC1101 successfully receive/catch the data... the read byte value is correct just as what i send in Tx. so...

[Mechatrommer]

i also found out some others have experienced similar problem to me and post question in ti.com, but they have settled their problem, i dont know how they do that or whats going on.

below is my cheapo camera flash remote trigger taken out of its casing... transmitter below, receiver at the top (with big 3V CR2 battery). i have another elcheapo brand that i'm yet to test. my earlier trigger, is not really reliable, sometime it will miss trigger, and sometime it will trigger by itself automatically (less noise/interference immunity i think). these elcheapo will be my plaything when i give up with the "more expensive" CC1101 module. and they seem to be unable to transmit data at higher speed than 15Kbps. i need at least 20Kbps minimum!

[Mechatrommer]

i looked at the "standard" schematic provided/suggested by texas instrument. the only missing part in my RF1100SE board (CC1101 chip) is a ferrite bead to power supply. is it possible or more likely that ommision of this ferrite bead is the cause for inefficiency?

[alm]

Not likely in my opinion. The bead is there to absorb conducted EMI. If the board is battery powered, you don't have to worry about conducting RF to the mains supply, or about interference from other units connected to the same power source. Unless there's something else in that unit that might be influenced by interference. The only EMI related issue might be the wires to the battery acting as antenna, but EMI is mainly about interfering with other equipment, not really about getting the circuit to work (although that other equipment can be another part of your circuit).

[Mechatrommer]

...If the board is battery powered, you don't have to worry about conducting RF to the mains supply...

1) during the testing, the transmitter is battery powered, as you said, its ok... ok!  but my receiver is supplied by pickit2, is it still ok? does pickit2 provide stable enuf power?
2) as i understand, ferrite bead is to avoid any EMI coming into RF circuitry and spoil it? not the other way around. maybe i'm mistaken? as you said... to avoid EMI into the main supply (reverse direction)
3) even battery powered, wont the other oscillating signal from other parts (be it the mcu, crystal, op-amp etc) spoil the RF circuit/module?

[alm]

EMI suppression is usually about preventing signals from getting out, although it obviously works both ways. It's easy enough to test. Use a battery to power just the RF circuit. If it improves things, power supply noise might be an issue.

[Black_Guard_109]

I'm working quite a bit with wireless sensor design so I will try to give some helps here. I have been working a bit with TIs transcievers (2500,2480 etc). I have to admit i haven't checked all your register settings very hard just though i would try to give some little hints that might help. From my experience you will usually have two kinds of problems when starting to use more commercial transciever chips, one is that there is a lot of registers as you have already seen. Some that might be useful to look into are:

Frequency, Channel - Are you sending on the same frequency/channel, from what i glanced i dont think that should be an issue

Output power - Try setting it to max if you havent already, unless you hardwire it directly to the transciever the chances that you're gonna overload the receiver is very slim

Test Mode - A lovely mode to verify that you are actually outputting anything! Problem is that you would really need a spectrum analyzer (for measuring high frequency signals) and these can be hard to come by unfortunately,.... If you do not have a way of measuring the output rf power this mode is probably not gonna help 

Manchester encoding - Could be useful to allow for more smoothly varying data and allowing your receiver to sync correctly

FEC aka Forward Error Correction - Can be very useful to remove errors during transmission, doesnt help much if you're not receiving anything though (are you using CRC?)

CRC aka Cyclic Redundancy Check - Discards any messages with errors, make sure it is off when just trying to send or receive anything

Also make sure that you're actually activating the transmit mode, you should be able to measure the currrent consumption of the device when transmitting/receiving (also when using constant output carrier for debugging) you should see a spike in power consumption, going from a few mA in idle to about 15-20 mA. If you're not getting this spike in power consumption, chances are that you are not transmitting/receiving anything. Make sure to check this!!! 

If you are measuring a high power consumption both on your transmitter (TX mode) and receiver (RX mode) and all your registers seems to be in order it can be the RF-part. If you havent designed the PCB/Antenna yourself this shouldnt be a problem hopefully but if you're making your own pcb you have to be very careful about designing all the balanced to unbalanced converters (balun), matching circuit and antenna. As I said, if you're using a premade module this should not be a problem. Also, keep in mind that the signal strength at different locations in the room are not as uniform as you might belive, you may suffer severe fading in some locations (loss of received signal power) due to the signal being reflected from different places and interfering with itself, jsut moving the device a little bit could solve this. But it sounds like this is not the issue here though... 

Also, of course make sure that the antenna you're using is actually for 433 MHz, otherwise you might mess things up quite a bit... duh, stupid comment maybe...   

Also, one last things to check out for is as someone mentioned that you have enough power consumption. If you are using battery power and have bad batteries they might not have anough juice to power the switch into RX/TX mode and thus fail to properly function in these modes. But as long as you can supply a constant 25-30mA of current (plus extra to any other connectec circuits) you should be fine.

Hopefully you find something useful in my ramblings, my advice on all the above is to start monitoring the power consumptions so you at least can tell if you're getting the commands through and try setting it in constanc carrier output mode and make sure you see the little magical 15-20mA current draw before trying to send actual data!

Good luck!

[Mechatrommer]

I'm working quite a bit with wireless sensor design so I will try to give some helps here...

thanx black! for raising this "almost dead thread". its not a stupid rambling, but a good info.

1st.. pretty much from all your advices, i've done it, tuning... registers, output/receive dBm, current consumption check etc. but i still got the intermittent receive not at 100%, pretty much like 1% succesfull rate at around 10cm-100cm distance between Tx and Rx. this thing should be able to work up to 100m distance from what i research (without amplifier!, just the bare chip+antenna!). the seller of the module claimed that they have made the testing for it. i've downloaded the "chinese manual" from manufacturer and try to follow the registers setting. still problem the same.

The only advice that i've not followed is the spectrum analyzer, coz i dont have one. All i know, the TI Tx is sending something by looking at my cheapo brand Rx that it is receiving something continuosly when i put TI on Tx. i dont think it will be necessary to activate FEC, CRC, manchester. i'm just working short distance here, without those, by right i should still have the correct data on Rx. from what i know, those things are features for long distance that comm start to become unreliable.

the matter of fact, i'm pretty much give up with this, i've put it on hold and try to do it on the cheaper RF i owned, so far i got +ve result from the cheapo. its just, i've to re-adjust some spec due to slower speed bps capability.

when i get back to this TI Chip i think i will have to re-solve some issue that i think have not been solved:
1) tuning somemore of the registers, frequency, deviation, offset etc. really pain in the arse! since i got 2 Tx n Rx to be programmed, but 1 pickit2 only. but better than buying $499 development tool from TI... for me.
2) hardware issue. i've to study more on hardware, coz i suspect some anomaly in the hardware. maybe mismatched part value? i saw other people can solve their RF easily by changing to the correct registers setting. but for me, i changed to everything, the problem still there.

[Mechatrommer]

here is the "crap" that i was working and its antenna which is claimed as 433MHz antenna (434MHz?), picture for front and back and other 90 degree angled antenna. just in case.. if some experts can spot the anomaly etc.

i bought 4 units of these... all the same! duhhh!

and note that i've modified the hardware by putting bypass cap and a smd ferrite just on the bottom left corner near the header, just as the standard EVM suggested. which have been ommited by the chinese manufacturer. luckily there is a blank pad there for me to solder on. but adding this components give no help at all. now i understand why the manufacturer omitted it  

and can someone advice the ppm accuracy of the crystal? i dont know what type it is and i still dont have the datasheet. there is a ppm vs bps issue in the TI's manual. but as i said, i've changed from slowest, to mid to high speed bps.. problem still there. for lower bps, my chip got hanged somemore!