https://docs.modalai.com/modal-esc-datasheet/

Hi @mlarsen , If you're familiar with QGroundControl, similar to the pixhawks, you can use the Analyze > Logs feature to grab them (over an IP network not USB...) [image: 1667487221073-f8c31789-b1a1-4aa9-a498-d789ade3d86c-image.png] We are also saving this on disk here on VOXL2, eg: voxl2:/$ cd /data/px4/log/ voxl2:/data/px4/log$ ls sess001 sess003 sess005 sess007 sess009 sess011 sess013 sess015 sess002 sess004 sess006 sess008 sess010 sess012 sess014 voxl2:/data/px4/log$ ls sess001 log001.ulg log002.ulg log003.ulg Using the USB connection over adb, you can pull from device to your host system, eg: adb pull /data/px4/log/sess001/log001.ulg .

Same as every PX4 quadX: https://dev.px4.io/master/en/airframes/airframe_reference.html#quadrotor-x [image: 1666970979497-b3515d73-ffea-40c8-bacd-3c2584cfc059-image.png]

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

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.

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

@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.

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

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.

@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

@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

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

@modaltb Thank you. It works....

@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/

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.

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!