Fixing reliability of RTK Fix

For the last few seasons, I’ve gotten by well enough on an M8T in dgps mode with V4.X So this year I finally managed to figure out how to set up a RTK base station and RTK capable GPS module in the tractor, and was able to get the RTCM data, all seemed good. BNO085 IMU upgrade, then got steering mostly dialed in (that was painful and frustrating). It felt glorious to have it pretty much dead straight instead of my usually 1m wander around and using overlap to cover properly.

Did the first field, and about halfway through, the AB lines started jumping back and forth as it went from float to fix. Eventually I had to set it to disable steering if it lost fix because it would violently jump over 2-10 meters.

I’ve had my base station running for weeks and it seems dialed in for position, and has been faithfully updating rtk2go @ 1Hz as far as I can tell. The tablet has a SIM card and seems to keep good connection, though I haven’t ran a long term test for latency and ping, maybe I should.

I’m using PX1122R at both ends, and have an extra module on the tractor but am not using it currently since I’m not quite sure how AOG official version is supposed to handle dual GPS.

Is this a GPS module problem, or an NTRIP connectivity problem, and why such wild jumps when going off into Float? How can I fix this, because at this point I’d be better off going back to M8T and V4 to actually get spraying done without losing my mind. Am I just SOL using this Navspark module and should try to get a F9P ASAP?

Yes

Just like the Deere 9600 was the start of good combines, the F9P is the start of good GPS. The hassle level is very low with F9P, it fixes very fast and stays fixed under some quite impressive conditions.

1 Like

It sounds like you loose some of the necessary satellites to get correct fix.

I use px1122 as base but f9p as rover, and have stable fix.

I use 3 constellations to get as many satellites in view as possible.
Of course set same constellations at both ends.

Bad example, but if you set beidou at base and GPS at rover, then you have no satellites to calculate fix, even if you have 10 visible sats at both ends.

I think minimum sats are 8 to calculate fix.

EX if you have antenna at hood (low), then the tractor cabin will shadow some of the sats at that side and maybe you then get under 8 visible sats? (must be same 8 sats, that are visible at base at the same time)

Even when it’s on Float, I’m seeing 23-27 sats. Antenna is on top, there’s maybe a worklight in the way but like I say, # of sats isn’t a problem.

I think I have all the same constellations but I"ll check that, good idea.

I’ve added all constellations in GNSS viewer, and my caster entry is:

STR;BarK3;Mayerthorpe;RTCM 3.2;1005(1),1033(10),1074(1),1084(1),1094(1),1124(1),1230(10);;GPS+GLO+GAL+BDS;SNIP;CAN;53.91;-115.24;1;0;sNTRIP;none;N;N;3780;

I don’t see a place that you configure the rover’s constellations in GNSS Viewer, it just seems to take all of them in normally. I’ve tried just specifying the NTRIP caster in GNSS viewer itself, taking AOG out of the picture and it still jumps in and out of fix. I’ve used both my pushed out stream to rtk2go and a direct connction via vpn to my SNIP caster, no difference.

What antennas are you using? I haven’t had any opportunity to do real testing yet, but my gut feeling was when I switched from a u-blox magnetic antenna to a nice survey antenna (the BT-300S in my case), it seems to work better. I can get a fairly stable RTK fix even with the antenna sitting on the dash of my truck, whereas with the u-blox antenna even on a metal plate I never could. This is just a PX1122 that I use for doing hand surveying so I stick it on the dash when I’m driving out to where I want to do some surveying. I have yet to test it in a tractor though.

I can’t check right now, but as far as I remember, also px1122 have a speed limit if all constellations are used, so somewhere is must be possible to choose constellations.

Well, I tried a field after making those changes, got about 25% through in full RTK fix, then it started flapping to Float and became unusable, had to drive the rest of the field by eye.

I’m really not sure what to try next. Wish I had a F9P to test with to see if this is a module issue or a configuration issue.

Strange. But is the rtk2go map showing your base fairly close to the place where it actually is?
Within 10 m

Well, strange. It shows it about 400m away. I set up the base station as per the navspark instructions, in survey mode, and it’s been running for a few weeks, so I’d have figured it would be zeroed right in. I didn’t even know there was a map you could check.

When it gets an RTK fix, the tractor works perfectly, within a few cm. Not even sure how that would work if the base is locating itself 400m out of place.

Edit: Tried in static mode, no better, still shows it in wrong position.

I once moved my F9P base station about 400 metres to a new location and I assumed it would just survey-in on boot, but the Sparkfun version had a battery backup that kept the last base station position stored. RTK would still be achieved by my roving units but it sometimes took a longer time. And everything was 400 metres off of where they were before, because everything is computed relative to the base station position! So yes things can still work sometimes even if the base station location is a long way off from the survey location.

My base station is within 3 metres of the “real” position on google maps or another survey, but the PX1172rh and 1122 were still having problem holding RTK for me. So I suspect the skytraq units just aren’t as robust as the F9P and their algorithm gives up sooner. Like I said before a survey antenna seemed to make the skytraq work better than the ublox magnetic antenna.

My px1122 base is also within 3 meters.
I discovered the distance problem when I set the coordinates in static mode in gnss viewer.
It was 300 m off, and I could only get float at my f9p. Reason was because I accidentally used the wrong type of coordinates in the setup. And also I first used the , comma to separate the numbers. It must be with a . Dot (European style versus US style)

