Also this is what I was getting when inspecting the mavlink server.

00:19:39.969721 IP 192.168.1.1. domain > 192.168.1.134. 40850: 5282 Refused 0/0/0 (42)
00:19:39.970315 IP 192.168.1.134.48451 > 192.168.1.1. domain: 5282+ PTR? 1.1.168.192. in-addr
• arpa. (42)
00: 19:39.973637 IP 192.168.1.1. domain > 192.168.1.134.48451: 5282 Refused 0/0/0 (42)
00:19:40. 106351 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:41. 068099 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:41.553204 ARP, Request who-has 192.168.1.1 tell 192.168.1.134, length 28
00:19:41.553488 ARP, Request who-has 192.168.1.138 tell 192.168.1.134, length 28
00:19:41.558414 ARP, Reply 192.168.1.1 is-at 80:69:1a:06:84:4e (oui Unknown), length 28
00:19:41.561634 ARP, Reply 192.168.1.138 is-at 34:c9:3d:07:16:8d (oui Unknown), length 28
00:19:42. 065376 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:43.070712 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21
00:19:44.075718 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:45. 064630
IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21
00:19:46.062935 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, Length 21
00: 19:47. 107960 IP 192.168.1.138.14550 > 192.168.1.134.14550: UDP, length 21

@ijones2 This is great news! It looks like everything is functioning as expected so no need to go through the unbricking process at this point.

It does appear that there is a fairly old SDK loaded on there so I would recommend flashing the latest SDK (1.3.3) from downloads.modalai.com under "VOXL 2 Platform Releases"

Just follow the instructions here to do so: https://docs.modalai.com/flash-system-image/#flashing-a-voxl-sdk-release

hmmm, There is a similar (but not exactly the same) behavior with SPI on APQ8096 where all reads are preceded by a single random byte meaning libvoxl-io needs to read one extra byte than expected and then discard the first dummy byte. However this happens under the hood here:

https://gitlab.com/voxl-public/voxl-sdk/core-libs/libapq8096-io/-/blob/master/lib/sdsp/io_rpc_spi.c#L254

I've not seen such a thing with I2C. Have you looked at our VL53L1X driver for APQ8096? It might just work with your newer VL53L1CB sensors with small changes.

https://gitlab.com/voxl-public/voxl-sdk/services/apq8096-rangefinder-server

@doe43john77 You're right, that isn't the case. That doc is a bit outdated (we're going through a massive overhaul of the docs at the moment that will be live in a few weeks)

As long as both devices are connected to the same VPN it would work just fine. So you absolutely could have your host machine connected to the internet via. wifi / ethernet as long as it then connects to said VPN

@tpavlic Thank you, glad it helped!

LuxF7HD is a betaflight flight controller. https://rpg.ifi.uzh.ch/docs/IROS18_Falanga.pdf developers from the university at zurich were able to bridge the betaflight controller to the onboard computer. we think we have the wiring portion done, but we need to somehow send the parameters changes from the voxl to the betaflight controller via a serial port. we are using serial port j10012 currently. please let us if you have any ideas on how to bridge the two

Check out the troubleshooting tips here for future referenec

https://docs.modalai.com/flying-with-vio/#position-mode-rejected

Wanted to update this by saying I experienced same issue, but I resolved this by disconnecting tracking camera that had been installed upside down. So, if anyone is reading this in the future....try disconnecting your cameras attached to the board

@vmassague Hi, I am pretty much doing the same thing and I faced a similar issue with you.
have you solved this issue?
https://forum.modalai.com/topic/919/using-motion-capture-systems-optitrack-for-position-estimation/2?_=1656684369036