Solo with NEO-M8N Module and 8.3mm Active Patch Antenna Test

[SteveMyers75]

The title says it all.

I made up a cable to adapt the DF13 plug on a NEO-M8N Active/Passive Module to the Solo's Molex CLIK-Mate.

A quick un-mounted, un-shielded test and it picked up 13 SATs with PDOP of 1.8 in about 45 seconds from Waiting for Solo to Searching For GPS on a cold start with the module never seeing the sky here before.

I then turned Solo off, removed the battery, waited 15 minutes and tried again.
It locked in 13 SATs /1.8 PDOP within 5 seconds from the controller going from Waiting for Solo to Searching For GPS.

At the same exact spot with the stock setup it maxes out at 9 SATs with PDOP of 1.8 also.
...but it takes between 60 and 120+ seconds every time I startup Solo.


I'm designing up a 3D model then will print an adapter that will fit in the same spot as the stock module but allows for the much taller Passive and Active patch antennas I will be testing on this weekend's flight tests. There's plenty of room below the stock module for this.

.

There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I'm testing this anyways and if I lose my Solo, it was mine to lose.

I will be test flying it at a local 800+ acre Off-Road Motorcycle Park where everyone around has thick leathers and wears a Helmet. That's the safest place I can think of to test it.
(And Yes, I will have "A" Programmed to Manual Flight)

 

[Rich]

Best of luck with your tests, thanks for keeping us informed.

 

[David Weston]

You are one clever dude, Dude! Best of luck and right side up.

 

[Jubalr]

Nice Work Steve! Very impressive. Keep us up to date, but I think it will do well.

 

[rrmccabe]

LOL on all your disclaimers. Good job.

 

[Raybro]

.

The title says it all.

I made up a cable to adapt the DF13 plug on a NEO-M8N Active/Passive Module to the Solo's Molex CLIK-Mate.

A quick un-mounted, un-shielded test and it picked up 13 SATs with PDOP of 1.8 in about 45 seconds from Waiting for Solo to Searching For SATs on a cold start with the module never seeing the sky here before.

I then turned Solo off, removed the battery, waited 15 minutes and tried again.
It locked in 13 SATs /1.8 PDOP within 5 seconds from the controller going from Waiting for Solo to Searching For SATs.

At the same exact spot with the stock setup it maxes out at 9 SATs with PDOP of 1.8 also.
...but it takes between 60 and 120+ seconds every time I startup Solo.


I'm designing up a 3D model then will print an adapter that will fit in the same spot as the stock module but allows for the much taller Passive and Active patch antennas I will be testing on this weekend's flight tests. There's plenty of room below the stock module for this.

.

There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I'm testing this anyways and if I lose my Solo, it was mine to lose.

I will be test flying it at a local 800+ acre Off-Road Motorcycle Park where everyone around has thick leathers and wears a Helmet. That's the safest place I can think of to test it.
(And Yes, I will have "A" Programmed to Manual Flight)

Awesome! When can I order one....

 

[BVIsolo]

Can't wait to hear your results!

 

[Earldgrayjr]

I am betting this (and variants) will be more important than any of us know right now. The Solo features are is highly reliant on GPS. The GPS is an issue, and I am not sure it is solved by firmware.

 

[Dirby]

what will they cost?

 

[Retired2Fly]

Hello Steve,


While I certainly applaud anyone’s effort to make solo better, IMO, based on the information you provided so far your conclusions are flawed…


Both the NEO-M8N and the NEO-7 u-blox 7 GNSS module (the one currently shipping in solo) cache GPS/QZS/ and/or GLONASS last coordinate positional data in flash within the module so removing the battery for 15 minutes or 15 days is not going to provide any different results if you are testing in the same location each time. You will need to move to a new location at least 500m (data straight from the manufacturer) from the previous position lock to get valid “cold start” data. In addition, the Solo GPS module has an on board battery on the GPS module that utilizes a feature found in both the NEO-7 and NEO-8N that caches up to the last 50 GPS coordinate locations.


