https://community.element14.com/products/roadtest/The element14 RoadTests are an extensive collection of detailed product reviews for engineers that are written by members of the group. The reviews cover a wide range of new B2B products used for in the engineering design and development process. Product ren-USTelligent Community 12https://community.element14.com/products/roadtest/rv/roadtest_reviews/1915/evaluation_of_microchip_ev06m52a_curiosity_nano_evaluation_kitThu, 04 Jun 2026 06:11:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:93a6cd23-4fa3-4c29-bc89-beffeab94370neerajrd821. Unboxing and First Impressions: Hardware Readiness The image illustrates the unboxing of the Microchip EV06M52A Curiosity Nano Evaluation Kit from its distinct red "Development Tools" packaging. The kit arrives with the main development board and two detached 14-pin berg strip headers. Because a USB Type-C cable is not included in the retail box, developers will need to supply their own to power and interface with the unit. The evaluation kit is cleverly designed to accommodate two entirely different debugging workflows: Internal Debugging (Ready Out-of-the-Box): The board features an on-board PICkit On-Board 4 (PKOB4) programmer and debugger seamlessly connected to the target PIC16F13145 microcontroller. For standard evaluation, firmware development, and testing of the internal Configurable Logic Block (CLB), no soldering is required . You can interact with the target MCU immediately via the USB-C port. External Debugging & Extension (Requires Assembly): The two included berg strips are provided for optional expansion. If you need to route signals to a breadboard, interface with external target chips, or use the on-board debugger to program an external MCU, these headers will need to be permanently attached to the board using a soldering iron. 2. Microchip EV06M52A Curiosity Nano Evaluation Kit connected with Windows 10 PC Upon connecting the EV06M52A Curiosity Nano Evaluation Kit to a Windows 10 machine, the plug-and-play convenience of the platform is immediately apparent. The on-board debugger automatically configures the necessary drivers and enumerates as a standard USB Mass Storage Class (MSC) device after loading MPLAB-X-IDE & IPE. As shown in the system explorer, it successfully mounts a virtual flash drive labeled CURIOSITY . This Mass Storage functionality is an excellent workflow feature; not only does it quickly confirm that the host PC recognizes the hardware, but it also allows developers to flash the PIC16F13145 simply by dragging and dropping compiled .hex files directly onto the drive, entirely bypassing the need to open a heavy IDE for rapid firmware updates. 3. Device Enumeration & Connectivity shown in Device manager in windows 10 A quick look at the Windows Device Manager confirms that the EV06M52A Curiosity Nano utilizes a well-designed composite USB configuration. Upon connection, the on-board debugger (PKOB4) automatically enumerates and exposes three distinct interfaces, each serving a critical development function: Microchip Tools: This entry represents the primary hardware debugger interface. It allows the MPLAB X IDE to seamlessly connect to the board, enabling full-speed programming, single-stepping, and in-circuit debugging of the PIC16F13145. USB Serial Device (COM Port): The board includes a built-in Virtual COM Port (CDC) bridge—in this instance, mapped to COM3. This is a highly convenient feature that links the target MCU's UART directly to the host PC. It eliminates the need for external FTDI cables or serial adapters when monitoring console output or sending serial commands. USB Mass Storage Device: This interface drives the drag-and-drop programming functionality. By enumerating as a mass storage device, the board can mount the "CURIOSITY" flash drive, allowing developers to program the target controller by simply copying a compiled .hex file directly over to it. This composite approach ensures that power, debugging, programming, and serial communications are all handled elegantly through a single USB Type-C connection. 4. Toolchain Integration: Connecting via MPLAB IPE To verify the programming interface and hardware communication independently of the main development IDE, I launched the MPLAB Integrated Programming Environment (IPE) v6.30 . The software quickly recognized the board's on-board debugger as a "PKOB nano" tool. Upon initiating the connection to the target PIC16F13145, the output console provided a clean and successful initialization sequence. Breaking down the connection log reveals several key operational details: Device Pack Initialization: The environment automatically identifies and utilizes the correct Device Family Pack ( PIC16F1xxxx_DFP, 1.29.444 ), ensuring the latest programming specifications are applied to the target. Target Power Delivery: The log explicitly confirms that the PKOB nano is actively supplying power to the target MCU at 5.00 volts ( PKOB nano is supplying power to the target (5.00 volts) ). This verifies that the on-board regulator is functioning correctly, allowing for immediate bench testing without any external bench supplies. Silicon Verification: The API successfully executes the read commands to query the configuration memory. It accurately detects the target device as the PIC16F13145 , returning a Device ID of 0x3129 and a Revision ID of 0x2003 . Overall, the MPLAB IPE demonstrates stable, error-free communication with the Curiosity Nano right out of the gate. The hardware handshake is seamless, establishing a highly reliable foundation for flashing custom .hex binaries throughout the rest of this evaluation. 5. Memory Erase and Target Reset Control To ensure a completely clean slate before flashing custom firmware, I executed a full device erase using the MPLAB IPE. Testing the erase function is a great way to verify that the on-board PKOB nano debugger has full read, write, and wipe authority over the target PIC16F13145 without any protection faults. The console output from this operation highlights a few excellent automated features of the Microchip toolchain: Intelligent Config Restoration: The log shows that immediately following the bulk Erase command, the API writes 10 bytes to the Configuration Memory (address 0x01000E ). This is a critical safety mechanism; the tool automatically restores default configuration bits (such as debug enable and oscillator settings) so the chip does not accidentally lock you out or enter an unrecoverable state after a wipe. User ID Management: The sequence also writes 8 bytes to the User ID memory space ( 0x010000 ). For developers planning to take this silicon into production, having easy IDE access to write version control or serial numbers directly to the ID space is highly convenient. Hardware Reset Control: The log concludes with the message *** Hold In Reset mode is enabled *** . This demonstrates that the PKOB nano actively controls the target's reset line ( MCLR ). Holding the chip in reset after programming or erasing is a vital debugging feature, as it prevents the microcontroller from immediately attempting to execute code or driving pins high before the developer manually releases it. Overall, the erase sequence was rapid, and the IPE handled all the necessary memory boundaries and configuration restorations seamlessly behind the scenes. 6. Firmware Deployment: Flashing the Application With the board successfully communicating and erased, the next step was to validate the core toolchain workflow by flashing a standard baseline application. Using the MPLAB IPE, I loaded a compiled blinky.hex binary and initiated the programming sequence. The console output provides an excellent, transparent view of how the PKOB nano handles the deployment of the firmware to the PIC16F13145: Automated Preparation: Upon starting the programming operation, the IPE first calculates the required memory ranges based on the hex file and executes a fresh bulk Erase command. This ensures no residual data conflicts with the incoming firmware. Target Memory Allocation: The log clearly details exactly where the code is being mapped: Program Memory (Flash): The toolchain writes 768 bytes starting at address 0x000000 up to 0x17f . This tiny footprint is exactly what you would expect for a highly optimized "Blinky" application on an 8-bit PIC architecture. Configuration & ID Spaces: Alongside the main application code, the programmer seamlessly writes 10 bytes to the Configuration memory ( 0x01000E ) and 8 bytes to the User ID memory ( 0x010000 ). This ensures all oscillator settings, watchdog timers, and developer ID tags are perfectly synced with the flashed code. Controlled Execution: Just like the erase operation, the programming sequence concludes by returning a Programming complete status and immediately enabling the *** Hold In Reset mode *** . This is a fantastic safety feature for hardware testing, allowing the developer to attach probes or prepare a test setup before manually releasing the MCU to execute the newly flashed code. Overall, the deployment was swift and flawless. The IPE and PKOB nano handled the address parsing and memory writing seamlessly, proving that getting code onto the Curiosity Nano is a highly reliable, frictionless process.Microchip Nano Curiosity Kitdevelopment kitmicrocontrollerPIC16F13276,PIC18F-Q35, EFM8LB1Evaluation Boardsnot yethttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1911/my_first_experience_with_arduino_uno_q_-_the_new_hybrid_single_board_computerSat, 30 May 2026 19:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d863f576-d5e4-4350-9ef3-71994134acdbtaifurIntroduction I started my embedded system journey in 2009 with the PIC microcontroller. The PIC16F877A was my first microcontroller, and I still love it because it was my first love in the world of MCUs. The journey was challenging because I had to build everything from scratch. I made my own serial programmer, spending countless hours troubleshooting and fixing errors. I learned every step through trial and error. I still remember the moment when I successfully uploaded my very first program to the PIC16F877A using my own programmer. It was just a tiny LED blinking program, but at that moment, it felt magical to me. At that moment, I felt like I had touched the sky. It was more than just running a program; it was the moment I truly fell in love with the world of microcontrollers and embedded systems. After a few months, probably in early 2011, I was introduced to the Arduino UNO. Arduino was not very popular at that time, but it was just starting to gain attention and showed enormous potential. Arduino changed the way I looked at microcontrollers and made the learning journey incredibly easy. There was no need for an external programmer, no frustrating fuse settings, and no constant tension about the power supply. Arduino made everything feel simple and accessible. I made many interesting and fun projects using Arduino. In 2012, Raspberry Pi officially entered the market and quickly became one of the most popular single-board computers among hobbyists and the maker community. Raspberry Pi made embedded and DIY computing accessible to everyone for just $35. But Raspberry Pi has some limitations. Since it runs a full-fledged operating system, it is not well-suited for real-time hardware control, as Linux introduces its own overhead and background tasks. Pi also lacks built-in analog-to-digital conversion (ADC) functionality. If you want to build a complex embedded system that reads multiple analog sensors, drives motors in real time, and simultaneously performs heavy vision processing, neither Arduino nor Raspberry Pi alone can perfectly handle everything. The common solution is to use an Arduino for low-level real-time tasks like sensor reading and motor control, while the Raspberry Pi handles high-level processing such as computer vision and AI. The two boards then communicate through USB or UART, working together as a complete system. However, this setup can sometimes introduce communication stability issues because you are trying to connect two completely different architectures. It may also introduce timing mismatches, and even minor issues such as vibration or a loose serial cable can disrupt communication. To address all these challenges, the Arduino UNO Q came into the picture. The UNO Q integrated these two different architectures, the "acting brain" and the "thinking brain", onto a single PCB, and the two brains communicate with each other using RPC bridge. First Look The Arduino UNO Q comes with the traditional UNO form factor and features a modern USB-C connector instead of the USB Type-B port used in the traditional Arduino UNO. The pin headers are fully compatible with the classic Arduino UNO, while the board also includes an additional QWIIC connector and an onboard 8x13 LED matrix. The top side of the board includes the main processor, LPDDR4 RAM, power management IC (PMIC), WiFi and BLE communication module, and USB-C bridge IC. The bottom side of the board includes the microcontroller and the eMMC storage IC. There are also two advanced expansion headers on the bottom side. The image is taken from the official Arduino website. A bit of hardware details: The Thinking Brain (MPU): Qualcomm Dragonwing QRB2210 Quad Core Arm Cortex-A53 processor Qualcomm Adreno GPU and Qualcomm Hexagon DSP for AI Inference and digital signal processing Dual ISP Video Processing Integrated WiFi 5 and Bluetooth 5.0 connectivity The Acting Brain (MCU): STM32U585 Arm® Cortex®-M33 up to 160 MHz 2 MB flash memory 786 kB SRAM Floating Point Unit Accurate ADC High-speed GPIO Arduino offers RPC Bridge (Remote Procedure Call) for effortless communication between the MPU and MCU. The image is taken from the YouTube video: https://www.youtube.com/watch?v=jr3KN-LEUUM&t=547s Getting Started with the UNO Q Before connecting the UNO Q to my computer and getting my hands dirty, I wanted to take a look at the official Arduino Getting Started guide. So, I searched for “Arduino UNO Q” and found the official Arduino UNO Q page here . The official page includes all the necessary resources, including the pinout, schematics, CAD files, technical specifications, tutorials, and the recommended libraries. I was looking for the getting-started guide, so from the tutorials tab, I clicked on UNO Q User Manual, which includes all the necessary information for getting started. As per the user manual, the following hardware and software are required to get started with the board. Hardware Requirements (1x) UNO Q 2GB or UNO Q 4GB USB-C® cable (1x) USB-C multiport adapter (dongle) with external power delivery (1x You can use any USB-C dongle with external power delivery capabilities except for Apple ones. Software Requirements Arduino App Lab Thanks to Element14 and Arduino for sending all the hardware components as the Road Test kit. From the page, I learned that the Arduino UNO Q can be used in two different modes. One is the single-board computer mode, where I need to connect a mouse, keyboard, and monitor to the Arduino UNO Q using a USB-C multiport adapter. The other is the PC-hosted mode, where I simply need to connect the board to my PC using a USB-C cable. I am a bit lazy, so I decided to try the Arduino UNO Q in PC-hosted mode first to avoid connecting all the external peripherals. For the PC-hosted setup, the host PC needs to have the Arduino App Lab IDE installed. So, I downloaded the Arduino App Lab IDE from the link provided on the page and installed it on my Windows PC. After installing the App Lab, I double-clicked on the App Lab desktop icon to run it and got the following message. From the message, I realized that I needed to connect the Arduino UNO Q to my PC before running the App Lab. So, I connected the board using a USB-C cable and was greeted by a beautiful blue Arduino logo animation on the dot-matrix LEDs. In addition, the green power LED turned on, and #3 green LEDs started blinking. I ran the App Lab again and got the following message: So, the Arduino UNO Q board is detected automatically. I clicked on the board name, and App Lab redirected me to the following configuration interface. I gave a name to the board (I tried a name with _ but failed) and clicked on the next button at the bottom. It guided me to the network setup window, but I was getting the following error message, though my WiFi password was correct. I tried multiple times and got the same message. So, I skipped the network setup option. After setting the Linux password, App Lab started successfully with several examples. I opened the Blink LED example as my first experiment. After opening the Blink LED app, a notification appeared to update the App Lab. I updated the app, but then I noticed that App Lab was stuck on the board configuration page. I clicked the “Next” button, but nothing happened. I closed the app and ran it again, but I still faced the same problem. I also connected and disconnected the Arduino UNO Q board several times, but the issue remained unchanged. Finally, after restarting my PC, the problem was solved. The updated App Lab ran with some new examples. I opened the Blink LED example, read the README document, and realized that it is quite different from the traditional Blink LED examples used with other Arduino boards. In this example, both the MPU and MCU are involved in controlling the LED. The MPU, programmed in Python, calculates the timing interval, while the MCU, programmed using traditional Arduino programming (C++), actually turns the LED ON and OFF based on the timing information provided by the MPU. The Router Bridge enables communication between the MPU and MCU. The following screenshot shows the structure of the Blink LED program. After successfully testing the Blink LED program, I became curious to try a few more examples. However, I realized that most of the examples depend on external hardware such as a camera or microphone, and require the Arduino UNO Q to run either in network mode or single-board computer mode. Before moving on to those examples, I decided to write and test a small program in host mode. For this experiment, I connected a 4-digit seven-segment display module to the Arduino UNO Q using male-to-female jumper wires. My goal is to create a digital clock where the time will be read by the MPU using Python, then transferred to the MCU through the Router Bridge, and finally displayed on the seven-segment module. For my project, the following Python code is used. From the screenshot, it can be clearly seen that the current time is being displayed in the Python console. The hour and minute values are then combined into a single number and transmitted to the MCU through the Router Bridge. The following Arduino code was used to receive the time value and display it to the seven-segment display. The following image shows the hardware setup and the result. So, I successfully modified an example program to build my own project without any difficulties. This is the end of the experiment, where my Arduino UNO Q was connected via a USB-C cable and serving in host mode. In the next stage of my experiment, I am going to connect my board in network mode. Testing the Network Mode I connected the USB-C Hub to the Arduino board and powered the hub externally. The Arduino started successfully in single-board computer mode and became discoverable from the Arduino App Lab. I then opened the Blink LED with UI example and ran the application. The browser window opened automatically, and the application worked as expected. The documentation provided with the app was also very clear and easy to understand. In this stage, I was curious to check whether SSH was working or not. So, I opened PuTTY and entered the IP address of the Arduino UNO Q. The board responded immediately, confirming that the SSH connection was working properly. After accepting, I entered the name and password for the board and got the following response. In the next step, I tried to run an object detection application on the Arduino UNO Q. Normally, object detection requires a USB camera connected directly to the board. However, I found an example application called “Detect Object on Smartphone Camera.” Before connecting an external camera to the Arduino UNO Q, I was interested in testing object detection using my smartphone camera with the board. I carefully read the documentation to understand how the application works. After that, I downloaded the Arduino IoT Cloud Remote app and logged into it successfully. From the App Lab, I clicked on the Run button. It took a few minutes to download and extract the required model and supporting files before deploying the application to the board. After the setup was completed, the following browser window opened automatically, displaying a QR code to connect the smartphone camera. Now it was time to connect the smartphone camera. To do that, I selected the “Stream Phone Camera to UNO Q” option from the smartphone app. During this step, I encountered an interesting issue. Initially, I was unable to connect the Arduino UNO Q board to my router’s Wi-Fi network, possibly because my Wi-Fi SSID contained an “&” character. To work around the problem, I enabled the hotspot on my iPhone and connected both my PC and the Arduino board to the hotspot network. However, when I tried to connect the smartphone camera to the UNO Q, the app displayed a message indicating that the phone itself also needed to be connected to the same Wi-Fi network. It was a strange issue at first, but logically understandable. The phone was using mobile data while simultaneously acting as a Wi-Fi hotspot. To resolve the connection problem, I renamed my Wi-Fi SSID by removing the “&” character, and after that, the connection worked successfully. The Arduino UNO Q then became discoverable from my phone. I connected the board to the mobile app using the password displayed in the browser window, and the detection result appeared instantly in the browser. It successfully detected my keyboard, mouse, and monitor with a high level of confidence. I was very impressed with the response time of the system. It also demonstrated excellent performance in detecting multiple objects within a single frame, as shown in the following screenshot. It detected my Amazon Echo device as a cup. I also tried detecting my headphones, a Li-ion battery, and my 3D printer, but the model was unable to recognize them successfully. In the next phase, I am going to connect my web camera to the Arduino UNO Q. The next day............... Working with the Camera I connected my USB webcam through the USB-C hub and then opened the Arduino App Lab. After launching the “Face Detection on Camera” example application, a browser window opened automatically, and the camera successfully detected me without any driver-related issues. The application detected my face with around 85% confidence. Initially, the response was almost real-time, but after a short while, I noticed nearly a 10-second delay in the camera streaming. This could possibly be caused by my slow network connection, although I am not completely sure. Even with a musk, the accuracy was quite good. After completing the face detection experiment, I opened the “Detect Object on Camera” application. The app ran perfectly and successfully detected me as a person. However, after a short time, I noticed some distortion and visual artifacts in the camera image, as shown in the screenshot below. I disconnected and reconnected the board’s power, then relaunched the App Lab and ran the example application again. This time, I tried detecting my phone, but after a short while, I encountered the same issue again. I was curious to understand why this was happening. Suddenly, one thing came to mind: I had been using a 2A smartphone power adapter to power the board through the external USB hub. I decided to try the power adapter that came with the Roadtest kit instead. After connecting the Multicomp Pro MP009260 30W power supply, the problem was solved. I successfully tried the Person Classifier on Camera . I tried to read Barcode and QR code using the QR and Barcode Scanner example app, but I failed to read either. I tried from a different distance and angle, but I was out of luck. I suspected the codes I had tested were too small, so I generated a few QR codes and barcodes on my computer and tried again. This time, the app successfully read them. Experimenting with QWIIC Sensors In this stage, I connected and tested the SparkFun QWIIC Environmental Combo Sensor with the Arduino UNO Q. The connection process was straightforward, thanks to the QWIIC ecosystem's plug-and-play design. I simply connected the QWIIC Environmental Combo Sensor to the Arduino UNO Q's QWIIC connector using a short QWIIC cable, no soldering or complex wiring required. After connecting the QWIIC sensor, the next step is to write the code. I created a new App in App Lab named "Environmental Monitoring." I downloaded two libraries (SparkFun BME280 & SparkFun CCS811) for the sensor. Then, with the help of the example programs, I wrote the code for reading the sensor data. I was facing problem interfacing the sensor using I2C, and suddenly I realized that the QWIIC port is connected to Wire1 instead of Wire. So, I modified the code and successfully got the sensor data as shown in the screenshot. The following is the full sketch for the MCU side. Sending data to MQTT Broker I used the bridge library to send the sensor data to the MPU. On the MPU side, I used a Python script to process the sensor data and send it to an MQTT broker. I looked for the MQTT Brick but did not find any Brick for MQTT, so I decided to use the paho-mqtt package for writing the Python code and sending the data over MQTT. The paho-mqtt client is not preinstalled in Arduino UNO Q. So, connected the UNO Q in network mode, open SSH, and use the following command to install the client: The paho-mqtt client was successfully installed without any issues. Then I wrote the following Python script to receive data from the MCU and send it to an MQTT Broker. The MQTT client was successfully connected and was publishing data to the MQTT broker on a specific topic for every sensor data received from the MCU. I used MQTT.fx to check whether the data has reached to the broker or not. I subscribed to that specific topic and successfully received the data. Installing Node-RED For installing Node-RED, I installed Node.js successfully on the Arduino UNO Q board using the command: . Node.js v20 was installed automatically. For installing any node package, I need npm. So, I installed npm as it is not already installed. Then I tried to install Node-RED using the npm command, and I got the following error messages. I tried multiple times but got the same result. I tried to find a tutorial on installing Node-RED on an Arduino Uno Q, but did not find one. I tried to solve the issues in different ways I found on the internet, but the problem has not been solved yet. Next day.............. I did some research on the internet, and I started to install Node-RED again with a fresh mind on my Arduino UNO Q board. I browsed the official Node-RED page and accessed the option to install Node-RED on Debian-based OS like Raspberry Pi. I entered the following command on the board shell: Everything went fine without installing the Node-Red core: I entered the following command and tried again: Still got the same result. Then I tried to install it with a specific version of Node with the following command: I was fortunate, and this time everything was installed successfully. I started Node-RED using the following command: I got the error message that to run Node-RED, I need to update Node.js version 18 or later, but I have v16. No, it is time to update the Node.js version again. To install Node.js version 18, I entered the following command in the shell: Then I enter the command: Node version 18 was installed successfully. After updating Node.js, I tried to run Node-RED again, and this time it ran successfully. And Node-RED was loaded successfully. Making a Node-RED Project After installing Node-RED successfully, I want to make a simple flow to receive the MQTT message from the Arduino UNO Q and print the message in the debug console. The message was received and displayed successfully, as shown in the screenshot below. Then I made a dashboard to show all the environmental data received from the Arduino UNO Q to the MQTT Broker. Following is the node flow design for my dashboard project. The MQTT message contains JSON data, and the JSON string was separated using a simple function node. The function node contains the following code: And my dashboard looks like this with all the data visualization:Single Board Computerarduino uno qmicrocontroller baordRaspberry Pi, LattePanda, NVIDIA Jetson Orin NanoDevelopment Boards & ToolsAs this is a comparatively new board, software support is very limited. Very few example programs/projects are available. No official camera module is available till now. For connecting a USB web camera, a USB-C hub is required, which reduces the compactness of any project.https://community.element14.com/products/roadtest/rv/roadtest_reviews/1909/uno_q_headless_smart_cameraMon, 25 May 2026 22:20:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9ce27112-4639-4764-b3f3-e67d8ec5d270ralphjyOverview The Uno Q RoadTest caught my interest since there are relatively few entry level development boards that offer hybrid MPU/MCU architecture. The RPi5 does include the RP1 which is a dedicated IO controller, and maybe the most comparable board is the Radxa X4 which uses an Intel N100 and the RP2040. The Uno Q makes some interesting design tradeoffs. It uses a Qualcomm Dragonwing QRB2210 MPU which uses the lower performance A53 cores that are used in the RPi3. And it lacks the normal IO ports that are generally found on MPU boards (USB host, Ethernet, HDMI) for standalone operation. It depends on using a powered USB-C hub to provide that functionality. It also does not have the CSI and DSI connectors that you find on other MPU boards that allow easily interfacing cameras and displays. The pins for these functions are available on the JMEDIA connector on the underside of the board, but these IO are coming directly off the MPU at 1.8V levels. To utilize this functionality, you need to use an adapter or shield that provides the IO level translation and connectors for the 3.3V CSI and DSI. Shields should be available later this year. The tradeoff is to use USB cameras and displays through the USB hub. I wanted to see in this roadtest whether I could discover a use case that would be compelling to use the Uno Q. One of the highlighted features is the AppLab development environment that allows unified software development for both the MPU (Python) and MCU (C). This roadtest is going to be about fitness for use in the types of applications that I develop rather than verification of performance specifications. Other reviewers have done an excellent job of documenting the Uno Q hardware and setup, so I'm not going to repeat that except as it pertains to my specific application. I have also provided links at the end of the review to relevant posts that I made. . I have been doing a lot of Edge Vision AI, so there is some emphasis on that functionality. I’d like to determine the difficulty of interfacing different camera types (USB, IP, SPI). I would have liked to have tried CSI cameras, but there are currently no available adapters. The title of my roadtest, Uno Q Headless Smart Camera, reflects the end application that I am trying to achieve. Test Plan This is a description of what was included in this roadtest. Also, a list of tests that I wanted to do but did not complete due to schedule constraints. Setup and Software Installation The Uno Q comes with the Linux environment pre-installed with AppLab. AppLab needs some initial configuration which needs to be done using a direct USB connection to a PC host for data and power. I cover this in Arduino Uno Q - AppLab initial configuration and examples . AppLab automatically checks firmware and software status and will recommend updates. There are a couple of caveats: First, updating is a very resource intensive operation. Firmware updates require 10GB of free space on the host PC for downloading and unpacking the data. Second, there is a paradigm shift from the Standalone Arduino IDE. Even though the AppLab interface might be running on the PC, all of the source files for your applications are only stored on the Uno Q. Therefore, you need to be sure to backup those files before a firmware update because they will be overwritten. Configurations USB connected to PC Host Power is limited by the USB port (900mA for USB3) Standalone Requires USB hub for display and keyboard/mouse Headless Requires WiFi connection Headless with OTG adapter Provides power passthrough with single OTG USB port Example Tests Blink LED Blink LED with UI Blinking LED from Arduino Cloud Home climate monitoring and storage Weather forecast on LED matrix Detect Objects on Camera with USB Camera Custom Tests Home climate monitoring and storage with distance USB Audio with USB Speaker USB Drive for storage Web Browser Viewer for SPI Camera Capture Images from IP Camera using RTSP Object Detection Stream for IP Camera not using AppLab Object Detection Stream for IP Camera using AppLab Tests not completed Build and deploy custom model with Edge Impulse (test integration) Create and deploy custom Brick Linux and Arduino IDE operation with AppLab uninstalled Example tests Arduino has done a great job of providing many sample tests to demonstrate the features of the Uno Q and AppLab There are 29 apps provided in AppLab 0.7.9. The latest AppLab update available during my review timeframe was 0.7.0. The app repository is https://github.com/arduino/app-bricks-examples/tree/main/examples There are also 22 Bricks provided for use. A Brick is a pre-built, modular software component that adds advanced functionality (like a “super” library). These "plug-and-play" blocks bundle Python scripts, containers, and AI models to accelerate development. The Brick repository is https://github.com/arduino/app-bricks-py/tree/main/src/arduino/app_bricks The MQTT brick caught me eye, but it turns out that the MQTT functionality is embedded in the Arduino_Cloud brick and does not use a more general-purpose broker like Mosquitto. I guess I’ll do it the old-fashioned way by adding Mosquitto to my application as I don't intend to use the Arduino Cloud. Blink LED The standard test now demonstrates the hybrid MPU/MCU architecture. The Arduino sketch controls the GPIO and the LED hardware and the Python script handles the timing and state logic. The Router Bridge provides direct communication between Python and Arduino. Blink LED with UI This example toggles an LED on the board using a simple web user interface. The application listens for user input through a web browser and updates the LED state accordingly. It shows how to interact with hardware from a Linux environment and provides a basis for building more complex hardware-interfacing applications. The assets folder contains the frontend components of the application. Inside, you'll find the JavaScript source files along with the HTML and CSS files that make up the web user interface. The python folder includes the application backend. The interactive toggle switch UI is generated with JavaScript, while the Arduino sketch manages the LED hardware control. The Router Bridge enables communication between the web interface on the Linux processor and the microcontroller. Bricks Used: web_ui: Brick to create a web interface to display the LED control toggle switch. Blinking LED from Arduino Cloud This Blinking LED from Arduino Cloud example allows us to remotely control the onboard LED on the Arduino® UNO Q from the Arduino Cloud. The LED is controlled by creating a dashboard with a switch in the Arduino Cloud. Bricks Used: arduino_cloud: Brick to create a connection to the Arduino Cloud This example worked as intended. It does require some configuration (add device to cloud account and add app key in Arduino_Cloud Brick). I don’t generally use the Arduino Cloud as I normally run my own local Node-Red dashboard. The Cloud Free Plan also restricts use to 2 devices. I just tried it to verify that it works. Weather forecast on LED matrix The App fetches weather data from the open-meteo.com API for a specified city and converts weather codes into animated patterns on the 8 x 13 LED matrix. Each weather condition triggers its own distinctive animation sequence with carefully timed frame changes that simulate natural weather behavior. The Python® script handles API communication and weather processing, while the Arduino sketch manages LED matrix animations and polling. The Router Bridge enables parameter passing between the Python environment and the microcontroller. Bricks Used: weather_forecast: Brick to fetch weather data from the open-meteo.com API and convert weather codes into simple categories. The example defaults to showing the data from Turin on the LED matrix. I made a copy of it to modify the forecast for Portland, but apparently it only allows a city name which is not unique so I'm apparently getting the results for Portland, Maine. There is a provision in the API to enter GPS coordinates, but I didn't try that. Home climate monitoring and storage The Home Climate Monitoring example records temperature & humidity data from the Modulino® Thermo node, and streams it to a web interface. The data is stored on the board, where we can view the data from the latest 24 hour period. Bricks Used: dbstorage_tsstore - makes it possible to save, read, and manage time-based data. web_ui - used to host a web server on the board, serving HTML, CSS & JavaScript files. I decided to use this example because I wanted to try out the Modulino Thermo and the QWIIC interface. This was the first example app that failed to run. It had a linking failure during compilation. It is something related to Zephyr. One of the changes to the Arduino IDE used for AppLab is the replacement of the Mbed hardware libraries with Zephyr due to the end of Mbed support. I'm not completely sure what this error is, but an AI query suggested that Zephyr needed to recompile (due to an update) and it did not have permissions to update the sketch directory because examples are read only. I created a copy of the app which allows me to modify it and it worked without modifying the sketch source code. The app uses the WebUI Brick to publish data to a web browser to display the data. The browser URL is unoq_ipaddr:7000. Detect Objects on Camera The Detect Objects on Camera example lets you detect objects on a live feed from a USB camera and visualize bounding boxes around the detections in real-time. Note: This example must be run in Network Mode in the Arduino App Lab, since it requires a USB-C hub and a USB camera. I discovered that I had issues with the PC host USB data connection to AppLab when I was using the USB-C hub. Bricks Used: video_objectdetection - used for detecting objects in real time from a USB camera video stream. web_ui - used to host a web server on the board, serving HTML, CSS & JavaScript files. I did not use a USB-C hub for this example, but instead tried a OTG adapter with USB-C PD passthrough to connect the USB camera. That is covered in the post Arduino Uno Q and USB3 adapter with USB-C PD . . I initially had an OTG adapter that failed to switch the Uno Q into USB Host mode. I found a different one that worked and the USB camera was detected and the app ran successfully. The browser window at unoq_ipaddr:7000 showing the camera stream with bounding boxes and detection results. Custom Tests Home climate monitoring and storage with proximity detection For my first custom test I decided to modify the Home climate monitoring example to add proximity detection using a Modulino Distance module. I modified the Home climate monitoring app to display the temperature on the Uno Q LED matrix. I used proximity detection to only display data when a person is detected within 500mm. So in addition to the Thermo, I needed to add a Distance module. The setup is shown below. The Distance (TOF) module is on the left and the Thermo (temperature, humidity) module is on the right with daisy chaining to the QWIIC connector on the Uno Q. Here is a view of my app file structure. Basically the same as the original app. Two Bricks are used Database for data storage WebUI for the web browser based data display Two Sketch Libraries are used RouterBridge to enable communication between Linux and the MCU Modulino that contains classes for all of the Modulino modules Two primary app source files Python - main.py Sketch - sketch.ino My new app just modifies the example sketch.ino file. main.py sketch.ino A quick demo of the app. A Serial Monitor output shows the result of my approaching from beyond 2m (Out of range) Then temperature and humidity data starts logging when I am within 500mm and stops when I am beyond it. Video showing the same sequence on the Uno Q LED Matrix (displays temperature only within 500mm). USB Audio with USB Speaker and USB Drive for storage I created 2 apps to use with the USB Speaker: Sound Generator Fur Elise and MP3 Player. I discussed the development of these apps in the post Arduino Uno Q - USB Audio . I'll include the code and the demo videos below. Please reference the post for more info. Sound Generator Fur Elise This app demonstrates using the Sound Generator Brick to play tones for Beethoven's Fur Elise. The python program controls the sound generation and playback over the USB speaker and the handshake for the LED matrix. main.py The sketch just controls the matrix. sketch.ino MP3 Player This app demonstrates playing an mp3 file from the USB drive on the USB speaker using pygame to play the audio. It also uses the Modulino knob to adjust the volume and the LED matrix to display the numeric volume percentage. main.py sketch.ino Web Browser Viewer for SPI Camera I was really hoping that the Arduino Uno Media Carrier would be available in time for the roadtest, so that I could try a RPi CSI camera or two. In the meantime, I thought that I would try an Arducam Mini 2MP+ SPI camera that I've used in with other MCUs and the Arduino IDE. This was my opportunity to try the Uno Q using the tried and true Arduino IDE on the host PC rather than using AppLab and connecting to the Uno Q via USB. At the start it felt like an old shoe. I could compile and upload MCU only examples like always, but as soon as I got to trying the Arducam camera library it failed immediately. The Uno Q requires using the new Zephyr OS instead of the older Mbed OS. Understandable since Mbed is now EOL, but it causes issues with older libraries that have not been updated to Zephyr. The other problem I had with the IDE is "where is my serial debug output". Not in the usual Serial Monitor of the IDE. Makes sense since the MCU doesn't have access to the USB serial on the Uno Q. So, reverted to using a USB to UART interface connected the TX and RX pins on the Digital header and received the output in a PuTTY terminal on the PC. I have FTDI boards somewhere, but I had an Adafruit MCP2221 that I was using elsewhere for I2C. Maybe I'll need that for the Uno Q later...The hookup is shown below. The library problems were class definition issues with data types and functions that were causing it not to compile. Modification to the Arducam_Mini.h and .cpp files got the camera working and I decided it was time to move it into AppLab. Created a new app and installed the Arducam Mini library. This is the same version of the library that is installed by the standalone IDE, so I needed to modify it. Next problem, where is the library? I couldn't find it by searching the file system using the find command. This is one of the quirks or features of AppLab that I've learned. Installing a library using the Library manager does not actually install the library until you try to compile. Of course, compiling also has the benefit of showing you the library path whether it compiles or not. The location was /home/arduino/.arduino15/internal/Arducam_mini_1.0.1_becf652cd4feef8c/Arducam_mini. A bit more obfuscated path than the standalone IDE where libraries are installed in a directory with the sketches. Before I discovered where the library was (I was overthinking things and wanted to fix the library before I compiled), I took the cheaters way out and installed a copy of the modified library in the sketch folder. Anyway, more than one way to skin a cat. The Python code requests frames from the MCU over the Bridge. The MCU captures the frame and returns it over the Bridge. The Python code then stores the frame in the "/app/assets". The WebUI starts a browser window at unoq_ipaddr:7000 and and the browser pulls the new frames for display. I was having a terrible time with intermittent behavior capturing frames over SPI when using either D9 or D10 as the SPI CS pin (I had used D10 without issues using the standalone IDE). When I switched CS to D7, the problems went away. The Arducam Mini has its own proprietary bridge chip on the SPI bus and there may be timing issues, but slowing the bus down didn't help - only changing the CS pin. There is stuff going on behind the curtain with pin and function mux'ing when using AppLab. As an example, I noticed on the debug UART that you get boot messages from the MCU before it switches to being Serial1 for serial print output. I believe that the D9 and D10 pins were glitching when the MCU was initializing and causing the bridge chip in the Arducam to hang intermittently. main.py sketch.ino Anyway, I got it working, but I would say that it isn't worth the effort. There is no shared storage between the MCU and MPU, so capturing on the MCU doesn't make sense because the update rate using the bridge is too slow. It's better to wait for for the CSI interface to become available and do everything on the MPU.. Capture Images from IP Camera using RTSP I use IP cameras for monitoring and security. I've been using Frigate (with and without Home Assistant integration) to do object detection. I thought that I would see how well an RTSP stream would fare with the Uno Q using AppLab. Since the VideoObjectDetection and VideoObjectClassification bricks work well with the Webcam it seems that processing an RTSP stream shouldn't be an issue. If you look at the API documentation for the VideoObjectDetection brick, the class definition has a camera parameter - class VideoObjectDetection(camera: BaseCamera | None, confidence: float, debounce_sec: float, camera_preview: bool) . As a matter of fact, supposedly the IPCamera option was added in Arduino App Bricks / CLI version 0.7.x+. I am running 0.7.0 and I could not get it accept anything - always returned "no camera device found". I tracked down the culprit - when the brick is added the app.yaml is modified to the following: name: RTSP VideoObjectDetection description: "" ports: [] bricks: - arduino:video_object_detection: {} icon: So, the definition is forcing default parameters and the default camera is USB. It won't let me edit the app.yaml, so I guess I can't use the brick. But, this is a Linux system and OpenCV is installed in AppLab - so, I should be able to capture images and display them in a browser which is the purpose of this app. Everything runs in the Python script... I had to put flask in requirements.txt to get that module installed. main.py The program captures images from the RTSP stream and stores the latest in a local directory "/app/assets". A browser window is opened at unoq_ipaddr:7000 and the browser requests images every second. And it works, albeit very slowly (if you watch the camera timestamp, the image is updating every 5 seconds or so). You can tell by the Title that I was somewhat optimistic - I was considering trying to make a custom brick. At this point I'm hoping that the Arduino Video Bricks get updated in the near future so that the IP camera option works... Object Detection Stream for IP Camera not using AppLab I couldn't get the VideoObjectDetection brick to work with the RTSP stream, but I thought that I could interface directly to the Edge Impulse model within AppLab using OpenCV. I found the YoloX model being used by the VideoObjectDetection brick. It's located at /var/lib/docker/overlay2/2a14d4e8a65ffc2837c54d4ff4ff0264f92bf5b9a574d86deab1e2e0d82e71d4/diff/models/ootb/ei/yolo-x-nano.eim. I was struggling in AppLab and in frustration decided to move out into regular Linux to try to see if I could get the model to run with the RTSP stream using the Edge Impulse command line tools. This was a risky decision as these tools are not by default installed outside of AppLab and it consumed a lot of precious "disk" space to install them. It should have been as easy as running this command "edge-impulse-linux-runner --model-file /PATH/TO/YOUR/MODEL.eim --url rtsp://YOUR_RTSP_URL". After fighting through permissions issues and missing dependencies like gstreamer, I discovered that the Edge Impulse tools installed on the Uno Q somehow are also constrained to using the webcam as camera input? It almost worked. [RUN] Starting the image classifier for Arduino / yolo-x (v7) [RUN] Parameters [RUN] image size 416x416 px (3 channels) [RUN] classes [ 'person', 'bicycle', 'car', 'motorcycle', 'airplane', 'bus', 'train', 'truck', 'boat', 'traffic light', 'fire hydrant', 'stop sign', 'parking meter', 'bench', 'bird', 'cat', 'dog', 'horse', 'sheep', 'cow', 'elephant', 'bear', 'zebra', 'giraffe', 'backpack', 'umbrella', 'handbag', 'tie', 'suitcase', 'frisbee', 'skis', 'snowboard', 'sports ball', 'kite', 'baseball bat', 'baseball glove', 'skateboard', 'surfboard', 'tennis racket', 'bottle', 'wine glass', 'cup', 'fork', 'knife', 'spoon', 'bowl', 'banana', 'apple', 'sandwich', 'orange', 'broccoli', 'carrot', 'hot dog', 'pizza', 'donut', 'cake', 'chair', 'couch', 'potted plant', 'bed', 'dining table', 'toilet', 'tv', 'laptop', 'mouse', 'remote', 'keyboard', 'cell phone', 'microwave', 'oven', 'toaster', 'sink', 'refrigerator', 'book', 'clock', 'vase', 'scissors', 'teddy bear', 'hair drier', 'toothbrush' ] [RUN] Thresholds: 12.min_score=0.3 (override via --thresholds ) [GST] checking for /etc/os-release [RUN] Failed to run impulse Cannot find any webcams So, I'm still missing a piece of the puzzle. One last try - back to running everything in Python without using the Edge Impulse CLI. Tried to install the edge_impulse_linux module, but ran into the modern Linux protection from yourself (the requirement to install user libraries in a virtual environment).. pip3 install edge_impulse_linux error: externally-managed-environment Decided not to fight it and created a virtual environment (venv), but made sure I inherited all the existing system python modules so that I didn't have to install them. Running in the venv, I finally have a smart streamer script that will stream the image with bounding boxes to a web browser. Still has warts. I haven't quite got the bounding box scaling right, but I'm still tweaking it. The first video shows that it started off awful, the scale and offset of the BBs was off and the labels on a lot of the BBs end up out of the image frame.. There were some sync issues also. I had used the higher resolution 1280x720 stream from the camera and that was causing processing delays scaling the model input to 416x416. For the second video I switched to the lower resolution 640x352 stream and did some scale and offset tweaking and shifted the labels to the bottom. Still needs work, but it is usable. smart_stream.py Object Detection Stream for IP Camera using AppLab I decided that I would try one last variation within Applab. I am going to try to run without the Edge Impulse integration and without using the Edge Impulse generated model. I am using OpenCV with a YoloV8 Nano Onnx model that I downloaded from the Ultralytics repository - "yolov8n.onnx". This model will provide the correct scaling and offset for the bounding boxes and has the advantage of having a model input of 640x640 which matches up nicely with the 640x352 stream from the camera. videoobjectdetection-webui.py The result is better. The image and BB sync is good, but I noticed by watching the camera timestamp that the output was lagging behind real time. The camera is streaming at 15 FPS, but the inferencing can only achieve 1-2 FPS depending on the quality of the image and the relative size of the target. I needed to discard some of the captured frames and inferences to prevent the input buffer from overflowing. This has the downside of reducing the confidence level the of the inference, so I needed to reduce the detection threshold. It also makes it more difficult to capture fast moving targets, but when you watch the video - it is stable and real time at 1-2 FPS. I believe that the Edge Impulse implementation takes advantage of the Adreno GPU and dual ISPs, so the inference FPS should be a lot better when the VideoDetection brick is fixed to allow IP camera input. A quick pic showing that it does detect other classes like person. I've also observed it detect dogs and bikes. Summary The 2GB RAM/16GB Flash version of the Uno Q started shipping in October 2025 and the 4GB/32GB in January 2026. With Uno Q there has been a paradigm shift relative to the traditional hardware/software architecture used by the Arduino UNO. The hardware is a hybrid processor SBC with a Linux MPU and real time Zephyr MCU in the traditional Uno footprint. The software has been redesigned to support and simplify development on the new hardware architecture using an integrated development environment, Arduino App Lab, that allows you to create applications using Python scripts and Arduino IDE sketches. AppLab has the following features: Provides a pre-configured, seamless inter-process communication (IPC) interface between the Linux side and the microcontroller side, the RouterBridge. Provides plug-and-play functional modules called Bricks that are advanced libraries that can add features like computer vision, speech recognition, or web dashboards without building them from scratch. Most bricks are isolated Docker containers that prevent library dependencies from conflicting with the main code. Sandboxed application environment that isolates applications from other applications and the host Linux environment. Comparison between the Uno Q and the latest “traditional” Uno: Key Differences: Uno Q vs. Uno R4/R3 Feature Arduino Uno Q Arduino Uno R4 Wi-Fi Primary Goal Edge AI + Linux Applications Modernized Low-Power DIY Processor Quad-Core ARM MPU + Cortex M33 MCU Renesas Cortex M4 MCU + ESP32 OS Linux (Debian) + Zephyr Bare Metal/RTOS Storage 16/32 GB eMMC Flash Memory (internal) Power High (Needs USB-C PD) Low (Battery friendly) I'm not sure why this board is still named an Uno. I guess because the footprint has been maintained and there is some shield compatibility. I am not a big user of legacy shields, so I would have preferred that other functionality (CSI, DSI, host USB-C) have been added in lieu of maintaining compatibility. I also think that they could have ditched the LED matrix as the low resolution is not very useful, especially for something that will probably end up in an enclosure. User experience When I started the roadtest, my general expectation was that I would struggle with learning curve issues with the new hardware and the new application development environment. And I also expected that there would be issues with documentation due to being an early adopter of the platform. All these of these expectations came to pass... This is not a beginner's board/development environment, at least not yet. The good news and bad news is that changes are occurring frequently. I expect that in another 6 months, many of the issues that I encountered will be resolved. And adapters for CSI/DSI are due within the next quarter. So, after using the Uno Q and AppLab to develop the types of applications that I use, what are my impressions of the platform? I am not convinced that this is a good general purpose development platform. There is not enough available storage for the sandboxed/container environment that is being used. One thing that Arduino should do is move the container storage to the user partition on the 32GB version. I'm not fully convinced that the 16GB version will be popular other than for playing around. I am constantly having to prune the Docker containers to maintain available space. I guess if you're not using many Bricks or AI it won't be a problem, but in that case what's the point of using this board? The Good The setup and installation was straightforward and well documented. Good set of examples available. Examples work well and use is well documented. The Bad Container use obfuscates file locations. Lack of space in eMMC due to partitioning. Developing applications outside the context of the examples can be challenging. Bricks appear not to be fully functional relative to their API (an example is the inability to select camera input type for video detection). MCU device libraries have not been fully updated to Zephyr (I expect this will take a long time due to the large number of older devices currently supported - this will also apply to the standalone IDE if legacy Mbed support is discontinued - Zephyr is required for Uno Q). Pros Dual Brain Architecture improves real time performance Quad core Qualcomm Dragonwing QRB2210 with Adreno 702 GPU STM32U585 MCU Standard Linux development environment eMMC storage Does not require SD card AppLab Integration helps manage MPU/MCU communication Bricks provide plug/play functionality for complex tasks Uno Compatibility compatible with 3.3V shields Cons Dual Brain Architecture increases programming complexity MPU uses A53 cores which is equivalent to the RPi 3 eMMC storage – only available in 16GB and 32GB Root partition in both versions is under 10GB No expandable storage except through USB-C AppLab Integration High storage consumption due to sandboxed container architecture Port limitations Single USB-C port for power and data Power consumption Links My roadtest blog posts Arduino Uno Q - Board received Arduino Uno Q - getting started Arduino Uno Q - AppLab initial configuration and examples Arduino Uno Q - Standalone Operation Arduino Uno Q and USB3 adapter with USB-C PD Arduino Uno Q - USB Audioarduino applabroadtest reviewarduino uno qI don’t think that there are equivalent boards to The Uno Q unless you are looking to compare very specific features. The Uno Q seems optimized for lightweight AI processing combined with capable real-time control. For my application I might have used a Raspberry Pi5 or Radxa X4.Development Boards & ToolsLack of adequate storage for sandboxed/containerized environment. MCU device libraries not updated for Zephyr. Brick API documentation shows functionality not currently implemented.https://community.element14.com/products/roadtest/m/managed-videos/151368Mon, 25 May 2026 00:41:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1af7ca7b-0be1-44e4-97ba-49ab43192899ralphjyhttps://community.element14.com/products/roadtest/b/blog/posts/element13-april-fools-roadtestThu, 21 May 2026 23:33:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2815f5be-174a-4dd4-9f90-dcbc0128836dntewinkelYou’ve gotta love it when a company goes all in on an April fools joke and calls your bluff… I saw the April Fools days posts about changing “element14” to “element13” and setting up an Aluminum foil Road Test , so I thought I’d play along and add my application. I expected maybe they would later share the Road Test applications somewhere in the community. But next thing I know there’s a package at my front door - they called my bluff! Now I need to keep my end of the deal and start folding some tinfoil hats! For those interested, this was my application: === Frequency Obscuring Outer Layer System hat (FOOLS hat) I was recently thinking about The Fermi Paradox: if life starts so easily, why haven't we seen aliens? And the obvious reason is: because they are sneaky and living amongst us. How else can you explain “Crocs", "Windows computers", and "April Fools jokes"? So we need to protect ourselves. We don't want them reading our brain waves, and also we don't want them implanting thoughts into our heads. Now I know what you're thinking - tinfoil hats. But... shiny side in? or shiny side out? Obviously the shiny side is the more reflective part, so we will need that to be on the INSIDE to keep our brainwaves from leaving. But also we need it on the OUTSIDE to keep them from implanting thoughts and memories! What a dilemma. My project, with enough funding and research time, aims to have a shiny side on both the INSIDE - AND- the OUTSIDE! Mind blown yet???? I know, right!!? brilliant, if I do say so myself! Anyway, hope you pick me. Before it's too late. I don't know if my cheap no-name aluminum foil is up to the task! === And here is my final Road Test review: Frequency Obscuring Outer Layer System hat (FOOLS hat)RoadTestapril fools 2026https://community.element14.com/products/roadtest/m/managed-videos/151354Thu, 21 May 2026 23:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2b3bd8a3-6b71-454c-af7b-60a522b99912ntewinkelhttps://community.element14.com/products/roadtest/m/managed-videos/151353Thu, 21 May 2026 23:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:2cc07306-d912-44e1-bc11-a30936a97cc9ntewinkelhttps://community.element14.com/products/roadtest/m/managed-videos/151352Thu, 21 May 2026 23:19:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d0d8d65f-ab21-4ef6-9682-37f84d2eede1ntewinkelhttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1912/frequency_obscuring_outer_layer_system_hat_fools_hatThu, 21 May 2026 23:17:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:a7860911-19a6-43a3-b27a-dbb357345064ntewinkelI approached this RoadTest like I would approach any new project: with existential dread, a little bit of skepticism, and a cup of coffee. With those prerequisites out of the way, I dove in... Before testing with the actual product (which is valuable and shouldn't be wasted on silly prototype tests), I decided to build a disposable prototype using paper. Here's a timelapse video of me hard at work... Having carefully crafted the paper prototype, I needed to find out which surfaces needed to be shiny, so I marked them all off with some creative artistic maneuvers... Seeing the resulting useless mess, I decided to just place some aluminum foil back to back (less-shiny sides touching on the hidden inside of course), and got deep into assembly of the final product. Now, the raccoon took off after we signed up for the RoadTest, so I had to find an unsuspecting stand-in for testing. Don't worry, this particular RoadTest does not involve Gamma Rays or microwave ovens . He suspects NOTHINK! Linus. D. Kat, brave volunteer! It seems to fit him very well, and he does resemble the raccoon a little bit, which helps it seem more authentic to the vibe of the original RoadTest. I can't help it that the raccoons deserted me. Linus did the final bit of testing, so we have to take his word for it whether it works or not. Right away you can see there is a little bit of a problem with the brainwave reflection concept - you can tell by his eyes that his own brainwaves are indeed no longer going outward (and thus the aliens won't be able to read them), but they are reflecting back inward and that is causing the brainwaves to resonate and collect in there, which is overheating his single braincell. Given that result, I was unable to get him to verify whether or not he was still receiving incoming commands from aliens - however, we're not sure if there were any aliens around at the time of testing, so that's a tricky scenario at best. Overall, I think this was a success - we learned a few things, Linus had a few extra treats, and we now have a nice shiny little hat to keep as a fun souvenir. In summary, I think it might be best to stick with single-sided aluminum foil hats to protect from aliens. Since we're still developing the blocking of the outgoing brainwaves, just remember to keep your thoughts short and dumb for now. Byeeeeee! ps, You can see my RoadTest application hereRoadTestroadtest reviewelement13The Thinking Cap (https://community.element14.com/challenges-projects/project14/wearabletech/b/blog/posts/the-thinking-cap)ElectromechanicalThe test subject (Linus) did not want to sit still long enough.https://community.element14.com/products/roadtest/m/managed-videos/151335Tue, 19 May 2026 23:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1531d662-9198-48f0-839d-276dcb93d2a0AngelSotohttps://community.element14.com/products/roadtest/m/managed-videos/151323Fri, 15 May 2026 17:22:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4d34e2d7-ddb3-4439-abc1-a9a4ac26a160taifurIs the Arduino UNO Q just another microcontroller, or is it a new category of embedded systems? In this video, we explore the revolutionary "Dual Brain" architecture of the UNO Q, which integrates a Linux-based MPU (the "Thinking Brain") and a rea...Tech ReviewApp Labqualcommedge airaspberry pi 5stm32Embedded Systemsarduino uno qmcuiotDual Brainarduinolinuxhttps://community.element14.com/products/roadtest/rv/roadtest_reviews/1900/osram_as1170_ir_driver_evaluation_kitSat, 09 May 2026 05:07:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:3ff616aa-0449-4411-9690-ed6c59f90c58chloroINTRODUCTION I must say that when I saw that the AS1170 had been scheduled on the Element14 RoadTest program schedule, I was immediately interested in it, and I was keen on getting my hands on it and reviewing it. I would first of all like to thank for making all of this possible from start to finish. I would also like to thank for shipping the package. About the AS1170 The AS1170 is a high-current driver for LEDs and VCSELs. The device is based upon an inductive and highly efficient DC-DC step-up converter. The chip has two independent current sinks and can supply up to 2 A in total. The device operates at a fixed frequency of 4 MHz and is primarily intended for the following applications : smartphone camera flash lighting, 3D structured light sensing, and active stereo vision. The chip communicates via I2C and has the ability to perform PWM dimming. The chip also has a flash mode with strobe control . The device has a comprehensive range of protection features and is contained in a very small WL-CSP package measuring just 2.25 mm x 1.5 mm x 0.6 mm. The thing that caught my attention was the device’s ability to have two independent current sinks and the ability to output up to 2 A in total. I am working with IR illumination and was looking for this sort of device. What’s in the Box? When I got the package, I'll admit that I was expecting nothing out of the ordinary. Which, again, is perfectly all right for an engineering tool. When I opened the box, I saw that there were four circuit boards neatly stacked on top of each other, as well as a micro-USB cable . First of all, I was surprised by how compact all of the items were. The main EVK board itself is smaller than than a credit card, and the IR LED breakout board that connects to it is even smaller. AS1170 Evaluation Kit Packaging AS1170 EVK – Box Contents Overview AS1170 Evaluation Board ESP32-S2 DevKit M1 Board Two Breakout Boards: ESP32-S2 DevKit M1 Board Support & Resources Card What I really liked was that first moment of seeing everything together. The kit is nicely packed in a box lined with foam, which already gave me that sense of premium and professionalism. It felt like they took the evaluation experience seriously, and right there, I felt confident that the documentation and support would be of similar quality. Detailed Component Description After the initial unboxing, I started examining each of the components in detail to understand their purpose, design, and how each of them contributes to real-world IR illumination and sensing applications. I recall sitting at my workbench and going through each of the boards one by one, and I have to say, I became more and more impressed as I looked more closely. 1. AS1170 Evaluation Board (Main Board) The heart of the kit is the AS1170 Evaluation Board (also marked as “AS1170 High Current LED/VCSEL Driver”). It is a compact, black PCB measuring approximately 60 mm × 45 mm, with clear silkscreen labeling. Key features visible on the board: Central AS1170 IC in a tiny WLCSP package Integrated DC-DC boost converter (inductor and capacitors clearly visible) Two pre-mounted 850 nm SFH 41747 IR LEDs (OSLON P1616 footprint) – these are the default onboard emitters One thing that surprised me was that the board was very thoughtfully laid out. The board is designed for both GUI tests and embedded development. The connectors are also clearly labeled, making it very easy for new users. While I am an experienced user of many evaluation boards, I found it refreshing that I did not have to search through the schematics to figure out where to plug in my USB cable. 1.1 Board Layout and Jumper Reference The board includes several important jumpers and connectors that control its behaviour. I genuinely spent a good few minutes just reading through the jumper table before touching anything — and I am glad I did, because getting this wrong, especially around the power path, could have caused real problems. Input Description BU1 VBAT Power Input Terminal : This is a red screw terminal used to connect the positive line from an external bench power supply . Only use this when the LED current is above 450 mA and USB power can’t provide enough power. The AS1170’s VIN range is "2.7 V to 4. 4 V." BU2 GND Terminal: This is the black screw terminal you use to connect the ground from an external power supply. S1 Strobe Button : This is a physical button that’s wired to the AS1170’s STROBE pin. When the device is set to strobe-controlled flash mode, pressing it will trigger a flash. This really helped when I first started testing, since I could send IR pulses without having to write any code. J1 External LED Board Connector : This is the connector where you plug in the IR LED breakout board . If you’re using J1, take off J5 so the onboard LEDs are disconnected. J2 MCU board connector ( lower header ) It brings out SCL , SDA , STROBE , and 3. 3V signals going between the ESP32-S2 and the AS1170 circuit. This is the I2C communication route. J3 MCU Board Connector (upper header): This is an extra header connector for the ESP32-S2 module. J5 Onboard LED Enable : If you install this jumper , it connects the onboard SFH41747 LEDs . Take it off when you’re using the external breakout board. J6 VBAT to 3V3 Jumper: If you install it, J6 lets the ESP32-S2 use its 3. 3V rail to supply the AS1170’s VIN. This is the default setup for running low-current tests over USB. The key point is that if you hook up a lab bench power supply to BU1/BU2 for high-current use, you need to remove J6 so the bench supply voltage doesn’t get sent back into the MCU board. J7 VBAT/GND Measurement Pin : This is a handy two-pin header that lets you check the supply voltage using a multimeter or an oscilloscope . Honestly, I thought the J6 detail was the one most likely to catch a new user off guard. The idea that leaving J6 in place while connecting a bench supply could back-feed voltage into the ESP32-S2 is the kind of subtle thing that is easy to miss on a first read. I was glad I caught it before making that mistake. For a deeper understanding of the board design, jumper configuration, and PCB layout, the following diagrams from the official documentation are provided. Figure 1.1: Jumper and connector overview showing all key interfaces and their functions on the AS1170 EVK. 1.2 PCB Layout Figure 1.2: PCB layout view highlighting routing layers and internal connections of the AS1170 evaluation board These diagrams show the top layer (red), inner layers for GND and VBAT, and bottom layer. They are very helpful for understanding power distribution, signal routing, and thermal design of the boost converter. When I first looked at the layout, what caught my eye was that it is packed tightly around the AS1170 in a manner that is specifically recommended in the datasheet layout recommendations for minimizing the area of the high-frequency switching current loops. The entire circuit diagram for power input, boost converter, LED outputs, I²C interface, and ESP32-S2 connection points. The complete circuit diagram showing power input, boost converter, LED outputs, I²C interface, and ESP32-S2 connection points. 1.3 Internal Architecture If we go through the provided documentation, it shows that the internal circuit diagram reveals a complete power management subsystem integrated into the single WL-CSP die. Figure 1.3 : AS1170 internal circuit block diagram from the datasheet, showing DCDC control, current sinks, comparators, and protection blocks The key functional blocks are worth tracing through: The DCDC Analog block sits at the centre, controlling the PMOS and NMOS switches (SW1/2) at a fixed 4 MHz clock. The oscillator on the bottom left feeds the clock throughout the chip. A ramp generator and comparator implement peak current-mode control of the boost converter. The current sinks on LED_OUT1 and LED_OUT2 are controlled by the digital core, which translates the I2C register values into a reference current for the current DAC. This is how the LED current is precisely set — not by varying voltage, but by directly controlling the current sinking through the LED. The VDS comparators continuously monitor the voltage across the current sinks. There are two thresholds: VLOW_VDS (~320 mV) and VHIGH_VDS (~900 mV). These are used to determine whether the boost converter needs to operate at higher or lower duty cycle, and they feed into the 4 MHz / 1 MHz switching mode selection logic. The protection blocks on the right monitor VOUT for overvoltage, the LED pins for short-circuit conditions, and junction temperature for thermal protection. All faults are reported through a dedicated register accessible over I2C. 2. IR LED Breakout Board The breakout board is designed to be flexible, and it is possible to populate different IR LED types according to the application to be evaluated. For my setup, the SFH41747 LEDs were already assembled on the main board, and additional external LEDs were promised to be provided later. However, in the kit, only pre-mounted LEDs are included. It connects to J1 on the main EVK through an 8-pin header. A very important note : when the breakout board is connected, J5 on the main board has to be removed to disconnect the LEDs assembled on the main board. 3. ESP32-S2 DevKit M1 Board The kit includes an official ESP32-S2 DevKit M1 board from Espressif . I am familiar with ESP32 modules, but I was glad to see it included in the EVK kit. It means you have a I2C controller right out of the box, with no need to connect any other microcontroller. The ESP32-S2 serves as a bridge between the PC GUI and the AS1170. It handles the I2C master communication and also generates the STROBE signal that triggers flash pulses. The module connects to the EVK board via two multi-pin headers (J2 and J3). When the micro-USB cable is plugged into the ESP32-S2, it provides 3.3 V to the EVK board through jumper J6 — a detail that is important to understand before changing any power configuration. It is a full-featured development board with Micro-USB Port interface, 4 MB flash, and plenty of GPIOs. The board is ready to use with Arduino IDE or ESP-IDF. 3.1 Technical Reference: ESP32-S2 Pinout and Layout For detailed understanding of the ESP32-S2 board layout and GPIO capabilities, the following reference diagrams are included. Figure 3.1 : ESP32-S2 DevKit M1 front view showing onboard components and interfaces Figure 3.2: ESP32-S2 pinout diagram highlighting GPIO functions, peripherals, and signal mapping. 4. Accessories USB 2.0 Type-A to Micro-B cable (1 m, S-IMPULS branded) – used for PC GUI communication and USB power. Small detail, but I appreciated the branded cable rather than a generic throwaway. It is the kind of small quality signal that tells you a manufacturer cares about the full experience. Software Setup and GUI This was the first real hands-on step, and I want to walk through this step exactly as I did it, because the order matters, and you'll be left with an empty GUI wondering what went wrong if you skip this step. GUI and Driver Installation Step 1: Go to this Github repository and download the AS1170_GUI_v1.exe Step 2: Download the require CP210x VCP Drivers – Silicon Labs Step 3: Attach Eps32 with main Board and connect it to PC using USB 2.0 Type-A to Micro-B cable Step 4: Open Device Manager and search for “USB to UART Bridge” Step 5 : “Update Driver” from your local drive and select folder of step #1 (location of extracted SW package) Step 6 : Driver is successfully installed launch AS1170_GUI.exe GUI Testing and Observations Having successfully connected the GUI and confirmed the chip ID, I now proceeded to test each operating mode individually. This was the part that I was most looking forward to. I was eager to actually drive the IR LEDs and see what this device was capable of. Indicator Mode / PWM Indicator mode uses the 6 LSBs of the LED current registers and applies a 31.25 kHz PWM modulation. This is designed for applications like always-on proximity sensing or low-power face tracking where the LED needs to run continuously but at reduced average current. I configured it as follows: selected "Indicator Mode/PWM" in the Operation Mode section, set Indicator PWM to 4/16 (25% duty cycle), LED 1 Current to 199.5 mA, LED 2 Current to 199.5 mA , then checked " Out On ". Figure : AS1170 GUI configured for indicator mode PWM, with 25% duty cycle, 199.5mA per LED channel, Out On enabled. According to the EVK user guide, this will drive approximately 400mA at a duty cycle of 25% with a PWM frequency of approximately 30.6 kHz on the LED OUT pins. Pointing the camera at the IR LED, I can see the IR LED lighting up. This is due to the camera's sensor, which can detect near-infrared light, not visible to the human eye. Flash Mode Flash mode is the high-power mode of operation in which the full range of the LED current register is utilized. I selected Flash Mode and left the current settings at 199.5 mA per channel. I then set the LED ON Time to 2 ms. With "Out On" checked and "Auto Strobe" selected, I pressed the S1 button on the EVK board, and the IR LED emitted a flash pulse.The IR LED emitted a flash pulse corresponding to the configured 2 ms timing, as expected from the AS1170 configuration. Figure: AS1170 GUI in Flash Mode 2 ms LED ON Time, 199.5 mA per channel. I recall when I first pressed the S1 button for the first time in flash mode and how nice it was to get the perfectly timed IR burst triggered by the physical button with no code written at all. This is the kind of workflow that makes a well-designed EVK so valuable. Assist Light Mode Assist light mode is situated between flash and indicator modes in terms of current range. Assist light mode utilizes the 7 least significant bits of the LED current registers. This limits it to half the maximum flash mode current. This mode is applicable in torch/video light applications where the LEDs operate continuously but at lower intensity than in flash mode. I configured this mode and checked that the LEDs emitted light steadily, which I could see via the camera. Fault Indication and Status Registers The GUI has a Fault Indication section where OV Protection, LED Short, and Over Temp are indicated by coloured LED indicators. There are also status indicators for Timeout and UVLO. Pressing the "Read" button to read the registers confirmed that there were no faults recorded during the tests. The "Reset" button resets the fault register, which is essential because the AS1170 holds faults latched until they are reset by the I²C readout process. This is noted in the documentation of register 0x08. What I think is particularly nice here is that with the GUI, the fault register is actually very easy to monitor. You don’t necessarily need an oscilloscope or a serial terminal to see what’s being reported by the chip. That’s actually very nice in terms of early-stage bring-up. Personal Experience with GUI Instability and GPU Interference In my case, the most frustrating problems I experienced were not with the hardware performance or the general functionality, but with the GUI. All other aspects of this setup seemed to be quite clear and easy to work with. However, the GUI was not consistent and caused problems with the workflow. The problems I experienced with this setup were mainly evident during long periods of testing. I have identified two major problems: 1. Configuration Panel Does Not Open Sometimes, clicking the button to open the configuration panel did not work. There was no error message, no signs of activity. It was just not working. This is very confusing since it is not clear whether the command was registered or not. The only solution I found was to restart the system. This is not very efficient and is very frustrating. 2. Chip Detection and Control Does Not Function Sometimes, the system was not able to detect the chip ID. This meant that the system was not in control of the main board. Although the interface was still working, it was not possible to do anything with it. No commands were registered, and no interaction was possible. ESP32 Integration via I2C The next stage of my analysis was to go beyond the use of the vendor GUI and directly connect to the AS1170, emulating the way the device will perform in a real-world embedded system using the ESP32-S2 DevKit M1 supplied with the kit. One of the best things about the kit is that ams OSRAM did not constrain the evaluation process to only software on the PC side but included an ESP32-S2 DevKit that can directly talk to the evaluation board. Hardware Interface This particular hardware interface was surprisingly simple. The DevKit M1 provided with the kit is intended to work with the AS1170 EVK via the onboard headers, so there is no need for wiring the connection yourself or placing the components on a breadboard just to check the functionality. The protocol used to talk to the AS1170 is I²C and its characteristics according to the documentation: Standard Mode: 100 kHz Fast Mode: 400 kHz My implementation uses fast-mode I²C communication at 400 kHz, which is perfectly sufficient for embedded control tasks. The ESP32 is connected to the AS1170 using the following lines: SDA → GPIO 12 SCL → GPIO 13 I²C Slave Address → 0x30 As you can see, the EVK itself comes pre-configured with the correct pull-ups. Arduino IDE Setup To test firmware code, I used Arduino IDE version 2.x. The configuration steps were simple: Launch Arduino IDE Go to Board Manager Find ESP32 by Espressif Systems Install the latest stable version Then choose: Tools -> Board -> ESP32 Arduino -> ESP32S2 Dev Module Connect ESP32 using USB Choose the appropriate COM port No additional libraries were necessary besides standard Arduino libraries The code includes: Wire.h to handle I²C communications HardwareSerial for command interaction SD.h (though CSV loading appears partially implemented) Firmware Approach Instead of working with a simplified demo sketch, I analyzed the real register-level firmware implementation given. It’s significant because it represents something far more useful than checking that the chip acknowledges on the bus; rather, it shows how you can have full, low-level control over the AS1170 just like an embedded program would. The code accesses the registers of the AS1170 through I²C communications. The slave address is configured as: And I²C initialization is performed as: with: Register-Level Control The value of this approach was its ability to provide access to critical control registers within the AS1170 system. The firmware interface enables interaction with: Register Address Function Fixed ID 0x00 Device identification LED1 Current 0x01 Set output current for LED channel 1 LED2 Current 0x02 Set output current for LED channel 2 Flash Timer 0x05 Configure flash timeout duration Control Register 0x06 Select operating modes Strobe Signaling 0x07 Configure strobe behavior Fault Register 0x08 Monitor device protection status PWM / Indicator 0x09 Configure PWM indicator operation This effectively exposes most of the core functionality of the AS1170 without needing the GUI. Available Controls Using this implementation, I was able to directly access functionality such as: Adjusting LED1 output current Adjusting LED2 output current Setting flash timeout duration Enabling/disabling output Switching operating modes Reading fault conditions Monitoring UVLO status Checking thermal fault conditions Detecting LED short conditions Reading device identification Configuring strobe signaling behavior This is precisely the sort of control expected in a real embedded deployment. Serial Command Interface Communication is achieved using the Arduino Serial Monitor. Command structures are simple. For instance: Reading all registers Results in: Output of LED currents Control register contents Fault conditions Chip identification Modify LED1 current This writes a new value to register 0x01 . Modify LED2 current Change flash timeout Modify control behavior This allows experimentation with operating modes. Reset ESP32 firmware Observations This was a particularly useful part of the roadtest in confirming that AS1170 isn't just another GUI-oriented demo board, but an actual embeddable solution. I²C communications were stable, register reading was flawless, and the firmware successfully gave meaningful control over the device. In comparison to the GUI, it feels much more natural as product integration. Instead of using vendor software, you control a subsystem from your firmware by clicking buttons. However, the API is quite low level. It is not intended as a high-level abstraction: it offers no higher-level APIs such as setFlashMode() writes override registers directly partially supported CSV loading However, for this kind of evaluation, this wasn't really a downside as we got insights on how the device can be controlled in firmware. Embedded Engineering viewpoint From the perspective of an embedded engineer, this was one of the most exciting parts of the roadtest. There are many eval boards that end up being nothing more than demos stuck within the vendor software ecosystem. Not this one. It worked exactly as any good embedded peripheral board should work: communicated via I²C protocol configured through firmware fault detection capabilities ready for automation This makes it a potentially useful device in: IR proximity sensing machine vision illuminator 3D sensing robots optical subsystems face recognition solutions Final Impression This exercise for me was an experience in which the AS1170 went from being "an evaluation board with a nice GUI" to actually being useful for embedded software development. The difference is important. GUI shows functionality. Register manipulation shows product readiness. Practical Demonstrations — IR LED Verification One of the most rewarding aspects of any IR LED driver evaluation is seeing this invisible light in action. As the AS1170 driver is designed to drive near-infrared LEDs (with the SFH41747 emitting at approximately 850 nm), this light is invisible to the naked eye but perfectly within range for detection by most digital camera sensors. 10.1 Camera Verification Method I used a digital camera on a laptop. I aimed this camera directly at the IR LED package. In Indicator mode at 400 mA combined current and 25% duty cycle, the IR LED was visible on the camera preview as a bright white/purple spot – very visible and unmistakable. The EVK document includes a comparison shot of the ams-OSRAM IR LED versus a competing IR LED product under the same conditions (400 mA, 25% duty cycle). The ams-OSRAM IR LED emits a much brighter light in the camera preview – again, in agreement with its much higher optical efficiency in comparison to the competing product’s IR LED chip used in this product – the SFH41747. Figure 13: Side-by-side comparison showing the ams-OSRAM SFH41747 (left, brighter) versus a competitor LED (right) under identical conditions — 400 mA, 25% duty cycle.. Comparative Analysis with Other IR Driver Solutions Having tested the AS1170 EVK in practical embedded applications, I felt that a comparison with the other commonly available solutions for IR LEDs and flash drivers could help me understand more about this device. I was not interested in just comparing technical specifications; rather, I wanted to look at practical issues like integration, versatility, safety features, etc. Feature ams OSRAM AS1170 EVK TI LM36011 TI LM3644 Generic MOSFET IR Driver Target Application IR LEDs / VCSEL / Embedded sensing IR illumination Camera flash + IR Basic LED switching Channels Dual-channel Single-channel Dual-channel Usually single Max Current Capability Up to 1 A per channel High-current flash capable High-current flash capable Depends on MOSFET Control Interface I²C + PWM + Strobe I²C I²C PWM / GPIO only Integrated Boost Converter Yes Yes Yes No External MCU Integration Very flexible (ESP32 tested) Moderate Moderate Manual implementation GUI Support Dedicated PC GUI included No dedicated GUI No dedicated GUI No Protection Features Thermal, UVLO, LED short, timeout Thermal + protection Thermal + protection Usually none Ease of Evaluation Very developer-focused IC-focused Mobile-focused DIY level Best Use Case 3D sensing, face unlock, IR systems IR flash Smartphone flash Simple IR LEDs Real-World Impression Most complete evaluation platform among compared options Strong IC but less evaluation-friendly Optimized mainly for mobile camera flash Cheap but lacks precision and protections Datasheet Deep Dive – How it Actually Works: Working Principle, Registers, and Characteristic Graph How the AS1170 Actually Works First and foremost, it’s worth noting that at its heart, the AS1170 is a current mode boost converter with precision current sink capabilities. The VIN pin is used to connect up a battery voltage that ranges over a typical range of 2.7 V to 4.4 V. The boost converter kicks this up to whatever voltage is required on VOUT to make sure that the LED voltage is always covered, while the precision current sink on LED_OUT1 and LED_OUT2 absorbs the LED current and regulates it to whatever was set in the current registers. The boost converter runs at a fixed 4 MHz. This is fast enough to allow very small inductors to be used – in this case, 1µH – but not so fast that EMI becomes a serious issue in RF circuits in a smartphone. The on-resistance of both the internal PMOS and NMOS switches is around 70mΩ – nice and low so that power is not wasted in these switches even at ampere-scale currents. Current Setting – How the Registers Map to Real Current led_current1 and led_current2 are 8-bit registers. From the register map above, current steps are 3.5 mA per LSB. The current is 551 mA per channel by default, as 0x9C is the default register setting. Setting both to 0xFF will get 900 mA per channel or 1800 mA total in flash mode with current_boost = 0, or 2000 mA total with current_boost = 1. There are operating modes, each of which has a current cap for the same register. In indicator/PWM mode (mode_setting = 01), only 6 bits of the register are used to cap current at 222.4 mA per channel. In assist light mode (mode_setting = 10), 7 bits of the register are used to cap current at 448.2 mA. In flash mode (mode_setting = 11), all 8 bits of the register are used to get up to 900 mA. Efficiency Graphs From the datasheet, Figure 4 is a plot of DCDC converter efficiency vs. VVIN (input voltage), for various levels of LED current. The important takeaway here is that at a typical 3.7 V Li-ion battery voltage, efficiency will remain within 90-95%. This drops significantly for lower voltage – lower than 3 V – which is why there is an undervoltage current reduction feature. Figure: AS1170 DCDC efficiency versus input voltage for various LED current configurations. Peak efficiency exceeds 95% at 3.7 V input with 1000–1300 mA load. From the datasheet, it can also be noted that Figure 5 indicates application efficiency, or rather, the efficiency in delivering power to the LED divided by the power being drawn from the supply. This is a much more useful figure, as it includes both the losses of the boost converter and the voltage drop across the current sink. With an application efficiency of 80-85% at 3.7 V, this means that for every 1W being drawn from the battery, 800-850 mW will actually get to the LED. This is a really impressive efficiency for a device of this complexity and size. Figure 6 in the datasheet shows battery input current versus VIN. What stands out here is that as input voltage drops (representing a discharging battery), the input current increases to maintain the same LED output power. This is the natural behaviour of a boost converter. At 2.8 V input with 2000 mA combined LED output, the battery current approaches 4 A — a number worth knowing when evaluating connector and trace sizing in a real product. Startup and Ramp Waveforms From the datasheet, it is clear that Figures 8 and 9 depict the LED current startup waveforms for 1.0 A and 800 mA, respectively. It is clear that the soft-start ramp is included, as the current does not change abruptly. Instead, it increases gradually over a period of 250 to 1000 µs. This is done internally to prevent a sudden surge in current, which would cause a voltage glitch. This is particularly important in RF environments, such as in smartphones, where noise is a critical factor Figure 8: AS1170 LED current startup waveform at 1.0 A — the soft-start ramp smoothly brings the LED current to its target value over approximately 500 µs, preventing supply voltage transients. Figure 9 shows the ramp-down waveform, which also performs smoothly. The ramp-down time is 500–1000 µs. Together, these controlled edges are what make the AS1170 suitable for camera flash applications where abrupt current switching could create visible artefacts in captured images. Short Circuit Protection As the current through the LEDs ramps up, the AS1170 monitors the voltage across the LEDs. If a short is detected, the voltage across the LEDs will be very close to zero. Therefore, this voltage should be less than the VLEDSHORT threshold of 1.0V. Once a short is detected, the boost converter is turned off, the current sinks are turned off, and the fault_led_short bit in the fault register is set. In a dual-LED system, if only one of the LEDs is shorted, then this LED is disabled and the part continues to operate with the good LED. This is a resilience feature that is actually useful in a production part. Potential application scenarios based on evaluation Of course, the AS1170 is not simply a device for hobbyists. It's a precision device for high-end applications. As I was reading through the application notes, I found myself wondering how many products I currently use that probably contain a device very similar to this working behind the scenes. Face Unlock and Biometric Authentication Today’s smartphones make use of a VCSEL flood illuminator to flood the face with near-infrared light and a dot projector for structured light, and these devices need high-precision, high-current pulsed light. The flash mode and strobe control of the AS1170 make it perfectly suited for these applications, as the processor configures the current and then fires individual flash pulses in sync with the camera frame capture, ensuring the IR light is only on for the time required for each frame of the depth map. 3D Sensing - Structured Light and Active Stereo Vision In the case of 3D cameras, which make use of a projector to send patterned infrared light, and then capture the distorted light to calculate depth, the ability to trigger from an external STROBE pin with sub-millisecond accuracy (flash timeout accuracy ±7.5%) makes the AS1170 perfectly suited for illumination in these devices. The auto_strobe = 1 mode is particularly relevant to this application, as it enables frame-by-frame illumination without any communication overheads between frames. Security Systems and Access Control For fixed-mount IR illuminators used with security cameras or face recognition terminal applications, an IR device is needed that can operate continuously in Assist Light mode. The AS1170's over-temperature protection, together with automatic current reduction when the device approaches its maximum operating temperature, makes it an appropriate device for these applications. Handheld Scanners and Industrial Sensing In barcode readers or other industrial scanners, the illumination cycle is often directly associated with the scan trigger. The AS1170's strobe trigger mode, together with its ability to drive two separate LED channels, makes it an appropriate device for applications where different illumination angles or intensities are needed for different scan targets. Robotics and Autonomous Systems For proximity and obstacle detection in robots, the AS1170 may be used to drive IR LEDs in the indicator/PWM mode with a moderate continuous current for always-on illumination of IR sensor arrays. The I²C interface enables the main MCU to adjust illumination intensity according to ambient conditions or power budget constraints. Technical References and Supporting Resources ams AS1170 Evaluation Kit ams AS1170 ams AS1170 Datasheet ams AS1170 Evaluation Kit GUI Software AS1170 Evaluation Kit Guide ams AS1170 Evaluation Kit Quick Start Guide ams A1170 Evaluation Kit Application Note Summary of Comparative Evaluation Upon analyzing data sheets, reference design and actual implementation considerations, I identified that the AS1170 EVK occupies its unique position, unlike many other LED driver products. Although such components as the TI LM36011 or LM3644 are very well optimized for applications in smartphone flash systems, AS1170 EVK appears to be far more flexible and development-friendly for experimenting with IR embedded systems. The most notable aspect of AS1170 EVK during comparative analysis is the combination of hardware flexibility with ease of software programming. The availability of GUI, external LED connections, ability to program strobes, two-channel configuration and connectivity to ESP32 microcontroller make the platform far more convenient than using any driver ICs and MOSFET drivers. When comparing the platform to simple MOSFET driver circuits, one can notice significant improvements in terms of better current regulation, higher level of safety, better timing accuracy and additional protection against overheating, low voltage conditions and LED faults. As for generic LED drivers, most of them are capable of producing high current levels, however, they are rarely optimized for IR pulses. Taking an engineer’s point of view, the AS1170 EVK seems to be a platform for prototyping rather than just a simple eval kit. This is due to features such as controllability, high current handling, boost topology, and the inclusion of tools designed by developers that make this module very useful in areas including 3D sensing, facial recognition, machine vision, robotics, and optics in embedded systems. This evaluation was particularly fascinating because I got to see that, despite its apparent simplicity, the IR LED driver is at the very heart of some really complex technology that we use all the time but never really think about. Despite not yet having received my extra LEDs, I'm definitely planning on testing out the breakout boards and doing something productive with them when they come in. Stay tuned!The TI LM36011/LM3644 and some analog devices’ IR flash drivers seem to be closest competitors, although after trying out the AS1170 EVK kit, it seems that AS1170 would be better suited for experimenting with infrared from an embedded design point of view.Evaluation BoardsThe primary problem was dealing with GUI to chip interfacing. It solved later.Received everything mentioned in the kit; however, due to some technical issues I did not receive the promised suitable LEDs.https://community.element14.com/products/roadtest/rv/roadtest_reviews/1910/foil_headwave_attenuator_devkit_applications_-_5_designsSat, 09 May 2026 04:54:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:d7a997f6-d8cb-4861-92ff-c7fead45f95fkmikemooOBJECTIVE: My objective in this RoadTest was the design and testing of various Foil aTtenuator options using the provided DevKit. Does the material and/or geometry of the headgear impact the effectiveness of the headgear? If so, which designs are most effective in protecting the wearer from unwanted cranial scans or monitoring? TEST PLAN: My testing plan is to build different variations of cranial shielding protective headgear and test their effectiveness. Loose and tight fitting cranial protectors will be tested. The test method will be to read sections of The Art of Electronics. If cranial scans are occuring, the test subject will have additional cranial activity and brain load - leading to sleep. The time from initiating reading and sleep will determine the effectiveness of the protective headgear: the longer the reading time, the more effective the headgear. MATERIALS: I did research other like materials - given that the attenuating media of choice is aluminum - of the foil variety. I ordered some attenuating foil from Temu. While it arrived quickly, I was not surprised by what I received. I belive that their source of supply is suspect and I wasn't quite sure of the units of measure that they used to describe the product. What is a "cantameter" anyway? Still, the price was cheap so I gave it a shot. Temu did not disappoint - although I will not be able to use their product. I compared the Aldis foil to the Element13 foil and decided to only use the Element13 foil as it was heavier and had a micro reflecting pattern that I belived to be more efficient at deflecting intrusive brain scans than the fully reflective surface of the Aldis brand. The Element13 foil is the picture on the left. Designs: The first design was the traditional "tin foil hat" design. It is modeled after the classic newspaper Captain's Hat and has been the traditional choice in cranial scanning protection for generations. It's stylish appearance belies it's subtle effectiveness. The angular design promotes reflection of any potential brain scans with extra attenuating material reinforcing the lateral plane. The one weakness of the design is the disproportionate protection of the side with extra material versus its opposite side – but with the right attenuating material, this argument is moot. The second design sought to minimize the space around the head so no extraneous emissions or scans could enter that space. A more form fitting headgear was designed and built to minimize potential entry points. A much less anglular design was selected in contrast to the angular design of the traditional Captain's Hat protection scheme. I call this the Beach Hat design. The third design attempted to capitalize on both the close fit and the angular design elements of the two previous designs. The approximation of flat sides and right angles may prove to be efficient attenuation characteristics in the testing phase. This style is also sometimes referred to as the Carpenter's Hat design. The fourth design opted to take a close cranial contour and angular deflection to a maximum level - for testing purposes. It also captures a classical design that has persisted for centuries. With a lineage as such, there has to be value in the design. This is the traditional Wizard Cap design. It is also my wife's favorite design. There is also no side view because it looks the same from every direction. In creating these designs, one flaw was noted. There is incomplete coverage of the lower cranial regions. Foil curtains could be added to any of the above designs to overcome this shortcoming BUT the fifth design attempted to mitigate this deficiency. The fifth design is a traditional attenuating helmet. It should be noted that once constructed, a major design flaw was revealed. It does not fit with my glasses on - so while it may be effective protection and attenuate brain scanning, it is limited in its use due to my poor eyesight. It also envoked an uncontrollable urge to shop for shrubberies. TESTING: Up to this point, this RoadTest had gone very well. Unfortunately, testing didn't turn out quite as expected. Perhaps a different test subject would have had more success. All attempts at the testing protocol ended with inconclusive results due to a lack of accurate data. No accurate time stamps could be asertained despite repeated attempts. CONCLUSION: I want to thank element13 for the opportunity to attempt this RoadTest. I do not feel that I was successful in completing my stated objectives BUT I do feel that I shared a few idea so others may pick up where I left off and continue the research. We all understand the value of protecting our thoughts from unwanted intrusion or monitoring and the only effective way to achieve that is through shielding. I will continue my research with the hope that one day, I will design the optimal Foil Headwave aTtenuator.tin foil hatdevelopment kitelement13Foil Headwave Aluminium aTtenuator DevKitprotectionAldis Aluminum Foil, Temu FoilPassivesValidating effectiveness of each design, finding comprable research projectshttps://community.element14.com/products/roadtest/m/managed-videos/151307Sat, 09 May 2026 03:30:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:aeaf73b3-2337-4555-82e5-10b1890736b9ralphjyhttps://community.element14.com/products/roadtest/m/managed-videos/151306Sat, 09 May 2026 03:30:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:9bca45fa-08cf-4f13-aacf-bca05877dd88ralphjyhttps://community.element14.com/products/roadtest/m/managed-videos/151305Sat, 09 May 2026 01:07:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c5afa04b-408f-4902-89e3-a1cd81841917ralphjyhttps://community.element14.com/products/roadtest/m/managed-videos/151304Sat, 09 May 2026 00:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:743d3b9b-b4aa-4b3a-ba93-ccda23957c25ralphjyhttps://community.element14.com/products/roadtest/m/managed-videos/151303Fri, 08 May 2026 21:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c3e33b39-7451-4867-a7d2-a2ee88f2f178ralphjyhttps://community.element14.com/products/roadtest/m/managed-videos/151302Fri, 08 May 2026 21:28:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:992fda81-5ddd-40d3-aa56-8b537f40078cralphjy