The Combine Forum banner
21 - 40 of 82 Posts
Discussion starter · #21 ·
My 372 gets a fix easily with the messages I described earlier. However I don't know if that's GPS-only or if Glonass is in the mix too. I suspect that it's GPS only, given your discovery that the 1230 messages are not right.
 
My 372 gets a fix easily with the messages I described earlier. However I don't know if that's GPS-only or if Glonass is in the mix too. I suspect that it's GPS only, given your discovery that the 1230 messages are not right.
Well I've taken GLONASS out of the mix now (messages 1087 and 1230) and just relying on GPS, Galileo and BeiDou MSM7 observations.

So sending out 1005, 1008, 1077, 1097 and 1127. A very quick and dirty test with an RS2 rover suggests a far faster and more stable fix. Will try again with the AG-382 tomorrow.
 
Update:

No joy with the AG-382 and the F9P base running native MSM7 unfortunately. Tried several combinations:

1. Removed all GLO messages (1087 and 1230)

2. Re-enabled 1087 from the F9P and added in 1033 messages from the near Leica base (that the AG-382 agrees to play with)

3. Re-enabled 1087 from the FP9 and added in "valid" (or at least they appear to have valid content) 1230 messages from the near Leica base

So I think I've exhausted all possible combinations of getting the AG-382 working with an MSM7 stream from an F9P. There is something there its choking on, but I'm not sure what.

The only thing left to do is to convert the MSM message stream to Classic 1004/1012 and feed that to the AG-382, which according to Konrad's post above should work fine. Oh well.
 
Update:

No joy with the AG-382 and the F9P base running native MSM7 unfortunately. Tried several combinations:

1. Removed all GLO messages (1087 and 1230)

2. Re-enabled 1087 from the F9P and added in 1033 messages from the near Leica base (that the AG-382 agrees to play with)

3. Re-enabled 1087 from the FP9 and added in "valid" (or at least they appear to have valid content) 1230 messages from the near Leica base

So I think I've exhausted all possible combinations of getting the AG-382 working with an MSM7 stream from an F9P. There is something there its choking on, but I'm not sure what.

The only thing left to do is to convert the MSM message stream to Classic 1004/1012 and feed that to the AG-382, which according to Konrad's post above should work fine. Oh well.
Why would you send MSM7 messages on the AG-382?
 
Update:

No joy with the AG-382 and the F9P base running native MSM7 unfortunately. Tried several combinations:

1. Removed all GLO messages (1087 and 1230)

2. Re-enabled 1087 from the F9P and added in 1033 messages from the near Leica base (that the AG-382 agrees to play with)

3. Re-enabled 1087 from the FP9 and added in "valid" (or at least they appear to have valid content) 1230 messages from the near Leica base

So I think I've exhausted all possible combinations of getting the AG-382 working with an MSM7 stream from an F9P. There is something there its choking on, but I'm not sure what.

The only thing left to do is to convert the MSM message stream to Classic 1004/1012 and feed that to the AG-382, which according to Konrad's post above should work fine. Oh well.
Why would you send MSM7 messages on the AG-382?
Well the ZED-F9P only supports ‘modern’ MSM4 or MSM7 message output when in base mode.

As far as I know MSM4 is not compatible with AG-series Trimble receivers (although I’ve heard it reportedly working with Spectra receivers in the survey game). MSM7 does actually work as a correction format on these receivers, as evidenced above in the OP.

I have also successfully used MSM7 stream corrections from a Leica GR-series receiver and the AG-382 is perfectly happy with that.

Transforming MSM message to legacy ‘1004/1012’ is possible as you know but it adds extra complication and you actually lose useful stuff such as Doppler info going from modern to legacy messages.
 
Discussion starter · #29 · (Edited)
Very odd indeed. Should be working. Are you using AgRemote or the RDI screen to talk to and configure the receiver? In DGPS Status, does it show a base station id (usually 0), and a distance from the base station? Are you getting any kind of age reading?

One thing about the F9P I discovered is that my particular board (the Sparkfun RTK2) has a battery that keeps some settings, including the survey-in latitude and longitude. So if when I moved the base station, I needed to go in and have it do a new survey. Otherwise the position was off by however far I moved the base station, which sometimes caused my 372 to not get a fix--it just couldn't resolve the ambiguity.

Every once in a while the 372 won't go into RTK mode. It says waiting for DGPS on the Pro 700. If I switch it to WAAS and wait for a DGPS signal, and then back to RTK it usually picks up the fix right away.
 
Very odd indeed. Should be working. Are you using AgRemote or the RDI screen to talk to and configure the receiver? In DGPS Status, does it show a base station id (usually 0), and a distance from the base station? Are you getting any kind of age reading?

One thing about the F9P I discovered is that my particular board (the Sparkfun RTK2) has a battery that keeps some settings, including the survey-in latitude and longitude. So if when I moved the base station, I needed to go in and have it do a new survey. Otherwise the position was off by however far I moved the base station, which sometimes caused my 372 to not get a fix--it just couldn't resolve the ambiguity.

