Best posts made by Mastermind

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