So I read an interesting article about GPS antennas called "Adding a GPS Chipset To Your Next Design Is Easy".
A few points to bring up that I have concerns with dealing with my M8N antenna.
1. Active vs Passive Antennas. Two paragraphs within the article describes the difference between Active and Passive antennas. According to CSG Shop's specification for the NEO-M8N it comes with a low-noise regulator and RF filter built-in. So I'm assuming that it is a active antenna.
2. Antenna's requiring adequate plane. If I read that document correctly, these GPS modules may require a GPS plane as they are installed on a PCB that does NOT have 40mm of side to them.
Quote: "Generally, patch antennas in the 15- to 25-mm size range with a least a 40-mm (on a side) ground plane will give the best performance in portable equipment, but this may be too large for your application. This could force you to look at smaller antenna topologies such as linear chip antennas."
3. The next concern is to mitigate the noise interference from FC, ESCs, and PDB. Since my Y6B is set up with a clam shell cover and my M8N is attached under and close to the all the electronics, I may need to develop a shield "ring" connected to the shield can and then connect that ring to RF ground through an inductor at a single point.
Quote: It's common in VHF and UHF RF shielding to connect all points of the shield can to the PCB's ground plane. This can be a mistake at GPS frequencies, since the open-air wavelength of a GPS signal is so much shorter than UHF. Depending on the size of the shield can, if there is current flow across the can, the shield can will be able to resonate near GPS frequencies resulting in interference or de-tuning of the GPS RF.
By developing a shield "ring" connected the shield can and the inductor, the inductor will filter any EMI-induced current flow. The ring connected to the shield can will prevent any current flows or resonation issues.
I'm not an electrical engineer and need guidance from those out there who are. Did I interrupted this correctly? and if so I could use some help with developing the "ring".
I want to quickly comment on the second item. This is a bona fide case of clock drift on Pixhawk, it has nothing to do with GNSS receiver performance and it shouldn't manifest into real issues for Pixhawk.
While we're talking about RF shielding, may I casually suggest you (plural) to have a look at Zubax GNSS (yes, it works with ArduPlane 3.2.1, ArduCopter master and PX4 stack).
AkCopter, I have the same question.
Soldering the RF ground to the shield is required to provide a lower resistance path that EMI currents will follow. Not soldering is not shielding anything; As Craig says, then the EMI sources should be shielded not to pollute the GPS (instead of shielding the GPS itself).
So back to the question : where to solder the ground plane to the GPS rf ground? Anyone has pictures to show that clearly ?
I think it's best to contact CSG Shop and request if they have schematics for their boards. Once we have this, it should be easy to soldier the ground plane.
I am also posting this here per DG suggestion
Several threads here on DIYDrones and RCGroups have been opened to discuss about the explanation and what represent these INAVERR errors in performance monitoring in logs
This problem was reported end of January
Still no answers from 3DR/Dev guys, to tell us something about this INAVERR in logs
A ticket was opened in Github about that
I know that they are probably busy, but could be great if somebody could tell if this INAVERR error if indicating a problem or is not
I found a post from Randy who in last November was thinking INAVERR at 255 was not a "very good thing"
Thanks for the info. Your copter missed one GPS message and went 0.07seconds without a fresh GPS update (you can see the 400ms jump in the GPS time between lines 2593 and 2606). You were in Loiter mode but it was so short lived it didn't upset the navigation at all. If it was -rc6 you would have seen a very slight twitch. If that INAVErr was 255 meaning it had maxed out the recording of errors I'd be more concerned. For now, this is consistent with what I'm also seeing which is that we're getting occasional missed messages which we still need to get to the bottom of but in low numbers it's not dangerous.
I'm not upset, its good to see folks discussing all the issues with GPS signals and INAVERRs. I do however, wish to see more discussion on the EMI ring concept and GPS Plane designs for testing.
The Inav errors mean that inertial nav has not received a GPS update within 0.3 seconds. So that probably means that the GPS is running too slowly (i.e 3hz or less) or messages are being missed. I've never used one of these GPSs so I'm really not sure what exact technical issue is that's causing the missed messages.
It's hard to say how badly this will effect inertial nav's position and velocity estimates but it will have a negative effect I think.
In case anyone missed this:
He is saying this is definitely a case of clock drift.
Well, now that is an interesting discussion there. Maybe I wasn't imagining the twitching (momentary loss of control actually) after all.
It does, if you have a look at the log you will see that even though I am in an open ground with horizon visibility of about 15-20 degrees elevation from the ground...
sats are 18-21 and hdop 1.1-1.4
I will check the wiring to see if its a problem..
right now I have two GPS modules and I have found that I get bad GPS health messages when I use the Rctimer GPS, this may be because they have a different connector than the one I used with my CSGshop GPS, on my CSG GPS I have used DF13 connectors
I will do some more testing today and let you know if its a wiring problem..
In all likelihood it isn't coz' I have been very careful about the integrity of cable connections on my hawk
I think I am having two problems both of which do not seem to be affecting autonomous flight in any manner, the first is the common INAVerr which as suggested by Thorsten seems to be occurring because of clock drift, and the second is most probably interference from my RFD900 radio, which may be producing out of band emissions, these coupled with the wide front-end bandwidth of the M8N may be causing bad GPS health messages...but why is the reported hdop so low even after getting these messages is a bit confusing..this is why I am a bit more keen on shielding rather than improving the sensitivity of the gps by providing it with a ground plane..
also my RFD is 20 cms away from the secondary gps and 35 cms away from the primary
I am not sure if clock drift is the cause. Most probably it is missing samples. The question is where these missing samples come from (GPS, driver, clock drift, ...?).
Yes, the HDOP is very low. But remember AC is reporting the PDOP, but names it HDOP. HDOP is approx. PDOP*0.6.
Don't know if they will be helpful but I've just gone through my old logs and have some from AC 3.1.5 and AC 3.2 on an APM with the M8.
As well as AC 3.1.5 on an APM with a neo-6m.
Having used the log analyser tool, it shows more errors occurring as the AC release number increases, I'm assuming that's because there is more stringent error checking as the code improves.