@tom Thanks for your thoughts Tom, it was new to us as well! We seem to have managed to fix the problem but we're not entirely sure how / why. Our best guess is that was a software glitch with the Microhard radios themselves.

I'm documenting what we found here in case anyone else runs into a similar issue in the future.

We were able to eventually duplicate the same problem on another UAV that had previously been perfectly stable, thus eliminating the VOXL as a potential cause with two separate units showing the issue.

We were testing a variety of settings today (e.g. channel, bandwidth, power of transmitter, which module is master vs slave) just to try and identify if anything made a difference. Eventually after re-setting the settings back to the microhard defaults (which we had done several times already), the problem mysteriously stopped. We've since kept a stable link open on two UAVs for the last ~6 hours without issue, so we suspect that there was some software issue that eventually cleared when we modified the settings. The last change we made was testing which module was master/slave, and after swapping them and then swapping them back the issue went away.

Really puzzling issue, we're just glad it seems to be fixed. As I said, we suspect it was an issue with the radio and not with VOXL. Why it would be perfectly stable with one drone for hours and then have an issue with a different identical drone is beyond me.

You guys do great work, keep it up!

I did more digging and it seems that the problem is related to the v1.14+ firmware I upgraded it to (from the Flight Core v2 downloads). For some reason in recent firmware updates it breaks the SBUS input.

I verified this by also upgrading a working VOXL Flight and was able to reproduce the same problem with the upgraded firmware in 1.14 and 1.15.

Any idea why this would break on the latest firmware releases?

Hello,

I'm trying to connect an SBUS receiver to a particular Flight Core v2 and it's not detecting it. The same cabling and receiver works just fine on a VOXL Flight, but this particular Flight Core v2 board won't detect it.

We haven't used SBUS with this particular board before (previously was using MAVLINK for control). We've tried the usual things like firmware updates, resetting all parameters, etc, but it won't seem to register the SBUS connection.

Is there something different with the v2 like requiring the signal to be inverted, or could there something wrong with this particular unit?

Appreciate any ideas anymore might have like a parameter that could be wrong!

Thanks!
Ansel

Anyone have any ideas here? We need to get Wifi working on this unit and are at a loss what to try when this is the only unit out of an identical batch of 7-8 that we set up with the same procedure and identical FW.

Hello,

One of our brand new VOXL Flights is having a wifi problem where it doesn't seem to be accessing the onboard wifi chip and is behaving differently than all the other identical units we've set up.

Steps
-Install system image
-Install voxl-suite
-Set up WiFi in access point mode
-Claims setup was successful, but no Wifi network is created

We then noticed there was no wifi network created so we checked and unlike every other system we've set up, this one doesn't have the second connection box for the Wifi network.


Any thoughts on how to fix this? From what we can tell VOXL doesn't seem to be communicating with the wifi chip to create the network. We've done this setup many, many times with the same procedure and firmware without issue, we're not sure what's going on.

Hey @modaltb,

Wanted to follow up again on this thread as we managed to make some progress.

We've continued troubleshooting and can conclusively say that the firmware linked to on the https://docs.modalai.com/flight-core-v2-firmware/#v1132-px4-support page does not work when flashed on our units. We finally tried downgrading to an older version of the firmware in desperation and it worked just fine. On the linked FW version the attitude estimator doesn't start up correctly which renders the controller unusable for flight. Not sure why it worked for you when you installed that version of the firmware but we were able to replicate the behavior on two separate units in our possession. Is it possible it went unnoticed that the attitude estimator was broken when you tested it on your end?

Wanted to share that insight with you and ask if there's any progress or an ETA on getting the QGC auto connection on windows fixed?

Thanks!

Will try the Pyserial on Windows on our end to see if that fixes our firmware issue, which I suspect it might given everything works fine on your end. It's a super busy week for us so will try to verify that by EOW if possible! Let me know what you figure out on the auto-connect issue!

@modaltb Awesome, glad you were able to replicate it! We'll keep working on the firmware on our end to see if something weird was happening with our firmware flashing.

Again, appreciate the help!

So we can confirm that the Windows USB driver is the main issue with the connection, it connected right away on QGC Mac. Looks like something's being buggy there.

We had a friend try installing the firmware via Mac instead of Linux just to test if something in our setup could be messing with the firmware, but couldn't get the bootloader to actually write the firmware and gave up after an hour of troubleshooting (that's the third engineer who's tried working on the problem from our end). We'll keep working at it on our side but we're running out of new computers to test things on.

Any thoughts on why our firmware seems to not be working correctly (e.g. attitude estimator not running on bootup)? Could there be a glitch we're running into on our machine during the firmware installation that would mess with that?

Will be good to see if you run into the same connection problem on Windows too.

Great, thanks!

We'll also try repeating everything on Mac instead of Linux to see if we can further troubleshoot on our end in case something weird is happening with our Linux build.

Hi @modaltb ,

Really appreciate your help on this! I figured the connectors were a red herring. And understand about the MAG, I get that not everyone wants to use it as they can be prone to interference when not separated. Thanks for the re-enabling script instructions!

It looks like the connection is a Windows issue as that's how we do out setup (because that's how most of our clients access the drone in the field). It shows up normally as a COM port but for some reason QGC doesn't seem to be recognizing the FCv2 where it doesn't have issues with FCv1, VOXL Flight, or VOXL 2.

The status looks identical once the manual connection is established:

Airframe is also looking the same but without the dev of course:

I also took a screenshot of the console in case that helps. This is where a link has NOT been established, so QGC clearly sees the device on the COM port but doesn't connect to it. The streamer error is because it's looking for streaming video (eg. a VOXL Flight setup) and none exists:

Could you try a Windows connection on your end and see if you get similar results with v1.13.2? We're getting the same thing on two different Windows computers we've tried on our end.

Still not sure why our firmware flashing seems to produce some buggy startup issues on the unit, we'll keep testing the firmware side tomorrow to make sure we didn't miss anything.