ModalAI Forum

Yes, the beta release is fine. It was beta only for some features that are not used on our development drones. Otherwise it was a stable release.

@zauberflote1 Hi ZBFT, reagardng your fitst question: yes, we have added few elements: 2d Lidar 50gram above the gps bridge 2 x light ilumination (front, down - we are flying and dark tunnels next to tracking cameras) props guards the are seen by the tracking camera we have added tof camera, moving from C28 to C29 ( currently its not working or wired in sw), we have changed the extrinsix.conf file in /etc/modalai accordingly. all of those changes did not effect our filght and we had good flight with good vio during the flight. rerding youe second point: we did not fly with logs. that is the first thing we are going to do Sunday morning when we will be back in the lab. hope to understand more from logs. if not we will send it to you hopefully you can enlight us. regarding your third point I dont actualy know the answer: as I wrote first time I started this thread, we are monitoring the px4 using mavlink status and we see the horizontal position was lost in the middle of flight after starting a manuver to the right which is using position hold. but even when we tried to position hold from code we so vio is lost. I want to emphasize we had a stable system hw and sw wise and suddelny it degregated and we cannot put our finger what has changed. BR, Roy

@patkirkmartin , let me double check with the team what the process for this will be and the timeline. I will get back to you soon. Since the plan would be to provide the source to the public, it would be posted on gitlab, the feature-related discussion can happen there. We will certainly be able to help review the code and perform some testing. Alex

@Ben-Linne I'm likely able to perform those updates. A fix is good, but root cause understanding of the issue is better at this point, so I will try updates once all other debug opportunities are spent if I can't reach a deterministic resolution. receiver antenna [...] understood and checked out. I've confirmed the umcc(u.fl) connection is fully seated and no damage is present anywhere. If the transmitter is showing signal but the drone is not responding it's possible you are bound to another transmitter. this is a state I will confirm. So far though, I believe the failure mode is observable with no other transmitters powered, but i will confirm. Thanks.

That'a a calibration parameter that is set automatically by the mag calibration procedure. Normally it should properly detect the orientation / rotation and set it. I'm not sure why that wasn't happening for you when you calibrated the mag.

What is the physical connection between the Optical flow unit and the FC? Is it a UART? Which optical flow unit are you using?

I am able to download the log from the site along with all of the parameter settings. The accelerometer bias is clear in the log. Can you try to recalibrate the IMU with air flow on the unit to keep it from getting too hot? The yaw estimate error is not active during the log. However, to remove the interaction with VIO, try setting EKF2_EV_CTRL to 0 and see if that clears that occasional error. If it does then that helps narrow the issue to the VIO input versus the magnetometer / IMU input. Is the red light on the GPS unit or the RC receiver?

Hi @electroAJ, thanks for the detailed writeup and follow-up SKU info. From a hardware standpoint, the 200mV droop you are observing on VDC_5V_LOCAL and VDC_5V_LOCAL_USB1 during ToF activity is not a concern at the rail level. That kind of transient is most likely localized contact/pin loss at the connector interface rather than a bulk supply issue. On a 5V rail, 200mV is well within normal operating margin. The eFuse on that rail does not assert until approximately 4.4V, so a 200mV droop from 5V puts you nowhere near that threshold. Downstream logic is regulated from a 3.8V VBAT rail that has demonstrated margin well above the minimum needed, and that rail is permitted to droop past 3.3V before any real issue occurs. The ToF-induced droop is not your RC dropout culprit. Additionally, the M0129 VOXL Mini ESC power stage has been proven to the same load capability and test rigor as our standalone M0041 power module, using the same parts, so the supply itself is not a suspect to me. Would hate to see you chase a red herring. The I2C errors and UART dropout sequencing are worth looking at together as they may share a common upstream cause. Beyond that, this one is likely better handled by our software team who can dig into the dmesg and service state in more detail. I will flag this thread for them.

