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

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.

Hi @modaltb,

Making some progress here, that explains the MAG question, thanks for the clarification on that!

I've been doing some troubleshooting with the various v2 boards we have and this is what I've found:
-We're definitely using the J3 port for USB
-We bought three new v2 boards, none of them connect natively to QGC (v4.2.4, tested on multiple computers)
-In order to connect it needs a manual COMM link for any of these three boards to be recognized, and must be set to a BAUD rate of 115200
-We upgraded FW on two of the boards and have one left in its default shipped state

The board in the default state is mostly working aside from the QGC connection issue.

• The one board we have not updated the FW still has the Attitude Estimator working when it connects via the manual COMM link in QGC. This might be an earlier FW version because the compass is working without an external MAG plugged in so it seems the onboard MAG is enabled on this particular board (FW v1.13.1dev, custom FW v0.0.9). The J12 port is a beige instead of yellow on the other two boards, I don't think that would make a difference but wanted to mention it in case.

• The two boards we updated the FW as per px_loader.py seem to have issues around the attitude estimator no longer booting up once the new FW is installed (v1.13.2 custom FW ver 0.1.1)

Any thoughts on what could be causing this? Could there be an issue with the more recent FW file? The difference in FW versions seems to be the only difference we can see, aside from the fact that QGC still won't recognize any of the boards without a manual COMM link that you don't seem to be having the same problem with.

As always, any thoughts or troubleshooting help is greatly appreciated!

Hi @Chad-Sweet,

We followed all instructions on the 'general user guide' as listed to install v1.13.2-0.1.1 and that's where we're running into issues.

Are there further steps we have to take to get it working right (e.g. using an STLink)? Our reading of that page was that we didn't need to go through the steps in the developer guide below as we're not doing anything custom with these.

Any further guidance would be appreciated, we did this on two separate boards with the same result.