This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

InsightSIP AoA Demo kit

We have been looking at InsightSIPs AoA Demo kit (https://www.insightsip.com/products/bluetooth-smart-modules/isp1907) and are trying to understand the communication protocol used between the anchor board and the tag board.

We are wondering whether the source code or compiled firmware is available. Our understanding is that the firmware is based on a modified version of and older version of zephyr RTOS which was modified to add direction finding support. It is unclear from the documentation whether the firmware was developed by InsightSIP or Nordic.

Using the nRF Sniffer FW on a nRF52-DK, we have determined that the tag board periodically sends ADV_SCAN_IND packets with address c6:05:04:03:02:01 without any payload. We have also determined that the anchor board is entirely passive, not sending any packets (no SCAN_REQ, which is what we would expect).

Our understanding of the Bluetooth specification is that ADV_SCAN_IND packets are not supposed to carry CTE signals, since they do not have provisions for containing the CTEInfo byte. However, looking at the documentation for the RADIO peripheral on the nRF52833, it appears that it should be possible to transmit a CTE signal at the end of any packet regardless of what the Bluetooth spec says about it.

Is it correct that the RADIO-peripheral can append a CTE signal to arbitrary Bluetooth packets?

Are the CTE signals in the AoA Demo kit appended to the ADV_SCAN_IND packets or is there some additional communication happening between the tag and anchor boards?

We have tried using a nRF52833 devkit to send the same ADV_SCAN_IND packets we observed, with 160µs CTE enabled. Please find the firmware we wrote to achieve this under https://github.com/mhs-emlogic/nrf-standalone-cte.

When running this firmware on our devkit the anchor board prints messages indicating that it is receiving messages from the tag board, but the elevation/azimuth angles which are computed change erratically and appear to have no relation to the actual positioning of the devkit board. Sample output from the anchor board when running this firmware on the nRF52833 devkit is also available in the github repo, in the “anchor_board_output.txt” file.

Could it be that we are just configuring the DFE registers incorrectly? Is there any easy way for us to check this?

Parents Reply Children
  • The code used in the sample used with the InsightSiP solution is running a proprietary RF stack and is not Bluetooth compliant. This was developed as a quick solution for getting CTE over the air. The solution is not supported for further development. For SW development we recommend to use the nRF Connect SDK main branch, this is where work for Bluetooth compliant AoA/AoD is being performed.

Related