SkyTraQ Receiver on Open Station Tractor

I’ve implemented AgOpenGPS using a SkyTraQ receiver from Navspark on a New Holland TT75 with no cab. It’s a utility tractor with loader that gets used for all sorts of jobs but unlikely to do more than a 20 acre paddock. I’m in New South Wales, Australia, on flood plain country with no hills or obstructions blocking Sky.

My setup uses free NTRIP corrections from the Government as the correction source, a Navspark Evaluation Board, a $50 antenna from Navspark, a Surface Go as the Tablet PC, a Brick V2 and a USB hub. An Iphone is providing the internet connection via hotspot.

So far I’ve put ~25hrs on it and it’s working fine for the most part but I’ve had some reliability issues I need to resolve and would like advice as to the best path to take. An open station tractor certainly has it’s own challenges so maybe someone else might find this useful too. My tractor has one of those plastic canopies that are held up by the roll bar and a light frame. It gets plenty hot enough here to soften the plastic so mine has sagged in the middle. Very hot and dusty environment. I’ve used AgOpenGPS to pick up pipes, etc on foot, and had it on the car driving around during testing.

My first issue appeared to be related to the WIFI hotspot. I think the Iphone was disconnecting the tablet. A USB power point installed on the tractor with the phone always charging seems to have fixed it.

Second issue might be Brick related. I tried without the brick, and found the heading to be a bit dodgy on rough ground. The Brick solves that, but I have had a couple of instances where the heading from the Brick appears to spontaneously invert (change by 180 degrees) which puts AgOpenGPS into a spin until it settles down again. Seems to be a rare problem. The brick is in a small case stuck the underside of the canopy roughly in the middle.

My main problem seems to be reliability of an RTK Fix. I’m finding it is in Float for what seems like a quarter of the time. Once it is in Float the accuracy drifts noticeably pretty quickly. Sometimes it doesn’t seem to be able to get the fix back. Sometimes it struggles to get a fix from startup. On occasion rebooting the GPS and doing a cold start seems to have resulted in a fast and persistent Fix. I don’t know what the problem is, but assume that something is causing the receiver to struggle with a RTK solution. I have some theories to test and would like advice so as I don’t waste a heap of time.

  1. SkyTraQ receiver not up to the task. Maybe the little computer just can’t figure out a solution? I can’t find a way to see what is stopping the receiver from getting a solution. I can tell if it’s receiving corrections, but don’t know what the problem is. The solution would be to change to Ardusimple receiver as that appears proven in this application.
  2. Antenna not up to the task. There are no markings on the antenna so no idea who makes it or where it’s from but I’m pretty impressed by its ability to pick up satellite and the signal to noise ratio looks good. Maybe its just too different to the corrections coming into it? The solution is to upgrade the antenna.
  3. Settings are wrong. Here I’m thinking changing Masks. I seem to be able to change elevation, DOP, CNR and position fix Masks. The trouble is I don’t truly understand what this affects other than reducing the inputs available to the solution. There’s are a lot of a combinations so I’m worried about wasting a bunch of time without knowing if I’ve actually improved the situation.
  4. Bad antenna placement. I see a lot of shaking/vibration as is and am wondering if that is upsetting the solution. The antenna is mounted on the front of the canopy to one of the mounting bolts. It would be more solid at the rear where the roll bar is but that’s behind the axle and AgOpenGPS doesn’t allow that. Alternatively I could mount it forward on the bonnet, but I was worried about the obstructions of the loader arms and canopy etc. That’s probably what I would test next in the absence of other advice.
  5. Too far away from the base. I’m 25km from the base which is further than what conventional wisdom suggests, however our Government reckon for Ag purposes out to 50km is fine which is why stations are spaced every 100km. My accuracy from my tests seems to be very, very good, and plenty good enough for what I’m doing, and setting up my own base would be a pain as there is no power or internet.
  6. Expectations too high?

