Topics created by Mastermind

Hi @Mastermind
All I know is that the specific error you pointed to has nothing to do with physical power capability.
The specific failure in Linux "Rejected Configuration due to insufficient available bus power" is strictly due to messaging between host OS and USB drivers, and USB devices downstream. We have seen it, and we had Microchip confirm with us that error is a SW element. I am 100% confident on this. USB Tree View will show you exactly which combination of devices is reporting what power so you can start to isolate the issue. In our experience, it has been Linux drivers working with OpenSource USB devices exposing bugs in various Linux USB drivers... they are not all the same or correct.

OS's do not measure VBUS. If VBUS has an issue, the Hub will handle it for our design, and power cycle the device if there is a fault. In most designs, maybe the power control device may flag the OS there was an overpower event, but that is not where the current reporting comes from.
Please feel free to measure VBUS, I suspect you will not see any perturbations on there indicating low power (even if it is a competitor's product, I have confidence that is not your issue, especially since our dongles do not source USB VBUS for power ... they have the external 5V supply which you provide). VBUS on our designs is only used as a "detect" function for enumeration.

It is possible the linux OS driver for USB enumeration was modified by that device if you installed any device drivers... but I am venturing out of my wheel house... if you can remove any drivers you installed for the SDR radio, and try again, that may help confirm that.
Then, try to add in the SDR radio after enumeration with the MH radio.
All the while, I would get USB Tree View and see what you can observe with the device reporting demands.
Another option I would explore is the configuration of the SDR radio. I wonder if it's possible it is reporting it as a permanently connected device (like an embedded USB device), set for bus powered, and hogging all the resources. Even after you remove it... if it is setup as a permanent connected device, the OS may not be releasing the resources for it. So, uninstalling any drivers may help there.
If you have USB Tree View, you can send the config values (attributes, revision, config, etc reported) to the vendor to ask them to explain the register settings, and if they are correct or not.

Hope I am being clear... I'm not the best writer, nor a SW person, but I am very familiar with USB, and we have had this exact issue before, and learned how to fix it.

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

@Mastermind That sounds like it would be possible, but obviously depends on the driver of the wlan adapter you choose. You would need to implement the bluetooth broadcast portion of Remote ID. The source code for voxl-remote-id is here and only currently supports the Wifi portion of Remote ID

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

@tom
When running our algorithm or doing voxl-streaming while connected to a microhard, the drone is experiencing a random reboot. This issue is difficult to see when connected via wifi (station mode). When the drone reboots, it is disconnected from qgc and reconnected to qgc about 1 minute later. I think they had the same problem, can you tell me how they solved it?

@Mastermind Okay, interesting. Let us know if you figure out the root cause. Thanks!

@Vinny Thanks! I will have to get one of these boards and then see how we might do the integration. This might require a company like ConnectTech 🙂

@Mastermind This is the source for voxl-wifi on VOXL2 if you want to take a look: https://gitlab.com/voxl-public/voxl-sdk/utilities/qrb5165-system-tweaks/-/blob/master/scripts/voxl-wifi