Help with CC1100 RF Modules.

I am experimenting with the CC1100 (clone) RF modules and find myself stuck in the middle of nowwhere. I have a pair of Demo Boards from the manufacturer on which these modules work perfectly and on all frequencies so it rules out the possibility of the Modules not working. I have had major help from Ron Marcus and Joe Desimone who shared their code with me for a jumpstart.

Solution:
I have a demo board of my own made for a 28 Pin PIC MCU (16F876A @ 4Mhz ) with 4 tactile switches, 4 LED's, and LCD (which I don't use) and a RS232 IO. I am just interested in sending a ASCII character from one Board to the other , at the press of a switch. Actual configuaration of portpins is given in the code. I prefer to use 315 Mhz as I have a old IC-R1 Communication receiver (my test equipment) to monitor the frequency for Transmission. On the manufacturer's demoboard i get a clean chirp of data transmission.
The RF modules that I have , have 5 pins for control, viz: TE (enables PA on Board), CSn, SO,SI and SCLK operating on 5V..

Problem:
It just does not Transmit, and the receiver just does not Receive. The reason I tell this is because , I tried transmitting some data from the manufacturer's Demo Board on that frequency and try to monitor the Rx FIFO on my board for any data. I cannot transmit because , i monitor for some Data on my IC-R1 and nothing copied. I am surely doing something worng somewhere. But I can program, verify the registers on the module perfectly. I can also see that Data goes into the TX_FIFO and (hopefully) Flushes out when I enable the TX. I check the TE going High during Tx the same way it happens on the Manufacturer's Demo Board, so no chance of getting that wrong (Active High/Low)

There are just a few doubts regarding :
- Register values. These values fairly tally with the values I derived from Smart RF studio for the frequency.
- Transmit and Receive Sequence. Can someone please tell me the Receive and Transmit sequence with these modules.

I attach various codes I tried to this thread for some one to help me.

I once again , sincerely, thank Ron Marcus and Joe Desimone for their help with their code, and look forward to their help once more.

regards

Even a Flowchart or a pseudo code would help.

Try using shiftout and shiftin. It's one less thing to worry about in your coding. Also, at 4 MHz, I don't believe your pauseus can go much below 20 uS minimum. Use five nops using asm if you need such a short delay. Shiftin uses the 0 mode, and Shiftout the 1.

Ron

Next thing to do is to set the registers for continuous transmit of random characters. See if you get an output from the transmitter. At this point, don't worry about what comes out, just that something does. Next, I have smoked a number of cc1100s with only a slight overvoltage pulse. Is it possible to jumper the mfg board processor output to the CC1100 input? This will test the CC1100 in circuit and see if it is operating.I did this with the development kit and saved mucho time.
that's all for now,
Ron

Hello Ron,

Thanks a millon for coming to my rescue. Well a few things I need to understand is what is the sequence to transmit a particular byte thru these modules and What is the sequence to set the Module in receive mode. As you said , there is a lot of grey area in the datasheet , which only explains on how to program the registers. Well I have successfully been able to program the registers and all that what is said on the top.

OK some inputs to your suggestion. I have been able to transmit some 15 bytes using the method I explained in my previous thread and for sure , I have monitored these signal on my R1 Scanner Receiver.

How do I
1. Program the registers for continous transmisson.
2. How do I program the PA_Table. Is it necessary.
3. In the abscence of GD0 and GD1 Pins How do I provide an interupt to the MCU for a received packet in the buffer.

I have many more question to ask, but I just don't want to bother you on that.

regards


p.s. I have the Code for the Manufacturer's demo Board in "C" but don't understand Head "NOR" Tail from it. If it helps you , I can send it to you. I just understood that the manufacturer sends the packet at different PA level for possibility that the module is just to near to each other and likewise. More on this later.

How do I
1. Program the registers for continous transmisson.

