ModalAI Forum

Hi @austin-c yeah, and it will not. There are dozens of changes between the two boards. It's just easier and cheaper to order the correct version. We have no documents showing how to convert it is simply not doable for the cost and risk and time. Not the news you wanted, but please trust me on that one.

@Vinny Got it. Thanks!

@jmltt Each microhard modem hosts a web server that can be accessed via it's IP address. You can see what data is available and can likely script a query for signal strength. (They may have an API but it's not something we've investigated)

@Alex-Kushleyev Thank you very much!

@Gus-Meyer It looks to be some kind of configuration issue rather than a hardware issue. If I turn on the board while pressing the S2 switch, the USB connection is recognized. But I'm assuming this puts it in some particular mode where the device isn't used normally, because I do not receive an IP on the ethernet device under this circumstance.

@Jetson-Nano Here's some example code: https://gitlab.com/voxl-public/voxl-sdk/services/voxl-vision-hub/-/blob/master/src/autopilot_monitor.c?ref_type=heads#L514

@v_v_ramarao I don't think we can answer this, it would likely be worth reaching out to the Microhard support team

@Vinny Yep, that's what I figured. Thanks for the info!

Hi @Serhii I'm surprised anyone knows about that design. In any case, it is not in active production, and to the best of my knowledge, not supported nor do we have any plans to support it. M0048 is our primary focus for MH radios.

@swickliff please submit a request at https://modalai.com/rma .

@Nick-Stroumtsos Moderator said in Power supply brownout w/ the Microhard Carrier USB Dongle @Nick-Stroumtsos Our carrier board design is a few years old, there's a good chance it won't meet this newer spec. That is correct, it is not going to be supported on this design. We designed for the 30dBm max power modes from several years ago as shown here: [image: 1708033819478-f1f632e6-b6ae-4764-9042-22ea4426fe05-image.png] We have a power consumption table in our tech docs that helps a user determine the limits for various modes: https://docs.modalai.com/microhard-add-on-datasheet/#power-consumption but nothing above 30dBm. We'd need new hardware for that. Sorry, but at least hopefully that explains the behaviors you are seeing.

@Vinny , Thanks for the speedy response and for the recommendations. I will discuss the options with my team. That dongle sounds like a good alternative for this use case. Jacob

@Jeremy-Frederick Can you try to lower the bitrate or resolution to see if it's a bandwidth issue? I understand that, in theory, the rendering software (VLC or QGC) shouldn't matter for your issue. But, it typically helps to see if there is a config that will work reliably and then push it from there.

@Jeremy-Frederick I would look at this being a radio thing. I would try get some distance between the radios. if they are too close together there might be too much noise in the system monitor the radio health when you see the cut out (should be able to see that from the menu of microhard 192.168.168.2) see if this happens if you connect over straight ethernet (use this cable: https://www.amazon.com/USB-Ethernet-Adapter-Gigabit-Switch/dp/B09GRL3VCN/ref=sr_1_2_sspa?crid=1ZBIC6DOI8DB5&keywords=ethernet+to+usb+adapter&qid=1699997723&sprefix=ehternet+to+usb%2Caps%2C124&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&psc=1). If you dont see the issue, i would look closer into how the radios are configured antennas: make sure you have the right radio antennas suggested by microhard

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.

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