I am interfacing cc2500 chip to controller PIC18F67K67 at target device side.My host side have cc2511 chip which receives data.

I have to transmit packet of size 247 Bytes form cc2500 to cc2511.

My question is how to transmit data grater then 64 Bytes (FIFO size) from cc2500 to cc2511???

I read datasheet both device but not getting help from it.

  • \$\begingroup\$ Welcome to the wonderful (hideously complicated) world of packetizing data, and reassembling it if you have dropped packets. \$\endgroup\$ – Connor Wolf Oct 10 '13 at 11:26

In order to transmit more than 64 bytes, you basically have to fill up the FIFO with the first 64 byte chunk, then check for the TX FIFO emptying. Place the radio in TX mode and as its transmitting, the TX FIFO gets emptied as bytes are sent. Once it reaches a threshold(watermark), you fill up the rest of the FIFO with more packet bytes.

In order to detect the FIFO threashold, you have to configure the device correctly to send large packets as well as the watermark and then either:

1) Poll the device to see the number of bytes in the TX FIFO 2) Configure one of the GDO interrupts to trigger when watermark is reached.

Take a look at this and App Note AN049, which should have an example of how to do this.

  • 1
    \$\begingroup\$ Design Note DN500 has information about this too. \$\endgroup\$ – kkrambo Oct 10 '13 at 11:45
  • \$\begingroup\$ @kkrambo: Excellent source as well. \$\endgroup\$ – Gustavo Litovsky Oct 10 '13 at 15:25


It looks like I misread the question but as Gustavo reckons it might be worth leaving up I will. I'm not really sure if the problem is the OP's misunderstanding of radio packets or if it is the FIFO he's not getting on with. Anyway, be kind if I've missed the mark on this.

A radio transmitter and receiver usually has a limited packet size because of the probability of data errors - the smaller the packet, the smaller the probability of error. The receiver should be able to detect an error by using the appended error check value. If an error is detected, the receiver requests the packet again.

If the packet was "long" there is a higher probability of error and it will take longer to retransmit the packet.

This is a "dilemma" when designing a packet radio system. Long packets are more error prone and take longer to retransmit hence effective payload data rate is slower. On the other hand a short or small packet is inefficient because it needs a bunch of bits (called a preamble) that allow the receiver's detector to lock-in and it needs a CRC (or error checking bytes appending).

Once the packet size is determined, transmitting (say) a 1MByte file is nothing to do with the radio's packet size rather, it is how you choose to embed a higher level of control into your protocol - let me say this again - this has nothing to do with the radio's packet size.

Trying to "hijack" the small packet transmitted by the radio to make life easier is fine but if you need to transmit something bigger then you need to apply a higher level protocol so that the receiving end can piece together the 1Mbyte file and understand when the file is completely received.

  • \$\begingroup\$ Is this an attempt to answer the specific question about the OP's specific chips? It's hard to tell. \$\endgroup\$ – Dave Tweed Oct 10 '13 at 14:45
  • \$\begingroup\$ @DaveTweed Well I thought it was but on reading again it seems he has problems understanding the FIFO and not being able to cram stuff into a specific packet length. I'll delete in a while. \$\endgroup\$ – Andy aka Oct 10 '13 at 15:22
  • \$\begingroup\$ @Andyaka: Actually your answer is very good in the sense that it covers the tradeoff between packet size and error rate. \$\endgroup\$ – Gustavo Litovsky Oct 10 '13 at 15:39
  • \$\begingroup\$ @GustavoLitovsky Thanks, from your comment I'll leave it up for a while longer. \$\endgroup\$ – Andy aka Oct 10 '13 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.