Posts made by Alex Kushleyev

For those who are tracking this issue.. We have some interesting updates with respect to the interference from IMX412 camera. As it has been previously documented, the IMX412 camera(s) on Starling 2 and Starling 2 Max are causing interference as soon as the streaming is enabled (there are clients to the streams that camera server offers for those cameras).

IMX412 camera has several internal clocks, which are generated from the 24 Mhz base frequency that is fed from Voxl2 to all cameras. These clocks are configured during the camera initialization phase - the settings are contained within the imx412 sensormodule files.

We were able to perform some parameter sweeps - specifically varying only the output MIPI bitrate, while keeping all other settings the same (gain, exposure, fps).

The test was set up as follows:

• generate imx412 sensormodule drivers for desired frequency range (1200-2100)
• all tests use the same camera resolution 3840x2160 at 45FPS
  • higher fps = more interference
  • tried to have a relatively large frequency range while keeping the fps high (low mipi rates cannot support high fps), so 45fps was a good compromise
• repeat for each frequency
  • copy appropriate sensormodules (for specific frequency) into /usr/lib/camera/
  • log baseline satellite signal strengths for all satellites 10 seconds -- this allows the experiment to not depend on any initial SNR captures at the beginning of the test, since SNR can change relatively quickly due to the environmental factors
  • start voxl-camera-server and voxl-inspect-cam hires_front_misp_color hires_down_misp_color and wait for 3 seconds
  • collect satellite SNRs for 10 seconds while the cameras are streaming
  • stop voxl-camera-server
  • wait for 3 seconds and repeat the loop for the next frequency

After data has been collected, analyze the logs and generate plots.

The tests were done outdoors using Starling 2 Max with original GPS receiver + V3 GPS mast and 75mm FR4 (with copper) circular plate under the receiver. Full Sun light and exposure was set to 0.1ms, gain to 100 (1.0x). During testing it was discovered that the most interference was present when the image was darker than normal (under-exposed) -- probably related to specifics of the MIPI packets that are causing the interference.

Note that the default IMX412 MIPI bitrate was set to the maximum that the camera officially supports, which is 2100Mbps.

As the plots show, there are several peaks where the satellite SNRs drop by 10-15dB, as initially noted in the overall system testing. Additionally, 2100Mbps is one of the worst frequencies to use, based on this data.

As a result of testing, the following frequencies were identified as causing significant interference with GPS L1 band:

• 1212Mhz
• 1260Mhz
• 1572-1578 Mhz (L1 band!!)
• 1800Mhz
• 2100Mhz

We will be releasing updated IMX412 drivers very shortly to avoid using 2100Mbps frequency.

There results below show 3 tests:

• 1200-2100 Mbps sweep with steps of 30Mbps
• 1200-2100 Mbps sweep with steps of 6Mbps
• 1760-2200 Mbps sweep with steps of 8Mbps (focusing on the upper range, slightly different PLL configuration)

1200-2100 Mbps sweep with steps of 30Mbps

1200-2100 Mbps sweep with steps of 6Mbps

1760-2200 Mbps sweep with steps of 8Mbps

Hi @irw ,

This seems like a hardware issue, potentially related to PMIC. Are you able to share full dmesg output from boot, when this issue is happening?

One thing to try would be to disconnect M0173 board from VOXL2 and see if you can reproduce the same messages related to cam_sensor*power_up -- these are definitely not normal. Perhaps there is a short on one of the camera power rails, which is preventing PMIC from working properly.

Alex

Hi @jameskuesel ,

Yes there is an issue when both MISP and snapshot are enabled. I will look into it again.

By the way, what snapshot are you looking to grab? There are a few options;

• a frame from high-res recording (with eis?)
• a frame from low-res streaming (with eis?)
• full frame, full resolution (no stabilization)
  • what format? jpg or raw bayer (for offline processing)

We can implement a snapshot feature in MISP (and not going through ISP).

Alex

@Noah-Heinen , unfortunately it is not possible to add a TOF sensor to your current Voxl2 Mini configuration. M0188 adapter does not support TOF.

The only way this would be possible is:

• remove M0188
• add M0172 and connect TOF and either M0186 or M0166 camera
• add another M0172 or M0194 and plug in a single camera. Unfortunately right now we don't have a small adapter like M0172 or M0194 that supports two standard cameras like M0166 or M0186.

