• TI Thinks Resolved

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

Expert 1750 points

Replies: 14

Views: 184

Part Number: CC1352P

Hi,

I am using CC1352P as collector with transmit power 12 dBm and CC1352R as Sensor with transmit power 12 dBm.

The following are the details i used in CM and Sensor

1 Non-beacon mode 

2. SDK3.3

3. 50 Kbps speed 

4. 863Mhz.

Sensor is sending a message to Collector but collector is not sending acknowledge to sensor. So in our application we are sending same message with time stamp. 

we have added data confirmation callback function messages to both collector and sensor.

we observe No Ack in sensor log. Collector is not performing any work at that time. what could be the reason?

What are the solution approaches for this scenario.

  • 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???

  • Genius 17965 points

    In reply to mamatha dasari:

    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

  • In reply to 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.

  • Genius 17965 points

    In reply to mamatha dasari:

    When you tell the MAC layer to send a message, you need to trigger a dataReq.

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

    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? 

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

  • In reply to AB:

    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

  • In reply to mamatha dasari:

    Hi,

    Can Someone reply to the above query?

    Thanks & Regards

    Haricharan

  • Genius 17965 points

    In reply to Haricharan sarpatwar:

    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.

  • In reply to AB:

    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.

  • Genius 17965 points

    In reply to mamatha dasari:

    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.

  • In reply to AB:

    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???