Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We have seen some 20737 units that advertise but do not respond to connection attempts. One conjecture is that these units have defective or insensitive receivers. We would like to add a receiver sensitivity test to our factory test flow.
I see the functions blecm_StartRevieverTest() (with its amusing spelling) and blecm_EndTest(), and I see how mbt.cpp uses HCI "equivalents" of those functions.
It's unclear, though, how one gets the receiver test results back from those API calls. In mbt.cpp, the "number of packets received" result comes back as part of an HCI response packet. For systems like ours, with no HCI UART access, that avenue is not available.
How would one actually use the "Reveiver" test API in practice?
I have read the document in question many times - assuming that it is Manufacturing-Bluetooth-Test-Tool.pdf . It does not address the issue raised in the question. That tool uses the HCI UART interface. As my question stated, our design does not have access to the HCI UART, so the tool cannot be used.
The question is about the API calls that provide similar functionality - but seem to be missing a crucial part of the result.