Doorbell ML Application
Description
These applications are designed for doorbell systems, leveraging on-device machine learning to detect the presence of a person within the camera’s field of view. Upon detection, the system captures and processes images to provide visual context such as high-resolution stills or a sequence of preroll images leading up to the event. This use case combines features from multiple SDK sample applications, including jpeg_preroll and image_stitching, to deliver a comprehensive visual snapshot that enhances detection reliability and situational awareness.
The latest example structure uses a common application source tree with board-specific hardware setup kept under hw/<BOARD>/. For this app:
Common application sources such as
main.c,uc_jpeg_preroll.c, anduc_jpeg_preroll.hstay in the app root.Application defconfigs are stored under
configs/.Board and hardware-specific setup is selected from
hw/<BOARD>/, for examplehw/SR110_RDK/.
The application can also be exported and built as a standalone app repository. In that flow, keep this app in its own directory, point SRSDK_DIR to the SDK root, and build from the app directory itself. For the full application workflow model, see Astra MCU SDK User Guide.
Supported Boards
This application supports:
SR110_RDK
Select the defconfig that matches your target board, and the build system will pick the corresponding board-specific hardware setup from hw/<BOARD>/.
Prerequisites
Choose one setup path:
Test Case Selection
Before building, choose the testcase defconfig that matches both your target board and the transfer mode you want to validate.
You can:
Select the required defconfig directly from the application’s
configs/directory.Run
make list_defconfigsfrom the application directory to list all supported defconfigs.
Available defconfigs:
sr110_rdk_cm55_doorbell_gpio_wakeup_defconfigsr110_rdk_cm55_doorbell_spi_preroll_defconfigsr110_rdk_cm55_doorbell_timer_wakeup_defconfigsr110_rdk_cm55_serial_camera_door_bell_gpio_wakeup_defconfigsr110_rdk_cm55_serial_camera_door_bell_timer_wakeup_defconfig
For this app, the default defconfig is:
sr110_rdk_cm55_doorbell_timer_wakeup_defconfig
Building and Flashing the Example using VS Code and CLI
Use the VS Code flow described in the SR110 guide and the VS Code Extension guide:
Build (VS Code):
Open Build and Deploy → Build Configurations.
Select the doorbell project configuration in the Project Configuration dropdown.
Build with Build (SDK+Project) for the first build, or Build (Project) for rebuilds.
Build (CLI):
Build from the application directory itself:
cd <sdk-root>/examples/vision_examples/uc_jpeg_preroll export SRSDK_DIR=<sdk-root> make <app_defconfig> BUILD=SRSDK
For faster rebuilds when only app code changes, reuse the app-local installed SDK package:
cd <sdk-root>/examples/vision_examples/uc_jpeg_preroll export SRSDK_DIR=<sdk-root> make build
If this app has been exported to its own repository, use the same commands from that exported app directory after setting
SRSDK_DIRto the SDK root.
CLI build outputs
The build process will produce the necessary .elf or .axf files for deployment with the installed package.
Flash and Image Generation (VS Code):
Open the Astra MCU SDK VS Code Extension and connect to the Debug IC USB port on the Astra Machina Micro Kit.
Refer to the Astra MCU SDK User Guide for detailed setup steps.
Generate firmware binaries using Build and Deploy → Image Conversion.
Select the required
.axfor.elffile. If the use case is built using the VS Code extension, the file path will be auto-populated.
Flash the application using Build and Deploy → Image Flashing.
Select SWD/JTAG as the interface.
Choose the respective image bins and click Run.
Flash (CLI):
Activate the SDK venv (required for image generation tools):
# Linux/macOS source <sdk-root>/.venv/bin/activate # Windows PowerShell .\.venv\Scripts\Activate.ps1
Generate flash image:
cd <sdk-root>/tools/srsdk_image_generator python srsdk_image_generator.py \ -B0 \ -flash_image \ -sdk_secured \ -spk "<sdk-root>/tools/srsdk_image_generator/Inputs/spk_rc4_1_0_secure_otpk.bin" \ -apbl "<sdk-root>/tools/srsdk_image_generator/Inputs/sr100_b0_bootloader_ver_0x012F_ASIC.axf" \ -m55_image "<sdk-root>/examples/vision_examples/uc_jpeg_preroll/out/sr110_cm55_fw/release/sr110_cm55_fw.elf" \ -flash_type "GD25LE128" \ -flash_freq "67"
Flash the firmware image:
cd <sdk-root> python tools/openocd/scripts/flash_xspi_tcl.py \ --cfg_path tools/openocd/configs/sr110_m55.cfg \ --image tools/srsdk_image_generator/Output/B0_Flash/B0_flash_full_image_GD25LE128_67Mhz_secured.bin \ --erase-all
Running the Application using VS Code Extension
Windows note: Ensure the USB drivers are installed for streaming. See the Zadig steps in
SR110 Build and Flash with VS Code.
In VS Code, open Video Streamer from the Synaptics sidebar.