I’m using the Multi Frequency High Precision Antenna - NavSpark Store multiband antenna.

As for why it’s 400m away, I’ve never done any setup on the base module when it wasn’t within a couple meters of where it sits now, so I have no idea how it got 400m away stuck in it’s memory, though it does have a soldered on backup battery. I can try factory resetting it, but I’m not hopeful since I’m fairly sure it’s been factory reset in its current position a half dozen times already.

I set static position via Google maps waypoint and used decimal version when I tried that. Doesn’t seem to want to change.

I think I’m just going to bite the bullet and order a couple of Ardusimple 2Bs. I already had to contend with an issue on these 1122s where Windows decides that they’re a serial mouse when you plug them in, and the cursor jumps around until you manage to disable the fake mouse in Device Manager (and then it comes back again as a different serial mouse type a couple more times until you disable those vendor IDs as well, crazy). They seem very low quality. Of course, it could be Windows being weird as well, but as much as I dislike Windows, I’ve never seen it do that with any USB modules I’ve connected before.

Edit: well, apparently it’s a known issue with Windows and USB GPS modules for a long time now: https://answers.microsoft.com/en-us/windows/forum/all/windows-detects-usb-gps-as-serial-ballpoint-please/e0e03b9b-e9ae-4645-8b3c-5754f06ec3b5

Is it advisable to get anything else if I"m upgrading, to stay right current with the development point? I’ve seen reference to $PANDA that I’ve gathered is an IMU fusion device based on a Teensy 4.1 and the BNO085/ardusimple combo. I see I can get Teensy4.0 but not 4.1 easily via Digikey, not sure if that would make a difference.

That looks very similar to the u-blox magnetic mount antenna. I assume you’ve attached it to a metal back plate that’s at least 10cm in diameter? These type of antennas need a metal surface under them.

Here’s the antenna that seems to work the best for me, and I will do more testing with and report back when I can:

Can also get it on AliExpress and probably other sources.

This is also the antenna I plan to use on my base station when I get it permanently mounted. Currently I’m just using the u-blox antenna (with an F9P) on my base station.

Another option is the Survey Grade antenna from NavSpark.

I can’t help but think these perform better, and you don’t need any kind of metal back plane.

1 Like

I am using the BT300 for base too it is a great antenna for very low cost, same as @torriem.

On tractor I like helical antennas, they shed dust well, and are better at grabbing low hanging satellites in holes, behind hills and near trees. The tallysman hc 871 packaged with emlid m2’s are great, but spendy at $300cdn. I will be trying out a hx 607 version soon.

“Mark” at “JINYUSHI” store has been great support, they ship fast, and package well.

1 Like

Just be aware there are subtle differences between the 300D and the 300S. They are nearly the same in specs, except that the 300D lacks in GPS L5, which isn’t so important now but may become important in the future. Other than that it works great.

That helix antenna looks very interesting. I’ll have to try some. Do they need a metal base plane?

1 Like

No base plane needed with a helical, they are meant for drones. The Tallysman 871 is bout the size of my thumb, they are not very big.

On the mower the helical massively outperforms the flat antennas in tight tree cover on two sides, and near buildings. On the Steiger in the field it is much more reliable along the bush line with both the previous ez150 conversion project and now AOG.

On emlid forum they tested the helical, patch and m2, the biggest difference was helical scored poorer on multi path rejection.

The big flat antennas are more accurate overall, in perfectly flat open conditions, but they only see up, tilting them cuts off a portion of the sky.

2 Likes

So this is what I’m seeing for sats and signal on the base station with the antenna I linked. Is this amount of sats and signal not good? It’s usually 20+ sats and the scatter view doesn’t budge on a .01m scale after it’s locked in.

If I plug those coordinates into google maps, it’s pegged right on the position of my base station. It would look like SNIP is also getting the correct coordinates into the stream

So I was going off the rtk2go map function as per Lars here: Fixing reliability of RTK Fix - #9 by Larsvest and that seems to be way off. So I’m not sure how much I trust the rtk2go map link on the Caster Table Decoder page, which is the only link I’ve seen to a map on RTK2go site.

One thing I notice is on GPS you’re not getting any L2 signal at all, just L1. Actually all your constellations are only picking up one band, not two (white bars, normally if both bands are there these are solid color). Yes you should be seeing way more satellites I’d think, and definitely seeing L2, G2, and E5b on GPS, Glonass, and Galileo. I typically see about 28 here in Alberta. Very odd. Are you using the same model of antenna on the base station as on your rover?

Here’s what it should look like when you get L2, G2, and E5b signals as well as the L1 ones (I got this from navspark’s forum as an example):


Ignore the “RTK fix” status; you should see the same multi-band satellites on your base station as well as the rover. Dual band satellites show up as a solid bar color with a black snr and white snr number on them. Also the red round background under the satellite number means those satellites have too low a signal to noise ratio and are not going to be any good for your rovers to fix from. Looks like all your satellites are red, which isn’t good. Perhaps the antenna is bad or the cable is bad.

If I do a factory reset, it eventually shows up as solid bars and more sats. Change it to base station mode and then it goes like I had shown.