detailed u-Blox and GPS driver logging in master

[Andrew Tridgell]

Hi All,

Prompted by an observation from Tom Coyle on GPS receiver performance
I've pushed some changes to master to allow the u-Blox driver to log
much more detailed hardware status information to dataflash logs. The
new logging information includes detailed numbers related to the
performance of the RF frontend of the u-Blox, as well as it's internal
noise level and jamming indicator.

You can see a couple of initial graphs of the values here:

http://uav.tridgell.net/GPSNoise/thumper_D4RII.png
http://uav.tridgell.net/GPSNoise/thumper_V8R7SP.png

this test was with my 'Thumper' rover, with two different RC
receivers. One was a FrSky V8R7SP, which is a non-telemetry
receiver. The other is with a FrSky D4RII which has telemetry enabled. I
was looking to see if the telemetry on the D4RII has an impact on the
internal state of the GPS.

I think the graphs make it very clear that telemetry does make a
difference, although without knowing more about exactly what these
numbers mean we can't analyse it more deeply. You can read a bit about
what these numbers mean here:

http://www.u-blox.com/images/downloads/Product_Docs/u-blox6_ReceiverDescriptionProtocolSpec_%28GPS.G6-SW-10018%29.pdf

we also log the noisePerMS, aPower and jamInd values from MON-HW. All
are logged at 0.5Hz.

I'm hoping that this additional logging data will allow us to refine the
GPS antenna placement recommendations, help design better GPS modules
and also look for the impact of the potential RF interference sources
such as the Pixhawk itself and various RC receivers and extra sensors.

Another aspect of these patches that I think will be of interest to
anyone else writing a new GPS driver (hi Niels!) or in fact any driver,
is that the changes add a new mechanism for driver specific dataflash
log messages. Each driver can now add its own dataflash message types
and log them without having to add it to a global list. In this case the
AP_GPS_UBLOX.cpp driver is adding a UBX1 and UBX2 message containing
u-Blox specific logging information, but this could equally well apply
to any new device driver by following the same recipe. Have a look at
the changes in this patch to see how it is done:

https://github.com/diydrones/ardupilot/commit/5630bb1ef608ffff758a51965e20c8108afcc4fa

The next step with this is to start gathering some logs to see how much
these numbers correlate with GPS performance, and how well they can be
used to pin down RF interference that may be impacting on GPS
performance. It would also be nice to talk to someone from u-Blox to see
if we can get a bit more information on what the numbers mean! The
description in the datasheet is quite sparse.

Cheers, Tridge

[Randy Mackay]

Tridge,

     Sounds great.  The jamming number is one item in particular I'm keep to see.

     Re GPSs we should probably discuss in tomorrow's dev call the occasional missed GPS messages we're seeing in some Pixhawk logs.

-Randy

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Plischka]

Hi Andrew,

attached a log file from the IRIS with  UBX1 and Ubx2 Messages.
The receiver is a FrSky X6R with telemetry.

regards Peter

[Peter Plischka]

Here is the IRIS log and a log of my Hexa. He also has the X6R Telemetry Receiver.

Peter 

[Robert Lefebvre]

I thought the GPS we are using already includes a SAW filter?

On 24 March 2014 03:42, Jesus Alvarez <wja...@gmail.com> wrote:

One of the things it is worth doing when installing a GPS on a plane/rover/copter is to install a GPS bandpass filter on the GPS antenna.

Maybe 3DR could think on adding a saw filter like this one.

http://www.digikey.es/product-search/en?pv327=87&FV=fff40034%2Cfff800f0%2C638001d%2C638001f%2C6380022%2C6540046&mnonly=0&newproducts=0&ColumnSort=0&page=1&stock=1&quantity=0&ptm=0&fid=0&pageSize=500

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Peter Plischka]

I turned off in about 2 minutes, the 3DR 433 MHz telemetry module.

In NoisePerMS and magl highly visible changes are seen.

regards Peter

[Peter Plischka]

At the IRIS the differences are (telemetry on / off) more clearly.
Here is the Compass closer to the GPS module.

regards Peter

[Matthew Lloyd]

I'd just like to chime in and say how excited I am about this addition! The u-Blox "jamming indicator" was what clued me off to the PZ0420 FPV camera emitting RF interference at 1.575GHz, which I wrote about on FPVlab: http://fpvlab.com/forums/showthread.php?27550-PZ0420-and-GPS-interference. Recording more detailed information about GPS signal quality would be a nice differentiating feature from ArduCopter's competitors.

