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.

CC1310: Frequency stability in different temperature level

Part Number: CC1310

Hi,

A customer has been designing their outdoor products with CC1310 as the remote control receiver. In test they found it could not receive remote control signal extreme temperature conditions, like high temperature 50℃ or low temperature -40℃. Their finally found this issue was caused by frequency offset and figured out a solution [Please check the code below]. Basically the Solution 2 could solve the problem, but there's still things unclear:

1.The current solution used easylink asynchronization, it lost packets sometimes. While easylink synchronization would not, do we have a easylink synchronization solution?

2.Does the solution 2 have other hidden dangers?

3.Do we have a document or example to solve this problem?

Code:

Original code(easylink synchronization, RF stuck under extreme temperature conditions, no packet loss at room temperature):

MyrxPacket.absTime = 0;
EasyLink_Status result = EasyLink_receive(&MyrxPacket);
if (result == EasyLink_Status_Success)
{
/* Toggle LED2 to indicate RX */
DealRxPack(&MyrxPacket);
}
else
{
}

Solution 1(easylink synchronization, RF stuck under extreme temperature conditions):

MyrxPacket.absTime = 10;
EasyLink_Status result = EasyLink_receive(&MyrxPacket);
if (result == EasyLink_Status_Success)
{
/* Toggle LED2 to indicate RX */
DealRxPack(&MyrxPacket);
}
else
{
}

Solution 2(easylink asynchronization, worked normally under extreme temperature conditions, but got a packet loss rate of 0.172%):

EasyLink_receiveAsync(rxDoneCb, 0);
// /* Wait for Rx */
if(Semaphore_pend(rxDoneSem, g_waitTick) == FALSE)
{
/* RX timed out abort */
if(EasyLink_abort() == EasyLink_Status_Success)
{
/* Wait for the abort */
Semaphore_pend(rxDoneSem, BIOS_WAIT_FOREVER);
}
}
RF_yield(rfHandle);

  • HI Viki,

    Could you potentially elaborate on when this happen exactly, is it following them leaving the receiver in RX for a long time and then try to communicate with it? If that is the case then I would imagine that this might happen if the crystal has been impacted since the RX calibration was last run. I would recommend to go out and in of RX if it has been active for a long period in order to re-calibrate the synthesizer. Looking at their 2 solutions, this is more or less what "solution 2" does as it has a "time out" element. As for the implementation, it looks OK to me but I do not understand where the RF_yield() comes from?

    Do you know which PHY they are using? 

  • Hi,

    Thanks for your comment.

    They tried the re-calibration and "RF_close,RF_open" API, which was not working. Their PHY was 433.92Mhz.

  • Hi Viki,

    RF_open/close is not required, restarting RX should be enough. As it works in the async solution they can stick with this if they wish. As for the PHY, what is the RX BW and deviation used? Did they measure the frequency offset in the system in anyway?