It is already well known within 3DR at this point that the issue with the current implementation of the NEO-7 u-blox 7 and GP.1575.25.4.A.02 Patch antenna in Solo is the cause of poor GPS positional data reception in less than ideal location situations and not the NEO-7 u-blox or antten themselves. . 3DR’s current implementation has the patch antenna mounted less than 2mm from the NEO-7 u-blox 7 which his directly underneath the on the 3DR solo GPS module. In terms of design that is needed to provide precision GPS navigation that is a big NO NO. While this type of implementation is frequently found in handheld consumer GPS equipment like those sold by Garmin, Magellan,TomTom etc, due to its very low cost to implement, it is not suitable for aircraft navigation such as MR’s when horizontal position data is possibly changing at a high rate and HDOP is relevant .The reason these type modules work well in consumer handheld car type GPS units is that being off a feet at any one time is not curtail to the overall operation .


IMO the “acquisition improvement” you are seeing right now is solely due to the fact you have your patch antenna separated from the NEO-M8N and you have both outside the solo with an unrestrictive view vs any improvements of the NEO-M8N over the NEO-7 u-blox . Once you mount both inside the solo you will see a definite degradation in signal acquisition as well as introducing additional interference problems.


The other issue with changing the GPS module in Solo with a unsupported 3DR module is that both the NEO-M8N and the NEO-7 u-blox support OEM initiated firmware flash upgrades so every time 3DR issues a Solo firmware upgrade you will either need to research the upgrade to verify that GPS module I not being upgraded or open up the solo and reinstall the NEO-7 u-blox every time so you can upgrade the firmware and then reinstall your NEO-M8N to ensure your NEO-M8N does not get bricked during the upgrade. That seems like a LOT of work to save a couple of minutes during power up. Plus there are many other reason other than the GPS acquis ion why you should not be so impatient trying to get in the air. For example IMU warm up.

 

[RichWest]

It is already well known within 3DR at this point that the issue with the current implementation of the NEO-7 u-blox 7 and GP.1575.25.4.A.02 Patch antenna in Solo is the cause of poor GPS positional data reception in less than ideal location situations and not the NEO-7 u-blox or antten themselves. . 3DR’s current implementation has the patch antenna mounted less than 2mm from the NEO-7 u-blox 7 which his directly underneath the on the 3DR solo GPS module. In terms of design that is needed to provide precision GPS navigation that is a big NO NO.

@SteveMyers75 it would make sense, based on the above, to simply relocate the antenna away from the current board. Simple for me to say, rather than perform.....

 

[SteveMyers75]

Hello Steve,


While I certainly applaud anyone’s effort to make solo better, IMO, based on the information you provided so far your conclusions are flawed…


Both the NEO-M8N and the NEO-7 u-blox 7 GNSS module (the one currently shipping in solo) cache GPS/QZS/ and/or GLONASS last coordinate positional data in flash within the module so removing the battery for 15 minutes or 15 days is not going to provide any different results if you are testing in the same location each time. ..../

I appreciate you taking the time to reply, but I was hoping the disclaimer where I said:

"There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)"
was going to save you from the typing.

The reason for not re-locating the Solo for the 15 Minute Test is obvious to me, but I'll answer that anyways.
I don't move 5 miles away every time I change batteries, and if I plan on using this for what they sold it as, it needs to be able to get back up ASAP from a battery swap.
With the current setup, it's minutes before I can get it back up, even if I don't move 5 feet.

I know quite a bit more about the inner workings of the Solo's Processors and hacking embedded Linux based systems than you might think, and have hacked much more complicated system than this simple little bugger.

IDAPro and a good working knowledge of encryption signature systems can do many wonders if you know how to use them. You can ask Samsung/Motorola (Verizon Wireless, Nextel, AT&T), DishNetwork, DirectTV, TiVo, Nintendo, Sony (PS1/PS2/PS3, but not the PS4 just yet...).