Can we expose at least some of these numbers via Mavlink? That would allow easy real-time testing, switching various systems on and off to find out which are causing interference issues with the GPS (this was how I identified the PZ0420 as the culprit). The jamming indicator and noise level would be the two most useful to see on the mavlink status panel, I'd guess.

The other message I think is really useful is SVINFO, which contains the CN0 (carrier-to-noise) ratio and signal quality for each satellite. Jamming sometimes shows up as 'ghost' satellites with poor quality indicators in this message, and I find that the CN0s seems reliable as an indicator of the signal quality and noise level than the single noise level value recorded in the MON-HW message. Do we have enough SD card bandwidth to store this message too? It's quite a big message (8 bytes + 12 bytes for each channel), but if we strip out the timestamp, elev, azim and prRes, and the unused fields, we could get it down to 2 bytes + 4 bytes for each channel.

[Robert Lefebvre]

Matthew, thanks for this comment.  I just posted on that thread.  I've got a bunch of these cams...

I also have a heli with servos that interfere with the GPS.  It's a rather frustrating problem.

--

[Jesus Alvarez]

yes it has Robert.

I just had quick fingers and did not verify it!! What I do not know is the saw filter specs... 

[Andrew Tridgell]

Hi Matthew.

> I'd just like to chime in and say how excited I am about this
> addition!

glad you like it!

> Can we expose at least some of these numbers via Mavlink? That would allow
> easy real-time testing, switching various systems on and off to find out
> which are causing interference issues with the GPS (this was how I
> identified the PZ0420 as the culprit). The jamming indicator and noise
> level would be the two most useful to see on the mavlink status panel, I'd
> guess.

yes, I'd like to add them as a MAVLink message, but first I'd like to
work out exactly which numbers are the best to report. When we add a
MAVLink message we need to propogate the message changes to all ground
station implementations, so we really want to get it right first time if
possible. Because the dataflash log format is self-describing it is much
easier to create/change messages.

> The other message I think is really useful is SVINFO, which contains the
> CN0 (carrier-to-noise) ratio and signal quality for each satellite. Jamming
> sometimes shows up as 'ghost' satellites with poor quality indicators in
> this message, and I find that the CN0s seems reliable as an indicator of
> the signal quality and noise level than the single noise level value
> recorded in the MON-HW message. Do we have enough SD card bandwidth to
> store this message too? It's quite a big message (8 bytes + 12 bytes for
> each channel), but if we strip out the timestamp, elev, azim and prRes, and
> the unused fields, we could get it down to 2 bytes + 4 bytes for each
> channel.

The problem isn't SD card bandwidth, the problem is the internal
processing in the u-Blox, and the bandwidth on the UART between the
u-Blox and the autopilot.

We are already pushing the limits of the u-Blox LEA-6 running the 4 main
messages (NAV_POSLLH, NAV_STATUS, NAV_SOL and NAV_VELNED) at 5Hz. I've
just add MON_HW and MON_HW2 at 0.5Hz. If we add SVINFO then we'd need to
be very sure that the u-Blox will continue to give us our main
navigation msgs at 5Hz completely reliably. If we push it too hard we
may miss messages.

The SVINFO msg is also variable size, which makes it a difficult message
to handle with our current u-Blox parser without taking up more
memory. Perhaps we could make it available only on PX4 and above (which
is what I did for MON_HW and MON_HW2).

The other problem is giving a clear report to the user. If you have 12
satellites being tracked you will have 12 CNo numbers. Some will be
larger than others. We'd need to know how we can interpret the numbers
to give a useful metric for users.

The UBX1 and UBX2 messages I've added are a first attempt to see what
numbers may be useful.

Could you get a log with the current code and your PZ0420 camera that
causes interference, with the camera on and off, and maybe at a couple
of different distances? It would be nice to see if the UBX1 and UBX2
messages should the effect clearly with your setup.

Cheers, Tridge

[Matthew Lloyd]

Hey Andrew,

On Monday, March 24, 2014 4:41:04 PM UTC-4, Andrew Tridgell wrote:

We are already pushing the limits of the u-Blox LEA-6 running the 4 main 

messages (NAV_POSLLH, NAV_STATUS, NAV_SOL and NAV_VELNED) at 5Hz. I've
just add MON_HW and MON_HW2 at 0.5Hz. If we add SVINFO then we'd need to
be very sure that the u-Blox will continue to give us our main
navigation msgs at 5Hz completely reliably. If we push it too hard we
may miss messages.

I see, yes, that would obviously be a bad thing...

 

The other problem is giving a clear report to the user. If you have 12
satellites being tracked you will have 12 CNo numbers. Some will be
larger than others. We'd need to know how we can interpret the numbers
to give a useful metric for users.