If you want to send the data as a packet, it is difficult at best. It's similar to filling up a bucket with water and when it gets to a preset level, the bottom drops out to empty it. The only difference is that it adds a CRC at the end. You can turn it into a transparent transmitter that will just send out anything you put into it, but you lose a lot of good reasons to use the CC1100 in the first place.

2. How do I program the PA_Table. Is it necessary.

The PA table is for power ramping in OOK or ASK. I guess it is useable in very restrictive areas for spurious reductions. Only the first address is used for normal use. Just input the value on page37 for the power level you choose.
Set FREND0.PA_POWER to 0 to choose the first register. PATABLE is $3E.
RXFIFO is 3F + $80. This is one of those gotchas. Get the transmitter working before you pull any hair out over receive. When you get a chirp, move on.

3. In the abscence of GD0 and GD1 Pins How do I provide an interupt to the MCU for a received packet in the buffer.

I believe GDO1 is presented as SO to you. When CS goes high, it becomes a general output. If you change the register data to $07, it will go high when a valid packet is received.

Hello Ron,

1. I tried your suggestion and i do get a chirp on my Receiver.
2. I don't understand what you meant by RXFIFO is 3F + $80. Does this mean that I have to look for data @ $BF. I tried to access it but no reply.
3. I changed PA_Table to C6 i.e. 8.7 dbm out put. You referred to page 37 but i found it on pg 49. I hope its the same.
4. OK one thing i wanted to tell you is that I can access the 31.3 Status Registers mentioned on page 81 with the addresses mention in the brackets. eg. RSSI I can access it @ F4 and not $34 likewise. Is this normal or something Wierd.
5. What is the procedure to Transmit and receive?. OK I shall tell you what I do. I go to idle mode. Flush out TX_Buffer. I fill the TX_BUFFER with 3 Bytes. Then enable TX and check the Tx_buffer. OK the buffer empties , so I presume that the data is flushed out.
6. Register values of my setup are
CC_Addr = _IOCFG2 : Reg_WR = $2E
CC_Addr = _IOCFG1 : Reg_WR = $07
CC_Addr = _IOCFG0 : Reg_WR = $06
CC_Addr = _FIFOTHR : Reg_WR = $07
CC_Addr = _SYNC1 : Reg_WR = $D3
CC_Addr = _SYNC0 : Reg_WR = $91
CC_Addr = _PKTLEN : Reg_WR = $FF
CC_Addr = _PKTCTRL1 : Reg_WR = $0E
CC_Addr = _PKTCTRL0 : Reg_WR = $05

CC_Addr = _ADDR : Reg_WR = $01
CC_Addr = _CHANNR : Reg_WR = $00
CC_Addr = _FSCTRL1 : Reg_WR = $06
CC_Addr = _FSCTRL0 : Reg_WR = $00
CC_Addr = _FREQ2 : Reg_WR = $0C
CC_Addr = _FREQ1 : Reg_WR = $1D
CC_Addr = _FREQ0 : Reg_WR = $89
CC_Addr = _MDMCFG4 : Reg_WR = $C7
CC_Addr = _MDMCFG3 : Reg_WR = $83
CC_Addr = _MDMCFG2 : Reg_WR = $03
CC_Addr = _MDMCFG1 : Reg_WR = $A2
CC_Addr = _MDMCFG0 : Reg_WR = $F8
CC_Addr = _DEVIATN : Reg_WR = $40
CC_Addr = _MCSM2 : Reg_WR = $07
CC_Addr = _MCSM1 : Reg_WR = $30
CC_Addr = _MCSM0 : Reg_WR = $18
CC_Addr = _FOCCFG : Reg_WR = $16
CC_Addr = _BSCFG : Reg_WR = $6C
CC_Addr = _AGCCTRL2 : Reg_WR = $43
CC_Addr = _AGCCTRL1 : Reg_WR = $40
CC_Addr = _AGCCTRL0 : Reg_WR = $91
CC_Addr = _WOREVT1 : Reg_WR = $87
CC_Addr = _WOREVT0 : Reg_WR = $6B
CC_Addr = _WORCTRL : Reg_WR = $F8
CC_Addr = _FREND1 : Reg_WR = $56
CC_Addr = _FREND0 : Reg_WR = $10
CC_Addr = _FSCAL3 : Reg_WR = $E9
CC_Addr = _FSCAL2 : Reg_WR = $0A
CC_Addr = _FSCAL1 : Reg_WR = $00
CC_Addr = _FSCAL0 : Reg_WR = $1F
CC_Addr = _RCCTRL1 : Reg_WR = $41
CC_Addr = _RCCTRL0 : Reg_WR = $00

