Yes, use the normal RC port. But cannot use an SBUS receiver with that port.

Great to hear @mikhail-mayers . I tested the module you sent back and it baffles me... must be some internal silicon damage to the IC since it had all in-spec inputs, and no faults on any outputs, but it was just not turning on... so, it is now one of my Mechanical Samples Glad we could get that resolved for you and thanks for your patience.

Thank you very much, Vinny, for your time and response.

Yes, your understanding is correct. To see the PX4 IMU values use standard PX4 commands. For example, on voxl2 you can use the PX4 listener commands: voxl2:/$ px4-listener sensor_accel TOPIC: sensor_accel sensor_accel timestamp: 30123125 (0.006725 seconds ago) timestamp_sample: 30122829 (296 us before timestamp) device_id: 2490378 (Type: 0x26, SPI:1 (0x00)) x: -0.05360 y: 0.01754 z: -9.68999 temperature: 34.62560 error_count: 0 clip_counter: [0, 0, 0] samples: 20 voxl2:/$ px4-listener sensor_gyro TOPIC: sensor_gyro sensor_gyro timestamp: 37716660 (0.003955 seconds ago) timestamp_sample: 37716405 (255 us before timestamp) device_id: 2490378 (Type: 0x26, SPI:1 (0x00)) x: -0.00409 y: 0.00796 z: -0.01429 temperature: 34.32669 error_count: 0 clip_counter: [0, 0, 0] samples: 20

Yes, unfortunately some of the dependencies have changed. Can you checkout tag sdk-1.6.4-1 of voxl-mpa-tools and then in the docker ./install_build_deps.sh qrb5165 sdk-1.6. That should work.

@astro_phil , I just tested your configuration on voxl2 mini ov7251 connected to M0135 JL imx214 connected to M0135 JU M0135 interposer connected to Voxl2 mini J7 cameras are connected to hardware camera slots 2 and 3 respectively This particular board is using an old SDK but it should not matter, kernel variant 2.0.0 hw platform: M0104 mach.var: 2.0.0 -------------------------------------------------------------------------------- voxl-suite: 1.3.3 voxl-camera-server -l DEBUG: Attempting to open the hal module DEBUG: SUCCESS: Camera module opened on attempt 0 DEBUG: ----------- Number of cameras: 2 DEBUG: Cam idx: 0, Cam slot: 2, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 1, Cam slot: 3, Slave Address: 0x0020, Sensor Id: 0x0214 DEBUG: Note: This list comes from the HAL module and may not be indicative DEBUG: of configurations that have full pipelines DEBUG: Number of cameras: 2 dmesg: [ 209.617719] CAM_INFO: CAM-ICP: cam_icp_mgr_hw_open: 3879 FW download done successfully [ 209.648730] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Linked as a consumer to regulator.59 [ 209.649003] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Linked as a consumer to regulator.55 [ 209.649103] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Linked as a consumer to regulator.60 [ 209.649137] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Linked as a consumer to regulator.79 [ 209.666156] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 918 Probe success,slot:3,slave_addr:0x20,sensor_id:0x214 [ 209.666263] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Dropping the link to regulator.79 [ 209.670389] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Dropping the link to regulator.60 [ 209.670476] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Dropping the link to regulator.55 [ 209.670541] qcom,camera ac50000.qcom,cci:qcom,cam-sensor3: Dropping the link to regulator.59 [ 209.688989] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.59 [ 209.691170] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.55 [ 209.693356] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.60 [ 209.693454] qcom,camera ac50000.qcom,cci:qcom,cam-sensor2: Linked as a consumer to regulator.79 [ 209.717968] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 731 [Applying Alternative Address] : Sensor Index : 2538021044 [ 209.717979] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 732 [Applying Alternative Address] : Slave Address : 0xE2 [ 209.717988] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 733 [Applying Alternative Address] : Slave sensor id: 0x7750 [ 209.717997] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 734 [Applying Alternative Address] : cci_client sid : 0x71 [ 209.718308] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 770 [Applying Alternative Address] : Probe : Alternate address updated [ 209.718543] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 918 Probe success,slot:2,slave_addr:0xe2,sensor_id:0x7750 I also tested the same configuration in J6: voxl-camera-server -l DEBUG: Attempting to open the hal module DEBUG: SUCCESS: Camera module opened on attempt 0 DEBUG: ----------- Number of cameras: 2 DEBUG: Cam idx: 0, Cam slot: 0, Slave Address: 0x00E2, Sensor Id: 0x7750 DEBUG: Cam idx: 1, Cam slot: 1, Slave Address: 0x0020, Sensor Id: 0x0214 DEBUG: Note: This list comes from the HAL module and may not be indicative DEBUG: of configurations that have full pipelines DEBUG: Number of cameras: 2 dmesg [ 216.996797] CAM_INFO: CAM-ICP: cam_icp_mgr_hw_open: 3879 FW download done successfully [ 217.029303] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Linked as a consumer to regulator.58 [ 217.029395] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Linked as a consumer to regulator.55 [ 217.029484] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Linked as a consumer to regulator.60 [ 217.029516] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Linked as a consumer to regulator.79 [ 217.046069] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 918 Probe success,slot:1,slave_addr:0x20,sensor_id:0x214 [ 217.046191] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Dropping the link to regulator.79 [ 217.050324] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Dropping the link to regulator.60 [ 217.050407] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Dropping the link to regulator.55 [ 217.050470] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor1: Dropping the link to regulator.58 [ 217.069409] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.58 [ 217.071541] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.55 [ 217.073710] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.60 [ 217.073801] qcom,camera ac4f000.qcom,cci:qcom,cam-sensor0: Linked as a consumer to regulator.79 [ 217.097221] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 731 [Applying Alternative Address] : Sensor Index : 390152372 [ 217.097229] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 732 [Applying Alternative Address] : Slave Address : 0xE2 [ 217.097234] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 733 [Applying Alternative Address] : Slave sensor id: 0x7750 [ 217.097239] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 734 [Applying Alternative Address] : cci_client sid : 0x71 [ 217.097532] CAM_INFO: CAM-SENSOR: cam_sensor_set_alt_id: 770 [Applying Alternative Address] : Probe : Alternate address updated [ 217.097747] CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 918 Probe success,slot:0,slave_addr:0xe2,sensor_id:0x7750 By the way, i think the SDKs are now not including the imx214 driver for slot 1. If you need it, you can use the following drivers https://storage.googleapis.com/modalai_public/temp/imx214_test_bins/imx214_eis_drivers_20250815.zip for all camera slots. The only functional change of these drivers is that the maximum resolution of the sensor has been changed from 4208 x 3120 to 4196 x 3120 due to some optimizations in gpu-based debayering that require certain image width (long story, but you can still use this driver, just may need to adjust your camera server config so that you are not requesting impossible resolution). When you do your tests, please make sure you have the correct sensormodule id's for each camera in /usr/lib/camera . The slot number where the camera is physically plugged in has to match the index at the end of the sensormodule file name (before .bin). Alex