I was thinking the SVINFO would be mostly for dataflash logging rather than mavlink export, and useful for post-crash debugging. There might be some metrics we could come up to derive from SVINFO that would be useful for mavlink, like the maximum or average values of CN0 or the quality indicator across the locked satellites.

 

Could you get a log with the current code and your PZ0420 camera that
causes interference, with the camera on and off, and maybe at a couple
of different distances? It would be nice to see if the UBX1 and UBX2
messages should the effect clearly with your setup.

Certainly! I recorded a .bin log with my PX4, and in a separate session I made a direct u-Blox recording. For both, SVINFO was turned on at ~1Hz. I wanted to record them together so I added a raw recording facility to AP_GPS_UBLOX, but I haven't been able to get it working reliably yet (SD card corruption...) So for now we'll have to make do with these two separate recordings.

This recording was made indoors, so the GPS signal was not great.

For the .bin file, the timeline is roughly:

0 - 42s: PZ0420 off (full lock)

42 - 52s: PZ0420 on, right next to antenna (no lock)

52s - end: PZ0420 on, 8" from antenna (full lock, but with fewer satellites than before)

For the .ubx file:

0 - 30s: PZ0420 off

30s - 1:02: PZ0420 on, right next to antenna (notice jamming indicator at ~50%)

1:02 - 1:55: PZ0420 on, 8" from antenna (jamming indicator at ~16%)

1:55 - end: PZ0420 off again (jamming indicator falls to ~3%)

Hope you find this useful!

Cheers,

Matthew

 

Cheers, Tridge

[Peter Plischka]

A few cm larger distance to the GPS changes the graph clearly.
In the first plot the X6R receiver antenna is 20 cm away from the GPS.
In the second plot the receiver is 34 cm away from the GPS.

regards Peter

[Robert Lefebvre]

34cm?  That's actually a fair distance.  How did you achieve that?  Even 20 can be hard to do.  Is this on a multicopter?

--

[Peter Plischka]

Hi Robert,

it is a Hexacopter. GPS is constructed approximately 12 cm from the center to the front.

The X6R receiver is on the right rear boom. The antenna is under the engine.

regards Peter

[Robert Lefebvre]

I see, good design.  Not many people doing that.  I actually had worked to put the Rx *directly* on the APM, but learned the hard way (and John Arne pointed it out) that the best place for the Rx isn't always the center plate with the FC.

--

[Peter Plischka]

I also prefer all components centrally under a dome.

But after I saw how strong the interference from the receiver and the 3DR telemetry module are, I've put them on the boom near the Motors.

The 433 MHz Telemetry module is 30 cm from the GPS and still disturbs.

Peter

[Roberto Navoni]

In your test could be good also understand what's happen when you use
gopro camera on drone ....
With wifi power on and power off and gopro in record mode ... so the
bus generate RF interference.
Best
Roberto

[Peter Plischka]

Hi Roberto.

we need bigger Copter so we place the components further apart :) or better protection against interference.

Peter

[Niels Joubert]

Hi guys!

This is super useful. For the Swift-Nav Piksi, I'd want to log a
similar message to the SVINFO uBlox message - We log the CN0 value of
every satellite, and that's the number I've primarily used for my
analysis. It'd be nice to log this!


I'm attaching the graphs of CN0 - that is, the unitless signal
strength ratios of each satellite. Here, it's a 3-condition test with
our Piksi GPS, the Pixhawk, and an external antenna:
Condition 1: External antenna 5 feet away
Condition 2: External antenna next to pixhawk, D4R-ii off
Condition 3: External antenna next to pixhawk, D4R-ii on

as you can see the SNR values drop significantly once the antenna is
next to the pixhawk, and then the SNR has much higher variance once
the DR4-ii is turned on (i'm guessing this is an artifact of their
spread-spectrum frequency hopping)

-Niels

[Clancey Aggen]

Hello All. happy 2016, I am new to Piski, And are doing some final Steps before testing the Piski system on an 800cm Hexa multi copter, I have the Piski connected to the Pixhalk flight controller, I'm to the point of configuring the Pixhalk for Piski, I was sent here by a Link from swiftnav in regards to something about interference from some sort of radio...  I have been reading and just don't quite understand what it is I need to do, I have the 3DR robotics U-blocks GPS as well as the PIski GPS and antenna mounted About 6"s above the craft on a plane of material that is shielded with copter foil tape 2 layers, I have a 3D printed case holding the Piski GPS and 3DR 433mhz telemetry radio together, do I need to separate these to devices?, I know you all are talking about it, I'm having a bit of a hard time understanding what you all are saying based off of the tests you all have done. I'm flowing this http://docs.swiftnav.com/wiki/Integrating_Piksi_with_the_Pixhawk_platform#Vehicle

