CC1352P: Sensor is sending repeatedly messages to Collector but collector is not sending acknowledge to sensor.

Part Number: CC1352R

Hi all,

mode : non beacon mode

operating frequency : 863 frequency 

one sensor is connected to a collector. the sensor is sending data to the collector for every 10 sec and polling only once after data sending.  the collector receives data but not sent ack to the sensor.  the collector received 1000 data points from the sensor. Out of 1000 data points the sensor didn't receive ack from collector for 110 times.  

1. What are all possible reasons for communication failure??

2. is sensor will get data confirmation(datacnfCB function) for every retry  of data transmission or after maximum retries???

Hello mamatha,

1. What are all possible reasons for communication failure??

It is difficult to tell why you are seeing this.

Can you show me the dataReq options you are sending to the MAC when sending messages to the collector?

Can you also check the sensorStats(it can be found in sensor.c) in your code? Maybe print them out? They should tell you how many retries, acks, nacks, messages successfully sent, total mesages sent, etc..

2. is sensor will get data confirmation(datacnfCB function) for every retry  of data transmission or after maximum retries???

retries are not taken into consideration in the total message count, if you sent a message and it retried 2/3 until it successfully received an ACK it will count as a single message sent. In other words, the datcnfCB gets triggered after the maximum number of retries. The error code should be 0x59

Regards,

AB

Hello AB, 

Thanks for the reply.

Can you show me the dataReq options you are sending to the MAC when sending messages to the collector?

What does the dataReq option mean??

Can you also check the sensorStats(it can be found in sensor.c) in your code? Maybe print them out? They should tell you how many retries, acks, nacks, messages successfully sent, total mesages sent, etc..

I am printing  sensorStats in code,  getting count but  not getting a reason for ack missing.  whatever data is sent by sensor, that data is reached to collector but not getting ack from collector to sensor.

If the collector is getting the data and the sensor is not getting acks, can you show me the relevant stats number in sensorStats struct? 

These are sensorstats values

Sensor_msgStats.join attempts =1;

Sensor_msgStats.joinFails = 0;

Sensor_msgStats.msgsAttempted =1929;

Sensor_msgStats.msgsSent = 1701;

Sensor_msgStats.trackingRequests =0;(we are not using tracking and config messages)

Sensor_msgStats.trackingRequests = 0;

Sensor_msgStats.trackingResponseSent = 0;

Sensor_msgStats.configRequests =0;

Sensor_msgStats.configResponseAttempts =0;

Sensor_msgStats.configResponseSent = 0;

Sensor_msgStats.channelAccessFailures = 0;

Sensor_msgStats.macAckFailures = 228; 

Sensor_msgStats.otherDataRequestFailures =0;

Sensor_msgStats.syncLossIndications =38;

Sensor_msgStats.rxDecryptFailures =0;

Sensor_msgStats.txEncryptFailures = 0;

Sensor_msgStats.resetCount =0;

Sensor_msgStats.lastResetReason =0;

Sensor_msgStats.joinTime = 3583;

Sensor_msgStats.interimDelay =1100;

Sensor_msgStats.numBroadcastMsgRcvd = 0;

Sensor_msgStats.numBroadcastMsglost = 0;

Sensor_msgStats.avgE2EDelay = 37;  what is the  Average end to end delay ?

Sensor_msgStats.worstCaseE2EDelay = 216;

Does the collector get 3 messages(retries) per instance since it is not ack?

No, collector is receiving only once per one instance. 

This is done in the sendMsg() function. Can you check the parameters passed to the MAC layer?

I attached parameters which are passing to mac layer

Hi,

Can Someone reply to the above query?

Thanks & Regards

Haricharan

The E2E delay is the time it takes the device to send a message(request) and get a response back(ACK) from the collector. 

ok, it seems you are getting some ack failures for sure, but also some sync losses.

Can you show the intervals at which you send these messages?

It seems like you are using the UART driver... why are you not using the CSF to send these messages? 

The reason I ask, is because doing these UART operations in the middle of a CB could be causing the device to lose important time critical operations.

The way we use UART and serial printing by default on the ssf and csf file is by filling up a buffer that only gets printed when the Device is in the IDLE task, this ensure real time operation.

Can you show the intervals at which you send these messages? 

sensor is sending data for every 10 sec.

It seems like you are using the UART driver... Why are you not using the CSF to send these messages?

In sensor, I am using UART only for debugging purposes.

10 seconds is more than enough time, this is a good interval.

Remove the UART lines, and let me know if you still see the same problem.

Hi AB,