The Doodle Labs pinout could be inferred from this cable mcbl-00085

Doodle Labs radios are pretty plug and play with the VOXL2, I've been working with that setup for a while. The breakout board used in that guide is one supplied by Doodle labs in an evaluation kit, but you don't really need it. The breakout board and radio shown in the pictures also seem to be older models, so the pinout and connections today are slightly different. The software setup is still the same, using voxl-configure-modem. With the VOXL2, you just need this cable: https://docs.modalai.com/cable-datasheets/#mcbl-00085 and an add on board that has a 10-pin USB + power port such as this: https://docs.modalai.com/m0151/ Then just connect the 6 pin cable to the mini oem's power port (port 4), and the 4 pin cable with the twisted wires goes to the mini oem's USB port (port 1), the mcbl-00085 link has some drawings. Then on the VOXL just run the configuration script. Also the radio can get hot pretty quickly so be wary of that. If you're using a mini oem for the GCS side you don't really need that breakout board from doodle labs, you just need a 5V 2-3A regulator to power the mini oem on port 4, and there is a Rj45 ethernet adapter from Ark Electronics that matches the pinout of the radio's ethernet port, and I like to connect it to the mini oem's ethernet port (port 2) for my GCS device to use, but you can also just use a USB-A to JST adapter connected to port 1 instead.

@Michael-Hatton Did you run through the voxl-configure-modem setup in order to configure APN, etc? https://docs.modalai.com/voxl-modem/#usage

@Michael-Hatton When you arm the drone it is in flight mode and the motors start to spin. It's that spinning of the motors that you don't want while plugged into a power supply. Only use your battery to actually spin the motors and fly.

@pmeras , the connector specs are provided here : https://docs.modalai.com/micro-coax-user-guide/ . Specifically, the connector part number is DF56C-26S-0.3V(51). You can find some more information regarding the cable pinout for our hires camera here : https://docs.modalai.com/M0186/ We do not manufacture custom cables, just the ones used in our VOXL camera ecosystem. Alex

