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.

CC1352P: Association Response Failed in sensor even the collector is with in <50 centimetre

Part Number: CC1352P

Hi,

I am using TI 15.4 stack collector and sensor with SDK 3.3?

We found a different issue during pairing, when pairing is on in the collector the sensor is placed nearby 50 CM. 

We kept debug logs in both Collector and sensor.

1. In collector after pairing was on, the sensor2 sends an association request but did not receive the association response from the collector.

2. The association response failure in the sensor2 occurred over 33 times. At the 34th-time sensor2 got an association response from the collector?

3. Why did the collector not responded to the sensor2 33 times and why the collector sends a 34th-time association response to the sensor.

4. Here in the field only one collector and two sensors are there. The sensor1 was transmitting data for every 10-sec interval. The sensor2 after trying 33 times paired to the collector and sends data normally.

 

  • Can you please provide information regarding what HW you are testing on?

    Are you using our LPs or have you made your own HW?

    I would strongly recommend that you test the HW first (either using SmartRF Studio, or the simple rfPacketRX and rfPacketTx examples from the SDK) to verify that your HW is OK and that your RSSI is as excepted, before start testing the sensor and collector example.

    If HW is found OK, please let us know if you if you have done any changes at all to the examples taken from the SDK.

    Be aware that there are different examples for the different LPs (P1, P-2, and P-4 LP), and that you must select the right one for our HW.

    BR

    Siri

  • Hi siri,

    We are using custom boards, also we tested the sample sensor boards which we have tested with packetrx and packettx examples and verified with smartrf studio we got RSSI in the tool as -60 if we keep the sensors near to another sensor at a distance of lessthan 3 meters. The sensors are without Enclosures during our testing.

    1. We have removed tracking in collector and polling is done only once in sensor, for every data sent to collector when reporting interval occurs.

    2. Also we used cc1352p1 with transmit power as 12dBm as collector and  cc1352r1 with transmit power 12dBm as sensor.

    The above changes we made.

    Please suggest if we need to change any thing in our application.

  • First of all, an RSSI of -60 dBm if you have 3 meters between the devices seems VERY low. When I  measure on my desk with 12 dBm output power, 2.5 m between TX and RX, I measure an RSSI of -31.

    Have you verified that your on your custom board, the antenna switch is set correctly depending on the current PHY configuration?

    I strongly recommend that you get the sensor and collector example up and running WITHOUT modification before you start modifying the code.

    This way it is easier to figure our where/what the problem might be.

    Siri

  • Hi siri,

    We have tested our modified firmware for over one month rigoursly with 50 sensors and it is working fine with our application.

    Also, we measure on our test setup with 12 dBm output power, 2.5 m between TX and RX, I measure an RSSI of -31. with plastic enclosures, it is -60dBm. The custom board has antenna placed correctly with current PHY configuration.

    During another testing at different location with 1 collector and 2 sensors we observe this issue of The association response failure in the sensor2 occurred over 33 times.

  • It is kind of hard to help debugging this when you claim that both your SW and your HW is OK. If both were OK, I guess you should not have any problems, but since you have, something must be wrong somewhere. In your case you are using custom HW with modified SW, meaning that we cannot reproduce this at our end. It is therefore important that we first try to figure out if the problem is SW or HW related. You can do this either my running unmodified SW on your custom HW, or test your modified SW on our known good HW (LPs).

    I will see if I can get someone else  also can advise you how to proceed the debugging.

    Siri

  • It would also be helpful if you can provide sniffer logs from the situation where things are failing.

    Siri

  • Hi Siri,

    I will send packet sniffer logs of association later, but presently I had encountered another issue, i.e., retry messages from sensor and collector not sending acknowledge t sensor. I had sniffer logs for this. Can you please check and confirm what are the things going over the air. Also, the association response does not send by the Collector maybe will come in the same category.

    Due to size constraint, I had removed hex data transferred from the sensor to the collector and some command data like the following

    Internet Protocol Version 4, Src: 192.168.1.3, Dst: 192.168.1.3
    User Datagram Protocol, Src Port: 17757, Dst Port: 17757

    TI 802.15.4GE SUN PHY without Mode Switch

    0000 05 9d cd 19 1e 00 4b 12 00 19 00 2a 42 3b 4e 39 ......K....*x;xx
    0010 44 43 44 31 39 31 45 30 30 34 42 31 32 30 30 3b xxxxxxxxxxxxxxx;
    0020 32 39 2e 31 37 3b 39 39 3b 32 30 32 30 2d 31 31 29.17;99;2020-11

    0030 2d 30 36 54 31 39 3a 34 32 3a 34 37 5a 3b 23 00 -06T19:42:47Z;#.
    0040 00 00 00 03 00 03 00 00 00 00 00 00 00 00 00 00 ................
    0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa ................
    0060 00 04 00 6e 00 00 00 00 00 00 00 2a 00 2e 00 e0 ...n.......*....
    0070 93 04 00 b8 0b 00 00 .......07-11-2020 - Copy.rar

  • Hi Siri, 

    There is one more query in the logs I have attached to the .png file which shows Bad FCS. Can I know the reason why this Bad FCS(Frame Check sequence) occurs?

    Also, note that the data is received by the collector without any duplicates even when the sensor retries two times when BAD FCS occurs.

  • Hi siri,

    We got this pairing issue of less than 50 cm at our customer location in Germany. We tested in India and never observe this situation up to now. Also we cannot get the packet sniffer logs at Germany location. The above packet sniffer logs are with my testing in india.

    Can I know, What could be the reasons why this pairing issue occurs at our customer location?

    Note: we are using 3.3 sdk and what if we updated our sdk to latest release can this solve the issue of no association response  or no ack from collector?

    As we found some issues are fixed with latest sdk

  • Hi Haricharan,

    Sorry for the late answer,

    Can you check whether you are getting any error messages or error return statuses in your application thread when this happens? I.e. check the return status of every api mac call. 

    It sounds like the RF frequency band you are using could be more busy in your Germany location. Just for debugging purposes, could you test with a different frequency band?