CC1310: Launchpad - PER varies with time - same location - 865Mhz to 867MHz

Sith

Prodigy 140 points

Part Number: CC1310

Hi,

We use CC1310 for a streetlight mesh network. We use Contiki-NG stack.

The nodes are configured to send data every 15 minutes. The nodes communicate at 865.5 MHz.

Mesh formation in Contiki-NG is highly dependent on PER.

The issue is that at some site locations, the nodes are not able to form the mesh network due to high PER (packet error ratio).

And this happens only during particular time of day. This time is common at all problematic sites.

i.e the nodes are switched ON at 6pm. The nodes fail to form the mesh between 6pm and about 11pm. The PER at this time is high.

After 11pm, the nodes were slowly able to form the mesh and continue to send data till morning 6 am at when all the nodes are switched off.

But still the mesh network is not stable. We observe nodes dropping out and rejoining.

But at some locations, this behaviour was not observed at all. Everything is normal.

To eliminate the suspicion on our own hardware and the software stack, we tested the PER with CC1310 Launchpad boards using the SmartRF Studio at two different locations.

At Location1, we see the PER variation with time. At Location2, there is no PER variation.

I have attached the details and results in the link below for your reference. Also the sheet contains the screenshots and configuration setup used.

Please check the link below.

PER Test Details and Results - CC1310 Launchpad Boards

You can see that the PER at different frequencies at Location1 and Location2.

Location1 shows more PER and Location2 shows almost nil PER.

Though we understand that there might be some external disturbances/noise/jamming effect at Location1, this same behaviour is seen in many sites at different geographical locations. And also at the same Location1, the nodes are working properly after 11pm.

Regards

Siva

over 5 years ago

0 TER over 5 years ago

TI__Guru**** 317180 points

TI has some restrictions on data on Google doc and similar so I'm not able to open the file easily here.

I see that you have measured PER variation but have you tried to place a CC1310 in cont. RX at the various locations and measured the noise floor at the frequency you are operating? I believe that we have seen something similar before where something was turned on for a given time period which disturbed the wanted RF communication. This is easy to see if you monitor the back ground noise over time at the various locations you use in your network.

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

Hi,

Thanks for the reply.

No, we have not checked the noise floor at these locations with continuos RX at the specified frequencies. We will try to do that too.

But is this normal at various places.

Because the pattern we see is that the mesh network/PER seems to be good at night but not ok in the evenings. And this pattern continues everyday like the interference is permanent.

Also, I have attached the documents for your perusal. Hope you can open them now.

Regards

SivaPER Test - CC1310 - Launchpad Boards.xlsx

Fullscreen 7802.smartrf_settings.c Download

//*********************************************************************************
// Generated by SmartRF Studio version 2.16.0 (build#215)
// The applied template is compatible with CC13x0 SDK version 2.10.xx.xx or newer.
// Device: CC1310 Rev. B (2.1). 
//
//*********************************************************************************


//*********************************************************************************
// Parameter summary
// RX Address0: 0xAA 
// RX Address1: 0xBB 
// RX Address Mode: No address check 
// Frequency: 868.00000 MHz
// Data Format: Serial mode disable 
// Deviation: 25.000 kHz
// Packet Length Config: Variable 
// Max Packet Length: 255 
// Packet Length: 120 
// Packet Data: 255 
// RX Filter BW: 98 kHz
// Symbol Rate: 50.00000 kBaud
// Sync Word Length: 32 Bits 
// TX Power: 12.5 dBm 
// Whitening: No whitening 

#include <ti/devices/DeviceFamily.h>
#include DeviceFamily_constructPath(driverlib/rf_mailbox.h)
#include DeviceFamily_constructPath(driverlib/rf_common_cmd.h)
#include DeviceFamily_constructPath(driverlib/rf_prop_cmd.h)
#include <ti/drivers/rf/RF.h>
#include DeviceFamily_constructPath(rf_patches/rf_patch_cpe_genfsk.h)
#include DeviceFamily_constructPath(rf_patches/rf_patch_rfe_genfsk.h)
#include "smartrf_settings.h"


// TI-RTOS RF Mode Object
RF_Mode RF_prop =
{
    .rfMode = RF_MODE_PROPRIETARY_SUB_1,
    .cpePatchFxn = &rf_patch_cpe_genfsk,
    .mcePatchFxn = 0,
    .rfePatchFxn = &rf_patch_rfe_genfsk
};