@AndrewC , sorry for the delay. There are no hardware modifications to VOXL2 before installing it into Starling 2 Max. You would just need to configure SKU on your new VOXL2 board (https://docs.modalai.com/sku/) and just just reflash the latest SDK to start off clean. During the SDK install, there are a few steps (voxl-configure-mpa) that will load all the needed configurations for your SKU. Please let us know if you have any issues with that. Alex

@shiva-rv Try heating up the IMU by stressing the CPU then shooting it with air to create a large thermal gradient between the silicon of the VOXL2 and the IMU die itself, I predict you'll see the Z bias jump like crazy, but X and Y not so much. You might also observe that the temperature gradient determines the bias, not the absolute temperature, hence using a temperature model for compensation is useless, and not applied by modal: https://gitlab.com/voxl-public/voxl-sdk/services/qrb5165-imu-server/-/blob/master/server/src/imu_interface.cpp?ref_type=heads#L168 If you're curious about the physics of why MEMs IMUs like ICM42688 act this way I'm sure your favorite AI chatbot could give you a nice explanation about the materials sciences at play here. Practically, thermally isolate the IMU component as much as possible.

@Alex-Kushleyev, thank you for your answer. I confirm your assumption, when I set the decimator to 1, the fps is not divided. Here are the tests I did on SDK 1.5.0 and SDK 1.6.3 : test with SDK 1.5.0 ; fps = 10 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 2.90 | 0 | 1540 | 28.0 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 7170622 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.30 | 0 | 2155 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10666991 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = false or true | decimator = 5 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 869 | 9.4 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 10753813 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 test with SDK 1.6.3 fps = 10 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 3.02 | 0 | 260 | 29.7 | 10.0 | 3.5 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2052194 | 240 | 180 | 7.1 | -0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 1 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.18 | 0 | 7532 | 9.3 | 59.9 | 20.7 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2190721 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 fps = 60 | standy_enabled = true or false | decimator = 10 | Pipe Name | bytes | wide | hgt |exp(ms)| gain | frame id |latency(ms)| fps | mbps | format | tof_depth | 43200 | 180 | 240 | 1.20 | 0 | 83 | 10.1 | 6.0 | 2.1 | RAW8 timestamp(ms)| w | h | Zmax | center point (m) (conf) 2469720 | 240 | 180 | 3.1 | 0.0 0.0 0.0 0 As you can see, for SDK 1.5.0, fhe fps is NEVER divided, regardless of the value of standby_enabled. For SDK 1.6.3, fhe fps is ALWAYS divided, regardless of the value of standby_enabled. So, my problem is solved but I think you have a bug on the management of the paramater 'standby_enabled'. I fastly investigate the code of voxl-camera-server and I can't find where you are using 'standby_enabled'. Here is the search result in all the project : # Query: standby_en # ContextLines: 2 6 results - 2 files include/common_defs.h: 370 modal_exposure_msv_config_t ae_msv_info; ///< ModalAI AE data (MSV) 371 372: int standby_enabled; ///< Standby enabled for lidar 373 int decimator; ///< Decimator to use for standby 374 src/config_file.cpp: 129 printf(" gain_min : %d\n", cams[i].ae_msv_info.gain_min); 130 printf(" gain_max : %d\n", cams[i].ae_msv_info.gain_max); 131: printf(" standby_enabled: %d\n", cams[i].standby_enabled); 132 printf(" decimator: %d\n", cams[i].decimator); 133 printf(" independent_exposure:%d\n", cams[i].ind_exp); 642 // standby settings for tof only 643 if(is_tof_sensor(cam->type)) { 644: json_fetch_bool_with_default(item, "standby_enabled", (int*)&cam->standby_enabled, cam->standby_enabled); 645 json_fetch_int_with_default (item, "decimator", &cam->decimator, cam->decimator); 646 } Maybe you should add a condition in your function PerCameraMgr::ProcessTOFPreviewFrame(): void PerCameraMgr::ProcessTOFPreviewFrame(mpa_ion_buf_t* buffer_info, camera_image_metadata_t meta) { tofFrameCounter++; if(grab_cpu_pitmode_active() && tofFrameCounter % (int)configInfo.decimator != 0){ return; } auto noStridePlaneSize = static_cast<size_t>(pre_width*pre_height*1.5); auto realWidth = static_cast<uint32_t>(pre_width*1.5); uint8_t* noStridePlane; if (buffer_info->stride != realWidth) { noStridePlane = new uint8_t[noStridePlaneSize]; removePlaneStride(buffer_info->stride, realWidth, buffer_info->height, (uint8_t*) buffer_info->vaddress, noStridePlane); } else { noStridePlane = static_cast<uint8_t*>(buffer_info->vaddress); } uint16_t srcPixel16[pre_width * pre_height] = {0}; // NOTE we don't actually puvblish tis particular metadata to the pipe // TOF data is published separately in a very different way to cameras meta.format = IMAGE_FORMAT_RAW8; meta.size_bytes = pre_width * pre_height; meta.stride = pre_width; Mipi12ToRaw16(meta.size_bytes, noStridePlane, srcPixel16); tof_interface->ProcessRAW16(srcPixel16, meta.timestamp_ns); if (buffer_info->stride != realWidth) { delete[] noStridePlane; } M_VERBOSE("Sent tof data to royale for processing\n"); return; } Best regards Quentin