@Alex-Kushleyev , Thank you, I successfully ordered the it.

@Vinny Yes, thank you very much!

We have updated the M0129 in the past few months to support 2S-6S, it looks like the datasheet is out of date. Thanks for pointing that out. If it is marked M0129-63 or M0129-65 it supports 6S M0129-3 and M0129-5 are the older version and they only go up to 4S

@Vinny Thank you for reverting back, I will follow the steps you mentioned along with the ESD safe method.

@Alex-Kushleyev Ok great. Thanks. One more question, to configure VIO/QVIO for a custom frame with a single (downward) camera, how should I go about following the documentations? I am starting with https://docs.modalai.com/open-vins/ However I came across this: "This documentaion will assume that there are some steps that have already be taken. ...Assuming that we are working with between two and three camera tracking." are there different procedures for a system with single camera? Also a high-level roadmap on how to go about configuring VIO/QVIO for a custom frame would be appreciated in case information is in multiple places in documentation. Thank you for your support.

@Vinny Got it. Thanks!

Hi @18257581 Sometimes our newer boards are lacking in full documentation, so thanks for your patience. We have not publicly posted our uCoax pinouts and not sure yet if we plan to. For now it is required to use our full solution which is host adapters, cables, and sensor boards. I'll bring it to the team. But, we are unlikely to open this up since in order for us to test the components, which are very fragile, they need to be bundled together and not separated, so it would actually cost us more (costing our customers more) to test units individually for customer designs. Only the Coax cable we sell individually and that is pinned 1:1 with all 26 conductors present unlike some of the other COTS FPV systems. However, for JST and other cable-to-board and board-to-board connectors, yes, we need to get that listed. The pinout on J4 of M0201 (the replacement for M0153) is in the same Dronecode inspired format we use at ModalAI for UART + I2C, but in this case since it is not UART, it is 2 GPIOS. So, Pin 1 = 3.3V Pin 2 = GPIO_1 (Undefined/Unavailable/Reserved for Future Use) Pin 3 = GPIO_2 (Undefined/Unavailable/Reserved for Future Use) Pin 4 = GIMBAL_I2C_SDA (3.3V Logic Levels, 2.2K pull-up resistor present) Pin 5 = GIMBAL_I2C_SCL (3.3V Logic Levels, 2.2K pull-up resistor present) Pin 6 = GND

@Sam-Kiley , yes, every Starling 2 / MAX is going to have M0173 board installed and needs to use the option 1. Alex

@psafi the html file is saved in the same folder where you run voxl-esc-spin* scripts if you have --enable-plot 1 . on VOXL2, the plot wont show up on screen, since there is no screen attached to VOXL2 (which would work on a linux pc), but it will be saved to html. In order to save to html, you will need to have plotly installed. You may first need to install pip3 apt update apt install python3-pip pip3 install plotly --upgrade Alex

Please keep in mind that the bayer image may have padding at the end of each row in order to align the line start with 16 or 32 byte boundary. This padding is done by the ISP when it receives the image from the camera. For example, a number of common raw resolutions have the line stride listed in the FindFrameSize function in voxl-camera-server source code: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L4636

@Rowan-Dempster , Here is where the raw data from the TOF sensor comes into voxl-camera-server : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/hal3_camera_mgr.cpp?ref_type=heads#L1242 The data is in the MIPI12 packed format. The TOF library expects RAW16 format, so the data is converted from MIPI12 to RAW16 and fed into the TOF processing library. It is possible that dumping the RAW data is what RRF recording would be doing, so you could add that functionality to camera server to write the raw data to file. I could also help with publishing the RAW12 data as is to a mpa channel, so you can log it outside of the camera server (for example using voxl-record-raw-image utility. You could clarify with PMD if that would work (in other words, you would need to know the log format of the RRF recording) We have not tried enabling the raw data logging. However, if you know what function needs to be called within PMD library (maybe you just enable logging, and it does everything for you), you should be able to add it somewhere in the TOF init code, maybe here : https://gitlab.com/voxl-public/voxl-sdk/services/voxl-camera-server/-/blob/dev/src/tof_interface.cpp?ref_type=heads#L982 You can find the API header files for Royale / Spectre in /usr/include/royale either on VOXL2 directly on in /opt/sysroots/qrb5165_1/usr/include/royale the voxl-cross:V4.4 docker. Hopefully that helps! Alex

Hello @Aaky , If you have a new motor / prop, please follow these instructions for initial tuning : https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/calibration.md?ref_type=heads We don't have this specific motor / propeller combo, but if you send a link where I can purchase these, I would be happy to do a tuning pass and some testing for you. Alex

@tomverstappen , I am glad you got this resolved. The "unknown board" message you were receiving was due to the older release of voxl-esc package, which did not recognize (and did not have firmware for) the M0129-6 ESC, which is the 6S-compatible version of the M0129 ESC. I hope this clarifies that issue. Alex

@Moderator Mint operates on the TMobile network so you we use the APN: fast.t-mobile.com. I have noticed that when I use the Mint SIM in an Android phone it uses the wholesale APN but fast.t-mobile.com will work with our modems.

@Alex-Kushleyev, Yes, what you have described for the client application is what I am trying to design. Ideally, I would have time synchronization so that frames always line up, but if latency isn't too big of an issue, this should work fine. I was planning on working with the RGB image, but I'm open to using YUV if it offers a noticeable reduction in latency. Also, to clarify my current setup, I have 4 AR0144 cameras placed at 90-degree angles to one another, so there is plenty of overlap between adjacent cameras for stitching. A simple example would be extremely useful! Thanks for your help!

@alexvolt , the datasheet for M0107 can be found here : https://docs.modalai.com/M0107/ . This is a Sony IMX412 camera. The connector pin-out provides the power supply voltages. This module is designed to work with VOXL products and it we would not be able to provide much support for connecting this camera module to another platform. The main reason being that inability to test the custom setup ourselves would make any debugging very difficult. Alex

Hi @Manoj-Kashyap As per that thread, we EOL'd M0169, so support should move to M0171. However, if you already have some M0169's, then this cable which will replace your normal MCBL-00001 will do the trick: https://docs.modalai.com/cable-datasheets/#mcbl-00095 Purchase link here: https://www.modalai.com/products/mcbl-00095

@erik I saw this discussion (https://forum.modalai.com/topic/4333/compatible-tof-sensor-setup-with-voxl2-mini) now, which answers some of my question. Thank you for getting back on the rest.

@Alex-May , our lenses do not have any IP rating for waterproofing, so we cannot provide any guarantee regarding the performance when exposed to water. Alex