// Overrides for CMD_PROP_RADIO_DIV_SETUP
uint32_t pOverrides[] =
{
    // override_use_patch_prop_genfsk.xml
    // PHY: Use MCE ROM bank 4, RFE RAM patch
    MCE_RFE_OVERRIDE(0,4,0,1,0,0),
    // override_synth_prop_863_930_div5.xml
    // Synth: Set recommended RTRIM to 7
    HW_REG_OVERRIDE(0x4038,0x0037),
    // Synth: Set Fref to 4 MHz
    (uint32_t)0x000684A3,
    // Synth: Configure fine calibration setting
    HW_REG_OVERRIDE(0x4020,0x7F00),
    // Synth: Configure fine calibration setting
    HW_REG_OVERRIDE(0x4064,0x0040),
    // Synth: Configure fine calibration setting
    (uint32_t)0xB1070503,
    // Synth: Configure fine calibration setting
    (uint32_t)0x05330523,
    // Synth: Set loop bandwidth after lock to 20 kHz
    (uint32_t)0x0A480583,
    // Synth: Set loop bandwidth after lock to 20 kHz
    (uint32_t)0x7AB80603,
    // Synth: Configure VCO LDO (in ADI1, set VCOLDOCFG=0x9F to use voltage input reference)
    ADI_REG_OVERRIDE(1,4,0x9F),
    // Synth: Configure synth LDO (in ADI1, set SLDOCTL0.COMP_CAP=1)
    ADI_HALFREG_OVERRIDE(1,7,0x4,0x4),
    // Synth: Use 24 MHz XOSC as synth clock, enable extra PLL filtering
    (uint32_t)0x02010403,
    // Synth: Configure extra PLL filtering
    (uint32_t)0x00108463,
    // Synth: Increase synth programming timeout (0x04B0 RAT ticks = 300 us)
    (uint32_t)0x04B00243,
    // override_phy_rx_aaf_bw_0xd.xml
    // Rx: Set anti-aliasing filter bandwidth to 0xD (in ADI0, set IFAMPCTL3[7:4]=0xD)
    ADI_HALFREG_OVERRIDE(0,61,0xF,0xD),
    // override_phy_gfsk_rx.xml
    // Rx: Set LNA bias current trim offset to 3
    (uint32_t)0x00038883,
    // Rx: Freeze RSSI on sync found event
    HW_REG_OVERRIDE(0x6084,0x35F1),
    // override_phy_gfsk_pa_ramp_agc_reflevel_0x1a.xml
    // Tx: Configure PA ramping setting (0x41). Rx: Set AGC reference level to 0x1A.
    HW_REG_OVERRIDE(0x6088,0x411A),
    // Tx: Configure PA ramping setting
    HW_REG_OVERRIDE(0x608C,0x8213),
    // override_phy_rx_rssi_offset_5db.xml
    // Rx: Set RSSI offset to adjust reported RSSI by +5 dB (default: 0), trimmed for external bias and differential configuration
    (uint32_t)0x00FB88A3,
    (uint32_t)0xFFFFFFFF
};


// CMD_PROP_RADIO_DIV_SETUP
// Proprietary Mode Radio Setup Command for All Frequency Bands
rfc_CMD_PROP_RADIO_DIV_SETUP_t RF_cmdPropRadioDivSetup =
{
    .commandNo = 0x3807,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .modulation.modType = 0x1,
    .modulation.deviation = 0x64,
    .symbolRate.preScale = 0xF,
    .symbolRate.rateWord = 0x8000,
    .symbolRate.decimMode = 0x0,
    .rxBw = 0x24,
    .preamConf.nPreamBytes = 0x4,
    .preamConf.preamMode = 0x0,
    .formatConf.nSwBits = 0x20,
    .formatConf.bBitReversal = 0x0,
    .formatConf.bMsbFirst = 0x1,
    .formatConf.fecMode = 0x0,
    .formatConf.whitenMode = 0x0,
    .config.frontEndMode = 0x0,
    .config.biasMode = 0x1,
    .config.analogCfgMode = 0x0,
    .config.bNoFsPowerUp = 0x0,
    .txPower = 0xA63F,
    .pRegOverride = pOverrides,
    .centerFreq = 0x0364,
    .intFreq = 0x8000,
    .loDivider = 0x05
};


// CMD_FS
// Frequency Synthesizer Programming Command
rfc_CMD_FS_t RF_cmdFs =
{
    .commandNo = 0x0803,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .frequency = 0x0364,
    .fractFreq = 0x0000,
    .synthConf.bTxMode = 0x0,
    .synthConf.refFreq = 0x0,
    .__dummy0 = 0x00,
    .__dummy1 = 0x00,
    .__dummy2 = 0x00,
    .__dummy3 = 0x0000
};


// CMD_PROP_TX
// Proprietary Mode Transmit Command
rfc_CMD_PROP_TX_t RF_cmdPropTx =
{
    .commandNo = 0x3801,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .pktConf.bFsOff = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bVarLen = 0x1,
    .pktLen = 0x78,
    .syncWord = 0x930B51DE,
    .pPkt = 0 // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
};


