SDK V1.0.1 Beta

Mastermind

@tom Thanks for the clarification. For some crazy reason I was misinformed and thought those two USB's could act as UARTs also.

For now I am referring to the pMDDL UART located in this image:

Mastermind

@Mastermind So this post is really about using the MH Radio with an external FC (in my case the ModalAI external FC), perhaps a title change is needed. Is there no current available UART that can be used for this, or J18 is the only option? If so, what steps would I need to take to make the previously mentioned code work?

On a side note, if I added a USB to UART adapter in between the MH Radio's 2 USB ports would that be an option? So MH USB-->UART Adapter-->Modal external FC

tom

@Mastermind There is no solution using the Microhard modem directly but since you're using an external fc we can utilize J18 on VOXL2 and turn it into an accessible UART via. some unreleased software as per @modaltb

https://forum.modalai.com/post/12041

Mastermind

@tom Ok I apologize AGAIN. Bare with me, as I am not with the actual hardware. The hardware is at a customer location where english isn't the first language (maybe not even the second).

Here is some valuable history and an update:

The external ModalAI FC was previously connected to the V2 LTE Carrier board USB using a short cable that was made in house. This setup was working for months without any problem using the USB port on the FC to the USB on the V2 Carrier Board.
V2 board was replaced by the MH pMDDL Carrier board and connected to USB3, however unlike the V2 LTE board, this connection does NOT populate lsusb with anything.

I confirmed that the USB on the carrier works, as the Alfa dongle produced a Realtek product listing in lsusb, but the FC does not populate as expected. Microhard made both carrier boards if I am not mistaken, so I would expect the wiring to be the same, and not something else.

Finally, to clarify, we aren't looking to use Telem1/2 but the USB instead as we did previously with the V2 LTE board.

modaltb

@Mastermind what are you wanting to use on VOXL2 to talk to the external flight controller SW wise, you own program, or voxl-mavlink-server?

I was about to start testing and I failed to realize we need to do some work to get voxl-mavlink-server to use this new interface... so more like EOW

Mastermind

@modaltb Somehow it's a conundrum for me. These customers somehow "incorrectly" managed to get the V2 LTE Carrier board to work with voxl-mavlink-server with the external flight controller using USB, not telem1/2. I've been asking for information about how they set this up and was told "We used the standard way of setup". I have no idea what that means. Here is what I know right now:

DMESG -W on the VOXL2 does show the external FC connected as ttyACM0:

[ 5625.761180] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
[ 8554.815948] usb 1-1.3: USB disconnect, device number 7
[ 8595.208465] usb 1-1.3: new full-speed USB device number 8 using xhci-hcd
[ 8595.299614] usb 1-1.3: New USB device found, idVendor=0483, idProduct=a330, bcdDevice= 1.01
[ 8595.299629] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8595.299640] usb 1-1.3: Product: PX4 FMU ModalAI FCv2
[ 8595.299649] usb 1-1.3: Manufacturer: ModalAI
[ 8595.299658] usb 1-1.3: SerialNumber: 0

However as you know, voxl-mavlink-server only talks on ttyHS0-2, so I am confused about how they had this working with the V2 LTE board. In any event, I tried a few hacks just to see if I could force this to work, I tried a few different ways of symlinking ttyACM0 and ttyHS0, but none of them work,

The great news is that it seems we should be able to use the MH Carrier with an external FC but voxl-mavlink-server needs to support this. In our case, the customer needs to use a 6S setup and the current internal VOXL2 FC and ESC only support 4S. Long term it would be nice to be able to carry the ModalAI external FC as a redundant controller (which is my long term goal) with the long range MH radio.

modaltb

@Mastermind OK I think I'm seeing things a bit more now!

First, let's confirm, when you say LTE v2, you mean this right? https://docs.modalai.com/4G-LTE-Modems/

I ask because Tom brought up, our 5G Modem, has a real UART: https://docs.modalai.com/5G-Modems/

OK back to the question, I think what you are seeing now, if you go directly from a USB port (say LTE board or MH board) to a Flight Core, you will basically be doing what happens when you connect a Flight Core to QGC.

That USB port on FCv1/FCv2 J3 is used for QGC connections and not telemetry like we expect via a UART TELEM. (as far as I know).

So imagine if you had QGC installed on VOXL2 (this won't work!) and then you had the setup of FC straight into USB, you would then have a QGC USB connection like a host PC!

Now, if there is a USB to Serial adapter between the LTE or MH board and a Flight Core's TELEM UART port, then I would expect something similar to enumerate in LSUSB (like /dev/ttyXXX) that COULD act as a UART, and then this would be OK to try with voxl-mavlink-server, but we likely need to modify code as it expects /dev/ttyHSX at this point.

So:
voxl2 --> add on board with USB --> straight to FC J3, not gonna work as we intended
voxl2 --> add on board with USB --> USB to Serial --> to FC TELEM port, should work as intended!

We are still pressing on with the DSP UART path and will get that online anyhow ASAP (but I'm kinda slow lately so bear with me)

Mastermind

@modaltb Thanks so much for the help here. After a lot of testing and translating with Google Translate, I finally understood how they they got it working on the LTE V2 board and how I finally got my setup working with the MH Carrier board.

They used socat to forward ttyACM0 to ttyHS4 and then created a .bashrc line to make socat run on boot. I found this to be messy and instead created a UDEV rule pointing ttyACM0 at ttyHS9 and then refreshed the UDEV rule and boom it works fine. I chose 9 only because I had no idea what ModalAI might want to use the rest of the HS numbers for.

This works really well with voxl-mavlink-server simply changing the conf file to point to UART 9 instead of 1

Thank you so much for all the help. If you need me to add more details to this or if anyone wants to see my actual edits and updates to make this work just let me know.

modaltb

@Mastermind holy moly! We haven't heard of this approach before! We'd love to learn more about this, if you could share here or even a google doc or something and we could get this approach into our user guides!

Mastermind

@modaltb Yes absolutely. In fact, I think some simple code update to voxl-mavlink-server would solve this. Essentially, we know the following:

It seems the ModalAI FC will ALWAYS be ttyACM0 when plugged into the MH Carrier board. At least this was true in all of our tests.

We know that ttyACM0 shows up in dmesg -w really fast on boot, well before the MH Radio even gets ttyACM1 (Not sure why that is...)

We have found that VOXL will hold the ttyHSx file in /dev even when the device is not connected and this cannot exist before enabling the UDEV rule or mavlink-server will think the UART is in use. So there needs to be some smart checking to ensure whatever value you have in the conf file DOESN'T exist BEFORE starting the udev rules AND before starting mavlink-server.

Create a file...
sudo nano /etc/udev/rules.d/99-usb-serial.rules
Put this in it for the ModalAI FC detected on the MH Radio USB carrier board
SUBSYSTEM=="tty", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="a330", SYMLINK+="ttyHS9"
Save the file and chmod +x to ensure access
Refresh UDEV with below to enable it
sudo udevadm control --reload-rules
sudo udevadm trigger

In my case I chose ttyHS9. I have been experimenting with a script/service as a workaround, but ideally the above would be programmed into mavlink-server itself to allow access to the FC over USB and not a UART, and even better over the MH Radio USB.

modaltb

@Mastermind thank you so much for documenting this, we are going give this a go and get it into our docs! Thanks for spending the time (and sticking up for us in the other post )

Mastermind

@modaltb Support is hard! I am not sure I could do it.