TI CC1101 RF Library

Thanks a lot once again for this great explenation. :grinning:

Glad to help :wink:

Without the forum and examples, many of us wouldā€™t get anywhere :smile:

~Michael

3 Likes

@Spangaard
Hi! Greetings from Berlin. I would like to use CC1101 868Mhz in my project with two photons or a photon with Tx and an electron with Rx transceiver. Confused with the pinouts. Need help!!

Module pinout : http://blog.steveundkristin.de/wp-content/uploads/2016/02/CC1101-Modul_PINs.jpg

Need pinout for Photon and electron.

Million thanks in advance.

SI means Slave In which lines up with MOSI (A5)
SO means Slave Out which lines up with MISO (A4)
SCLK is the clock pin SCK (A3)
CSN means Chip Select Negative (=active LOW) which by default is Slave Select SS (A2) but could be any other pin too.

For the secondary SPI port on the Particle devices you can look up the corresponding pins in the docs.

BTW, the same info was already provided further up in this thread

1 Like

I have never used that kind of board.

Mine are mostly this type:

But what are the problems ?

They both have 3.3v, GND, SPI (MISO, MOSI, SCLK, SS/CSN), GDO0 (interrupt) and antenna.

SS/CSN => A2 
SCK => A3
SO/MISO => A4
SI/MOSI => A5
GDO0 => A1 (interrupt)
GDO1 is not used. (guess this is GDO2 on your board?)

You can change CSN=A2 and GDO0=A1, but wait until you have the basics working :wink:

You must change the frequency in the example code to 868MHz and may be the TX power (depending on the distance between the radioā€™s) - se above in thread.

All your Photons with a CC1101 module can RX and TX, so you can send ACK, replies or forward to other devicesā€¦

Good luck :grinning: and let us know when you get it working.

~Michael

1 Like

@ScruffR Dammed you are fast :grinning:

3 Likes

:alien: ā€œWe are Borgā€ :wink:

3 Likes

@ScruffR, @Spangaard Thank you for your prompt reply. I have materials in hand. I will update here as soon as I am done with the basic code testing.

Hello Michael,

I am working on an issue right now for which I donā€™t have a solution yet and I thought to ask you about this specific problem.

I am experiencing hard faults on the Electron about every hour when I have the CC1101 module connected.

SOS pattern (3 short blinks, 3 long blinks, 3 short blinks)
1 blink (indicating hard fault)
SOS pattern (3 short blinks, 3 long blinks, 3 short blinks)
1 blink (indicating hard fault)

I did some testing the last couple hours (20h) and the result is that without having the CC1101 module connected, the Electron is not having this issue any more.

I am now thinking about what exactly could be the problem. Do you think that it might be caused by receiving false data (not numeric or even from other devices), as I am using this in the weather station with which you helped me earlier in this thread, or by the SPI connection between the module and the Electron itself?

Would be very much appreciating help.
Thanks
David

Hi David,
Sorry for not get back to you sooner ā€“ I hope you solved your problem, but if notā€¦

Iā€™m not familiar with the Electron, but I have not experienced any hardware issues of this kind with other MCU boards (Core, Photon, Arduinoā€™s, ESP8266ā€™s). If your SPI communication is sometimes working, I donā€™t see why this should cause problems over time ā€“ maybe check connections?

I have had lotā€™s of problems with traffic colliding in air, but never traffic from none-CC1101 devices. You could try changing the network-id, channel-id or tx-power. Traffic not identified to belong to same network and channel, will be filtered out by the radio. So I wouldnā€™t start there.

Could it be a software issue? I have not worked with the CC1101 radio in some time, but remember I often have code to build or parse the message, where it is quite easy to introduce errors by wrong array indexes, wrong parameters for memcpy etc.

Try deactivating all the code that handles initializing, sending and receiving data ā€“ just have the radios connected.

If that works, try activating the code for initializing the radio. If that works, try activating the code that sends messages. If that workā€™s, try activating the code for receiving messages.

If that does not help, try removing anything else ā€“ make a test with just the Electron and the CC1101 radio.

And if that did not yield any indications of the problem, try replacing the CC1101 board and the Electron (or switch to a Photon).

I could test your code on a Photon, but not and Electron.

Best regards, Michael

1 Like

Hi Michael,

thanks for your help, I very much appreciate you answering me.

I tried deactivating all the CC1101 related code and activated it step by step as you told me. It seems as if the code for receiving messages produces the hard fault some times.

What I also found out, while looking through the code, was the following term in the setup function contained in the initialization code:

// We don't let the CC1101 filter packets for this deviceAddress, we receive everything
cc1101.deviceData.addressCheck = true; //PREVIOUSLY "false"

I was curious if this could be a reason for my issue as I wondered about the comment stating that "we receive everything". I changed the value to TRUE, which I thought to mean that "we now don't receive everything", and tried the program again. It now seems to function properly for a longer period of time but the issue is not solved yet.