Many people said "It'll never work" "Your Doomed" "You're Wasting Your Time" when we went after those systems to make improvements too. Good thing we ignored them and tried anyways.
The Solo's going to need CFW and hacks like this for some of us.

I also know quite a bit about RC's,GPS Systems and other Navigational Systems, abet mostly from flying/driving Nitro's since 1978 and things that can actually carry people and their luggage...

 

[erikgraham]

I appreciate you taking the time to reply, but I was hoping the disclaimer where I said:

"There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)"
was going to save you from the typing.

The reason for not re-locating the Solo for the 15 Minute Test is obvious to me, but I'll answer that anyways.
I don't move 5 miles away every time I change batteries, and if I plan on using this for what they sold it as, it needs to be able to get back up ASAP from a battery swap.
With the current setup, it's minutes before I can get it back up, even if I don't move 5 feet.

I know quite a bit more about the inner workings of the Solo's Processors and hacking embedded Linux based systems than you might think, and have hacked much more complicated system than this simple little bugger.

IDAPro and a good working knowledge of encryption signature systems can do many wonders if you know how to use them. You can ask Verizon Wireless, Nextel, AT&T, DishNetwork, DirectTV, Nintendo, Sony (PS1/PS2/PS3, but not the PS4 just yet...).

Many people said "It'll never work" "Your Doomed" "You're Wasting Your Time" when we went after those systems to make improvements too. Good thing we ignored them and tried anyways.
The Solo's going to need CFW and hacks like this for some of us.

I also know quite a bit about RC's,GPS Systems and other Navigational Systems, abet mostly from flying/driving Ntro's since 1978 and things that can actually carry people and their luggage...

Yes, but have you considered the possibility that moving the antennas will result in a significant enough boost in performance, that it might be all you need to do?

 

[SteveMyers75]

I do understand, and I also have several NEO-7N's that have IPEX MHF antenna connection points I will be testing with.

The Module needs to be within 150mm of the patch, and cable routing is critical so this will be carefully considered.

I will be testing locations for the module offset mount as part of my research, and will print up several different models.

Info on some of the patches I have to test with:
http://www.taoglas.com/images/product_images/original_images/Internal GPS Active Patch Antenna(APN-13-8-002.B).pdf
http://www.abracon.com/Support/PatchAntenna-Application-Note.pdf
http://www.maxtena.com/uploads/6/6/6/5/6665461/mia-gps-25.pdf
http://www.u-blox.com/images/downloads/Product_Docs/GPS_Antennas_ApplicationNote(GPS-X-08014).pdf
(Page #24 outlines one of my projects for the NEO-M8N)

My selection of the NEO-M8N has to do with it being "Galileo Ready" and the module is capable of a few tweaks I have in mind to try.

This will not be a factor for most users, so if someone only cares about GPS/QZSS and GLONASS when 3DR upgrades to use it, the NEO-7N is fine.

 

[Retired2Fly]

Steve I agree with you 100%. Al l am saying is that IMO the initial improvement you are seeing in acquisition times have noting to do with switching the GPS module but the distancing of the patch from the GPS module. 3DR is already aware that is a problem. However given the number of solos already shipped I am not sure they will do anything design-wise about it in the near future since their current implementation, while a poor design , does technically work within the parameters they state for the product. (ie open field) wait for GPP lock HDOT of < 2.5 etc...)

