This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: How to read the noise floor in TI15.4 stack?

Part Number: CC1310

My customer would like to add a new feature on their collector based on CC1310: they want the collector to be able to read the noise floor of the environment during packet exchange, and to send a warning through UART to the user when the noise floor is over a certain level.

For now, the idea is to leverage the LBT(Listen-Before-Talk) in the 15.4 stack, and to use the same value that the stack uses to determine if the LBT threshold is reached. The question is if this value can be read from application layer? Or is there any other suggestion to achieve this feature?

Best regards,

Shuyang

  • Hi Shuyang,

    I'll look into this with the SW developer team. Since you say LBT, are you using 868 MHz frequency band?

    Which mode are you using? (FH, beacon or non-beacon?)

    Cheers,

    Marie H

  • Hi Marie,

    The frequency band is 915MHz, I just realized that 915MHz uses CSMA/CA instead of LBT, sorry for the confusion.

    The custoemr uses non-beacon mode.

    Could you kindly suggest the way to read the noise floor under the frequency band and mode?

    Best regards,

    Shuyang

  • Hi Shuyang,

    Thank you for the clarification. I will try to get back to you tomorrow regarding this topic.

    Cheers,

    Marie H

  • Hi Shuyang,

    I'm sorry, because of Easter I was not able to consult with the SW developers. I will have to get back to you next week.

    Cheers,

    Marie

  • Hi Marie,

    Is there any documents or existing discussions that I can take a look first before SW team has a feedback? Thanks.

    BR,

    Shuyang

  • Hi Shuyang,

    Sorry, not in relation to TI 15.4-Stack.

    Cheers,

    Marie 

  • Hi Marie,

    Hope you had a nice holiday. Have you heard back from the R&D team?

    Best regards,

    Shuyang

  • Hi Shuyang,

    We don’t have any direct number for the noise floor. However, when the collector sends a packet, the callback message contains the number of retries necessary to send the packet. See ApiMac_mcpsDataCnf_t struct define in api_mac.c. If the number of retries is more than 0, the channel was occupied. I would suggest using this to establish a picture of how busy the channel is.

    Cheers,

    Marie H

  • Hi Marie,

    Thanks for the reply. Unfortunately this method is not feasible in the customer's use case, because their collector only receives data from the sensors and does not send data packet, so the collector won't get any message callback.

    I have an idea which may be useful to achieve the customer's needs, can you help verify if it is feasible? I'm thinking if the collector can initiate an energy detect scan periodicly and use the measurements in the scancnf to determine the noise. I found a uint8_t value pEnergyDetect in the ApiMac_mlmeScanCnf_t, as the comment states, this value is proportional to the RSSI value measured.

    /*! The list of energy measurements, one for each channel scanned.
    * Energy measurements are proportional to the RSSI value measured */
    uint8_t *pEnergyDetect;

    My question is:

    1. If the energy detect scan can be itiniated after connection is established?

    2. What is the exact relationship between pEnergyDetect and the RSSI?

    Best regards,

    Shuyang

  • Hi Shuyang,

    The energy detect scan cannot be used after the connection is established. This disturbs the state machine of the collector.

    But it should be possible to use the energy detect scan with some modifications to the LLC, we are investigating this. 

    Regards,

    Sid

  • Thanks, Sid. Looking forward to the result of your reserach!

    BR,

    Shuyang

  • Hi Shuyang, 

    Please can you also elaborate on the intent of this feature?

    When they read the noise level in a channel and notify over UART and take action, there is a very likely chance that the environment would have changed.

    Regards,

    Sid 

  • They want to check the overall noise level of the channel, the idea is to read the noise level periodicly after the collector starts, the user can be notified and act accordingly, such as switch to another channel.

    BR,

    Shuyang

  • Hi Shuyang, 

    The energy detect scan can be performed, but this triggers the scanCnfCb, which we need to handle appropriately and also make sure the cllc process state does not change with this energy scan. 

    I am not entirely sure about other implications regarding this. I shall consult RnD and let you know. 

    Regards,
    Sid

  • Hi Shuyang, 

    I got some feedback from my colleagues. It should be possible to use that API in the application to perform an energy scan to determine the noise floor.

    The formula to get the RSSI value from the returned magnitude values is as follows:

    rssi = ((ScanResult * 85)/255) – 90

    But having said this, if the collector is not sending any packets, is it crucial for the collector to know about noise in the environment?

    Thanks for the reply. Unfortunately this method is not feasible in the customer's use case, because their collector only receives data from the sensors and does not send data packet, so the collector won't get any message callback.

    Also, additional things to be consider:

    1. Like I mentioned above, when using the sendScanReq(), on completion of the request, the scanCnfCb() is triggered. This handles the state change of the logical link controller. This state change should be avoided when using the API from the user application.(for example, use appropriate if checks).

    2.  When the collector is performing these energy scans, it cannot receive messages from the sensors. So there will be lost data if the sensors are sending the data to the collector when this energy scan is happening. So the scheduling needs to be taken care of by the application.

    Regards,

    Sid

  • Hi Sid,

    Thanks for the guidance, I added an if statement to avoid the state change in scancnfcb:

    static void scanCnfCb(ApiMac_mlmeScanCnf_t *pData)
    {
        if((pData->status == ApiMac_status_success) || (pData->status
                          == ApiMac_status_noBeacon))
        {
            if(pData->scanType == ApiMac_scantype_energyDetect)
            {
                if(coordInfoBlock.currentCllcState < Cllc_states_started)
                {
                    switchState(Cllc_coordStates_scanActive);
                }
            }
            ......
        }
    }

    And now I'm able to initialize an energy detect scan after forming a network.

    I found the energy detect results related with the scan duration. With the default scan duration = 5, the results in *pEnergyDetect are always above 220, which are much higher than the converted RSSI value in SmartRF Studio I used for comparison. But if the scan duration = 1, the results are close.

    I'm wondering if the scan returns the maximum result captured during the entire scan duration, and there happens to be a message from the other sensors in the air during the period? Or are there any other reasons?

    Best regards,

    Shuyang

  • Hi Shuyang, 

    Great that you have it working. I will consult RnD and get back to you with the possible explanation for the behavior. 

    Regards,
    Sid

  • Hi Shuyang,

    Your observations regarding the energy scan are consistent with what is expected. 

    During the energy scan, the maximum value of RSSI during the entire scan period is reported back on each channel. 

    To over come this, you can perform the energy scan for a duration of 100ms.

    Also, have a periodic energy scan with a sufficiently large period (for example 10 seconds) to make sure that the collector is available for communication most of the time. 

    Regards,

    Sid

  • Hi Sid,

    Understood. Thanks for the detailed explanation and advice, I will convey them to the customer.

    Best regards,

    Shuyang