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.

Max data throughput CC1200 1Mbps

Other Parts Discussed in Thread: CC1200, CC1120, SIMPLICITI, CC1101

Hello,

I'm using the CC1200 set for 500kbps 4-GFSK. All settings except for the actual carrier frequency come directly from SmartRF Studio. I need to get as much data as possible transmitted and received and noticed SmartRF has the default time between packets set to 50ms.

I've been able to reduce that delay in my code while still receiving packets but short of trial and error, is there any way to determine or calculate the minimum time required for the receiver to process the package? It is my understanding that it is the receiver that needs that delay between packets in order to process the packet. I'm currently appending the 2 status bytes but not processing them on the receiver. I am only performing an address check on the receiver then offloading the RX FIFO if packet is accepted. 

Can the cc1200 be configured to transmit and receive at a continuous 1Mbps? I looked at the infinite length example but even it introduces a delay between packets. I'm just interested in getting as much data as possible across and any tips to do that would be greatly appreciated.

Thanks,
Juan

  • Hi

    In theory the CC1200 can transmit continuously at 1 Mbps by enabling infinite packet length mode and send all the data as one packet. This is however not a good solution when it comes to handling errors in the packet. Sending shorter packets will reduce the amount of data needed to be re-transmitted in case of errors, but at the same time it will increase the amount of overhead (preamble, sync and CRC) and hence reduce the throughput.

    It is possible to transmit packets back-to-back by setting TXOFF_MODE = TX. The radio will then start sending preamble again as soon as a packet is sent.

    “Continuous RX” can be achieved by setting RXOFF_MODE = RX. The radio will then enter RX mode again as soon as a packet has been received. If this is possible to do or not, depend, as you said, on how fast the received can process the incoming packets. The minimum that has to be done is to read the RXFIFO over SPI to make room for the new packet. Max SPI speed is stated in the data sheet. All other processing needed depends on your application and how long it takes depends on the speed of your MCU.

    BR

    Siri

  • The delay between the packets set in SmartRF Studio is set due to the latency in the USB interface on the PC side. If set too short the PC does not have time to process all the content in the USB buffer. When using a MCU to control the chip the delay could be a lot shorter between the packets.
  • Siri, TER, thank you for your replies.

    Siri, I ran the infinite packet example for the cc1120 on the TrxEB+cc1200 and noticed that even on the transmitter I could not prep the next packet fast enough to continuously transmit. This seems like a limitation of the 25MHz MCU. Is that correct or am I could I be doing something wrong in the example? What is the recommended hardware to run the cc1200 at maximum throughput?

    On the receiver how could I go about offloading the RX FIFO fast enough to prep for the next packet? The example uses the Sync receive GPIO but I didn't think I could start offloading before it was fully received. I was looking at using the CRC_packet GPIO signal but would that be too late of a signal if another packet is incoming? To reduce overhead delays I'm using fixed mode and transmitting the max number of bytes. 

    Thanks,
    Juan

  • Hi Juan

    Please note that the SPI functions in our code examples running on the TRxEB are not optimized for speed at all. If you monitor the SPI traffic using a logic analyzer or scope you will see that there is a lot of overhead. This is because we use one function for all register writes and then there are checks to see if the register to write is in extended memory or not.

    For writing to the TX FIFO, the application calls cc120xSpiWriteTxFifo, which calls trx8BitRegAccess , which again calls trxReadWriteBurstSingle.

    At 1 Mbps it takes (128*8)/1 000 000 = 1.024 ms to empty the TX FIFO.

    Max SPI speed is 10 MHz and you then need a 100 ns delay between every byte in a burst access. This means that the time it takes to fill the TX FIFO is minimum:

    (((1 + 128)*8)/10 000 000) + 128*100*10-9 = 0.1032 ms + 0.0128 = 0.116 ms

    In theory you have more than enough time to refill the FIFO, but you need to add processing time.

    You must also have a SPI that can run on 10 MHz and only have 100 ns between every byte. In most cases you will have more processing time between each byte on the SPI unless you can use a DMA.

    On the receiver, you can start to read the RX FIFO as soon as there are data in it. To know if there are data in the FIFO or not you can use the RXFIFO_THR interrupt.

    BR

    Siri

  • If you are using an MSP430 which has a DMA built in there are 2 things you need to consider.
    As Siri has mentioned you need a minimum of 100ns between packets, this can be a 'major' pain if you aren't expecting it. The solution is NOT use the 10mhz and use half that SPI rate if you intend on using the MSP430 DMA to receive or send data.
    I was able to get this to work in simpliciTI on the CC1101 (much older TI part than the nicer CC112X and CC12XX series). The only way was to halve the bit rate for both transmit and receive. IF the radio you have has a correct receive fifo size after a full packet is received you can use that to set your DMA quantity. (The CC1101 has a bug that sometimes it doesn't work as expected).
    At 5mhz this puts timing for dumping to memory to < 120us. I don't recall the maximum size of the fifo for the CC112X series and the CC1200 off hand. I strongly urge however you to at least double buffer your DMA receiving (IE have at least 2 buffers).
    Over head for the 'handling' before emptying the fifo via DMA is probably going to be your biggest nuisance.
    The advantage of using the DMA is if you configure your DMA correctly you can continu execution whilst the DMA is occurring and inspect a flag when it's finished ( I would recommend using an interrupt to set a flag). So you can 'receive a packet' whilst preparing for the potential packet. If you set up a 'queue' system that uses the DMA interrupt to queue your data that should keep your receive bandwidth high. However this only works if you do not need a ACK for each packet like in a standard protocol.
    Also of note use the busy flag and not the interrupt flag on the SPI port if you are poling the to see if data was sent. You do not want to mess with the flags. Additionally, if your are sending data via the SPI port use a UCBxRXBUF read to clear the interrupt flag for receive. You do not want to do it any other way or things won't go well.
    For transmit and receive DMA you will want 2 channels (annoyingly enough) one for the receive trigger and one for the TX trigger. If you aren't transmitting you should say the transmit to 'no increment' and use a dummy buffer for the source address. For transmitting the reverse is true. This will keep the IFG flag states clean and untangled. You should not clear the SPI interrupt flags manually as this can create strange behavior. (See 35.3.8 of slau208n for details). I've personally lost hair over it.

    As I said you can get it to work without too much duress just be mindful the SPI subsystem has to be used carefully and observe what the user guide mentions. More importantly be sure to check the errata for your processor (just in case).

    Good fortune and I hope for your success.

    Stephen