Every once in a while the 372 won't go into RTK mode. It says waiting for DGPS on the Pro 700. If I switch it to WAAS and wait for a DGPS signal, and then back to RTK it usually picks up the fix right away.
Yep I know, I'm getting just a tad frustrated with it. I haven't yet hooked up a laptop with AgRemote onto a spare serial port on the receiver - I'll hopefully try that in the next few days...

In testing the Ardusimple board I typically check all the settings, load up as a "rover" in u-center first up to run the receiver in rover mode, to get an RTK fixed position from the Leica base.
Tools -> Receiver Configuration (choose file) -> Load Config -> Transfer File to GNSS

Once I have the fixed and referenced base co-ordinates, I push out a "base" configuration (as above procedure) from u-center to the Ardusimple and enter in the base co-ordinates in u-centre:

Configure window -> TMODE3 -> "Fixed Position" and enter or check the loaded ECEF X, Y, Z coordinates are as per the earlier rover RTK-fixed position, all as referenced to the Leica base.

I suspect the solution the AG-382 receiver is getting to is just "single" or left long enough a best of a "float" solution. It never gets close enough to resolve the ambiguities to get a clear "fix" as it does on the Leica with MSM7.

I will look into this further as said, as the VarioGuide display just doesn't give enough info there to call it. All I have for now are the status indications as per photos below, from the VarioGuide host display.

As noted in my earlier postings the distance to base steadfastly refuses to budge from 50,000m (the default) and the correction age (signal lag) is higher than I would expect, varying between 5 and 8 seconds typically. The very best accuracy I have seen (after 40 minutes) is 3cm.

