This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1200 infinite packet and fixed packet length

Fixed length:

The TX FIFO is 0x00 - 0x7F which is 128 bytes long, I've tried to send a fixed packet with a lengh of 127bytes and it works just fine. However, when I set the packet to be 128 bytes and strobe, I can see only the preamble and the sync word being transmited.

Infinite Packet:

I'm trying to transmit the contance of TX FIFO over and over again (always the same data), I'm trying to do so via the infinite packet mode: If I fill the fifo with 127 bytes and strobe I see the first 127 bytes being transmited and then I get and FIFO UNDERFLOW ERROR. But if i set the fifo with 128 bytes and strobe I see (as in the fixed mode) only the preamble and the sync word being transmited and than the device return to IDLE mode. 

note that I've tried also messing with the TXFIRST and TXLAST to avoid refilling the buffer but nothing works

I'm using the TrxEB kit, and looking at the infinite packet example could not resolve my problem, any suggestion (how can I transmit the same data over and over again, it is not random data, and I don't want RF pauses)

  • - Do you want to send exactly 128 bits?

    - Why do you think the infinite mode example can't resolve your issue? I would think that you should be able to rewrite the example to something you could use. First, you can drop the loop sending x packets. Then you have to store your packet in one or more variables and keep filling the FIFO with these. As an example first fill the FIFO with the first half of your packet and when most of it is sent (interrupt on FIFO threshold) write the other half to the FIFO. Next time the FIFO threshold is reached the first half has to be written and so on.

  • - No, I tried sending 128 bits just to debug the problem, and I thought it was related to my problem

    - I do think is the correct solution, however I could not really understand by looking at the examples and read the documentation: first, why should I rewrite the same data over and over again into the fifo (I always want to send the same data) Second, how is filling the fifo really works? what registers are changed? and how any why doesn't it interfeer with the data that is currently being send. (I could really appritiate a step by step explanation)

  • Lets say your packet is 100 bit long and when you have sent bit 100 you want to send bit 1 and so on.

    In this case you only need one variable.

    First write the content of the variable to the FIFO. When the FIFO is close to empty (FIFO threshold interrupt) then write the content of the variable to the FIFO again. The FIFO is just a RAM and the location the pointer points to is sent. (Figure 6 in the UserGuide). The filling of the FIFO will typically happen much faster than it takes to send one bit on the air (the datarate) and hence filling the FIFO will not interfere with the sending of data.

  • I just modified the EasyLink example to send packets of fixed length 128 and it worked fine.

    The following changes were done:

    PKT_CFG0 = 0x00 and PKT_LEN = 128

    #define PKTLEN                                 128

    // Initialize packet buffer of size PKTLEN

    uint8 txBuffer[PKTLEN] = {0};

    static void createPacket(uint8 txBuffer[]) {

    // Fill rest of buffer with random bytes

        for(uint8 i = 0; i < PKTLEN; i++) {

            txBuffer[i] = i;

        }

    }

    The packets were received with SmartRF Studio and fixed packet length = 126 (max supported by Studio).

    Even if the last two bytes of the packet are missing, and hence the CRC check fails you will see that the transmitter works as expected.

  • The symbol rate I'm trying to submit, is quite, which result in all the fifo being emptied in under 8ms, however. I filling the FIFO takes 19ms (I'm using the burst mode) so It's impractial trying to fill the fifo that quickly. is there some "hack" by manipulating the pointers, it will think that I filled the buffer again?

  • Not sure if I get your FIFO filling time.

    @ 6 MHHz SPI clock it takes

    1/6MHz*128*8=0.17ms

    The calculation is simplified because I haven't taken account for address bytes etc but it's far from 19 ms?

  • You should be careful if you are messing with the FIFO pointer while in RX/TX as they are also being updated by the packet engine. The FIFO pointers are meant used in IDLE if you for example want to re-send the same packet without having to write it to the FIFO over again.

    Agree with TER that it sound strange if you are suing that long to fill the FIFO.

    BR

    Siri