So you would probably be losing one of the tracking cameras if you want to add a TOF sensor.

Alex

@Jskim , maybe it's ok that the Device ID is increasing, however it could mean the USB device is not de-initializing properly (according to the Kernel). Perhaps the device is still open / in use by voxl-uvc-server when you power the camera off (switch to the SD card mode).

Please see some more information below that may be helpful.

Fix 1: Configure voxl-uvc-server to identify the camera by Vendor/Product ID

Instead of relying on the device index, tell voxl-uvc-server to always find your camera by its USB VID:PID. This is the most robust approach.

Step 1: Find your camera's Vendor ID and Product ID

lsusb

Look for your UVC webcam in the output. The ID is in VENDOR:PRODUCT hex format, e.g.:

Bus 001 Device 003: ID 090c:337b  <-- vendor=090c, product=337b

You can also use the ModalAI helper script:

show-video-device-info.sh

Step 2: Update the voxl-uvc-server service to pass VID/PID

Edit the systemd service override so the server always targets your specific camera:

mkdir -p /etc/systemd/system/voxl-uvc-server.service.d/
cat > /etc/systemd/system/voxl-uvc-server.service.d/override.conf << EOF
[Service]
ExecStart=
ExecStart=/usr/bin/voxl-uvc-server -v <your-vendor-id> -p <your-product-id>
EOF
systemctl daemon-reload
systemctl restart voxl-uvc-server

Replace <your-vendor-id> and <your-product-id> with the hex values from lsusb. With this in place, voxl-uvc-server will find the camera by identity rather than by device node index, so it will survive power cycles without needing a manual restart.

Fix 2: Create a udev rule for a persistent /dev symlink

This assigns a stable name (e.g., /dev/uvc_cam) to your camera regardless of enumeration order:

cat > /etc/udev/rules.d/99-uvc-camera.rules << EOF
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="<your-vendor-id>", ATTRS{idProduct}=="<your-product-id>", SYMLINK+="uvc_cam", MODE="0660"
EOF
udevadm control --reload-rules
udevadm trigger

After this, /dev/uvc_cam will always point to your camera. You can reference this stable symlink in any configuration.

Fix 3: Check dmesg for resource leak warnings

If the device ID keeps incrementing (e.g., /dev/video0 → /dev/video1 → /dev/video2...) rather than re-using the same node, there may be an underlying resource leak from improper de-initialization:

dmesg | grep -i "uvc\|video\|usb" | tail -50

Look for warnings about disconnection or failed cleanup. If the ID increments indefinitely, this points to a kernel-side resource not being released properly on power-off — that may require a deeper fix or a systemctl stop voxl-uvc-server before powering down the camera.

Summary

The vendor/product ID approach (Fix 1) should eliminate the need for the manual systemctl restart workaround entirely.

@syamala-kotireddy ,

If the ESC is not showing any signs of life (no blue led blink), it probably means the ESC power regulator is not working properly. However, you mentioned that VOXL2 is actually booting fine? Can you measure the voltage on the connector / pads that provide 5V power from M0129 ESC to VOXL2?

Please see the following post, where a capacitor on the ESC next to the main voltage regulator was knocked off, resulting in ESC not starting up. https://forum.modalai.com/topic/4151/voxl-mini-4-in-1-esc-missing-capacitor/ . However, in that post, i think VOXL2 was not booting either. In your case the issue may be something different.

It is worth carefully inspecting the ESC.

Also, if you have a power supply that can measure current, you can set it to 8V and measure the current draw of the ESC alone, it should be very small (maybe 20-30mA) but not zero.

Alex

@restore , the change to enable the maximum resolution raw output for OV64B was made at the end of October 2025, so you would need at least SDK 1.6.0, I believe. There was a change in the camera pipeline (not the camera driver) to allow such a large image size. Are you able to test on a newer SDK (just test the latest if you can)?

Additionally, the resolution 9248x6944 cannot be directly used in MISP debayering (which uses OpenCL). There are some special requirements on the image stride, which width of 9248 does not match. So what will happen is the cpu will realign the image before feeding it to the gpu, but it is a lot of data to copy for a 64Mpix sensor. So I made a small change in width from 9248 to 9216 (just cut off 32 pixels) and it can be fed into the gpu directly. That change is not published yet, but i can share it.

