#1 Does the CC2543 support a transparent mode at 2Mbps over-the-air transmission rate, or even 1 Mpbs, and at what deviations? #2 If we use the internal packet handler of the CC2543, which we thought we would do at 2Mbps over the air, what is the minimum time between transmitted packets, and how do we get the this minimum time? Same question for Rx. #2a Does the CC2543 Tx or Rx automatically turn off at the end of transmitted Tx packet, or the end of received packet, and in what mode is it in when it turns off? It seems the user guide describes going into an "active" mode and waiting. But the documentation does not define "active mode" or how long it must wait. #3 Does the CC2543 in the Tx or Rx need to go to synthesizer calibration, or once turned on, if it is NOT powered down, and the Frequency is NEVER changed, and the temperature variation is small (all very real conditions for us) can calibration be ignored between packets, or some how be corrected on the fly without waiting for 100s of usec or even msecs for calibration?
#1. The CC2543 does not support transparent mode at any rate.
#2. I will assume you are using basic mode here (no auto ACKs)? If you want to send and receive packets in one direction, the best way would be to set repeated operation (PRF_TASK_CONF.REPEAT = 1) on both Rx and Tx. On the Rx side, you should also set PRF_TASK_CONF.REPEAT_CONF = 1 to avoid spending time on recalibrating the synthesizer for each packet.
On the Tx side, you need to put new packets into the Tx FIFO as packets are transmitted. You can adjust the time between packets with PRF_TX_DELAY. I think you should be able to get it to work down to around 80 us gap between the packets for rates 1 Mbps and lower (note that there is a fixed delay component of around 40 us in addition to what is given in PRF_TX_DELAY). For 2 Mbps, short delays between packets in this kind of operation could be a little trickier due to the DC offset compensation, which needs some silence in front of the packet. I think it might still be possible to get the gap down to around 80 us, but it might take some adjusting. I would try the following:
I have not tried this particular setup. My answers are based on my knowledge and experience with this chip. We will provide some usage examples on the web in the future, but I don't believe this use case will be included in the first revision.
#2a. Tx or Rx is turned off when the task ends, see the user guide for details on when that happens. If you use repeated mode as I recommended, Tx will stop when the FIFO runs out of data, so it will stop automatically when you don't feed any more packets. Rx will not stop automatically unless you set a timeout on packet reception. If you do, Rx will stop when no more packets are transmitted by the peer or in case the radio fails to sync on a packet due to noise (in which case you will need to restart the Rx task). If you don't have a timeout, the radio will stop after having finished receiving any ongoing packet when you issue CMD_STOP. To stop Rx or Tx immediately, you can use CMD_SHUTDOWN. When you receive a TASKDONE interrupt (cf. the RFIRQF1 register), Rx and Tx will have stopped.
After Rx or Tx is stopped, the chip will be in active mode, as you say. Active mode is defined in Chapter 4 of the user guide. It means that the 8051 will be running, still clocked on the 32 MHz XOSC, as well as all enabled peripherals (but not the radio at this point). If you want to go to a low-power mode, this must be done in the 8051 program.
#3. With the situation you describe, the initial synthesizer calibration should be sufficient. In the Rx device, you will stop receiving packets should the synthesizer ever get out of lock. If you know that packets should always arrive, you can set a timeout and restart Rx if it expires in order to recalibrate the synthesizer. If you run Tx back-to-back for a very long time (such as approaching an hour or more), I would still recommend that you occasionally stop and restart the Tx task in order to recalibrate the synth. Your protocol may have mechanisms that means this will happen anyway (for instance switching direction and receiving some kind of status from the peer). If you do not want to stop Tx at any time unless really needed, you can occasionally poll the LOCK_STATUS bit of the RFSTAT register. If you ever see this being 0 while Tx is running with a short Tx delay, you should stop and restart Tx.
Thank you for your response. We will try your recommendations immediately. Thanks Charles (Skip) Robidart
Has anyone gotten basic mode to do both a transmit and receive? I have a transmitter sending continuous packets in basic mode, and can't get a receiver to see any of the packets. My RFSTAT shows LOCK_STATUS = 1, and RX_ACTIVE = 1. The channels are the same, both are at 2 Mbps, 500 kHz deviation, 0 address len, no length byte. Signal is strong (at least 10 dB above needed receive threshold).
Also, I tried setting the sniffer mode so I could watch to see if I was sending the correct TX data. It appears that rfc_sniff_clk is toggling at 1 MHz (1/2 the data rate), and the data pin is sending every other bit. I tried it with several data patterns, and it does indeed show only every other bit. The elapsed time for sending the packet matches the 2 Mbps rate, so it appears that I have the rate set correctly. Has anyone else seen this behaviour?
I have basic mode working, so the first question is no longer relevant. I hadn't set ADDR_ENTRY[0].CONF to enable the correct sync word. However, I still see the strange behaviour from the rfc_sniff_clk/data signals at 2 Mbps.
Unfortunately, there is a bug so that the rfc_sniff functionality only works on data rates 1 Mbps and below. Thank you for making us aware of this. The documentation should be updated in the future to reflect this.
Thanks for the info. I was hoping to use the sniffer mode, will it be fixed for 2 Mbps in the future?
I am afraid this is unlikely, as the sniffer is considered as a minor feature mostly for debugging.
What were your plans for using the sniffer? Maybe you could use the SPI or I2C to output the signal instead? It would of course take some MCU interaction, and it prevents you from using the USART or I2C for other purposes, but it should be doable.
I can use the SPI to do it. I was hoping to use the SPI for another purpose, and use the sniffer mode to move RX data to an FPGA without requiring much processing from the 8051. We are running the RX at 2 Mbps trying to receive about 1.6 Mbps of payload (not counting sync word, preamble, inter-packet gap, etc.). The 8051 is struggling to keep up, even with help from other peripherals. The I2C can't go fast enough at all. The SPI is rated to go fast enough, so I will try to use DMA to transfer from RF receive to SPI transmit.
DMA has some challenges in this mode, however. I need to set the SPI to be faster than the RF data rate, so that I can be guaranteed that the SPI channel will be ready anytime a byte is ready from the RF. The SPI says it can go up to 4 Mbps according to the datasheet, so I should be OK.
The other issue with DMA is that it appears that you do not get any indication from the DMA controller as to how many bytes have been transferred until it is done. Once you start the DMA, you don't have any visibility into its state till it is done with the entire transfer. I need to do some processing of the data as it comes in, so I think I need to watch the state of the LLE and a timer to determine how many bytes I have available.