Is it possible to somehow filter the received messages for a certain address, which the Electron provides me by publishing the following term (when it says: "the others are #40...)?

I am cc1101 address #10, the others are #40 #81 #44 #120

As I only have one device active sending the Electron data, I wondered about the other three addressed devices and how I could filter these out.

I would be very happy about being able to change the initialization term somehow to achieve this.

Thanks and best regards,
David

Hi David,

When cc1101.deviceData.addressCheck = true, the library should only return messages intended for this device (address). When cc1101.deviceData.addressCheck = false, the library should return all messages send on the specified frequency, network and channel ā€“ but only valid messages. The CC1101 chip takes care of the filtering.

I have never seen any problems like the ones you are describing, itā€™s like you have ghosts sending messages :wink: I think it is very unlikely, that there are 3 other CC1101 radios sending on the same frequency, network and channel ā€“ considering the limited range of the CC1101 radio.

You could try changing network-id, channel-id and device-address. Just to make sure, you donā€™t have a neighbor with a set CC1101 radioā€™s playing tricks on you :wink: And try replacing the radios, to rule out hardware faults.

My library is very inspired/copied from the Arduino PanStamp library, and should be tolerant to receiving garbage, but there could be an issue with buffer sizes, your code handling the messages, interrupts etc. Are you running the example code or have you customized it?
If for some reason you are receiving messages not using the ā€œprotocolā€ used in the example, you could get a result like what you are seeing ā€“ what happens if you turn off the radio sending messages ā€“ do you still receive messages ?

I donā€™t understand your setup. Is the Electron+CC1101 receiving messages send from a Photon+CC1101? Could you setup an extra Photon just to snif all packages send and see what is happening?

Otherwise Iā€™am blank. Publish your code, and I could try regenerating the error? - using Photons, not Electrons.

Br Michael

1 Like

@Spangaard How can I continuously transmitted without having to import data with Cc1101?
I want you to work at the receiver side at the same time?

I donā€™t understand you problem.

The CC1101 radio can transmit and receive. You code controls when you transmit, and you can execute code for receiving either by using an interrupt or by checking if data is available from the loop. No need to wait for at message, your receiver can do whatever your choose and read a message, when available.

I hope this helps ?

Br Michael

@Spangaard How can I send a text. Can you write a sample code in string.

@Spangaard

Where is this code wrong?

String tx_message = ā€œsample_articleā€;
int len = tx_message.length();
byte txbyte[len];
tx_message.getBytes(txbyte, len +1);
Serial.println((char *)txbyte);
cc1101.SendData(txbyte, len);

One thing thatā€™s wrong is that you are declaring txbyte[] too short for tx_message.getBytes(txbyte, len +1)

But other then that, you ask the question where the code might be wrong, but donā€™t state why you assume itā€™s wrong.
What exactly do you see wrong when running that, or should people look for a red herring?

@ScruffR Well, how should it be? Are you a small example author

I donā€™t use Strings, so canā€™t help you there, but Google is your friend :wink:

The sendData function takes a CC1101Radio::CCPACKET object as argument, not a string or a byte array. You can fill you data into the ā€˜dataā€™ attribute. Just as in the library example.

struct CCPACKET
	{
		public:
		uint8_t length; // data length in number of bytes
		uint8_t data[CC1101_DATA_LEN]; // data as an array of bytes
		boolean crc_ok; //CRC OK flag
		uint8_t rssi; //Received Strength Signal Indication
		uint8_t lqi; //* Link Quality Index
	};

Have you got two (or more) devices sending and receiving messages by using the library ?
Otherwise start with that, and when everything is working nicely and you understand the code, replace the data-part of the message with your own data.

Br Michael

1 Like

@Spangaard I understand, thank you. The data is coming but the IF command does not work. Do you see a mistake?

bool receivePacket() {

if(!cc1101.packetAvailable) {
return false;
}

// The cc1101 has received a package
detachIntr();
cc1101.packetAvailable = false;

CC1101Radio::CCPACKET pkt;

// read the packet
if(cc1101.receiveData(&pkt)) {

#ifdef _readPackets

// do we have valid packet ?
if((pkt.crc_ok==1) && (pkt.length > 0)) {

packetsReceived++;
packetsReceivedBytes+=pkt.length;

Serial.print("\r\nCC1101 have news! - ā€œ);
Serial.print(ā€œPackage len = ā€œ);
Serial.print(pkt.length);
Serial.print(ā€ lgi=ā€);
Serial.print(pkt.lqi);
Serial.print(ā€ rssi=");
Serial.print(pkt.rssi);
Serial.print(" CRC=");
Serial.print(pkt.crc_ok);
Serial.print(pkt.data[0]);

  if (pkt.data[0] == ("98")){
      pinMode(7,OUTPUT);
      digitalWrite(7,HIGH);
  }

// cc1101.printCCPACKETdata(&pkt);

#endif

} // crc & len>0

} // cc1101.readData

attachIntr(); // re-attach interrupt so packetAvailable will be set true in ISR

return true;

}