Hello,
I have a project that requires a throughput floor of 1 Mbps. Recently decided to purchase (2) of the CC1352P development boards. My plan was to test the TI BLE5 stack and chipset with help facilitated from TI's SmartRF Studio. I am interested in examining throughput and PER as function of RSSI for the various BLE5 PHY modes. Unfortunately I discovered two software problems that are inhibiting testing with your products.
1. SmartRF Studio sets a limit on MTU/Payload dummy data that can be sent with each exchange to ~37 bytes. This is 1/8th of maximum payload size defined by BLE5 (~ 250 bytes IIRC). This severely limits the throughput. Even when reducing the period between packet transmissions to 1 ms I can only achieve ~ 600-700 kbps in 1M PHY mode. In the post related to this, TI personnel on this forum recommended changes to the rfPacketTx driver and configuration files found in the SDK that would allow BLE5 stack and higher payload. At time of writing I am using SDK 3.30. The drivers in this SDK utilize a system configuration file that generates the necessary settings files, it does not use the smartrf_settings.c/h files from previous SDKs AFAIK - so the solution in the related post does not work in SDK 3.30.
2. Additionally, it appears as if the SmartRF Studio application itself is limited in the size of packet payload it can process. With a 37 byte payload, reducing the transmit interval wait to 1 ms occasionally produced a buffer overflow in the application that caused a failure to continue RX. It appears as if this is a design issue with the architecture of the application. Any thoughts on this? Wondering - even if I do get the rfPacketTx to do higher payloads, I don't think I will be able to receive with the SmartRF Studio application due to the overflow issue. Unfortunate to think I would have to manipulate rfPacketRx code also.
Maybe I am missing something but I was under the impression when I purchased this product that the SmartRF ecosystem would allow me to quickly evaluate the BLE performance of the chipset. As an RF engineer looking into quickly determining if this chipset would be right for my application, I am frustrated by the fact that I may now need to go in and start altering driver code just to test the chipset - especially when that is what the SmartRF application is marketed as being for!
Do any other forum members/TI staff have a solution for these issues? Perhaps I am just not seeing it in the forums. Thanks for the help!