@Daniel-Ryu Great to hear! I appreciate your patience with this.

@Daniel-Ryu Great!

Thanks,
I missed that going through the documentation.
We would prefer to use the direct add on but what we already purchased is
https://www.airborneinnovations.com/ai/products/picoradio/

We also need to incorporate FIPS 140.2 validated radios.
Currently microhard does not have FIPS 140.2 Validated radios and Doodle labs in in process. Doodle labs is borderline for us on throughput for our application. So we need to see about integrating different radios which could require a adaptor cable.

@Chad-Sweet Yes, it usually is a good starting point. I do want to mention it took us 3 or 4 separate resets of all related radio settings before this particular glitch went away.

@Viswanathan-R Our Microhard add-on boards are purely Microhard -> ethernet adapters, that may be more of a question for Microhard themselves. The antennas that we ship with support multiple frequencies so if you have a specific frequency you are using you may get better performance with antennas that tailored to that specific frequency.

We do not have any experience at this point with Microhard's meshing algorithm. You could reach out to Microhard?

@tangotoo Awesome, thanks for the feedback.

Thank you for the help! Will update this post when we are finished testing.

Hi @Jan-Hartmann ,
If you review our MH carrier block diagram here: https://docs.modalai.com/microhard-add-on-datasheet/#block-diagram
You'll notice we unfortunately do not expose the other Microhard Ethernet port. I'm not optimistic there is even a way to get it with blue-wires. Sorry about that.

For S.BUS support, we offer a small standalone product noted here: https://docs.modalai.com/voxl2-io/
We think that is a great little gadget that expands your PWM and I/O options and is meant for Voxl2.

Let us know if you have any other questions!

Hi @Byron_Ch ,
Thanks for your patience.
Yes, you are correct, but I wanted to add a few notes.

we are happy to review any schematic you make. If you want that, let us know and we can reach out to you using the email you registered with on this forum. the VBUS on V2 can supply a total of 2A, but due to pin limits (1A per pin) if you think you'll need that full 2A sustained (it's ok for burst/in-rush), I would use the 5VDC_IN rail (output of the eFuse) instead of VBUS, but you'll still need to use VBUS as the "host detect" function. you can start from our Altium package to get a jump start on connectors, pinouts, and pcb outline with mounting holes and connector placement here: https://docs.modalai.com/voxl2-connectors/#add-on-board-to-board-design-package
And I would still keep the J5 mate even if you don't need any signals. You can pick up the GNDs and it will provide a solid mechanical function providing two points of contact. on your plug in board, be sure to do a 3D fit check. There are some high components on V2 and you need to pay attention to any high components on the back side (with the connector mates) of your design. V2 3D is here:
https://storage.googleapis.com/modalai_public/modal_drawings/M0054_VOXL2_PVT_SIP_REVA.step
Let us know if you have any other questions. We want to see your plug in board succeed the first time!

@Byron_Ch As long as it is the mini OEM module (snapshots shown below), it'll work. I know they had a few offerings when the 2x2 MIMO first came out that exceeded that, but any module using that format will work from a hardware perspective.

Screenshot_20230212-074745_Drive.jpg

@Aks I was told by Microhard Support that this usually indicates a hardware problem that requires repair or replacement, but they also suggested to try reapplying the system firmware.

Reapplying the firmware for the modem seems to have worked for my case.

Thanks @Chad-Sweet I'll give that a shot.

@Mastermind In our next release (SDK 1.0.1) we will have the ability to use a UART on the DSP (assuming px4 isn't running on VOXL2) from the applications processor specifically for the use case of running an external flight controller through it.

@Mastermind This is great info! Thanks for sharing!

@AP123 What was the resolution to this issue? My team is experiencing a similar problem. Were you able to access the microhard web portal through the VOXL 2?

@Brandon-Wightman Ah that's a really old SDK release at this point, I'd recommend to updating to the latest (SDk 0.9.5)

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.