@ApoorvThapliyal Hello, I am using 1.6.3. Here is my attached output. Thank you! starling2-max (D0012):~$ voxl-version ──────────────────────────────────────────────────────────────────────────────── system-image: 1.8.06-M0054-14.1a-perf kernel: #1 SMP PREEMPT Wed Oct 22 04:29:38 UTC 2025 4.19.125 ──────────────────────────────────────────────────────────────────────────────── hw platform: M0054 mach.var: 1.2.1 SKU: MRB-D0012-4-V2-C29-T8-M36-X0 ──────────────────────────────────────────────────────────────────────────────── voxl-suite: 1.6.3 ──────────────────────────────────────────────────────────────────────────────── Packages: Repo: http://voxl-packages.modalai.com/ qrb5165 stable Last Updated: 2026-07-22 18:10:26 List: libfc-sensor 1.0.9 libmodal-cv 0.6.0 libmodal-exposure 0.1.4 libmodal-flow 1.0.3 libmodal-journal 0.2.7 libmodal-json 0.4.8 libmodal-pipe 2.14.11 libqrb5165-io 0.6.3 libvoxl-cci-direct 0.3.3 libvoxl-codec 0.0.2 libvoxl-cutils 0.1.6 modalai-slpi 1.2.2 mv-voxl 0.1-r0 qrb5165-bind 0.1-r0 qrb5165-dfs-server 0.2.0 qrb5165-mini-tof-server 0.2.2 qrb5165-rangefinder-server 0.1.6 qrb5165-slpi-test-sig 01-r0 qrb5165-tflite 2.17.2 voxl-bind-spektrum 0.1.1 voxl-camera-calibration 0.6.1 voxl-camera-server 2.2.19 voxl-ceres-solver 2:2.0.0-2 voxl-configurator 1.1.5 voxl-cpu-monitor 0.7.7 voxl-docker-support 1.3.1 voxl-elrs 1.1.0 voxl-esc 1.5.7 voxl-esptool 0.2.0 voxl-feature-tracker 0.5.2 voxl-flow-server 0.3.6 voxl-gphoto2-server 0.0.10 voxl-imu-server 2.0.1 voxl-io-server 0.0.8 voxl-jpeg-turbo 2.1.3-7 voxl-lepton-server 1.3.3 voxl-lepton-tracker 0.0.4 voxl-libgeographic 1.0.0 voxl-libgphoto2 0.0.4 voxl-libuvc 1.0.7 voxl-logger 0.6.1 voxl-mapper 0.2.4 voxl-mavcam-manager 0.6.0 voxl-mavlink 0.1.6 voxl-mavlink-server 1.4.14 voxl-microdds-agent 3.0.0-0 voxl-modem 1.2.3 voxl-mongoose 7.19.0 voxl-mpa-to-ros 0.3.9 voxl-mpa-to-ros2 0.0.7 voxl-mpa-tools 1.5.6 voxl-nano-tracker 0.1.7 voxl-nlopt 2.5.0-5 voxl-open-vins-server 0.6.0 voxl-opencv 4.5.5-3 voxl-osd 0.3.8 voxl-portal 0.8.7 voxl-px4 1.15.3-2.0.88-202606042017 voxl-px4-params 0.9.0 voxl-qvio-server 1.2.3 voxl-remote-id 0.0.9 voxl-reset-slpi 0.0.1 voxl-ros2-foxy 0.0.1 voxl-state-estimator 0.0.6 voxl-streamer 0.8.0 voxl-suite 1.6.3 voxl-tag-detector 0.1.0 voxl-tflite-server 0.5.1 voxl-utils 2.0.2 voxl-uvc-server 0.1.7 voxl-vision-hub 1.9.21 voxl-voxblox 1.1.5 voxl-vtx 2.0.2 voxl-wavemux 0.0.3 voxl2-io 0.0.3 voxl2-security-hardening-utls 1.0-r0 voxl2-system-image 1.8.06-r0 voxl2-wlan 1.0-r0 ────────────────────────────────────────────────────────────────────────────────

@Alex-Kushleyev Hey Alex. Thanks for this input. I will incorporate your feedback as we continue initial motor testing and let you know if we need further guidance. Much appreciated!

@Jetson-Nano Given the crash and hardware issues I'd recommend sending this board in for an RMA

What i meant was that sometimes, depending on the frame design, the orientation of the cameras may change slightly over time. This can happen as the plastics can change shape due to exposure to heat, sunlight, humidity (depends on the plastics), bumps and crashes, etc. Additionally, there has been some research showing that the camera + lens intrinsics change over time / temperature, especially if the lenses are made of plastic (which is the case in our old OV7251-based fisheye modules, which use plastic lenses - although we have not characterized them vs temperature). It is possible to use stiffer and more stable materials (metals, carbon fiber) to ensure that the sensor mounting remains consistent over time. I hope that answers your questions. Alex