For logging output, click SERIAL MONITOR and connect to the DAP logger port on J14.
To make it easier to identify, ensure only J14 is plugged in (not J13).
The logger port is not guaranteed to be consistent across OSes. As a starting point:
Windows: try the lower-numbered J14 COM port first.
Linux/macOS: try the higher-numbered J14 port first.
If you do not see logs after a reset, switch to the other J14 port.
Doorbell application automatically connects to Video Streamer upon reset.
On person detection, video streamer opens with the captured frame and preroll context images saved to
video_stream_output/overlayed_frames.
Adapting Pipeline for Custom Object Detection Models
This person detection pipeline can be adapted to work with custom object detection models. However, certain validation steps and potential modifications are required to ensure compatibility.
Prerequisites for Model Compatibility
Before adapting this pipeline for another object detection model, you must verify the following:
1. Model Format Requirements
Your object detection model should be in
.tfliteformatThe model should produce similar output tensor structure (bounding boxes, confidence scores)
2. Vela Compiler Compatibility Check
Step 1: Analyze Original Model
Load your
door_bell_flash(384x512).tflitefile in NetronDocument the output tensors:
Tensor names
Tensor identifiers/indexes
Quantization parameters (scale and offset values)
Tensor dimensions
Step 2: Compile with Vela
Pass your model through the Vela compiler to generate
model_vela.binormodel_vela.tfliteAnalyze the Vela-compiled model in Netron using the same steps as above
Step 3: Compare Outputs Compare the following between original and Vela-compiled models:
Output tensor indexes/identifiers: Verify if they remain in the same order
Quantization parameters: Check if scale and offset values are preserved
Tensor dimensions: Ensure dimensions match your expected output format
Pipeline Adaptation Process
Case 1: No Changes Required
If the Vela compilation preserves:
✅ Output tensor indexes in the same order
✅ Same quantization scale and offset values
Result: You can proceed with the existing pipeline without modifications.
Case 2: Modifications Required
If the Vela compilation changes:
❌ Output tensor index order
❌ Quantization parameters
Required Actions: Modify the pipeline code as described below.
Code Modifications
If your model’s output tensor indexes change after Vela compilation, you need to update the tensor parameter assignments in uc_jpeg_preroll.c:
Location: detection_post_process function
Original Code:
g_box1_params = &g_all_tens_params[0];
g_box2_params = &g_all_tens_params[1];
g_cls_params = &g_all_tens_params[2];
Modified Code: Update the array indexes according to your Vela-compiled model’s output tensor identifiers:
// Example: If your model_vela output has different tensor order
g_box1_params = &g_all_tens_params[X]; // Replace X with actual index from Netron
g_box2_params = &g_all_tens_params[Y]; // Replace Y with actual index from Netron
g_cls_params = &g_all_tens_params[Z]; // Replace Z with actual index from Netron