CC430 RF Variable String Communication

Hi Luke,

Could you please provide a few more details: which board are you using - is it this? http://www.ti.com/tool/em430f5137rf900

What example communication code are you using? Is it the simpliciti code linked at the bottom of the EVM page above, this: http://www.ti.com/lit/zip/slac284

If it is the Simpliciti code, I think you are going to get better support by posting your question in the Simpliciti forum, as they are really the experts on this software stack: http://e2e.ti.com/support/wireless_connectivity/f/156.aspx

Regards,

Katie

Hi,

Thanks for replying and sorry for being vague, I am using a developer kit that I have been given so am not sure on the exact details other than the information found on http://www.bis-space.com/2013/03/09/9301/kicksat-technical-summary.

I have been reading this datasheet http://www.ti.com/lit/an/slaa465c/slaa465c.pdf and the example code under "Code Organisation" in a package called SLAC525

Hope this helps and thanks again,

Luke

Thanks for the additional details.

So it looks like the examples you mentioned simply show how to send and receive a few bytes of information - looking at RF_Toggle_LED_Demo.c, the packets sent and received are stored in arrays TxBuffer and RxBuffer. These are containing arbitrary data in this example, just to prove that the communication is working.

It also sounds like you are looking for advice on what are your next steps, and you are creating an application where one device will send commands to the other, and the device will take actions based on this and send some data back (or something similar)?

The first thing to do in this kind of application is to define a packet/command protocol structure for your application. When you are not using some particular existing packet structure, and aren't trying to communicate to a device that someone else has already made (you are designing both of the devices that will be talking), you can really define this however that you want. Some common things you will see in a lot of protocols are a header, maybe a length field, a command, data, and then some sort of checksum to show the data received was correct. Sometimes the receiver also needs to send a response back to the transmitter to ACK the packet and let it know it received the packet successfully and the checksum matched the data. You can try to look at other applications to see things they have done in the past for ideas. The structure all depends entirely on what you decide and what is needed by your application - for example if all packets you send are going to be the same length, then you may not need a length byte. All of this will be up to you.

Once you've written up a protocol specification to design to, you can start implementing it in your code. You'll add some functions to form your packets and to react to particular commands etc. When you want to send you could fill the TxBuffer array with your packet you've made and use the existing transmit functions from the example. The same will go for the receiving.

Was this the kind of guidance you were looking for? Maybe there was a more specific question that you had?

Regards,

Katie

Yes, thank you very much for your reply.

I understand it much better now, so the TxBuffer holds the information being transmitted? So that is the array to edit in order to change the packet being transmitted? I will work on that now and post if I get stuck again.

Thanks again,

Luke

Hello again,

I have changed the packet format (essentially put extra information at the start of the TxBuffer). But now of course when I load this onto two chips they don't register each other's transmissions. I think this is because the new packet format isn't what the receiving code is looking for but I'm not sure where in the code this is controlled.

Thanks again,

Luke

Hi Luke,

Yes, you will need to modify the receive handling functions to do something with the data, and to handle whatever new length of packet that you are doing, etc. Looking in one of the demo codes, you can see that there is a CC1101_ISR interrupt service routine that appears to handle when you finish receiving a packet. It looks like there are some functions included in the RF1A.c that get used here to copy the data from the RF peripheral into the RxBuffer array, and then in the example code all it does is check the CRC and toggle a GPIO. Instead of doing this you will want to do processing on the packet to do something with the data.

One thing to please note as you modify the code - I would strongly suggest that you should not do all of your packet processing inside this ISR, because interrupts are disabled while you are in the ISR and you could miss another interrupt (this is bad coding practice as well). What I'd recommend is that in the ISR you may want to copy the data into the buffer and check CRC as the example is doing now, and then create a variable that is essentially a flag that lets you know you have data needing to be processed. Then have the ISR wake the device at the end of the ISR. Your main loop can check the flag you created to see if there's a packet ready to be processed and do all the packet processing and reaction in the main loop - this way it will not be blocking interrupts.

Hope this helps get you started.

Regards,

Katie