• State
  • Locked Locked
  • Replies 9 replies
  • Subscribers 20 subscribers
  • Views 1906 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 FIFO mode infinite packet length

canals
Prodigy 50 points

Other Parts Discussed in Thread: CC1200, CC1120

Hi,

Is it possible to send a continuous data streaming using the FIFO mode/Normal Mode with the infinite packet length? because I try it using the GPIO0 to check the RXFIFO_THR but before this signal goes high the CC1200 changes to state IDLE from the TX state. 

I am working at 500ksps with 4-(G)FSK at 868MHz

Any Idea?

thank you very much in advance

  • 0
    TI__Genius 12735 points

    Hi

    We have a sw example for infinite packet length for the CC1120 which can be found here:

    http://www.ti.com/lit/zip/swrc253

    To port this for the CC1200 you just need to re-configure for CC1200 register settings. Please use SmartRF Studio for optimum settings.

    canals said:

    because I try it using the GPIO0 to check the RXFIFO_THR but before this signal goes high the CC1200 changes to state IDLE from the TX state. 

    You can not look at the RXFIFO_THR when you transmit. The CC1200 has separate FIFOS for TX and RX so you need to look at the TXFIFO_THR when transmitting.

  • 0 in reply to Martin B
    Prodigy 50 points

    Hi,

    Thank you Martin for your quick answer. I wanted to say TXFIFO_THR instead of RXFIFO_THR. The smart Rf studio does not have the infinite packet length option. I will check the sw exemple.

  • 0 in reply to Martin B
    Prodigy 60 points
    Hi
    I've checked the sample code, and got a question on the receiving.
    As I understand, the total data lenth for receiving is "packetLength + 2". In function syncReceivedISR(void), "bytesLeft" is used to keep track of bytes left to read from the RX FIFO. Then why "bytesLeft" is assigned to "packetLength + 2" instead of "packetLength" after 2 length bytes have been read from FIFO? Is that a bug?
    Looking forward to your quick reply, thanks!
  • 0 in reply to Xing Ma
    TI__Guru**** 317180 points
    Please check out the tx code in the same example. +2 is a convention to take into account the 2 length bytes.
  • 0 in reply to TER
    Prodigy 60 points
    Hi,
    I know clearly about the 2 length bytes, and could find nothing wrong with the tx code. But please pay more attention to what I refer to from the rx code.
    In function syncReceivedISR(), there is no doubt that CC112X_PKT_LEN should be set to (packetLength + 2)%(MAX_VARIABLE_LENGTH + 1). But when function rxFifoAboveThresholdISR() is called for the first time, there should have been (2+BYTES_IN_RX_FIFO) bytes received. So the left bytes to receive should be bytesLeft-(2+BYTES_IN_RX_FIFO), not bytesleft-BYTES_IN_RX_FIFO, isn't it?
  • 0 in reply to Xing Ma
    TI__Guru* 87061 points
    The + 2 is because you need to read out the two length bytes also (APPEND_STATUS = 1).

    Siri
  • 0 in reply to Siri
    Prodigy 60 points
    Are you sure? Nowhere could I find PKT_CFG1.APPEND_STATUS is configured. Besides, if APPEND_STATUS is configured, do you mean, when setting CC112X_PKT_LEN in syncReceivedISR(), the +2 is for two length bytes, and when caculating bytesLeft in rxFifoAboveThresholdISR(), +2 is for appended status bytes? If so, I am even more confused now about the logic.
    I'd like to describe what I thought should be the right logic(without append_status), could you please help to do a check if anything I might misunderstand?
    step1. set CC112X_PKT_LEN to (packetLength + 2)%(MAX_VARIABLE_LENGTH + 1), packetLength is the payload length, +2 is for the two length bytes;
    step2. read out the first two length bytes from rx fifo;
    step3. BYTES_IN_RX_FIFO bytes received in rx fifo, check if (packetLength + 2) - 2 - BYTES_IN_RX_FIFO is less than 256. (packetLength + 2) is the total length expected to receive, -2 is because two length bytes have been received in step2.
    step4. step5...
    The rx sample code does exactly the same with "my logic", all the steps except step3. I couldn't find -2 when caculating the value of bytesLeft. This is exactly where I'm confused.
  • 0 in reply to Xing Ma
    TI__Guru* 87061 points

    Hi

    Yes I am sure. APPEND_STATUS is set in the PKT_CFG1 register and the reset value of this bit is 1.

    The PKT_LEN register is used by the radio to determine how many bytes should be sent/received when using fixed length. The status bytes that are appended in the FIFO is not something that is sent over the air or received by the radio in RX, so the PKT_LEN register should not take these two bytes into account.

    The two status bytes are appended after the last received bytes in the RX FIFO, and therefore needs to be accounted for when calculating how many bytes should be read from the FIFO.

    siri

  • 0 in reply to Siri
    Prodigy 60 points

    Ok, got it. Thanks a lot !