Indeed it was the diodes! I was able to fix one board by bridging the pads with some solder, the other one had the pads completely gone. Very strange, the flight cores are powered by the VOXL with the serial pins connected as well, but I don't see how that could cause hardware damage?

Hey @colerose, What was the voxl-streamer output when you tried to start the second stream? I was able to successfully start a stream with both the hires and tflite-overlay cameras, however voxl-streamer is very resource intensive when we have multiple streams running. Have you considered using voxl-portal to view both? [image: 1631730040501-dual_camera_streams.png]

@Matt-Turi Great thanks! I'll give it a shot now!

Hey everyone, just wanted to let you know that my fix got merged into master so it should work for everyone now... I'd have loved to change the title of this to something a little more descriptive but it's too late now I guess. anyway, cheers everyone, happy flying.

@SWARNA-MOHAN-CHANDRA-KANTH said in How to use PCA9685 with voxl: PCA9685 Seems like that is an I2C device, you could start looking here at how to control an I2C bus from VOXL: https://docs.modalai.com/voxl-i2c-io/ How are you looking to control this and for what use case? Above assumes you are running the I2C program on the VOXL's processor (not PX4). If using PX4, you'd want to do this in the PX4 firmware instead.

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

Actually, I don't think it's possible because two identical PMD sensors will have the same I2C ids and communication will interfere. All cameras, with the exception of right stereo (if stereo flex is used) are communicating on the same (primary) i2c bus. The right stereo camera uses the secondary i2c bus. If it were possible to change the I2C id of the PMD sensor, then it could work, but I am not sure if that's an option.

@modaltb said in Soft-Reboot not working: Hi @m4v3r , If you have VOXL connected via ADB and issue a reboot command via QGC, do you lose the ADB connection? Hi, yes if it's rebooted in ADB it's the same behavior. This particular VOXL did live through several crashes and stuff though (I am a test-pilot mainly afterall ... ;D) so it might just be busted. A different one, setup exactly the same, behaves as expected. Thanks for the insight though.

Computer Vision, of course. =D Since working with the VOXL I already learned RTK, VIO, EKF and so on... but this one escaped me, so thanks haha.^^

Welcome aboard Chris! Looking forward to helping out.

Our sense resistors aren't capable of measuring that amperage (out of spec for this power module), but the connector would be an XT90 or greater. To get accurate current readings (not sure if that's critical for you or not), then you'd need to rework the power module's and then update some PX4 params.

Oh yes, this would absolutely cause a problem. Glad you found it. You can find just the stereo flex cables here : https://www.modalai.com/collections/accessories/products/voxl-replacement-stereo-flex-cable

@modaltb i am using win10. i can ping to voxl. Pinging 192.168.8.1 with 32 bytes of data: Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Ping statistics for 192.168.8.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 3ms, Average = 3ms C:\Users\David>ping 192.168.8.1 Pinging 192.168.8.1 with 32 bytes of data: Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Reply from 192.168.8.1: bytes=32 time=4ms TTL=64 Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Reply from 192.168.8.1: bytes=32 time=3ms TTL=64 Ping statistics for 192.168.8.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 4ms, Average = 3ms i have turned windows firewall off. qgroundcontrol still no response

@Mark-Sears Hi, I have also got the flight deck only. Now, I would like to connect to FS-iA6B receiver. For that given cable is not suitable. Could you please suggest me in this regard. Thanks

Although a majority of our testing is at the higher baud, we've used lower without problems, so it should be fine.

@Eric-Katzfey The main cause was system image version. The internet problem has solved! now i'll try again the QGC setup. Thanks a lot.

Hi @Prasad-Pawar , Might be better to post QGC queries on their forum: https://discuss.px4.io/ Thanks!