Lets first confirm that you can use the 1.6.x SDK to start the camera server at 9248x6944 and you should be able to save raw bayer and view the misp output.

you can always double check the list of available raw resolutions using voxl-camera-server -l

by "start the misp output stream", i mean that you need to have a client that subscribes to the misp output stream, so that the frames start going and AE can work, sending exposure and gain updates to the camera, so that the image is properly exposed. For example, viewing the stream in voxl-portal or just using voxl-inspect-cam hires_misp_color to get the data flowing, then you can save the raw bayer, which will have the proper exposure and gain applied.

Alex

@Michael-Soul , it is EAR99

@restore , a few more things:

• you should set the auto exposure to lme_msv, which is the non-isp option, since we would not be using isp in this case
• before saving the raw bayer, start the misp output stream, so that AE can actually process, otherwise the exposure will be stuck in default value -- the bayer stream does not trigger AE to process.

Alex

@restore, that is strange. Does this effect appear in the jpeg snapshot only? (as opposed to the preview stream).

Yes, we do support saving raw bayer10 for this camera. For 9248 x 6944, each image would be something like 80MB (10-bit bayer)

In order to test it,

• set your preview width and height to 9248 x 6944
• en_raw_preview : true
• en_snapshot : false (for now)
• en_misp : true
• set misp width and height to something reasonable (1920x1080)

When you run it, assuming there are no errors, you should see hires_bayer pipe and you can dump individual images using voxl-record-raw-image tool.

I have not tested this in a while, but it should work. Let me know if you run into any issues.

Also, please use an SDK that is not older than few months, as we recently enabled the full raw resolution support for this camera.

Regarding the jpeg smoothing, the parameters are baked into the chromatix tuning file and we have not tuned that for any particular application. However, you should first check whether the jpeg encode quality is sufficiently high. snapshot_jpeg_quality param in your voxl-camera-server.conf is set to 75.

Alex

@austin-c , The GPS driver is built for SLPI as well as APPS PROC, so you could connect it to a apps-proc UART and start the driver on the apps proc side of PX4.

This was done on RB5 : https://docs.modalai.com/Qualcomm-Flight-RB5-linux-user-guide/

https://docs.modalai.com/voxl2-linux-user-guide/

Regarding magnetometer, just like with the GPS driver, you should be able to enable the mag driver to build for apps proc. Since the apps proc i2c uses standard posix interface, it should just work. However, i don't think we have ever tried it.

Alex

@ktrieu , you can find the STEP file for the M0166 camera module here : https://docs.modalai.com/pcb-catalog/

@syamala-kotireddy ,

If your M0129 ESC only has a label that says M0129, it most likely means it is M012-3. The only difference between -3 and -6 is that -6 is rated for 6S battery voltage (which is irrelevant for Starling 2).

Was the ESC working? How did it get into non-working state?

Please make sure PX4 is not running before you use the voxl-esc tools : systemctl stop voxl-px4. You should reboot, disable voxl-px4 and try to use voxl-esc tools directly from /usr/share/modalai/voxl-esc/

In order to test if the ESC itself is working, the best way to connect it directly to a Linux PC using a serial-to-usb adapter and use voxl-esc to scan, test, etc. You can make your own adapter or purchase one here.

Also, double check if the status of ESC LEDs when you turn on the power. Additionally, does the ESC make motor sounds? See additional debugging information here : https://docs.modalai.com/voxl-escs/faq/

Alex

@Jskim , you should check dmesg to see maybe there are some warnings. Perhaps the device is not de-initialized properly (how are you powering it off?) and next time the OS allocates a new Device ID.

Either way, using udev rule should help resolve the issue, however make sure there is no resource leak as a result of the device on/off. Also, if you keep turning the device on/off, does the device ID increment indefinitely?

Alex

@fhaltmayer , unfortunately, we do not have any updates at this time. It looks like we may never release Ubuntu 20.04 for VOXL2 because it is a LOT of work to switch to a new major Ubuntu release and test + maintain everything. Additionally, even Ubuntu 20.04 is already relatively old, so we are trying to focus our efforts on more forward-looking software development with larger impact.

