Developer Log in | Recover your password | Subscribe to our newsletter | create an account

Yes, you need to update the macro ACC_BOARD_REF_FREQ in the board file.

The crystal oscillator (B1) and clock buffer (N14) on the XC111 could be used to generate external clock references in order to test this use case. The components are not mounted since the default clock solution is a crystal oscillator connected directly to A111 on XR111.

XC111 product brief

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.

No, the unused sensor GPIOs (GPIO0-GPIO4) were connected to resistors R1003-R1006 on XC111 as an option for sensor synchronization. That is however handled by the host that activates the sensors one at the time.

XC111 Product Brief

Unused GPIOs (GPIO0-GPIO4) should be grounded. They can be hard grounded, no need to ground them via resistors. These pins are grounded via resistors in the XC111 to allow maximum flexibility.

It should be noted that since version 1.0 of the A111 datasheet, GPIO0-GPIO4 have been changed to GND pins.

On the XC111 there is a levelshifter (TXB0104PWR, reference designator N11) for GPIO5 that is bidirectional. The reason is that XC111 was designed to be as flexible as possible. However, GPIO5 (which is renamed INTERRUPT in the latest datasheet for A111) is only used as an interrupt from the sensor A111 to the host MCU. Thus it can be changed to a unidirectional component.

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 worked with STM32L475 and STM32L476 (ST-Micro), and ATSAME70Q21A-AN (ATMEL).

The STM32L476 evk is available for download on Acconeer’s website. (Includes BowerBin, Envelope, and Distance Peak)

There is currently no public evk built for Atmel SAM-E70 but it can be delivered on request.

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.

Yes the Single Thread version can be run on OS free platforms

For version <= 1.6.2:

Use the following API command:

‘acc_log_set_level(ACC_LOG_LEVEL_VERBOSE, NULL);’

For version > 1.6.2:

Update the log_level in the HAL struct that is registered at activation:

‘acc_hal_t hal = acc_driver_hal_get_implementation();

hal.log.log_level = ACC_LOG_LEVEL_DEBUG;

acc_rss_activate_with_hal(&hal)’

For version <= 1.6.2:

Use the following API command:

‘acc_log_set_level(ACC_LOG_LEVEL_ERROR, NULL);’

For version > 1.6.2:

Update the log_level in the HAL struct that is registered at activation:

‘acc_hal_t hal = acc_driver_hal_get_implementation();

hal.log.log_level = ACC_LOG_LEVEL_ERROR;

acc_rss_activate_with_hal(&hal)’

It is not possible to set a constant amplitude threshold that works for all sensors since the amplitude might differ between A111 samples. The best way to solve this is to calibrate each sensor individually.

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.

It depends on the use case. Currently the minimum requirement for the least complex use case ”power bins” is  200 kB flash, 60 kB RAM. 

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.