Hope this you helps you help Clancey Aggen.

[Niels Joubert]

Hi Clancey!

Sounds like you're about ready to go there. We found that the Pixhawk interferes with the GPSes, and to a lesser degree, the 3DR telemetry radios does as well. Thus, I'd suggest you move the telemetry radio away from your GPS antennas.

As a tip: for my setup, I inject GPS observation packets over the normal MAVLink telemetry radio. This works well for me, but I don't fly the normal 3DR telemetry radios anymore - I've fully switched to the new 3DR Solo and send GPS observations over Sololink. I bet you can do this as well, but you'd probably have better luck upgrading to something like the RFD900 radios. (http://store.rfdesign.com.au/rfd-900p-modem/)

Cheers!

-Niels

[Clancey Aggen]

Okay great thanks for the reply Niels Joubert. I understand what you are saying, I only bought these radios because that is what was suggested,  I was gonna say why not just change to frequency of the telemetry radios, Sorry I posted that my radios were 433mhz, there actually 915mhz what would be best frequency to use that wont case issues?, could i still use my radios and possibly add in some sort of filter? I think my GPS's are well shielded and my radios are as far apart as posable, I Also Had a simple question in regards to a setting for Pixhalk shown bellow, Does this need to be set to 0 or 1, if I intend to use piskis for use with pixhalk flight controller for better GPS position hold. and can I use Piskis for more then one task at a time, I Would like to integrate a camera and gimbal here soon once I dial in the flying PIDS gains for the copter, i wanna be able to understand geotag and basically make mini hi res maps and collect data for like land surveying.

Thanks this has helped me more, I will make some changes to my setup glad I asked, thanks for helping me and others Clancey Aggen 

GPS_AUTO_SWITCH**

0

Switch to GPS reporting best fix for vehicle control.**

[Clancey Aggen]

Should I be worried about how long I make the extension cable for the telemetry radios I just added so i have a total of 20 inches. Also would adding a ferrite ring help any? by putting one on the 3DR radio?

Thanks Clancey Aggen

[Clancey Aggen]

The Weather looks good today I am going to get test fly my rig with Piskis, I also have a concern in regards to the ground ground Piski GPS system and the 915MHZ telemetry, radio should I extend the wire  between the piski and the Radio? the wire is currently 9" long.

Thanks Hope this helps you Help Clancey Aggen

[Clancey Aggen]

Success on my first test flight with Piski Really happy so far, I had a fixed position with 9 Sats showing in Piski console, The position hold was really good, Are needing to tune my barometer for better ALT hold, but other then that test my test was successful.

[Igor Vereninov]

Hi Tridge,

Very needed addition indeed! 

We have a vast experience with all sorts of GPS systems and receivers and here is my opinion on signal quality reporting to user. 

1. HDOP, which is used now is very loosely correlated with reception quality and presence of interference, you can have a good HDOP, but poor signal strength. That results in glitches for users, because looking at low HDOP they are sure that setup is perfect, while actually there is plenty of interference. Modern chips are too good at using weak signals. Overall, I would say that there is no need to show DOP numbers to user at all. If there is enough info about SNRs and satellites in view that indicates that chosen place for the GPS is good and there is no interference around. After that there is nothing you can do to improve DOP and considering how many GPS and Glonass sats we have in view now bad DOP situation is very unlikely. 

2. For any receiver manufacturer or antenna maker the ultimate metric is CN0, in any user interface of an RTK system first thing that you see are bars with SNRs. For UAVs GPS is critical and we should adopt best practices from those who excel in GNSS.  Here is how it is done in A2 http://www.dji.com/newsroom/news/introducing-the-new-a2-gps-pro-plus-module

My suggestion is to provide an average of SNRs of 5-10 best satellites. That will help solve many issues with poor GPS placement. By this number with addition of number of sats in view you can easily tell everything about particular GPS installation. In Mission Planner we can show something like: sats:18 SNR: 45. 

Another great thing about this solution is consistency. Every GPS receiver will report SNR, be it u-blox, MTK, Topcon, Piksi or Reach. I understand that SVINFO is a big message, but if we decide to use jamid or other u-blox specific numbers we will never reach consistency when using different receivers. 

Best regards,

Igor Vereninov

[Igor Vereninov]

Hi Tridge,

Sorry, I did not notice how old this thread was. Shame on me :( 

I really would love to see SNR reporting in APM.