Also despite the popular believe here 3DR did nothing firmware-wise in their 1.05 firmware upgrade release other than change a few arducopter GPS related parameters to correct the initial GPS issues. Why 3DR initially shipped the solo with a HDOP of 4.5 as acceptable for a preflight GPS parameter check is beyond me? I got five of the first production solos shipped to the US from China and having flown Adrucopter FCs for a number of years now the very first thing I did was comb through solo's 500+ parameter set and discovered that HDOT SNAFU. Using Tower I immediately changed it to 2 and never any issue related to GPS performance others here experienced in 1.0. Anyway I am on vacation down in the Caymans with very limited Internet access until the end of the month. When I get back will be more than happy to discuss solo's GPS mods and what works best. Until then good luck with your design mods and don't forget to RF shield that Click-Mate power/data line running from solo's MB to whatever you devise.

 

[SteveMyers75]

Retired2Fly,

Thanks for the feedback, and I do have shielding and a ferrite for the CLIK-Mate/DF13 cable, but pulled it back for the photos to show the ends and how the connections were made.

The cable is too long now, but until I know exactly where it's going to go I've found it's a lot easier to cut it shorter than to cut it longer...

I bought enough cable ends to make up at least 10 cables of various lengths.
Once I complete my module to patch location testing I plan on "As-Short-as-Possible" for both the power/transmission and the antenna cables.

I was one of the victims of the 1.0 FW and it's sudden GPS position corrections causing crashes with no user inputs as clearly shown on the MP tlogs.
They did make it better, but it still has a long way to go.

 

[Leafy]

I am going to do this.

The title says it all.

I made up a cable to adapt the DF13 plug on a NEO-M8N Active/Passive Module to the Solo's Molex CLIK-Mate.

A quick un-mounted, un-shielded test and it picked up 13 SATs with PDOP of 1.8 in about 45 seconds from Waiting for Solo to Searching For SATs on a cold start with the module never seeing the sky here before.

I then turned Solo off, removed the battery, waited 15 minutes and tried again.
It locked in 13 SATs /1.8 PDOP within 5 seconds from the controller going from Waiting for Solo to Searching For SATs.

At the same exact spot with the stock setup it maxes out at 9 SATs with PDOP of 1.8 also.
...but it takes between 60 and 120+ seconds every time I startup Solo.


I'm designing up a 3D model then will print an adapter that will fit in the same spot as the stock module but allows for the much taller Passive and Active patch antennas I will be testing on this weekend's flight tests. There's plenty of room below the stock module for this.

.

So to bottom line this because I haven't taken my solo apart yet. You just put the proper connector on your M8N and plugged it in. APM and Pixhawk both detect and configure the GPS on boot up, correct? I would think the solo would do the same. I just got a call from 3DR technical support and they told me if I am going to fly near "trees" then I should fly in manual mode without GPS by arming with the left stick down and to the right like an APM. I have enough experience that I prefer manual mode anyway, but others may be best to stay in an open field. That's BS in my opinion. They know the GPS isn't working properly.

There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I'm testing this anyways and if I lose my Solo, it was mine to lose.

I will be test flying it at a local 800+ acre Off-Road Motorcycle Park where everyone around has thick leathers and wears a Helmet. That's the safest place I can think of to test it.
(And Yes, I will have "A" Programmed to Manual Flight)

The title says it all.

I made up a cable to adapt the DF13 plug on a NEO-M8N Active/Passive Module to the Solo's Molex CLIK-Mate.

A quick un-mounted, un-shielded test and it picked up 13 SATs with PDOP of 1.8 in about 45 seconds from Waiting for Solo to Searching For SATs on a cold start with the module never seeing the sky here before.

I then turned Solo off, removed the battery, waited 15 minutes and tried again.
It locked in 13 SATs /1.8 PDOP within 5 seconds from the controller going from Waiting for Solo to Searching For SATs.

At the same exact spot with the stock setup it maxes out at 9 SATs with PDOP of 1.8 also.
...but it takes between 60 and 120+ seconds every time I startup Solo.


I'm designing up a 3D model then will print an adapter that will fit in the same spot as the stock module but allows for the much taller Passive and Active patch antennas I will be testing on this weekend's flight tests. There's plenty of room below the stock module for this.

.