Thanks for your patience, I will try to test this today.

@nickanick , Here is some background.. The Mini ESC (M0129) and the FPV ESC (M0138) do not have individual channel current sensing (unlike M0134 ESC), so the individual ESC channel current is reported as 0, while each ESC channel still reports the measured voltage in the standard telemetry packet sent to the FC. For these two ESCs (M0129 and M0138), one of the ESC channels measures the total board current that flows through the ESC and sends out a second telemetry message with just voltage and total current. For M0129, the ESC channel 3 does this, and for M0138, channel 2 (0-indexed). The telemetry messages are sent from the ESC to the FC (VOXL2) via UART and is parsed in the PX4 in voxl-esc driver. In the voxl-esc driver, if the battery status telemetry message is received from the ESC and VOXL_ESC_PUB_BST is enabled, then the driver will publish the battery_status topic with the battery voltage and current from the ESC telemetry message. In order to do a quick test to make sure the ESC is sending out the battery status, you can do the following: stop px4 : systemctl stop voxl-px4 test the ESC using voxl-esc tools (note that these tools are not part of px4): cd /usr/share/modalai/voxl-esc-tools ./voxl-esc-spin.py --id 255 --power 0 Note that you will be running a spin test command (take off props for safety!), but the command is 0, so the motors will not spin, but you will see the telemetry from the ESC being printed in the terminal on voxl2. You will seeBOARD_VOLTAGE and BOARD_CURRENT being reported and that is coming from the extra telemetry message from the ESC. If you see this current printed, then the ESC is sending the correct information. The argument --id 255 will tell the test script to communicate with all 4 ESC channels and the commands will be sent and telemetry requested from all 4 ESC channels (including the channel that sends back the battery status telemetry message). Can you please check this? voxl2:/usr/share/modalai/voxl-esc-tools$ ./voxl-esc-spin.py --id 255 --power 0 Detected Python version : 3.6.9 (default, Mar 10 2023, 16:46:00) [GCC 8.4.0] Found voxl-esc tools bin version: 1.9 VOXL Platform: M0054 Detected RB5 Flight, VOXL2 M0054 or M0104! INFO: Scanning for ESC firmware: /dev/slpi-uart-2, baud: 2000000 Sending library name request: libslpi_qrb5165_io.so Sending initialization request INFO: ESC(s) detected on port: /dev/slpi-uart-2, baud rate: 2000000 ID : 0 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555313000F0036 Firmware : version 39, hash 9c6233d6 Bootloader : version 184, hash 10bf24c8 ID : 1 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555313000F0032 Firmware : version 39, hash 9c6233d6 Bootloader : version 184, hash 10bf24c8 ID : 2 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555313000F0034 Firmware : version 39, hash 9c6233d6 Bootloader : version 184, hash 10bf24c8 ID : 3 Board : version 40: ModalAi 4-in-1 ESC (M0129-3) UID : 0x2039333557555313000F0038 Firmware : version 39, hash 9c6233d6 Bootloader : version 184, hash 10bf24c8 --------------------- WARNING: This test requires motors to spin at high speeds with propellers attached. Please ensure that appropriate protective equipment is being worn at all times and that the motor and propeller are adequately isolated from all persons. For best results, please perform this test at the nominal voltage for the battery used. Type "Yes" to continue: yes [0.015] (0) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A [0.015] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A [0.015] (2) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A [0.015] (3) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A [0.036] (0) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A [0.036] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A [0.036] (2) RPM: 0, PWR: 0, VOLTAGE: 16.059V, TEMPERATURE: 38.85C, CURRENT: 0.000A [0.036] (3) RPM: 0, PWR: 0, VOLTAGE: 0.000V, TEMPERATURE: 0.00C, CURRENT: 0.000A [0.059] (0) RPM: 0, PWR: 0, VOLTAGE: 16.039V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.059] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.24C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.059] (2) RPM: 0, PWR: 0, VOLTAGE: 16.059V, TEMPERATURE: 38.85C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.059] (3) RPM: 0, PWR: 0, VOLTAGE: 16.047V, TEMPERATURE: 38.86C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.075] (0) RPM: 0, PWR: 0, VOLTAGE: 16.039V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.075] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.075] (2) RPM: 0, PWR: 0, VOLTAGE: 16.065V, TEMPERATURE: 38.89C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.075] (3) RPM: 0, PWR: 0, VOLTAGE: 16.047V, TEMPERATURE: 38.86C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.047V, BOARD_CURRENT: 0.240A [0.101] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.19C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.101] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.101] (2) RPM: 0, PWR: 0, VOLTAGE: 16.065V, TEMPERATURE: 38.89C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.101] (3) RPM: 0, PWR: 0, VOLTAGE: 16.041V, TEMPERATURE: 38.91C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.119] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.19C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.119] (1) RPM: 0, PWR: 0, VOLTAGE: 16.054V, TEMPERATURE: 38.23C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.119] (2) RPM: 0, PWR: 0, VOLTAGE: 16.060V, TEMPERATURE: 38.88C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.119] (3) RPM: 0, PWR: 0, VOLTAGE: 16.041V, TEMPERATURE: 38.91C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.041V, BOARD_CURRENT: 0.232A [0.137] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.25C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A [0.137] (1) RPM: 0, PWR: 0, VOLTAGE: 16.049V, TEMPERATURE: 38.22C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A [0.137] (2) RPM: 0, PWR: 0, VOLTAGE: 16.060V, TEMPERATURE: 38.88C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A [0.137] (3) RPM: 0, PWR: 0, VOLTAGE: 16.043V, TEMPERATURE: 38.90C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A [0.156] (0) RPM: 0, PWR: 0, VOLTAGE: 16.044V, TEMPERATURE: 38.25C, CURRENT: 0.000A, BOARD_VOLTAGE: 16.043V, BOARD_CURRENT: 0.248A

