Rapid-refresh multi-wixel communication

Hey folks,
I’ve been tasked with getting eight wixels to send status updates to eachother at 100 times per second.
Here was my plan:

  1. Number the wixels 1 - 8.
  2. Divide up a 10ms period into 8, and assign one slot per device
  3. Hope all the messages get recieved. (Maybe an ACK can be included as a byte in the next packet)

Now, there’s several challenges in this, but what I’m concerned about is the RX timeout. I don’t want to configure the wixel based on whether other devices are participating on or not, and since the wixel should be receiving in the time between transmitting, I can see it often waiting for a packet that won’t arrive.

The function to recieve a packet, radioMacRx(), provides an option for timeout. Knowing the packet might not arrive, that leaves us with three choices when we want to transmit soon:

  1. Set the timeout large, and expect to Interrupt the reciever with radioMacStrobe().
  2. Set the timeout small, and wait for the reciever to timeout.
  3. Don’t recieve, and stay in the idle mode until we transmit.

Looking at radio_mac.c, you can see that the radio strobe won’t have effect if the rx_timeout is under 10ms. This won’t work, because we need to send another packet within that time.

if ((MCSM2&7) != 7 && WOREVT1 < MAX_LATENCY_OF_STROBE)
{
	// We are currently listening for a packet and the timeout is going to happen
	// soon (within 10 ms if MSCM2==1 or 20 ms if MCSMS2==0), so we will not actually issue a RADIO_MAC_EVENT_STROBE
	// right now.
	return;
}

But the rx timeout has its own issues. At an rx_timeout, the radio assumes it dropped a packet, and goes into calibration. This is normally a good thing, because the radio needs to be calibrated regularly to deal with frequency variations from temperature and voltage. However, calibration takes ~800us, according to Table 71, which doesn’t leave enough time to transmit.

The third option doesn’t really accomplish what I want. It will most likely miss packets from the preceeding wixel, leaving it with an incomplete dataset.

What I’d like to do is go straight from RX to TX to transmit a packet at the appropriate time, and then go immidiately back to RX to listen for any other devices that may be transmitting. These would provide small enough transitions that I’m not likely to miss anything by way of not being ready to receive.

Hello.

If you are not calibrating the frequency synthesizers regularly, you could use the FREQEST register to see how much the radio frequencies drift over time. We would be interested to hear more about your project as it progresses.

–David

Thanks for the tip! Could you give some advice on manual calibration? Do I do something like this:

RFST = SIDLE;
while( radio is not idle );// wait for radio to go idle
RFST = SCAL;
while( radio is not idle); // wait for radio to finish calibrating

I think I’m going to try option 1, and use timer2 for timing the transmission slots. I’ll just have to modify radio_mac.h so that it will always interrupt when radioMacStrobe() is called.
It looks like I can use MCSM1 to make the radio automatically stay in RX, but at that point I’m seriously messing with radio_mac.h, which I don’t think I’m ready to do yet.

Something similar to your code should probably work. The radio’s state machine is tricky, though, so I wouldn’t be surprised if there were some special cases you had to account for.

–David