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.

CC2652P: Porting SDK from SDK 4.2 to 5.1 reduced data frequency drastically.

Part Number: CC2652P
Other Parts Discussed in Thread: CC1352P, SYSCONFIG

Hi,

Our Transmitter(CC2652P) are transmitting at 100 data packets per second to RX (CC1352P4). From 4 Tx i.e. 400 data packets per seconds.

As per my previous thread I got to know that SDK 4.2 doesn't support high PA which was a Bug. I upgraded my SDK to 5.1 and saw a good RSSI and checked the same on RF Analyzer and it was active.

But,

This change in SDK has lead to dropping of data that I received in CC1352P from 4 slaves (CC2652P). With Earlier SDK I was able to get 98% data on Bench test and 90% in Automotive Environment. But with new SDK I was able to see MAX- 70% data. I saw the slaves are connected but unable to send data.

1. Why is this issue with new SDK. Which I saw is that the Slaves are Unable to send data for 20- 50 seconds which is very critical. As per the Migration Guide I have copied all Application files Including Simple Peripheral.c and .h and just copied sysconfig manually.

2. My SDK on Tx is 5.1 and Rx is 4.2 will this effect in frequency. 

3. In SDK 5.1 I have seen an option to disable Update Parameters. But once I disable the Update parameter on Tx side I see this error.


Please suggest solutions to this.


