CC2543 Time between Receive Question

Hello Brian,

Could you please elaborate what you mean by "1 mSec data resolution for the switches"?

Yes it means the RX/TX turnaround time. Just ignore the content of the test condition cell ("RCOSC, with 32MHz XOSC OFF"), It does not make sense as the 32 MHz XOSC must be on for the chip to be able to do RF operations at all. It will most likely be removed for the next revision of the DS and replace by "Proprietary auto mode". If you use basic-mode instead of auto-mode you can achieve turnaround time less than 100 us. In basic-mode you will have to implement the acknowledgement scheme yourself. I  can give you more details after you answer my initial question at the top.

What I mean by 1mSec data resolution for the switches is that I would like to have a message sent from the switch every 1mSec.  That would give the host micro an update every 1mSec of the switch state.

So I'm trying to do the math.  Minimum packet size that I would like to use is 1B preamble, 2B Sync, 1B address, 9b header, 1B data, 1B CRC  for a total of 52 Bits.   At 2Mbps transmit rate that is 26uSec to transmit the message.  

The following steps would take place:

The main controller switches to transmit and sensors switch to receive, 180uSec(from data sheet) to setup.

Transmit time of message, 26uSec.

Sensors receive message and switch to transmit mode for the auto ACK and main controller switches to receive, 130uSec(Tx-Rx time)

Sensor 1 sends message back, 26uSec

Time between receive message at main controller, 130uSec(Tx-Rx turnaround time)

Sensor 2 sends message back, 26uSec

Time between receive messages at main controller 130uSec(Tx-Rx turnaround time)

Similar thing happens for sensors 3-8,  26uSec x 6 + 130uSec x 5

Loop starts over.

This is a theoretical minimum with 0 excess time and would most likely not work in the real world, but this gives a total of 1454 uSec.  The largest contributor to the loop is the 130uSec between receive messages on the main controller since it needs to receive 8 short messages per loop of the sensors.  So it looks like the best I could realistically do would be a 2mSec resolution on the switches.

Could you please double check my understanding of the math and the timing? 

Edit:  After re-reading your post, you mentioned that the Auto mode is longer than the basic mode.  I guess that implies that this time is for switching from transmit to receive.  If I set the main controller to just receive messages, how much time must I leave between the messages for the receiver to become ready to receive again?

Hello Brian,

Payload:

I would recommend a different packet format based on the following assumptions:

• A 32 bit sync word would give better performance than a 16 bit. If you use a 16 bit you must choose a sync word with very good auto-correlation properties. a 24 bit sync word can be a good compromise between packet length and robustness.
• If you are going to send on 2 Mbps you will need to enable the AGC and then you will need more energy in front of the packet than just the 1 preamble byte. It depends on the AGC and RSSI setting, but at least 4 bytes in total is recommended. 
• 3 or more CRC bytes is recommended to achieve robust operation. A 24 bit CRC check will protect against 1, 2, 3, 4, 5 and all other odd number of errors. 

If you use a 1 Mbps link instead you can use 1 Byte preamble, but I still recommend using 3 bytes CRC.

Timing:

You seem to understand correctly. But if you use the same frequency you can utilize the following feature documented in the user guide:

"If PRF_CHAN.SYNTH_ON is 1, the synthesizer is not turned off after the task ends. This can be used to
start a new task immediately on the same channel and get faster start of Rx or Tx. To do so, the next task
should be started with PRF_CHAN.FREQ set to 127. Note that the synthesizer should not be allowed to run
for a long time after a task has ended, as this causes excessive power consumption. The synthesizer can
be stopped by sending a CMD_SHUTDOWN command."

It could be a good idea to implement some sort of frequency hop between each event to increase robustness in the case of strong interference. 

Does the 130uSec include the time to setup the synthesizer?  What would the minimum time between receive messages be if I used the PRF_CHAN.SYNTH_ON = 1 setup?

Ok, so if I revise my timing it would look like this.

Packet size: 4B preamble, 4B Sync, 1B address, 9b header, 1B data, 3B CRC  for a total of 113 Bits.   At 2Mbps transmit rate that is 56.5uSec to transmit the message.  

The following steps would take place:

The main controller switches to transmit and sensors switch to receive, 180uSec(from data sheet) to fully setup.

Transmit time of message, 56.5uSec.

Sensors receive message and switch to transmit mode for the auto ACK and main controller switches to receive, 130uSec(Tx-Rx time)

Sensor 1 sends message back, 56.5uSec

Time between receive message at main controller with no re-init of synth, 20uSec

Sensor 2 sends message back, 56.5uSec

Time between receive messages at main controller with no re-init of synth, 20uSec

Similar thing happens for sensors 3-8,  56.5uSec x 6 + 20uSec x 5

Loop starts over.

So this would give me 958.5 uSec to get all the data from the 8 sensors.  This would still get me the 1mSec resolution that I am looking for.  I would be staying on the same frequency for this application.  There will most likely be a few of these setup ups within range of each other so I would like to keep them at a constant and different frequency to avoid interference.