@Tamas-Pal-0 We have observed this issue a few times and the solution is always to either swap out the MCBL-0001: https://docs.modalai.com/cable-datasheets/#mcbl-00001 (power module to VOXL2 cable) or insepct the cable closely and push the wires back into the connector if they have come loose. It seems as though after time if these cables are unplugged and re-plugged often that there is enough degradation that the VOXL2 isn't able to pull the current necessary on boot and thus enters the boot cycle. We are actively looking into this issue to determine the root cause. If you aren't able to fix the issue based off this info we can get you a new MCBL-0001.

@Alex-Gardner After installing the packages from staging version the cameras are not working. How to solve it ?

HI @Akhil-Raj ,
We might be OK with the sequencing.
All OVT's specs are shared under NDA, so we do not have access to every sensor spec sheet that they make.
However, it should be OK if you can share the one chart of power up sequence requirements, and I can check our design to flag any issues or concerns. Most sensors have "no required sequence" such as the OV9782 Chad mentioned, and we have only come across 2 or 3 in our history that care about it, but I like to check.
So, let me know if you can re-post that data in whatever format is easy for you (screen shot, re-type, etc) But be sure to respect your NDA with OVT.

Thanks!

Hi, good question. For the low speed connector on VOXL 2, Zybax makes what you are looking for. https://www.zebax.com/index_files/page2540.htm

Last I checked they did not have one for our high-speed connector. We're hoping they make on though. If we can find a contact, we will reach out to them and see if they are going to.

Otherwise, any specific requests? We may have something in the works that will be useful.

@Aks You can probably get better answers by contacting Doodle Labs themselves and VOXL2 really only acts as a bridge to pass through data to the Doodle Labs network as the smart radios handle most of the networking themselves.

Here's a datasheet for the Helix smart radio: https://doodlelabs.com/datasheets/smart-radio-platform-1625-2510-mhz-datasheet/

@modaltb Thank you. It works....

@mrawding Wanted to reply here and say sudo did not work but sudo su allowed us to overcome this problem

@Daniel-Mellinger
I am still facing the issue with the remote, but i believe its only with the remote as I was able to get it flying in offboard mode using the VIO onboard. Its flying and is quite stable at the moment. Due to the nature of our research, we dont fly with the manual remote (we only use that for initial tests).
But from my experience im not sure if the remote controller could be at fault, because

I have used the same RC / receiver pair on the VOXL (version 1) and its able to fly in manual mode without any problems If you look at the Manual Control input plot in the px4 review mentioned in the 1st post, you will see that there are no discontinuities present in the signal. The setpoint thrust and pitch curves look fine. Whereas the setpoint pitch and thrust going into the attitude controller is quite discontinuous

In summary, we are just using the remote to change modes and trigger emergency kill switch and thus this bug is not affecting us anymore

@wilkinsaf Yeah no leds or noise. Welp, I am going to send this back for hardware inspection. See if a cable is loose. Thanks again @modaltb

Hi @pfranklin ,

Sorry for the lag.

The VOXL 2 architecture has a few processors, the I2C on the 5G modem port is mapped to the applications processor. The I2C we use by default in PX4 is connected to a DSP (image here https://docs.modalai.com/images/voxl2/m0054-px4-block-diagram-0.4.png).

For each driver we've used on the DSP, we've had to make a few small mods to get going. Here's an example of an I2C driver we use on the DSP for talking to a baro:

https://github.com/modalai/px4-firmware/tree/voxl-dev/src/drivers/barometer/icp10100

It's enabled in the build here:
https://github.com/modalai/px4-firmware/blob/voxl-dev/boards/modalai/rb5-flight/qurt.cmake#L55

Are you already using J19 pins 3 and 4? If not we could hijack those from the mag driver perhaps and you could use the sensor there.

I've been meaning to get this into a user guide as well, but for the applications processor GPIO, here's an example of setting IO programmatically, in this case GPIOs 46/159:

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-bind/-/blob/master/src/voxl-bind.c#L58

https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-bind/-/blob/master/src/voxl-bind.c#L147

@Vinny Sounds good, I'll look at the expansion board for J3. In the past, I've had issues maintaining 40MB/s write speeds over USB2, not sure if it was hardware or software, but thus my jump to USB3.

Thanks for the info about the Mythic, I'll reach out regarding that.

Moved to https://forum.modalai.com/topic/1481/5g-add-on-board-accessing-the-quectel-module-linux-shell

Hi @Mark-Lee ,
Chad is correct in that we have not tried it, but my idea is that if you wanted to access the Linux shell on the modem card, you would need a modem development platform from Quectel.
Here is an example I found online (please do your research to ensure this will work for you, but I do see they mention serial port access):
https://www.aliexpress.us/item/3256803611119964.html?gatewayAdapt=glo2usa4itemAdapt&_randl_shipto=US

In our architectures, we do have a mechanism to talk to the serial port over software using one of the QUPs, but there has been no need to do so, and would be a costly SW expense to develop it.
If you are willing to void your warranty (not recommended), I can show you which resistors have it and you could try to solder on to them, but you are better off with the Dev Kit IMHO.

Hi @Tamas-Pal-0 ,

You can calibrate outside of the system fully using something like this: https://www.youtube.com/watch?v=OOplk52R4no

I've not done this myself.... but it's the original way to do this from what I understand