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.

CC430F6137 Time needed to change radio core state

Other Parts Discussed in Thread: CC430F6137

Hello,

I am working on a project using the CC430F6137.

When I change the state of the radio core from IDLE to TX or RX it can take up to 810µs.

I use the following code:

	if((Strobe(RF_SNOP) & CC430_STATE_MASK) != checkState){						// Check if the radio core isn't already in the givven state
		do{
			Strobe(radioState);														// Set the state of the radio
			__delay_cycles(10);
			setRadioStateTimeOut--;												// Decrease timeOut
		}while(((Strobe(RF_SNOP) & CC430_STATE_MASK)!= checkState) && (setRadioStateTimeOut > 0));// Check if the radio state has been entered
		if(setRadioStateTimeOut == 0){												// Time out expired?
			Strobe(RF_SIDLE);												// Set radio state in idle mode
			error = CORESTATE_ERROR_FAIL;
		}
	}

So basically:

  • Check if not already in the state
  • Set the state
  • Check the state

This takes up to 810µs, wich is strange since the radio core is never in sleep mode.

So this delay is not the workaround for RF1A7 wich is included in the Strobe command (from the RF1A librarie from TI).

Is it normal that it takes such a long time for the radio core to enter the state? 

810µs is ages when you are communicating at 175kBaud.

Does anybody have an idea what causes this long delay?

With kind regards,

Wim

  • If you have MSCM0.FS_AUTOCAL enabled you will calibrate the VCO/PLL each time when going from IDLE to active mode (RX/TX). 810 us seems about right in this case.

    You need to calibrate the unit after power-on using e.g a manual calibration (strobe SCAL). Disable the autocal. The transition time will then be approx 80 us. Note that if the conditions change significantly (e.g. more than +/-30C) you need to re-calibrate as the PLL then will fail to lock.

    We use the auto calibration option in our SW examples for more robust operation, but if you have a temp sensor in your system and check if the PLL is in lock you only do a re-calibration if the PLL lock fails.
  • Hello Sverre,

    Thank you for your quick response.
    I just found out that it was the auto calibration and came to update my post, but you were a bit faster :)
    I have disabled the auto calibration and I calibrate every second when there is much traffic, and every minute when there isn't as much traffic.
    I changed my code and connected my scope and it works like a charm.

    With kind regards,
    Wim