Thank you very much, Eric. That answers our question about the RC receiver. If we remove the ELRS receiver and fly with a QGC joystick over Wi-Fi, is there anything we should set for the case where the Wi-Fi/QGC link is lost (for example, a GCS loss failsafe such as land or hold)? We would also be grateful for any information on the remaining points: Wi-Fi (-M36): What is the model of the included Wi-Fi dongle? Can VOXL 2 use another USB Wi-Fi adapter, and if so, which chipsets/drivers are supported? (In Japan we need a radio that is certified under Japanese radio law.) Propeller guards: Are official guards or a cage available for the Starling 2 Max? If not, are CAD/STEP files of the frame or arms available so we can design 3D-printed guards? Payload (about 100-300 g): Is there a recommended mounting point or mounting holes on the frame? What power output is available for a payload (voltage and maximum current)? And roughly what flight time should we expect with 300 g? Lead time: Is "ships within 60 business days" still the current lead time for the C28 / Wi-Fi configuration? Thank you again for your help.

There's some documentation here: https://docs.px4.io/main/en/flight_modes/offboard#ros-2-offboard-control. I would review that to make sure you are following the correct procedures.

Title: Starling 2 Max – Flight Performance at 2,800–3,000 m Above Sea Level Hello ModalAI Engineering Team, We are evaluating the Starling 2 Max for research flights inside rose greenhouses in Tabacundo, Ecuador, at approximately 2,800–3,000 meters above sea level. Before purchasing the aircraft, we need to assess whether this operating environment falls within its safe flight-performance limits. Could you please clarify: What is the maximum recommended operating altitude above mean sea level for the Starling 2 Max? Has flight performance been tested or characterized at approximately 3,000 meters above sea level? What reduction in thrust margin or flight endurance should we expect at this altitude? Are there recommended limits for payload, battery configuration, ambient temperature, or mission duration under these conditions? Does ModalAI provide performance curves or engineering data that could help us evaluate this operating scenario? Are there any special safety precautions or configuration changes recommended for high-altitude operation? Our primary concern is maintaining adequate thrust margin and safe, repeatable flight performance inside a confined greenhouse environment. We would appreciate any relevant documentation or test data. Thank you. FloraVision AI Engineering Team Ecuador

Hi @marcos-correa Apologies for the delays here, I was out on leave for a couple weeks. It sounds like the M0141 issue you might be having is very similar to this one: https://forum.modalai.com/topic/1356/sentinel-drone-randomly-reboots/2?_=1790714717250 It's important to use 5mm spacers between any VOXL 2 plug-in board, especially if it only picks up J3 and not J5, since that leave all the pins on J5 vulnerable to contacting circuitry from whatever plug-in board is installed. Symptoms from that contact are most certainly proven to be resets and brown outs, as we have seen that before. If you are already using spacers between your board, then I'd need to think about other potential root causes. Hope this helps. Thanks! Vinny

It looks like we have one M10000633 on hand. Reach out to https://modalai.com/contact and see if they can get it to you

Michael, They take approximately 60 days to deliver once you put in a order.

@tom thank you

Most of this can be answered by our documentation here: https://docs.modalai.com/. If after reading through that you still have any specific questions feel free to reach out here on the forum. The short answer to most of your questions is "yes".

Hi @tom, That's exactly what I was looking for, thank you!

Hi @alraj, 05c6:900e QUSB_BULK is not EDL (that is 9008). It is the SoC crash-dump mode, so the board is attempting to boot and failing before the OS comes up. Since Sahara/Firehose completed with the correct M0054-2 image, the flash contents are unlikely to be the problem. In past cases a board that returns to 900e after a successful QDL has not been recoverable by reflashing (https://forum.modalai.com/topic/1468 and https://forum.modalai.com/topic/3263), and a similar Sentinel case came back from RMA as a damaged main board (https://forum.modalai.com/topic/2131). Two things worth ruling out first. Pull the VOXL 2 out of the drone and boot it bare with every camera and add-on disconnected, since a mis-seated camera connector produced this same 900e state once (https://forum.modalai.com/topic/3230). Then re-check the steps at https://docs.modalai.com/voxl2-unbricking/#if-the-device-still-shows-900e-or-boot-loops-after-a-successful-flash and repeat the flash once. If it still comes back as 900e, an RMA is the next step: https://www.modalai.com/pages/rma. Include the serial number and QDL log. Keep the crash dump private, support can request it if needed.

The ExpressLRS receiver requires* one additional wire. The ghost atto only connects one wire to the VOXL RC RX pin, but the ELRS receiver will also require a connection to the VOXL RC TX pin, otherwise the wiring is identical. Pre-crimped wires can be found easily for the JST GH connectors (J19) to make adding connections simple. *You could leave the receiver's RX line (the VOXL's RC TX) disconnected; this would make updates and other control using the voxl-elrs application impossible but basic RC functionality would work.

@alex-kushleyev Thanks for the response! A control model is a simple MLP (multi-layer perceptron) Input observation space: PX4 odometry topics, ToF depth/Depth estimation model, object detections. Output action space: PX4 offboard commands ( position and yaw for now, but we might extend to velocity/Collective thrust and body rates)

I want to develop a battery management system to read live battery data and use it into a software that plans launch, path, return and control of the drone

RMA'd the VOXL2 board, it was found to be unrepairable.