Posts made by Mastermind

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

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

@tom If that is true, how come I cannot see those on the VOXL? How do they should up? If I plug the external FC into the MH Carrier board, I should be able to see the FC show up in when doing lsusb right? But it doesn't. Can you tell me what I am doing wrong? If needed I can wire it up and show you the outputs I am seeing.

@modaltb Thanks!

I totally misunderstood. I thought this update was to expose the 2 USB ports on the MH carrier board. As I understand it, they are not usable by the VOXL because the Kernel doesn't support it. We'd like to have them usable for some more sensors we want to carry, having the MH radio carrier board makes it impossible to use any of the USB carriers options.

That said, having J18 for the flight controller solves the most immediate problem, which is getting that working with the MH carrier board at the same time. Could you give me some pointers to using this library in V1.0.1?

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

@josephmlullo said in pMDDL2350 w/VOXL2 Carrier Board:

In order to access the webserver for the radio you intend to install onboard the voxl2 you should first access the webserver when it's installed on the host pc carrier board and change the firewall settings to enable remote access. The ip address that's set as the static ip in LAN settings is the actual radio ip address. You enter that address in your browser to access the webserver, not the ip address you assigned when running voxl-configure-modem.

I recommend creating a free account on the microhard support website and downloading the product manual here:

https://support.microhardcorp.com/portal/en/kb/articles/pmddl2450-pmddl2350-pmddl2550-user-manual

It's got a pretty good walkthrough on setting up a master/slave radio configuration right up front.

Here's a pic of the general firewall settings as I have them configured. When I first tried to set up the radios I did so on the host pc carrier but when I deployed them to the voxl2 I couldn't access the webserver either. I realized the remote access is disabled by default, you have to check that middle box.

Hope this helps.file:///home/joe/Pictures/Screenshot%20from%202023-07-31%2009-37-33.png

Thanks Joe!

I can confirm that this is indeed the case. I can also confirm that if you have SSH turned ON for the radio, you cannot SSH to the VOXL, the radio will answer instead.

@Eric-Katzfey We are trying to expose the USB ports on the MH Carrier board, and I understand that this is solved in V1.0.1. Two questions:

1. Is this stable enough for us to use a pre-release for testing? If so, how can we get the SDK to flash?
2. If no to #1, but the code for the MH carrier is ready, is it possible for us to update the 1.0 SDK we are running? As I understand it, it would be a combination of kernel update and source code update for the carrier board.

Thanks

Jason

@Vinny Is this still the case?

I am using the MH pMDDL2350 radio with a VOXl2 and the V1.0.0 SDK. I would like to use the external ModalAI Flight Controller because of issues related to running a 6S configuration with the internal FC and ESC's. Without the MH radio in the architecture this works fine. However, once I try to connect the FC to the MH radio carrier USB port, I cannot get the communication to work. It seems the 2 USB ports on the MH Carrier board are not exposed to the VOXL2 as UARTS?

In general, without voiding our warranty, we'd like to use the MH Radio AND the external flight controller. Is there another UART we can use on the VOXL2 for this?

@Vinny @tom

Thanks. I am getting some other people from my team to post pictures of our power setup and how everything is connected so you can see. At first the reboots only happened when sending video over the link. I also had the radios set to 20dbm, but I have since changed that to 9dbm. At one point the VOXL2 was in a constant reboot loop. We moved it onto a much better power supply but we are still having an occasional reboot with the same loss of power problem. We also cannot get to the web server on the radio onboard voxl2. The IP for the USB0 responds only to the voxl and does not present the webserver as expected. I've been trying to understand why, and haven't really found a reason.