Welcome to Acconeer’s Developer Page. Here you will always find our latest SW releases for the different HW targets and OS that we currently support. You will also find the latest versions of our Datasheets and User Guides as well as Reference Applications and Tools via a link to our Github. Remember to check in continuously for updates and new content. Or, subscribe to our newsletter that will contain Release information about the latest release as well as other technical information that we would like to make available to you. You will also have the option to subscribe to our Company Newsletter.
This page will contain SW for all versions of Acconeer EVK (XC111 and XC112) and Modules (XM112) as well as SW for other micro processors’s.
You need to go through the Click Licence Procedure in order to achieve access.
You will need an account in order to access these files. Create one here.
Do you already have an Acconeer account? Log in here.
Forgot your password? Recover your password here.Would you like to receive updates on our company and products? Sign up for our newsletter here.
All our appplications and tools are available on our GitHub page.
Acconeer Exploration Tool
Acconeer Python Exploration Kit is a set of tools and examples for getting started with the Acconeer Evaluation kits. By seamlessly feeding radar data to your local machine, it allows you to quickly start exploring the world of Acconeer’s radar sensor technology.
In this section you will find all available documentation about Acconeer products. Datasheets as well as User Guides.
You will need an account in order to access these files. Create one here.
Do you already have an Acconeer account? Log in here.
Forgot your password? Recover your password here.Would you like to receive updates on our company and products? Sign up for our newsletter here.
In this section we will publish links to our instruction videos and demo videos on our Acconeer Youtube Channel.
HW
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.
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.
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.
SW
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.