Suggestions will be welcomed. At the moment it is good enough to supplement my driving, but not reliable enough to be doing skips and spraying. If I can get it to the stage where I trust it better I might head down the Autosteer route. The AgOpenGPS seems to be doing everything it should and is a great tool, and it’s amazing I’ve gotten this far with a $200USD GPS and a cheap tablet!


1 Like

I would suggest a support arm to your front of canopy.

Which mountpoint did you connect to?
At the documentation for skytrak PX1122R they demand RTCM 3.3
Edit: it seems that the main difference between 3.2 and 3.3 is the 1042 for Beidou and 1046 for Galileo so drop using Beidou might help. (1046 is only for security/safety so Galileo should be ok)

RTCM 3.2 1004(1),1008(10),… RTCM3 data streaming with data specification (messages 1001-1039, 1044-1045, 1057-1068, 1071-1230, 4001-4095)
RTCM 3.3 1004(1),1008(10),… RTCM3 data streaming with data specification (messages 1-100, 1001-1039, 1042, 1044-1046, 1057-1068, 1071-1230, 4001-4095)
RTCM 3 Message List - SNIP Support
End Edit:
When operating in rover mode, PX1122R can decode following RTCM 3.3 messages:
RTCM Message Type Description
1004 Extended L1/L2 GPS RTK observables
1005 Stationary RTK reference station antenna reference point
1012 Extended L1/L2 GLONASS RTK observables
1033 Receiver and antenna description
1074 GPS MSM4
1075 GPS MSM5
1076 GPS MSM6
1077 GPS MSM7
1094 Galileo MSM4
1095 Galileo MSM5
1096 Galileo MSM6
1097 Galileo MSM7
1114 QZSS MSM4
1115 QZSS MSM5
1116 QZSS MSM6
1117 QZSS MSM7
End Quote!

And here I found they only deliver 3.2!

"Host Domains

Port 2101

Mountpoint Information

The available data streams are listed in the sourcetable. All mountpoints contain the station 4-character identifier followed by a number which indicates the type of data format.






In addition to the data streams, satellite orbit and clock correction streams are rebroadcast from the Products IGS-IP Ntrip Caster. Details on these streams can be found at the IGS Real-time Service."
End quote!