I am facing a problem with uart write callback. I am writing  55 bytes on uart, out of  55bytes 33 bytes are printing properly but remaining 22 bytes are printing 0xFF on docklight. I attached UART code here   

unsigned char Uart_Init(void)
{
// Semaphore Setup
Semaphore_Params_init(&gSemParams);
//set all sems in this module to be binary sems
gSemParams.mode = Semaphore_Mode_BINARY;

Semaphore_construct(&gUartSemStruct, 1, &gSemParams);
gUartSem = Semaphore_handle(&gUartSemStruct);

UART_init();
/* Create a UART with data processing off. */
UART_Params_init(&uartParams);
uartParams.baudRate = 115200;
uartParams.writeDataMode = UART_DATA_BINARY;
uartParams.readDataMode = UART_DATA_BINARY ;
uartParams.readEcho = UART_ECHO_OFF;
uartParams.readMode= UART_MODE_CALLBACK;
uartParams.dataLength = UART_LEN_8;
uartParams.stopBits = UART_STOP_ONE;
uartParams.writeMode = UART_MODE_CALLBACK;// UART_MODE_CALLBACK//UART_MODE_BLOCKING
uartParams.readReturnMode = UART_RETURN_FULL;
uartParams.readTimeout = UART_WAIT_FOREVER;
uartParams.readCallback = UartReadCallback;
uartParams.writeCallback = UartWriteCB;

uart = UART_open(CONFIG_UART_0, &uartParams);

if (uart == NULL)
{
/* UART_open() failed */
//while (1);
return 0;
}

UART_control(uart, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL);
uiReturnValue = UART_read(uart, cUartRxBuff, BUFF_LEN);
gUartWriteComplete = true;
return 1;
}

static void UartWriteCB(UART_Handle _handle, void *_buf, size_t _size)
{
uint32_t key = HwiP_disable();
gUartWriteComplete = true;
/* Exit critical section */
HwiP_restore(key);
}

static void UartReadCallback(UART_Handle _handle, void *_buf, size_t _size)
{
// Make sure we received all expected bytes
if (_size)
{
// If cleared, then read it
if(cUartBuf[0] == 0)
{
// Copy bytes from RX buffer to TX buffer
for(size_t i = 0; i < _size; i++)
{
cUartBuf[i] = ((uint8_t*)_buf)[i];
}
}
memset(_buf, '\0', _size);
Csf_setUart0Clock(1);
}
else
{
// Handle error or call to UART_readCancel()
UART_readCancel(uart);
}
}

bool UARTwriteString(char *_buffer, size_t _size)
{
//Error if no buffer
if((uart == NULL) || (_buffer == NULL) )
{
return 0;
}

bool uartReady = false;
/* Enter critical section so this function is thread safe*/
uint32_t key = HwiP_disable();
if (gUartWriteComplete)
{
uartReady = true;
}

/* Exit critical section */
HwiP_restore(key);

Semaphore_pend(gUartSem, BIOS_WAIT_FOREVER);

if (!uartReady)
{
/*
* If the uart driver is not yet done with the previous call to
* UART_write, then we can attempt to wait a small period of time.
*
* let's sleep 5000 ticks at 1000 tick intervals and keep checking
* on the readiness of the UART driver.
*
* If it never becomes ready, we have no choice but to abandon this
* UART_write call by returning CUI_PREV_WRITE_UNFINISHED.
*/
uint8_t i;
for (i = 0; i < 10; i++)
{
Task_sleep(1000);
uint32_t key = HwiP_disable();
if (gUartWriteComplete)
{
uartReady = true;
}
/* Exit critical section */
HwiP_restore(key);
if (uartReady)
{
break;
}
}

// If it still isn't ready, the only option we have is to ignore
// this print and hope that it wont be noticeable
if (!uartReady)
{
return 0;
}
}

key = HwiP_disable();
gUartWriteComplete = false;
HwiP_restore(key);

// UART_write ret val ignored because we are in callback mode. The result
// will always be zero.
if (0 != UART_write(uart,_buffer, _size))
{
Semaphore_post(gUartSem);
return 0;
}

Semaphore_post(gUartSem);
return 1;
}

why am i not getting proper data on docklight when i send more than 32bytes???

Can Someone reply to the above query?

Haricharan,

As I mentioned before, I think you are interfering with the UART that is already being used by the application.

Did you make sure to disable CUI, and Display MODE UART on the application?

Thank you AB,

Did you make sure to disable CUI, and Display MODE UART on the application?

yes,We disabled the Display_MODE_UART, CUI .