@I_Dwyer I have been down the rabbit hole here. It seems that qualcomm has not used any of the standard network management tools like Netplan. They use a hybrid of Systemd-Networkd and a wide range of complex scripts to manage all the interfaces. None of the scripts are standard. I am at the point of possibly stripping all of that out, and replacing it with either Ifupdown or Netplan and creating a firmware build that works better for our use case. There are a number of problems with the older Qualcomm network scripts, such as the DHCP management you are encountering. For example I have noticed that if WWAN0 has an IP, then WLAN0 will NOT get an IP from the DHCP server, even thought the wifi is connected to the local AP! To get around that I added an ifconfig statement issuing a static IP to wlan0 every time the drone boots, but this is a hacky solution.

Would like to see ModalAI replace the entire Network Management stack with something better and easier to maintain.

@Vinny said in Microhard pmddl2450 long range testing:

Hi @Aks ,
You might need to request help from Microhard on those two questions or maybe post a fresh forum topic specific to the MIMO question so our broader team sees it.
The only thing I can caution about adding encryption to your data is to understand the difference between baud rate (or link rate) vs data throughput (or data rate). You may be lengthening the number of bits per packet to include the encryption info yet your effective baud rate is unchanged, hence your effective user data throughput can decrease hence making it appear you have lower rate rates despite the radio performing well.
Something to think about.
Usually the more complex the interface with error bits, check bits, encoding bits, etc, add more "overhead" to the link relative to the user data. Perfect example: USB2 with 480Mbps... most applications can only get ~300-340Mbps from it, despite running at 480.

Just replying here with our own findings which we did recently for anyone looking to use MH radios. We opted for the pMDDL2350 specifically because it would have slightly less interference from the 2.4ghz WiFi bands. Vinny is spot on, use the lowest channel width and compression ratio you need for your requirement. We did some tests with the basic pigtail antennas and found that we could get about 800ft through solid concrete and brick buildings before the data would not transmit. In clear site, this turned into about 4km at about 10mb/s which is more than enough for telemetry and H.265 video with 256AES encryption (this was also done in a high interference area in a city, but with clear LOS for the radios). Also, as you pointed out the antennas on both sides can be improved. For the drone side you can use upgraded monopole type, and for the base you can order either more directional long range antennas, or a monopole, and Microhard also sells amplifiers if needed for really long range. It all depends on your use case. For us, ultra short range, around 500m radius in and around structures was needed, and these are way better than standard WiFi.

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

@Vinny Thanks! That is very interesting information.

So if I understand correctly, you are saying that when we added the ADS-B SDR radio it somehow changed the USB bus causing it to demand power for each device? My issue is that we removed everything except the ModalAI Carrier Board and still get the error (which we never got previously). Oddly, putting the carrier into another Linux computer produced the same error... this led us to think that the 5VDC wasn't being supplied properly... but now you're saying this might actually just be software. Why would the problem manifest without ANY other USB devices installed except the MH Carrier board?

Hi All,

So this is a new one for me. We had the base carrier board plugged into an Nvidia Jetson, this setup was working flawlessly for weeks. A few days ago, we added another USB device to the Jetson and noticed that the MH Carrier board started having connectivity issues. These were ultimately not IP networking issues, but instead the USB BUS itself was complaining of a lack of power as noted in this log snippet:

[459105.042939] usb 1-4.2: new high-speed USB device number 59 using xhci_hcd
[459105.149176] usb 1-4.2: New USB device found, idVendor=1f94, idProduct=3002, bcdDevice= 4.14
[459105.149181] usb 1-4.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[459105.149183] usb 1-4.2: Product: pMDDL2350AES256
[459105.149185] usb 1-4.2: Manufacturer: Microhard
[459105.149186] usb 1-4.2: SerialNumber: 1524269
[459105.149430] usb 1-4.2: rejected 1 configuration due to insufficient available bus power
[459105.149433] usb 1-4.2: no configuration chosen from 1 choice
[459106.801097] smsc75xx 1-4.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1
[459112.404859] smsc75xx 1-4.1:1.0 eth0: link down
[459113.998390] smsc75xx 1-4.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x4DE1

I do want to stress that this problem is persisting through multiple radios and carrier boards and on two different linux computers (the above snippet is actually with a brand new radio and carrier board on another Linux desktop). Since we have never seen this error before, our guess is to look at the external 5V connection as the possible point of failure?

What would be the ideal way to troubleshoot this? As I am writing this I am wondering if my power source for the external 5V is stable.

Thanks,

Jason

@Chad-Sweet More on this from the manufacturer:
MIPI Protocol

The product we use is 2lane MIPI. The MIPI interface includes 1 pair of source-synchronized differencing clocks and 2 pairs of differencing data lines clock signals, which enter the high-speed mode at the beginning of each frame and exit the high-speed mode at the end of each frame. The interframe is in low power mode (both data and clock line are at 1.2V high level). MINI2-640, for example, uses a clock frequency of 400MHz. The data line sends the start packet of each frame at the beginning and the end packet of each frame at the end. The number of long packets between the start and end packets of each frame is the same as the height value of the array (such as a 640 * 512 module with 512 long packets), and each long packet data contains row valid data.

@Chad-Sweet @Zachary-Lowell @Patrick-Hinchey

My company has been using the USB-C version of IRAY's very micro thermal core, which comes in two variants 320x240 and 640x480 as an option for our customers. They have informed me of the availability of their new MIPI version, and are asking for integration information. From what I saw in a previous post by Chad, this is not easy and requires an interposer board. I can tell you these cameras are excellent, the smallest on the market and full of options, and would make a great addition to the VOXL2 family. My company has a good relationship with the manufacturer and are willing to help develop this integration. Is it possible to get more detailed info? I have already told them that they will need the Qualcomm vision stack and sent them the specs on VOXL2, is it possible to get detailed information including PCB design and possible source code to other MIPI cameras for reference?

Thanks,

Jason

Hi all,

I realize that RemoteID is still a work in progress by the FAA and that the current architecture doesn't really make sense. That said, we are about to deploy our VOXL2 based system in a location where the FAA expects us to be broadcasting RID. The current docs use the VOXL in SoftAP mode as an example of broadcasting and supporting RemoteID. Unfortunately, our requirements don't allow us to use SoftAP, we are actually using Microhard 2.3ghz Radio, WiFi Client and LTE Cellular. I don't see how we can be broadcast compliant since nobody outside of our network can connect to or read any of our communications. The only simple way I can see to meet the requirement would be to expose a Bluetooth radio on the drone and direct the RID software on VOXL2 to use that for RID.

Bottom line, can we use a WiFi Adapter that support both WiFi and BT 4.2+ and then we can use the WiFi as a failover if needed but use the BT constantly to support broadcast of the RID information???

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

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

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

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

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