The frequency of the crystal oscillator connected to A111 is specified between 20-80MHz. It must be at least 20.625MHz in order for the SPI frequency to reach 50MHz which is necessary in order to obtain the 1500Hz update rate.
Is there a benefit to use a crystal or external reference clock with higher frequency than 26MHz to the A111?
The main purpose of having a range for the input frequency on XIN between 20MHz and 80 MHz is to allow for a flexible hardware integration. It allows the customer to choose a crystal oscillator more freely and an already existing reference clock in the design could be reused for the A111. It must however be ensured that the crystal or the reference clock that is to be used fulfils the requirements stated in the datasheet.
The use of a crystal oscillator or reference clock with higher frequency could benefit the accuracy of the sensor measurement if the relative increase in phase noise is smaller or equal to the relative increase in frequency. The use of a crystal oscillator or reference clock with higher frequency will however increase the power consumption of the A111.
Acconeer have extended support for STM32L476 (ST-Micro) and STMCubeIDE.
Any MCU based on ARM CM0, CM4 and CM7 can be used by downloading the corresponding SDK and by implementing the HAL layer as described in the HAL SW Integration User Guide.
Accessing A111 registers via the SPI interface is not supported. The main reason is that to make changes to the registers, one must have knowledge about proprietary design details which are confidential. The performance of the sensor also depends on nontrivial calibration and signal processing software that is included in the software libraries.
The sensor is controlled using the Software API “Radar Services” and all settings are done using this API. A description of how to change the settings as well as a description of the radar data provided by the different services is documented in the user guides that are available on the Acconeer webpage.
No, you can use open source software such as gdb and openocd.
This is the direct leakage caused by TX leaking over to RX directly without bouncing on a real object. Increasing the start range solves the problem.
QUESTION: Test result after S/W Compile shows reaching distance no further than 40cm. It is normal or do we expet to see up to 2m?
ANSWER: This is as expected, the test program you are running is probably set to measure up to 40cm. To make other measurements you include other input parameters in the Distancestrongest API. For guidance please look at API user manual, found in doc/html,with index file, when extracting SW zip file to a new directory.