Starling 2 Max is designed for 4S batteries only (two 2S Li-Ion battery packs, which are connected in series inside the vehicle). The Mini ESC, which also acts as a power source for VOXL2 inside the Starling 2 Max, is rated at least for 4S input (depending on the version of the ESC). There are several versions of the Mini ESC to provide the users some flexibility, in particular the voltage of the VOXL2 regulator (5V for VOXL2 and 3.8V for VOXL2 Mini). Since Starling2 Max uses a VOXL2, the ESC part number will be either M0129-5 or M0129-65. An updated (6S) version of the Mini ESC was released after the release of Starling 2 Max (new ESC part numbers: M0129-63, M0129-65). This ESC update extended the supported voltage for the ESC (not for Starling 2 Max) from 4S to 6S. The 4S version of the ESC has been phased out because the 6S version outperforms the original version even at 4S voltages (due to better Mosfets), so the 6S version is an improvement over the original 4S version of the ESC, while being fully backwards compatible. Using the 6S-rated ESC in the 4S-rated Starling 2 Max is completely safe. If you use the Mini ESC outside of the Starling 2 Max, you need to verify the part number / sticker on the ESC before plugging in 6S battery (M0129-63, M0129-65 only) The ESC variants and part numbers are documented here : https://docs.modalai.com/voxl-mini-esc-datasheet/ Alex

Hi @kristi, I'm experiencing a similar, though maybe not identical issue. Would you mind sharing the repeatability of your problem? is it consistent? thanks.

@alex-kushleyev @ModalAI-Team . Could you guys help me with this? thank you!

@Omri-Eival The Zorro Blue User Manual should answer most of your questions, with a shell script to copy all of the latest data to a handset in the provided zip file. While you are there, if your firmware is out of date it may be worth going through the update process.

