CC1314R10: Data loss from sensors

Hi Veselin,

this sounds like the RX queue gets filled up but the transmission window is getting to short to transmit all of it.
The sensor will only go in orphan state when it looses the connection to the collector. Because of that it seems like the connection is up.

Can you please help me with:
1. Which phy settings are you using?
2. How often do you send data and how long is the message?
3. How many sensors are connected to one collector. Do you connect 64 sensors?

Kind regards,
Theo

Hi Theo,

1.You can find attached the collector.syscfg file.
2.Message is 1 byte, send every 1 min.
3.Yes 64.

collector - syscfg file.zip

Kind regards,

Veselin

Hi Veselin,

thank you for sharing your configuration.

Comparing the settings to our test data: https://www.ti.com/lit/swra782 I would expect a low packet error rate but that should not be an issue since the stack implements automatic resending if this is detected. Also with this configuration there should be no message overhead.

Can you explain me how you notice that messages are lost and how the communication in the network is set up focusing on:
- When and how do you observe the message loss?
- Are all sending a message every minute at the same moment?

Kind regards,
Theo

Hi Theo,

We don't see dataIndCB called for each new message, but sensor receives data confirm message, because we don't see orphaned sensors.

All sensors randomly upload data not at same moment.

Kind regards,

Veselin

Hi Veselin,

how are you observing the dataIndCB?

The sensors will report data based on the reporting interval. Do you use the resending functionality if data is not acknowledged?

Kind regards,
Theo

Hi Theo,

Observing by adding message to UART every time when function called and we see missed messaged. What is "resending functionality" how we can use it?

Kind regards,

Veselin

Hi Veselin,

Can you share with me how you print the data to the UART? This can not be done in the callback as it will interfere with the message sending. Instead you can run it as separate thread or from another process.

The resending is automatically done by the stack when it does not receive an acknowledgement. You use it automatically for all acknowledgeable messages.

Kind regards,
Theo 

Hi, Theo

CUI_retVal_t CUI_writeString(void * _buffer, size_t _size)
{
    SemaphoreP_pend(gUartSem, SemaphoreP_WAIT_FOREVER);
    // Check pre-conditions
    if((gUartHandle == NULL) || (_buffer == NULL) || (_size > sizeof(gTxBuff)))
    {
        return CUI_UART_FAILURE;
    }


    gTxSent = 0;
    if(_size!=0){
      gTxLen = _size;
      memcpy(gTxBuff, _buffer, _size);
    }
    else{
        sprintf((char*)gTxBuff,"%s\n",(char*)_buffer);
        gTxLen=strlen((char*)gTxBuff);
    }



    UART2_write(gUartHandle, (const void*)gTxBuff, gTxLen, NULL);

    return CUI_SUCCESS;
}

Kind regards,

Veselin

Hi Veselin,

please send me the snippet where you call it in your code so that I can check if it interferes with the stack.

Is there a specific reason why you call the semaphore before checking the pre-conditions?

Kind regards,
Theo

Hi, Theo

Attached you can find the code.

Kind regards,

Veselin

extraction.zip

Hi Theo,
We made different test and it seems the problem exist even with one connected sensor.
We created network with 1 collector and 1 sensor working on fixed frequency 863.1MHz with Timeout for collector - 2sec. and keep alive for sensor - 1sec.
The data observing in TeraTerm via UART and in the same time in SmartRFStudio7.
In SmartRFStudio7 wasn't detected errors, but in the TeraTErm there're 5.
Attached are the 2 file logs with 30 messages comparison.

Kind regards,
Veselin

comparison of messages between UART and SmartRF.zip

Hi Veselin,

looking at your log: what exactly means "CF sensor". Please explain me what I should look at exactly.

In general if you use such a fast tracking interval of 1 s you should at least use a polling interval of 500 ms to avoid that data gets queued up.

If you want to see exactly which packets are sent you can use a packet sniffer to capture them: https://dr-download.ti.com/secure/design-tools-simulation/calculation-tool/MD-r3ewsc0OIX/1.10.0/SmartRF_Packet_Sniffer2_1.10.0.zip 
A guide can be found here: https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_7_41_00_17/docs/ti154stack/html/ti154stack/packet-sniffer.html?highlight=wireshark#

I'm looking forward to your explanations to help you resolve this.

Kind regards,
Theo

Hi Theo,

The UART data that i sent was from the collector and show address of the sensor from which receives data at the moment of the receiving.
Sensor just periodically sends data and right after send poll request for downlink data to collector (NBCN Mode).
The "CF addr" show the address of the sensor that cause communication failure.

Kind regards,
Veselin

Hi Veselin,

unfortunately I still don't understand the kind of error.
In the logs that you shared it looks like all packets are received.

Do you receive a malformated packet, is it CRC error or what exactly is the error?

Did you check with the packet sniffer what is actually sent?

Kind regards,
Theo

Hi Veselin,

unfortunately I still don't understand the kind of error.
In the logs that you shared it looks like all packets are received.

Do you receive a malformated packet, is it CRC error or what exactly is the error?

Did you check with the packet sniffer what is actually sent?

Kind regards,
Theo

Hi Theo,

Thank you for your response, what is good way for find missed packets between stack and app? Thanks.

Hi Veselin,

every time that the mac layer receives data the dataIndCB() (sensor.c) is called. Depending on the command id that the message is carrying application code is executed.

You could for example increment a counter for every incoming packet and do the same on the collector for every sent packet. Then you could add an event in the collector and sensor process (sensor.c, collector.c) that writes this counter to the UART.

But to get a deeper insight on what is sent over the air I would really recommend you to set up a packet sniffer as previously recommended. With this you can see every packet that is actually sent and check if you observe any weird packets.

Kind regards,
Theo

Hi Theo,

We successfully set packet sniffer that work with Wireshark.

We set group with 1 collector and 9 sensors (timeout interval on collector is set to 19sec., keep alive time on the sensors is set to 10sec.)

Attached you can find extraction from Wireshark and Uart terminal.

The "CF addr:" that we see in the terminal show the address of the sensor from which the collector didn't receive data message in the required time.

In the Wireshark we see that the collector didn't receive data message from the sensor (only request on which he didn't respond) and some seconds after that the terminal show the "CF addr:"

How we need to proceed after this captured data?

Kind regards,
Veselin

comparison between uart and wireshark.zip