Regards

  • Hi,

    Thank you for the provided information. Could you specify which sample project your project is based on? Can you verify what values are set for the PDU size and the PDU amount in Sysconfig? Could you compare this with the values set in your original project?

    Best Regards,

    Jan

  • Hi,

    We are using Simple Central and Simple Peripheral Projects as base for our code for Rx and Tx respectively.
    PDU Max Number of Connections - 4, Max Number of PDU - 5, Max Size of PDU (bytes) - 69.
    I compared this with original project its same.

    Regards

  • Hi,

    Got it. Thank you for verifying. Can you try increasing the PDU size and the PDU amount and re-testing? Afterwards, can you share if the behavior is the same or if you are able to detect a difference in the amount of data detected?

    Best Regards,

    Jan

  • Hi Jan,

    Yes will do the testing and share you the difference if seen.

    Can you please help answer point 3 and also please confirm if having sdk 5.1 on tx and 4.2 on Rx will impact anything. 

    Regards,
    Ankit

  • Hi Ankit,

    With regards to question 2, the SDK version should not have an impact on the frequency. If possible, I would recommend using the latest SDK version because several bugs have been fixed throughout the SDK releases and several features have been added.. I would also recommend using the same SDK for both projects if possible to ease development and not have to worry about switching between SDKs.

    With regards to question 3, those errors are occurring because those constants are not being defined anymore. Those constants are defined within the SysConfig auto-generated files if the Send Parameter Update Request option is checked. If it is not checked, then those constants are no longer defined automatically. These constants are used to specify the desired connection parameters to request after a connection. If no parameter update request will be sent, then these parameters are no longer needed.

    Best Regards,

    Jan

  • Hi Jan,

    I test my Slaves with Max Number of PDU - 8, Max Size of PDU (bytes) - 250. I saw good Data percentage above 90 percentage in few case only ( Line of Sight). But I saw some issues Slaves faced while connection. 

    1. I saw Slaves sending good data and suddenly they stops sending data for 3-4 seconds and then again connects again.
    2. If any 1 slave disconnects that leads to issue with connection of another slaves as well.
    3. While doing the same test just with No line of sight (ex. Slaves placed on ground and Rx(CC1352P) above ground I saw less percentage say 70%.
    4. Also with the SMA Connector the results are bad i.e. 60% sometimes and sometimes it rocked around 85%.

    Can you please suggest some more parameters which can effect these performance.

    Note: I have 4 Slaves Transmitting around 100 packets per second each i.e. 4 x 100 = 400 pkts Rx by CC1352P4 Launchpad.


    Regards,
    Ankit

  • Hi Ankit,

    Thank you for the additional details. Could you specify what is the connection interval that you are using? Could you try changing the connection interval to 7.5ms, if it is not already, and see if the behavior is still present?

    Best Regards,

    Jan

  • Hi Jan,

    My Connection Intervals are as follows 

    Transmitter Side : Connection Update Params Request : 12.5 - 42.5 

    We choose this Connection Request as we were facing Reconnection Issues with Low and less connection Interval

    On Receiver Side also we have same Connection Interval 12.5 - 42.5. 

    As we need data packets to come every 10 ms and not in burst and we have limitation of max delay of 40ms we cannot go above 40ms as we then get packets in pair of 4-4-4-4.

    Please suggest us some good connection Interval as per your experience which will give us consistent results and good reconnection as well. Can you please specify connection Interval in Min and Max by 7.5 I guess you want me to set 7.5 - 42.5.

    EDIT 1 : I tried Connection Interval 7.5-42.5 and the results are worst 50% data only received. The connection worked fine for around 150 seconds and then the data stopped coming. and comes every 6 to 7 second once.

    Regards,
    Ankit

  • Hi Ankit,

    Thank you for performing this test. Can you try one more test where the minimum and maximum connection interval is set to 7.5ms on both the central and peripheral projects? I would also recommend referencing the Bluetooth 5 Throughput Demo ( central | peripheral ). These examples implement a high throughput data streaming via notifications which may be helpful for your project's development. Can you take a BLE Sniffer log that showcase the connection with the data being received at the expected rate and that also shows the bad data percentage?

    Best Regards,

    Jan

  • Hi Jan,

    I tried 7.5 across all connection interval, I saw that I am able to connect to only 1 Slave even if all slaves are ON.
    I also checked that removing the supply of that slave which is connected leads to the successfully connection with other slaves.
    FOr Ex. if my SLAVE 1 is connected and all slaves are ON, if I disconnect the same SLAVE 2 will connect then, SO ONE CONNECTION IS ONLY POSSIBLE AT ONCE NOT 4.

    Regards,
    Ankit Tomar

  • Hi Ankit,

    Got it. Thank you for running this additional test. As mentioned previously we have a Throughput Example available in our GitHub page (Central | Peripheral) that may be helpful. This example sends notifications constantly with low data loss at a high rate. Can you try importing the project and referencing the sysconfig used in the throughput examples? Can you try using the BLE settings used in the SysConfig for the throughput example in your project?

    Best Regards,

    Jan

  • Hi Jan,

    Can you please confirm if my understanding is correct.

    I need to look at the Sysconfig settings of Central and Peripheral from the GitHub project and copy the same into my syscong. The Application code and rest remains the same.

    Also can you confirm if this is okay with 4 slaves as we have 4 slaves and with proper reconnection and low data loss.

    Regards,
    Ankit Tomar

  • Hi Ankit,

    Yes, this will help us determine if the Sysconfig settings are related to the issue you are observing or if the cause is located somewhere else in the project. Our devices should be able to connect to 4 peripheral devices when operated in the central role without any issues.

    Best Regards,

    Jan

  • Hi Jan,

    I did some tests with the settings suggested by you.

    Unfortunately, I can just see the connection established but the slaves are unable to send the data at all.  Though Isaw most of the settings similar.

    I would love to know the difference between External and Internal RF Bias will this cause any effect ?

    Regards,
    Ankit

  • Hi Ankit,

    It is possible that using an incorrect RF Bias setting may have a negative impact on RF performance. Please ensure the selected bias mode matches the hardware configuration of your board. Is there a custom board being used somewhere in the network? Could you provide your sysconfig file? Can you take a BLE sniffer capture of the behavior? I believe a capture may help us greatly in resolving this issue.

    Best Regards,

    Jan

  • Hi Jan,

    Yes my 4 Slaves are custom board and has an external Balun matched with Antenna used. We have used differential mode. I was just worried about Internal or External Biased. Since I have an Balun should I use External Bias and as we have used differential Rf so External Bias Differential Mode.

    SysConfig Files - I would love to share these over mail.

    BLE Sniffer - I am very new to this can you share some documents to capture the same using your Sniffer tool.

    Regards,
    Ankit Tomar

  • Hi Ankit,

    I have accepted your friend request. Thank you for the information. Are you able to observe the same performance when using LaunchPads? Can you flash your project and re-run the test using LaunchPads only (no custom boards), do you see this behavior? It is possible that this may be related to the hardware design. This will help us isolate if this behavior is being caused by HW or SW. A dedicated BLE sniffer such as a Frontline or an Ellisys would be ideal as this will give us a lot of information about what is going on over the air and what is happening in each BLE packet. They are a great debugging tool and very useful during development.

    Best Regards,

    Jan

  • Hi Jan,

    As per your suggestion I have tried testing via LE coded. 

    I saw same behavior as earlier. I saw that all 4 connections are established but only 2 sensors are sending the data not all 4 sensors are sending the data always.

    My PDU is also Max 250. Can you suggest something. My No of PDU is 8 does increasing this will help me ?

    Regards,
    Ankit Tomar

  • Hi Ankit,

    Thank you for providing me the requested information via email. At this point, I would suggest to run a quick test using SmartRF Studio 7, Can you try performing packet test and continuous RF test using the BLE configuration in SmartRF Studio 7? Can you verify if you still see the same performance? This will help us determine if the issue lies more on the SW or in the HW/RF environment.

    Best Regards,

    Jan