On the other hand the Leica base running from the same caster, almost immediately gives the correct distance to base (less than a few hundred metres) and the age of correction is around 0 to 1 second (as you'd typically expect with NTRIP). It converges usually in a matter of seconds or under a minute when 'cold'.

Looking through the RTCM3 messages above, it's (unsurprisingly) apparent that the two base receivers are processing slightly different code observations for the various constellations. The Leica code observations in the MSM7 messages look more "complete". Perhaps as you'd expect with a reference class receiver?

Leica
GPS: L1C, L2W, L5Q
GLONASS: L1C, L2P
Galileo: E1C, E5Q
BeiDou: B1, B2

ZED-F9P on Ardusimple RTK2B
GPS: L1C, L2L
GLONASS: L1C, L2C
Galileo: E1C
BeiDou: B2I

Theres's a worrying niggle in my mind, based on what someone else said to me on the TFF forum a little while ago, effectively that the u-blox F9P is a lost cause acting as a base with legacy third party receivers, I quote:

"All the ‘experts’ stating how low cost dual frequency receivers are going to be a great alternative to major brand base stations without first testing the specs. There’s no P code, L2C only, meaning, out of the box, your Topcon, Trimble etc doesn’t fix on RTK. I know, I’ve spent some time testing it."

Hmmmm....yeah.
 

Attachments

Discussion starter · #31 · (Edited)
Reading that forum post now...

I'm pretty sure I'm getting a real RTK fix on my 372. I'm pretty sure the precision is an inch or less. Even if it's not, I'm getting repeatable accuracy anyway, which is all I really want. In reality, getting a machine to drive within a couple of inches of a desired track is pretty impressive.

The only way I know of to tell what kind of fix it's getting is to look at the HDOP and VDOP numbers. I'll have a look tomorrow and see exactly what they are.

Using AgRemote will let you access the console directly and you might be able to see some more information about what is going on. I can access this through my Pro700 monitor using it's RDI interface without needing a computer.

EDIT: So I was looking at your screenshots and I notice that it's saying RTCM 3.1. Pretty sure the F9P is using RTCM 3.2. But then again, the Leica is using the same messages, and therefore the same RTCM version. So that shouldn't make any difference.
 
Yes the F9P is definitely using RTCM 3.2 as modern MSM messages were only introduced from that revision to the standard. RTCM 3.1 is “only” the original legacy message types and GPS+GLO only. However as you have pretty much said, I think it’s a red herring, to some degree anyway, as the 382 is quite happy being fed MSM7 from the Leica base....

Will investigate the DOP figures on screen and compare against both base corrections. Also get my laptop hooked up to the roof to see what other info I can garner direct from the receiver.

Thanks for your thoughts and help. It’s appreciated.
 
Discussion starter · #33 ·
So I checked my setup today again. For whatever reason the DOP numbers never seem to change whether it's on RTK or WAAS. However in the AgRemote console (RDI on the pro700), under GPS Status it says the position source is RTK Fix. Also my phone running Lebefure NTRIP client reports that the 372 is in full RTK mode, not RTK Float, and the NMEA stream coming from it reports a horizontal accuracy of 2.0 cm. In WAAS that's usually around 100 cm. RTK Float is usually reported as 50cm in my experience.

So I am pretty sure I'm getting a full RTK Fix on the 372, with between 8 and 12 satellites.

One thing that I thought of is to use AgRemote to see what your SNR and elevation masks are. Changing those masks can include more satellites in the solution, which might help.
 
So got around to making up a little loom cable to talk to the receiver. Luckily I had some size 20 deutsch crimp sockets handy, and managed to get away without using a wedge lock for the DTM plug...temporarily anyway!

Got the laptop hooked up into Port 1 (Port A connector) of the AG-382 using AgRemote. Ports 2 and 3 (on Port B connector) are occupied with connections to VarioGuide steering controller unit etc.

I also hooked up FlashLoader200 and took a config snapshot.

Explanation of the attached thumbnails:
01 Home Screen with Leica base running MSM7
02 Receiver Version Info
03 Receiver Version Info
04 DOP status with Leica base running MSM7
05 Home Screen with F9P base running MSM7
06 Config with SNR and Elevation masks
07 RTK Config with DOP mask
08 Config Port A
09 Config Port B
10 Config Port C
11 Config Port D
12 Base station Info - Base ID with Leica base
13 Base station Info - SV info with Leica base
14 Base station Info - Base ID with F9P base
15 Base station Info - SV info with F9P base
16 Base station Info - Correction age with F9P

Some quick observations ~

- 382 receiver definitely gets an RTK fixed status when connected to Leica base using MSM7
- when connected to F9P base the solution drops to single - on AgRemote its actually shown dropping to either xFill "X\3D" or xFill Premium "P\3D" (it took me a while to figure out what the P stood for) when connected to F9P base using MSM7

In the "Base Station Info" status section:
- Base ID is present for both bases (its says "RTCM1492" for both bases because I'm simply copying the 1008 message from the Leica stream and injecting it into the correction stream from the F9P on my caster. It must be getting the "1492" from the Station ID in that message. Station ID is "0" on the F9P base)
- Correction age is present and looks broadly similar for both bases (< 1 second)
- SVs quantity and IDs are shown for the Leica but not for the F9P base, which indicates "00SVs"
 

Attachments

...and the other thumbnails attached below for the Base Station Info.

...
11 Config Port D
12 Base station Info - Base ID with Leica base
13 Base station Info - SV info with Leica base
14 Base station Info - Base ID with F9P base
15 Base station Info - SV info with F9P base
16 Base station Info - Correction age with F9P
 

Attachments

Discussion starter · #36 ·
When the weather warms back up and I can pull the sprayer out of the shop, I'll have a look at what things look like for me on my 372.
 
Rtcm 1008

I have tried to get eringerli/RpiNtripBase running on PI Zerro where zed f9p is connected to PI via usb and only RTCM 3 out, 1005 1077,1087,1097,1127 and 1230 come through to rtk2gocom but don't think i can start inject rtcm 1008, are there any that have the complete start command for PI Zerro?
Have tested this:
sudo systemctl enable baseProxya115200.service
sudo systemctl start baseProxya115200.service
sudo systemctl enable ntripcaster.service
sudo systemctl start ntripcaster.service
sudo systemctl enable logrotate-ntripcaster.timer
sudo systemctl start logrotate-ntripcaster.timer
sudo systemctl enable str2str-injectrtcm1008.service
sudo systemctl start str2str-injectrtcm1008.service
 
When the weather warms back up and I can pull the sprayer out of the shop, I'll have a look at what things look like for me on my 372.
By way of super quick update, I'm trying to get a support case opened directly with u-blox to discuss the null/zero 1230 message, which I reckon could be what's stopping the Trimble receiver from getting GLONASS rtk ambiguity resolution - a fix - with a ZED-F9P as the base/reference receiver.

I then stumbled across this article, pre-dating the release of the ZED-F9P, but which has a bit of a smokin gun, when its says:

"In GLONASS RTK, inter-frequency phase biases (IFPB), if left uncalibrated, contaminate estimated carrier-phase ambiguities and prevent successful ambiguity resolution. For this reason, the Radio Technical Commission on Maritime (RTCM) Services has defined message type 1230 to exchange IFPB calibration values. When this calibration information is available, GLONASS RTK can be performed just like GPS. However, not all reference stations provide the calibration message and newer receiver types, especially low-cost receivers, may not have calibration values available."

https://www.blackdotgnss.com/2018/03/05/glonass-rtk-with-low-cost-receivers/

What stumps me is that u-blox have gone to the bother of including the 1230 message in the supported list of RTCM output messages, but then either not configured the data to go in the message....or I'm just thick and overlooking something to get it configured or activated in the setup.
 
Discussion starter · #40 ·
Agreed. It's likely the F9P doesn't have those values but it is odd they provide the 1230 message at all. I wish there was a way to look at my messages and decode them to see what it's saying, but I don't have the software to do that (or a Windows machine to run it on). Maybe if you provide a hex dump of your raw 1230 message (from the F9P), I'll check mine. I suspect it's also blank.

Still, though, this might be a red herring as the Trimble should still have enough observations to do a GPS-only fix.
 
21 - 40 of 82 Posts