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.
Tool/software:
Dear TI Support team,
we are using the CC1352R in the following basic configuration:
- RF frequency: 869.525 MHz
- Symobl rate: 200 kbaud
- RX filter: 621.6 kHz
- TX power: 12 dBm
- HF Clock Source: External 48 MHz TCXO
- TCXO Source: CMOS Type
- Global LDO mode
- Temperature range: -40°C - 70°C
We have to equally configured CC1352R devices communicating to eachother. The connection is conducted through an RF cable and 40 dB attenuation.
This works fine at room temperature as well as at min./max. temperatures for several days as long as the temperature stays constant.
The problem of loosing the communication only happens when the environmental temperature changes. It does not matter if the temperature
inreases or decreases. We see the problem also occuring shortly after the temperature change (climate chamber) has been completed.
It does not mater if the DUT is transmitting only or receiving only. In both cases the communuication stopps when the temperature changes.
In TX mode we see that the transmitted RF spectrum changes when the problem occurs. Instead of a "nice" 2-GFSK spectrum at the center
frequency of 869.525 MHz we see the spectrum in the picture below at an incorrect center frequency of 869.0 MHz. There are spurs in the
FFT that do not appear during normal operation.
We observe that when the DUT is in failure state a RESET (Pin 35) of the CC1352R always solves the problem, and the DUT goes back to normal, expected operation.
Is this issue known? And if so, is there a way to prevent it?
Let me know if you need more information.
Thanks a lot for your help!
Best regards
Joerg
Hi Joerg,
Could you please reupload the image? It seems that it didn't attach correctly.
Is the temperature being changed while a transmission is in progress?
we also observed the following:
We have one device transmitting all the time and the other device receiving all the time.
When the TX device in in failure state it does not help if we swap RX and TX to make the TX device now receiving and vice versa.
A RESET to the TX device in failure state, however, did solve the problem.
In order to make sure that the frequency is set up correctly, we have set in the sysConfig GUI the CMD_FS enabled. In our initiallization of our code, we used the following command:
RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs_custom868_1, RF_PriorityNormal, NULL, 0);
After failing with this command we also tried to re-set it every time before we were transmitting. However, this didnt also help. Do you have any suggestion if the way we are setting the CMD_FS command is ok, or do we have to set this command in a differnet way. Or are there any other recommendations.
Hi,
After checking with a colleague, here is some feedback:
If the temperature changes, you will need to re-calibrate the synth by issuing a
CMD_FS
. This command will always run if the device has been in Standby (even if you just call it once in your application, the RF driver will always run a cached version of the setup command and FS command when getting out of Standby.In an application where you never turn off the RF core or enter Standby, you will need to call the
CMD_FS
regularly in your application.
Please also clarify what you mean by "transmitting and receiving all the time".
For RX that presumably means that you are in continuous RX. If that is the case, you need to manually exit RX state to re-calibrate from time to time. In TX, presumably means that you are transmitting packets (and not transmitting continously), but you will need to issue the
CMD_FS
from time to time in your application if you are never turning off the RF Core (so that the RF Driver calls theCMD_FS
for you).
Regards,
Zack
Hi Zack,
in TX mode we transmit packets, correct. After each packet we send the command: RF_yield(rfHandle); and wait for the next packet on the UART. That in total seems to work. We don´t see the communication drop when the TX-only device operates at changing environmental temperatures.
In RX continous mode we still see the communication drop when the RX-only device operates at changing environmental temperatures.
We send the following commands:
RF_cancelCmd(rfHandle, rxCommandHandle, 1);
RF_yield(rfHandle);
usleep(50);
/* Set the frequency */
RF_postCmd(rfHandle, (RF_Op*)&RF_cmdFs_custom868_1, RF_PriorityNormal, NULL, 0);
rxCommandHandle = RF_postCmd(rfHandle, (RF_Op*)&RF_cmdPropRx_custom868_1, RF_PriorityNormal, &callback, RF_EventRxEntryDone);
Could you plaese explain in more detail how to exit the RX state an do the recalibration?
Best regards,
Joerg