@modaltb Thanks a lot . I have updated to system image 1.3+. The device can be find on /dev Best Wishes

Thanks, @modaltb! yes, that seems to be the cause; we received two sentinel drones yesterday and for the same reason they have not had GPS signal available either. But that's ok, we don't need GPS for indoor flight tests. could you please comment on the odometery problem which I mentioned in the first post? I have two odemetry components with id=1 and id=197 in MAVLink Inspector in QGC. The odometry component with id=1 works fine and voxl-inpsect-imu outputs correct values in the VIO-enabled, GPS-disabled setting. But I get invalid local position for ekf2 status in MAVlink console and "reject position mode" message when try to fly the drone with RC in position mode. do I need to reset the PX4 firmware? thanks

Hi Xeno, We are not familiar with that sensor. The Flight Core portion of m500 is stock PX4. You could look at the connectors found on the Flight Core datasheet and see if there is an appropriate connection. Then you could see if PX4 supports that sensor. If it does not, you will need to develop the driver on your own. You can find details on building PX4 for Flight Core on the Flight Core Firmware page

Update: I've tried again and the licenses are now available. Seems like Qualcomm needed a day or so to propagate licenses. Thanks again for your help Eric.

@Steve-Turner Thanks for your information and I will check it. Dan

Hi @Ed-Sutter, A platform release just includes the latest sdk along with the system image build. As for voxl-configure-opkg, this was replaced by voxl-configure-pkg-manager with the same functionality.

@張為超 You are correct about the Original Order Number. In your case it would be 2838. First step for the RMA process is to fill out the RMA form and send it to rma@modalai.com Second is to purchase the RMA diagnostic (In this case you would choose drone diagnostic). Third would be to ship the drone back to ModalAI Headquarters. When we receive it we will look it over and email you a report of our findings and how to proceed. Step five usually is only after the team has looked over the RMA and we have discussed how to proceed.

Hi @SHofmeester , Sorry this message got lost on my side, any luck making progress on this?

Hi @shlee853 , Sorry this is a super old post that got missed, checking in to see if you were able to resolve the issue or not?

this is a standard linux networking system. Have you googled how to manage the network interfaces? Maybe make sure your routing tables are properly configured for what you are trying to do? https://opensource.com/business/16/8/introduction-linux-network-routing

yes, it sounds like a cable is not connected or was damaged somehow

@Chad-Sweet got it, thanks

@Chad-Sweet said in Change Altitude of Take-off mode: MIS_TAKEOFF_ALT I am able to set this value with the desired height. The issue is that why is it that the takeoff service height is ignored?

Thanks, I will try that

@Chad-Sweet I believe this is what I need. Thanks.

@MartinP This is a bug that we have since fixed but requires flashing that the image you're trying to flash in order to fix... However, a work-around is to do the following when forcing the board into fastboot: disconnect power and USB press and hold fastboot button attach power attach usb wait a few seconds now release fastboot button

@Eli-Pollack It's not something we've tried ourselves. I would recommend reaching out to Microhard. If they have suggestions, I may be able to help with figuring out implementation.

@Alex-Gardner @Matt-Turi Thank you for quick reply. It help me a lots. In conclusion, via cable, I can use adb pull to download file. via local network, I can use scp to download file. latest version, I can download file via voxl-portal Map page.