Skytrak also mention max 30 km distance. So you should be good there (but try if fix is stable if you drive closer to base (in your car)

To ease load on reciever, only set 3 signals (e.g GPS GLONAS and Beidou)

I also bought a PX1122R but haven´t got time to implement it yet, want to try it as base for my F9P

You can do u-turn and spraying without RTK (I did this autum seeding in single mode) You just have to press the centering button at bottom left, when you return to field after a break. (park/drive on tramline and press centering and A B line is ok again)

Thanks Larsvest,
The mountpoint I’m using is RTCM3.2 but does say it’s outputting all the constellations (GPS+GLO+GAL+BDS+QZS) and my interpretation is it is still sending BeiDou corrections, but maybe the receiver isn’t using them?- my nearest mountpoint is GUNN00AUS0. I’ll take a look at dropping a constellation or two and see if it helps the load on the receiver. BeiDou is probably half the satellites in view, so kicking that off should reduce the thinking the receiver needs to do. I did a bit of messing around with an online planning tool to confirm I wasn’t having satellite problems when I was using it and was surprised I can increase the elevation mask by quite a lot and still have 15 or more without BeiDou so I might increase that to 25 degrees to exclude a few more and reduce multipath worries a little more too. DOP levels go up without BeiDou so I guess I’ll see if that affects the solution in any way.

If front of canopy is the best place, then I’ll take a look at bracing it some more.

Thanks for the feedback…

I’ve been doing some testing with the unit on the roof of my car. I have changed the elevation and signal mask to 25 degrees and 30dB without an obvious difference except maybe being a bit better near trees. I tried cutting out constellations but found that made performance worse plus gave a worse solution in Float. I’m getting quite inconsistent results which is leading me to the conclusion it’s atmospheric conditions causing the trouble with the Fix solution.

I have been driving between my Home (5km from Base) to the farm (22km) and to work (40km+). I also took a drive to my parents on the weekend over 100km away. Some days it has no trouble at all getting a fix, and others it seems to struggle. For example, yesterday on my way home I had a fix at work (furthest from base) then it lost it then struggled. I stopped at the Farm on the way home, messed around with some settings, and rebooted a few times and only managed 50% of the time in Fixed mode. It was struggling all the way home, still going into float at home (closest to base). This morning it got a fix very quickly and held it for the entire 50min drive to work.

I’ve managed to get a fix (driving) up to 60km from a base. Mobile coverage has been a major challenge for testing though, as I’m relying on an Iphone for the Wifi Hotspot, and it clearly doesn’t put a lot of priority on the connection as it will disconnect if there’s not service. I have good coverage at the farm though so I don’t think that’s an issue.

The next step I think is either a better antenna, or try my own base closer. I have no internet at the farm though, so that will require some sort of WIFI or radio solution.

Hello, faced the same problem. RTK FIX solution is not robust. even in clear weather, with good satellite geometry, I tested 3 simultaneously switched on PX1122 receivers. The FIX solution was not the same on them, then on one it will disappear on the other. I think you need to contact the manufacturers, they probably do not know about such problems. I also found that if there is a FIX solution on the receiver, then blowing the px1122 module with my mouth, the solution disappears, try it, I think it’s an unprotected quartz.

That seems to confirm the issue is with the receiver. Probably means they’re not up to the task then. Are F9P users getting 100% Fix solution I wonder?

I use Ardusimple simpleRTK2B as base and rover and I have rtk fix 99.9% of time with open sky. It only goes to float when near from trees or buildings.
AOG says 12 Sats.
From what I saw one the forum I would say F9P would give 95%+ RTK fix.

But I don’t know if it’s the same for Australia.

Thanks! I think I’ll get an Ardusimple board, but the risk is always that it is actually something else. From the data I’m seeing I shouldn’t be having issues. The systems at my work have been extremely reliable. The trouble here is the apparent difficulties retaining and regaining a solution. The position in float also drifts fairly rapidly.

You can check if your CORS station send all the needed messages and if they are multi-band. From what I see they don’t send 1005 messages and 1230 only once per minute. But they send other messages (like 1006) my F9P don’t.
Mine send RTCM3.3 1005,1077,1087,1097,1127,1230
Don’t know if this can be an issue.

You can also run some RTKLIB tool to monitor the satellites available from the base and the rover just to see if they are the same.
I was playing with when I was trying to use two ublox M8T (simple band) but the result with these was disappointing. Rarely got an fix, float most of the time.

1 Like

I tried the “Blow On it” trick Rybak mentions, and sure enough it loses fix straight away. Don’t even need to blow hard! Mine has been in a box, but might explain why I get better results in the dark than in the afternoon. Seems dodgy.

Ardusimple board has been ordered so I’ll be able to compare.

The CORs network is the professional surveying network and I’m pretty sure it’s good. It used to be a very expensive subscription. Happily it’s now free.

Have received my Ardusimple Board and that has been very successful. It seems to be far better at holding a fix. It has the added advantage of using the same serial port to send nmea sentences and receive NTRIP corrections, so I can use AgOpenGPS for that which is easier to monitor.

I have noticed that I am sometimes having an issue receiving corrections. It seems to be the data flow just stops. It doesn’t seem to be the internet connection, so given it’s harvest time around here, maybe the CORS network is struggling to keep up. I suspect this was some of the problem with the SkyTraq unit, with the difference being it immediately lost fix and seemed to drift more rapidly, whereas the F9P seems to cling onto its fix for 30s or so. Stopping NTRIP and starting it again seems to solve the issue, or it will often get it back after a couple of tries.

I have the occasional issue still with the Iphone dropping the hotspot. I don’t know why it does it, but it is pretty painful.

I’m much more confident with the Ardusimple solution but will try and do some side by side testing at some stage…