CC_Addr = _FSTEST : Reg_WR = $59
CC_Addr = _PTEST : Reg_WR = $7F
CC_Addr = _AGCTEST : Reg_WR = $3F
CC_Addr = _TEST2 : Reg_WR = $81
CC_Addr = _TEST1 : Reg_WR = $35
CC_Addr = _TEST0 : Reg_WR = $09
CC_Addr = _PATABLE : Reg_WR = $C6
7. Any simple code that I can try to test the communication. The modules are working as after each couple of test i test it on the Manufacturer's demo board.
8. I have the code for the Manufacturer's demo board written in C. If that could help ? I personally don't undrestand C.
9. Am I right in checking the status byte on the receiver board for received data. I presume apart from showing that the module is in Rx mode it will also tell me of the number of bytes it would have Rx. or is there any other way.

Ron,

I am having problems with some of the routines using Shiftin / Shiftout.

You mentioned in your earlier thread to use a couple of (5) nop using asm. can you please give an example.

I am having some problem issuing a strobe signal using Shiftin/out and reading the status register. presumeably it should be the timing problem.

Otherwise the register read/write work perfectly. Even the Multi Read/Write works great.

Just one querry. What should be the addr value when you enter the read_stat routine.

thank you.

Ron,

I finally got the modules to transmit and receive some data in the RX_BUFFER at the other end , but there is a problem.

If I transmit 3 Bytes , I get 6 Bytes in the Rx_Buffer which do not tally, but are consistent and not random.

Can you help. A PM helps you understand it much better.

regards

The receiver adds a CRC and RSSI info to the packet. Read the bytes out and see if your data is in the packet.

How do i remove the CRC and RSSI data out from the packet. Any idea.

Thank you for the help.

Quote:

---

Originally Posted by charudatt

How do i remove the CRC and RSSI data out from the packet. Any idea.

Thank you for the help.

---

There is a register in MDMCFG or PKTCTRL that will remove the offending appended bytes. Did you get the proper bytes in that packet along with the other stuff? If you can use the packet type of transmission the CC1100 provides for, it will be far more powerful than sending the bytes without any error checking.
Ron

Hello Ron,

I am very happy to inform you that I finally got the modules (One to tx and the other to Rx) to work.

There were some problem with the MCSM1 and MCSM0 register which I corrected. removed Manchester coding and incorporated a VCO calibration check, which you had disabled. After doing all these changes , i started getting random results at the receiver end, then I added a few delay in between the Buffer fill and just got the modules to work exactly as I wanted.

Oh god massive modules and adventure guaranteed.

There are still a few glitches (even after getting it to copy the write bytes) , which i plan to solve them myself.

I have yet to get the SO pin going high after a good packet is received. don't know why that is not happening. As a result I have to keep polling the RX_Buffer every time to see if i have Rx any data in it.

This is the start of my adventure and I sincerely thank you and Joe Desimone for taking time out and trying to solve my problem.

Now I shall play arround with the registers (value) and see the changes in the modules.

regards/

""I have yet to get the SO pin going high after a good packet is received. don't know why that is not happening. As a result I have to keep polling the RX_Buffer every time to see if i have Rx any data in it.""

Supposedly, when the CS goes high (deselect), SO should become a standard output. If you have not selected packet protocol, then this will not work. I have it working quite well with GDO0 as the valid packet flag. I have not tried GDO1.
Ron