// CMD_PROP_RX
// Proprietary Mode Receive Command
rfc_CMD_PROP_RX_t RF_cmdPropRx =
{
    .commandNo = 0x3802,
    .status = 0x0000,
    .pNextOp = 0, // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
    .startTime = 0x00000000,
    .startTrigger.triggerType = 0x0,
    .startTrigger.bEnaCmd = 0x0,
    .startTrigger.triggerNo = 0x0,
    .startTrigger.pastTrig = 0x0,
    .condition.rule = 0x1,
    .condition.nSkip = 0x0,
    .pktConf.bFsOff = 0x0,
    .pktConf.bRepeatOk = 0x0,
    .pktConf.bRepeatNok = 0x0,
    .pktConf.bUseCrc = 0x1,
    .pktConf.bVarLen = 0x1,
    .pktConf.bChkAddress = 0x0,
    .pktConf.endType = 0x0,
    .pktConf.filterOp = 0x0,
    .rxConf.bAutoFlushIgnored = 0x0,
    .rxConf.bAutoFlushCrcErr = 0x0,
    .rxConf.bIncludeHdr = 0x1,
    .rxConf.bIncludeCrc = 0x0,
    .rxConf.bAppendRssi = 0x0,
    .rxConf.bAppendTimestamp = 0x0,
    .rxConf.bAppendStatus = 0x1,
    .syncWord = 0x930B51DE,
    .maxPktLen = 0xFF,
    .address0 = 0xAA,
    .address1 = 0xBB,
    .endTrigger.triggerType = 0x1,
    .endTrigger.bEnaCmd = 0x0,
    .endTrigger.triggerNo = 0x0,
    .endTrigger.pastTrig = 0x0,
    .endTime = 0x00000000,
    .pQueue = 0, // INSERT APPLICABLE POINTER: (dataQueue_t*)&xxx
    .pOutput = 0 // INSERT APPLICABLE POINTER: (uint8_t*)&xxx
};

8625.smartrf_settings.h

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

I managed to open the file now. The PER data doesn't tell me anything else than what you have described by words.

Since the PER loss is time dependent and repeatable you should look for an external event. From your description it sounds like something is turned on at a given time and turned off later. This could be a noise source. But could it also be something that act like a physical shield like a shutter or something similar? You have to find out what happens on the different locations at 6 pm.

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

Thanks for the reply again.

I highly doubt the possibility of a physical shield/shutter since the actual nodes are on top of streetlights and are in open area. We conducted our tests using launchpad boards in the same open area.

Anyways, we will try to record the noise floor to identify the external event if any.

For this, Is there a way to log the data in the SmartRF Studio, since we need to run the test for atleast 12 hours?

Also is there any change in device configuration that needs to be made in the SmartRF Studio to check the background noise?

//Siva

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

SmartRF Studio has not a log function in the GUI when using cont. RX. It's possible that you can do this with the RF test lib (Click on the wrench icon in the upper right corner in SmartRF Studio and select "SmartRF Test Environment". Then you should be able to set the chip in RX and then read the RSSI at the interval you would require.

Is it something common with the locations that cause a issue?

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

Hi,

Sorry for the delayed reply. Thanks for the SmartRF configs.

We are trying to get the log in a couple of days (its getting difficult to access the location due to lockdown)

About the locations, we did not notice anything common that could cause this interference/noise.

I just want to know, in case if we find out that there is an external noise, is there some plausible way to make our boards work in this environment?

Because, we have no control over the noise source. So is there something we could do in our board side.

//Siva

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

If you manage to find out why you see a poor PER at given times of the day we can start to look if you can get around the issue. Without knowing the root cause it's also difficult to give an advice on how to fix it.

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

OK. We will try to get the data at the earliest.

0 Sith over 5 years ago in reply to Sith

Prodigy 140 points

Hi,

We managed to collect the background noise floor at the the particular location for an entire day.

Unfortunately, we could not record the data continuosly.

But we were able to take the screenshots of the SmartRF Tool at hourly intervals. Hope this is sufficient to get the idea of what is happening.

We could notice only a slight change in disturbance/interference. We observed that the noise level remains close to -100dbm from 6PM to 10PM and then gradually reduces to -105dbm. It is only a slight change. I am not sure whether this could affect the PER to that extent.

I am attaching some of the screenshots at different time intervals for your reference (file names are in chronological time : starts from evening to next day afternoon)

//SivaNoiseFloorTest.zip

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

Interesting.

From this it doesn't look like background noise is the root cause.

How are the modules powered? If they are powered from mains could power supply noise be an issue?

Have you manage to look into what happens at 6 pm on the locations you have issues?

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

Hi again,

The modules are connected to laptops, so they powered from laptop USB ports. The laptop chargers are not connected to power. So power supply could not be the issue.

Unfortunately, because of this Covid-19, our engineers were not able to visit the site location. But when we visited the site during our first test, there was no noticeable event at 6pm in the evening.

It is just a commercial road in a tier-2 city. Anyways, will try to observe for abnormalities.

But is there any lead from here or any way forward for debugging?

//Siva

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

And no process that start on the PC at 6 pm?

0 Sith over 5 years ago in reply to TER

Prodigy 140 points

No, there is no process in the laptop that start at 6pm.

Also, the same behaviour is observed in purely battery powered nodes as well. (Directly connected to battery rather than to a laptop)

0 TER over 5 years ago in reply to Sith

TI__Guru**** 317180 points

Have you been able to replicate the behavior at locations you have full access to?

Sub-1 GHz

Sub-1 GHz forum

CC1310: Launchpad - PER varies with time - same location - 865Mhz to 867MHz