For the past two years, I've made a living designing and integrating VOXL2-based systems for clients across Europe. In many cases, I've demonstrated autonomous flight capabilities to customers only to later recommend that they move away from the platform. I've even rebuilt equivalent systems at roughly 30–40% of the cost while delivering many of the same capabilities and, in some cases, a more reliable development experience. Ironically, a significant portion of my business exists because of the problems I've had to solve within the VOXL2 ecosystem. If you're considering VOXL2 for research or commercial work, I would strongly encourage you to carefully evaluate the platform before committing to it. Until ModalAI demonstrates a stronger commitment to documentation, software quality, hardware quality control, and customer support, I believe there are better alternatives for most developers. The following are the most consistent issues I've encountered. 1. Outdated and Incomplete Documentation Much of the documentation is outdated, incomplete, or simply incorrect. This creates a frustrating development experience where AI language models, developers, and even experienced robotics engineers are all relying on inaccurate information—not because the tools are wrong, but because the official documentation is. The result is wasted engineering time, unnecessary debugging, and teams losing confidence in otherwise competent engineers who end up chasing problems that originate from incorrect documentation rather than their own mistakes. 2. Quality Control Problems I've encountered multiple instances of hardware being shipped with incorrect labeling or configuration. The most surprising example was ESC boards intended for 4S batteries being labeled as 6S versions, and vice versa. Mistakes of this nature should never pass quality control. What was even more disappointing was the response. Rather than issuing a recall or offering replacements, I was effectively told to live with the problem. I shared that experience with my clients, and it ultimately contributed to the cancellation of an order for ten additional units. Poor customer support doesn't just damage individual relationships—it costs future business. 3. Weak Peripheral Ecosystem The surrounding hardware ecosystem feels underdeveloped for a premium platform. GPS shielding is inadequate, and many of the peripherals appear to be low-cost outsourced components with inconsistent quality. Signal integrity and EMI-related issues occur far more frequently than they should at this price point. 4. Thermal Design and Open-Source Accessibility One of the more surprising design decisions is that the Qualcomm compute board ships without active cooling. The apparent assumption is that propeller wash during flight will provide sufficient airflow. That may be true under ideal conditions, but it overlooks how many developers actually use the platform. Bench testing, indoor development, simulation, calibration, and autonomous software development often involve long periods where the aircraft is powered but stationary. I have a fan blowing into it but the device needs to have a cpu fan anyway. Developers coming from more traditional PX4 companion computer architectures also don't expect CPU temperatures to directly influence flight performance, because those systems typically separate the flight controller from the companion computer. On VOXL2, thermal throttling can become part of the flight stack's behavior, which is not obvious to new users. Compounding this issue is the difficulty of navigating ModalAI's platform-specific source code. While ModalAI works closely with PX4, locating and understanding the relevant code paths is far more difficult than it should be. This makes debugging platform-specific behavior unnecessarily time-consuming. 5. Confusing Feature Organization Several features behave in ways that are poorly documented or unintuitive. A common example is Vision Hub, where enabling certain functionality can unexpectedly cause the aircraft to fly a figure-eight trajectory as on by default. While there may be technical reasons for this behavior, they are not communicated clearly enough, leaving many users wondering whether they have misconfigured the system. Because a take off leads toe a fly away which makes the user think the PX4 paramers are incorrect when really they just left a demo code on in their system. 6. Non-Standard ESC Calibration The VOXL ESC calibration process differs significantly from standard PX4 workflows. As a result, it is often unclear whether calibration has completed successfully or whether changes have actually propagated through the PX4 stack. This ambiguity complicates troubleshooting and increases development time. 7. Excessive Platform-Specific Customization ModalAI has introduced a significant number of custom modifications to the PX4 ecosystem. While customization isn't inherently bad, many of these changes make the platform harder to understand, maintain, and debug. Instead of benefiting from the familiarity of standard PX4 workflows, developers frequently have to learn ModalAI-specific behaviors that add complexity without delivering proportional value. 8. Proprietary Cable Ecosystem The shielded 22-pin coax FFC cables are sold without publicly available pinout documentation. As a result, customers are forced to purchase expensive replacement cables instead of fabricating or repairing what is, in reality, a relatively inexpensive component. Publishing the pinout would save customers time and money without negatively impacting the platform. I could continue, but these are the recurring issues I encounter across professional deployments. If your goal is to make meaningful progress in research or commercial development, I believe most teams are better served by alternative platforms. If you choose to use VOXL2, I would recommend limiting it to the areas where it genuinely excels—primarily as a companion computer for its four-camera multiplexer and out of the box deployment of open vins. That is their business moat and for the drones mentioned above I spent 80% of my time having to do charge the client to solve this problem. The difference is i use parts at 50% the cost and make profit because I spend more time listening to the needs of my client and fostering relationship with other companies to foster a collaborative environment in the ecosystem of engineering development. Even then, I'm not convinced it represents good value. The weight savings rarely justify the cost, particularly as newer, lighter companion computers continue to emerge with more open software stacks, better documentation, and a significantly more developer-friendly ecosystem. None of these criticisms are impossible to fix. Most are engineering, documentation, or customer support issues rather than fundamental hardware limitations. However, until those issues are addressed, I find it difficult to recommend VOXL2 for anything beyond niche use cases. EMI Shielding on the device is very poor. This is by design