There's no need to remind me that this will never work...that 3DR already tested the NEO-M8N and decided the NEO-7N is better...that they know way more about this than I do.
(They don't know what I can or cannot do...)

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

I'm testing this anyways and if I lose my Solo, it was mine to lose.

I will be test flying it at a local 800+ acre Off-Road Motorcycle Park where everyone around has thick leathers and wears a Helmet. That's the safest place I can think of to test it.
(And Yes, I will have "A" Programmed to Manual Flight)

 

[Ian [P13]]

There's a number of fundamentally incorrect statements (putting it kindly, effectively there's a number of complete lies) being delivered as "facts" here, which worries me, especially from Retired2fly.

Examples...

The original Solo firmware wasn't even performing the HDOP check so the claim the recent firmware was just a set of parameter changes for GPS is total BS, for one libraries/AP_NavEKF/AP_NavEKF.cpp was changed and the HDOP fail added to the IF statement.

    // record time of fail
    // assume  fail first time called
-    if (gpsVelFail || numSatsFail || hAccFail || yawFail || gpsDriftFail || gpsVertVelFail || gpsHorizVelFail || lastGpsVelFail_ms == 0) {
+    if (gpsVelFail || numSatsFail || hdopFail || hAccFail || yawFail || gpsDriftFail || gpsVertVelFail || gpsHorizVelFail || lastGpsVelFail_ms == 0) {
        lastGpsVelFail_ms = imuSampleTime_ms;
    }

There's even a note for the change "Tests in a urban conjon have showed the GPS receivers hAcc and sAcc cannot be relied on in an urban canyon environment and that a maximum HDoP criteria provides some additional protection at the cost of preventing flight in some cases."

Other libraries were also changed, including but not limited to, e.g: libraries/AP_NavEKF/AP_NavEKF.cpp and libraries/AP_NavEKF/AP_NavEKF.h

As well as the Arducopter code changed, there was a change to the interaction with the GPS and configuration was saved to non-volatile memory in UBlox GPS.

Here's a preview of the number of GPS code changes made to AP_NavEKF.cpp alone...

 

[Retired2Fly]

Sorry Ian [P13] but you are clearly wrong here. The HDOP parameter on the original 1.0 solo release was set at 4.5. ANYONE with a virgin Solo can easily confirm this.To say HDOP was not even checked in the initial solo release is crazy and shows a complete lack of understanding of Arducopter code and quite frankly is an insult to the entire solo development team not to mention slanderous since it opens 3DR up to potential lawsuits. Even if 3DR wanted there is there is NO way to circumvent the GNU Arucopter code in the Pixhawk II NOT to check HDOP. 95% of the Pixhawk II code did NOT change from the original Pixhawk. Yes there is and always will be non solo-specific code changes to the Pixhawk II in EVERY solo firmware rerelease as that currently is ONLY way to upgrade the Pixhawk II code in solo. Just because 3DR make changes to Pixhawk does not mean they have anything to do with solo I ere-iterate, the only changes 3DR made relative to solo concerning the GPS were parameter based. Other similar changes to the code were related to the GPS signal being too weak or looses lock to is to switch to manual and to check for that scenario more frequently. Those changes were in the Linux code NOT the Pixhawk II!. As for the rest, when I get back from vacation I will be glad to sit down with Chris and discuss your bogus statements in a conference call.. Bottom line don't post what you don't understand.

 

[Ian [P13]]

And I've provided the evidence that changing that parameter was irrelevant anyway (which you claimed wasn't the case) as the check wasn't even in the EKF code, Solo has the EKF on which uses different logic to 3.2 Arducopter which defaults to EKF off.

You categorically stated 3DR ONLY delivered parameter changes for GPS that is out and out BS.

That is Solo specific Arducopter detailed, you clearly don't even seem to understand Solo runs on its own branch of Arducopter.

Given I don't work for 3DR speak to whoever you like.