LP-CC1312R7: RSSI vs time get stuck & TX carrier drift during temperature test.

thomas stichelbout said:

i.e. changing the signal level does not result in a change in RSSI, less than 10 minutes after pressing start continuous rx.

I have seen that SmartRF Studio can stop updating the graph after some time. If you need to log RSSI over time I would look into writing a few line of code that output the RSSI on UART.

thomas stichelbout said:

During testing of the evaluation board vs temperature i have also observed the following : 

During the temperature cycling from 85 degC to 0 degC, it was observed that, the frequency carrier drift by 1.8 kHz until the radio is stopped and restarted. 

How do you do this test? I did a test with CC1312R and found that I had to re-calibrate the VCO if the temperature changed by more than about 35 degrees. If the temperature change more than this the PLL goes out of lock. 

The carrier frequency will be a function of the reference, typically the xtal. What is the datasheet spec for the xtal you are using, how many ppm is the xtal frequency expected to change over the temperature range you are using? Note that most xtals has a s-shaped frequency vs temperature curve, see the xtal documentation. 

The test are performed on TI LP-CC1312R7 evaluation board controlled by RFstudio in both cases. The RSSI reading is the value on the top right corner in the RX continuous. Rx RSSI test was only performed at room temperature 

The evaluation board is place in a Vötsch climate chamber to control the temperature. The PLL went out of lock as the temperature was changed without restarting the radio due to lack of internal recalibration.

The frequency vs temperature plot looks like expected. Do you have further questions? 

the plot corresponds to behaviour with regular recalibration. Regarding the RSSI reading , the value is stuck after 10 min. Is this a tool issue or an evaluation board problem due for example to a lack of internal recalibration ?

RSSI reading: No, I believe this is mainly a GUI problem with SmartRF Studio (meaning that the RSSI is read from the chip but the graph is not updating) 

so if the continuous RX is used for BER testing, it would continue working after 10 min ? This will be needed to perform blocking test which requires the radio to remain in a correct state for long time if doing more than check of a few points

i haven't figured out how to get clock and data on a pin from Rf studio to be able to loop back to the generator yet ... could you describe how this is done in RF studio ?

or how to setup the generator correctly for a PER test.

thomas stichelbout said:

continuous RX is used for BER testing

If you want to test sensitivity you should test PER and calculate BER based on the result. it is possible to take out a bit stream in cont. RX but this is a stream that is taken from early in the RX chain and the amount of post processing is less than if you receive packets and hence poorer sensitivity. Since in an application you will receive packets you should use the same for testing the performance. 

To compare the results with the datasheet numbers you can use 3 byte payload, fixed packet length. 

You need a generator that is able to send packets, do you have this? 

yes. i have a ESG 4438C with BER option too

Looking quickly through this it doesn't look like you are able to send a packet using this with the modulation format. As said, BER testing will not give the wanted/ expected performance.  

it is possible to setup a frame up with formated data, but not for BER testing. this would be single frame sent and received for doing a PER test on a low amount of frames. BER rate test requires clock and data entry.

mode --> custom -> real time IO baseband --> data as "user file" while the carrier and modulation settings are selected in other sub menu of the custom settings

when using for example wmbus mode , do i need to have the preamble (i.e 0x5555 5555)  and what  the CRC   ?

For wmbus OTM i would expect the packet to look like : 

Preamble (8 bytes): 0x5555 5555

sync word for wmbus, Mode C FFB (8 bytes) = 0x543D543D (page 29 in EN 13757-4)

Payload : 8 bytes

carrier settings : 869.525 MHz, gfsk, 50kbps, 25 kHz freq dev.

You have to construct a packet with preamble + sync + payload + CRC as according to the wmbus standard. Start by use SmartRF Studio and the settings you have highlighted and see if you receive anything. 

i am still missing to calculate the CRC but the rest is according to the wmbus mode C specifications

It's several pages online that can calculate the CRC for you when you type in what you want to calculate CRC from. Even easier:

Setup two board as RX and TX using SmartRF Studio using wmbus c-mode. See that you manage to receive your wanted payload. Then change the RX side to fixed payload and receive two extra bytes. The two extra bytes are the CRC and you should be able to use this as part of the packet in the generator. 

is the CRC calculated on  preamble + sync + payload or just the payload ? and do i need a CRC-8, 16 or 32 ?

Payload. I assume that this is also defined in the standard. You have to use the correct polynomial and initial conditions as defined in the standard. 

i never had to make up real packet data before just for testing the receiver as i usually manage using BER for pre qualification. Therefor this is not straightforward for me ..  Doing automated test is not possible using per while we can for ber quite simply to evaluate the rx performance 

if i use 2 evaluation boards using default wmbus mode C MTO it works .. but when i try to change the settings to OTM with the same payload / preamble / sync ... i start to get CRC error ?!?!?

For example : pure wmbus mode C MTO settings

i only changed the data rate from 100 kbps to 50 kbps

if i change also the frequency deviation to 25 kHz i receive nothing between 2 TI evaluation board ??!?

I overlooked the C-mode settings you are using. When I read C-mode I automatically think about 100 kbps and I didn't read the actual mode you are using. 

I suspect this is because the patch used is written for C1 operating on 868,95 MHz and 869,525 MHz operation could potentially need some other settings. I will check what we have done here.  

i haven't tried to demodulate the data provided by the transmitting board with a vector signal analyzer but i would suspect that the symbol rate setting / frequency deviation are not applied correctly to the complete bit stream ..

For the 100 kbps mode, the patch is written to combine C and T mode. I suspect that this generate an issue here. But for the 50 kbps mode I assume  that you don't need to combine this mode with some different mode. If that is the case you should be able to use the standard 50 kbps setting (the first on the SmartRF Studio list of available phys) for this test. 

it helps for receiving board to board data

wmbus mode c2, OTM tx

wmbus mode c2, OTM rx

i still dont' get my data through from the ESG4438C with the preamble + sync + payload + crc below

55555555 543D543D 756B7F56 80DE

which should correspond to the same as the data transmitted from evalboard to evalboard .. i 'll have to look with a vsa at the difference

Did you check that the CRC you use on the signal generator is correct? 

i have used the same as the one found between the 2 evaluations board i.e. 80DE