Alex

Hi @austin-c ,

You can find the latest M0138 firmware with regen completely disabled here

Also, I added the esc config that i've been using for testing here

For step tests, i have been using pretty aggressive step command:

./voxl-esc-spin-step.py --id 2 --rpm 2000 --step-amplitude 4000 --step-frequency 2.0 --timeout 2.0 --cmd-rate 2000 --enable-plot 1

In order to make the ESC not de-sync (due to long demag time of the motor), the following params were adjusted:

• max_rpm_delta set to 4000 (you can go lower), to cap the maximum rpm transitions. Although in my test, the step is 4000, so this had no effect
• timing_advance: 45 -- this is pretty high commutation advance to trigger commutation earlier so that there is more time for back-emf sensing -- high advance wiil reduce motor efficiency and will cause the motor to heat up a bit more
• sense_advance: 30 -- delay back-emf sensing so that we don't sample back-emf during the motor coil demagnetization
• more details : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/dev/voxl-esc-tools/doc/low_kv_motor_tuning.md

I had another thought.. What if you use a small battery to absorb the voltage spikes? Basically hook up a 6-7S battery with a beefy Schottyky diode (10A) set up with Cathode (negative) pointing to the battery.

• you will have to make sure the power supply voltage never exceeds battery voltage + diode drop.
• you will also need to make sure that you don't over-charge the battery with repeated spike absorption.. It is possible to have some sort of self-discharge circuit to slowly discharge the battery to a certain voltage (using a Zener diode + resistor or something similar).

Anyway, just an idea..

Try out the no-regen firmware..

Alex

@fhaltmayer , it looks like there maybe something missing from /usr/lib/camera/, as the camera is detected by the i2c probe but not accepted by the system.

Can you please let me know how exactly the camera is connected (to camera slot/id 2, it seems) and also list all the contents of /usr/lib/camera/.

Alex

@cbay , yes this should work.

Whenever you add cameras of the same type, you should always check for possible I2C (CCI) conflicts. If you look here https://docs.modalai.com/M0188/#image-sensor-interfaces , the sensor IDs 0,2,3,6 (which is what you use) use unique CCI buses 0-3, so that is all good.

If you used ID 1, it would conflict with with another AR0144 on ID6 (both use CCI1)

One last thing to check is the sensor sync.

• if you see fsin in the configuration of the sensor (and name of the sensormodule in /usr/lib/camera/), it means it is set up as a sync slave
• currently you have the IDs 0 and 6 set up as sync slaves, but ID 2 and 3 as free-running

There are two issues enabling sync'ed drivers for AR0144 in ID 2 and 3:

• the driver is provided only for ID2 in : /usr/share/modalai/chi-cdk/ar0144-fsin/ - this is easy to fix
• ID1 and ID3 on M0188 do not have the sync line connected to the camera connector
  • this is easy to fix by installing a 0-ohm resistor, which is DNI by default.

Depending on your requirements for VIO (which VIO are you using?), you may or may not need the cameras synchronized.

Please let me know your requirements and we can go from there..

Alex

Hello @adam , please see the following post regarding GPS signal quality on Starling 2 and Starling 2 Max : https://forum.modalai.com/topic/5116/gnss-emi-mitigation-guidelines

There is no voxl-gps service - voxl-px4 handles the GPS functionality, so as long as that is running, the GPS module should be active. Please go through the documentation linked above, there are some mitigation steps that are relatively easy to implement.

We apologize for the inconvenience, but enabling usable GPS on Starling 2 will require some tweaks.

Alex

@RyanH ,

Sometimes there is small pieces of random magnetic debris that gets stuck in the motor.

First, you could try using compressed air to clear out the motor.

Additionally, It could help to spin the motor up and down using voxl-esc command line tools a few times to clear it out (without prop is best, just for safety). Spinning the motor without prop a bunch of times could get the debris dislodged and actually broken up by the moving motor parts, so that the debris is no longer large enough to cause a problem. Reversing motor spin using voxl-esc test tools can help dislodge the debris (you can commend negative power/rpm).

You can find useful info regarding motor testing here : https://docs.modalai.com/voxl-escs/faq/

Alex