Cycle slips? or not?

[abertier (Andy Bertier)]

Hi all,
I planned investigating some occasional loss of fix (purpose was to compare ‘in field performance’ between multiple ntrip providers). But after downloading/analyzing some logs of the RS2, I see lot’s of cycle slips. I’ve no idea if I did something wrong during conversion/display, or if these are real slips.
Anyway here is the ground track: 92% Fix

ObsData of reachRS2:

G04 had SNR of 45 and elevation of 80° seems perfect to me…

Also I only find data of the base for GPS, I guess it should also send glonass data… could it be lost in the RTCM to obs-conversion?

And here are the logs of rover/base/solution of RS2

RS2 was mounted on hedge-trimming equipment, ca 5m above ground level, with a couple of trees around (but definitely not covered)

Edit:
Also, I cannot get any solution with RTKPost ( I must be doing something wrong)

[artem.fomenko]

Hi Andy,

I’ll look into the logs and let you know.

Could you please tell me which version of RTKLib are you using?

[abertier (Andy Bertier)]

I’m not at my RTK-computer, I’ll look it up this evening, I think I downloaded it from one of the tutorials on the emlid-docs about a month ago. (I think 2.4.3_b33, but I could have mixed up with the reachview-version )

Edit:
Actually I’m surprised of the high number of Fixed-solutions given the amount of cycle-slips

[abertier (Andy Bertier)]

I have to correct myself, my rtkplot-version seems to be 2.4.3 b8

[abertier (Andy Bertier)]

I made another attempt with the RTKLib-AppImages by emlid, and the results make more sense now.
Is this due to bugs which were fixed by emlid? or is there something else at play?
Is emlid thinking about backmerging these kind of fixes into the public rtklib sources?

Since these are my first steps into analyzing the observations, i’ld like to ask some more questions:

• The huge amount of cycle-slips are now gone from the GPS-satellites, however I still see a lot of slips on the L7 band of galileo for sats with good elevation:
  

  
  
  How can these slips be explained?

• I’ve also seen that the SNR for frequency types other than L1 is pretty low (except for Beidou), is this due to antenna type/design?
  Anyone has some documentation/resource on all the ‘L-frequency’-types used in rtklib?

• Another thing I don’t understand: why is it that i.e. G04, with a good SNR and elevation of 75-80° at the rover, only has a very small number of measurements in the RTCM-stream (but the measurements which are present have a good SNR). Could this be because the RTCM-stream was coming from a ‘virtual reference station’? a multiple physical stations were less than 30km away.
  

  
  
  left: G04 from RTCM-base observations, right: G04 from RS2-rover
  I expected sats with an elevation of >70° to be visible at both rover and base.
  Since the SNR is also good, could this be a RTKConv-issue?

[abertier (Andy Bertier)]

Meanwhile I tried to postprocess with rtkpost 2.4.3b33-Emlid, but still cannot get close the the results outputted by the RS2 during the actual capturing of the logging. This is the best I can get (post processed vs position output-log):

Is there something missing from the RTCM log?

[artem.fomenko]

Hi Andy,

We’ve just updated the RTKLib distributive with some minor tweaks which improve the calculation of the solution, that is why you might see the difference between the newest version of RTKLib from our site.

We try to adapt our version of RTKLib according to our receivers, that is why you might expect a better result with Reach receivers using the version from us, and also that is the reason why we can’t be sure that the improvements we introduce will be a universal solution for all other RTKLib users.

I’ve looked into your logs and I can agree that the satellite vision is not optimal. But in order to check the quality of the signal, I’d recommend analyzing the L1 and L2 solutions separately. The Gallileo signal is relatively poor in the L1 band and there are some cycle slips on the GPS satellites:

Speaking of the log quality from the base, there are some interruptions there too:

The VRS should not affect the signal quality itself, but it might produce the interruptions in the RTCM3 stream. But sure, this is up to the performance of the particular NTRIP provider, the quality of the cellular data and many other factors, so I would not have considered it as a valid reason. 30 km of the baseline seems fine for the multi-band receiver, but sure the closer one will do a better job.

I’m uploading the L1 logs only because the signal quality on the L2 and L7 bands is looking close enough to L1, and more pictures in one post might produce some confusion. So, with such signal quality, I’ve managed to get no more than 25% of fix solutions in the RTKLib version from Emlid, which is an expectable result for the logs of such quality:

The most common reason for cycle slips is antenna placement. You’ve mentioned that the RS2 was placed only 5 cm above the ground, and that might be the real reason for such behavior. Sure, the sky view can be obstructed by the tree canopies, but they should not block the sky view much too. Could you please test the signal quality in the conditions when the receiver’s antenna is at least 1.6 meters above the ground?

Regarding your comments on the elevation mask, the lower the angle, the more there is the probability that more common satellites from the base and rover will be used in the calculation. So, the elevation mask in the range of 70° might just trim off either the signal from the base or the rover. Generally, we recommend keeping the elevation mask in the range of from 15° to 25°. With the elevation mask of 70°, there might be not much data for calculations.

[abertier (Andy Bertier)]

Hi @artem.fomenko,

Thanks for looking into my logs, and the explanations, I’ll keep using the emlid rtk-lib with your receivers. However I want to respond with some comments:

1. Feedback about antenna position

@artem.fomenko

The most common reason for cycle slips is antenna placement. You’ve mentioned that the RS2 was placed only 5 cm above the ground

I mentioned 5m above ground (not cm ), probably it was between 4-5m (last heights from the solution logfile are -3m, at this point the RS2 was ca. 1.5m above ground. In the middle part of the log, the arm was raised above some hedges, so must be 4.5m above ground.

2. That’s my point too, in the field the RS2 got 92%FIX, but I’m unable to reproduce with post processing.

@artem.fomenko

So, with such signal quality, I’ve managed to get no more than 25% of fix solutions in the RTKLib version from Emlid, which is an expectable result for the logs of such quality

3. elevation/SNR mask is/was at default values of 15°/35. I just took G04 as an example because it had an elevation of at least 70° at the rover (so I guess similar at the base), but there is little data in the RTCM-stream for G04. Is the data somewhere lost during logging/converting?

[artem.fomenko]

Andy,

It is not likely that the data will be lost during logging and converting stages, most likely it happens at the stage when the RTKLib trims off the signal during the calculation process.

Excuse me for confusing the info on the antenna height. Could you please provide a picture on how does the RS2 is fastened onto the arm? The log quality seems to be not optimal, and at this stage we will need to investigate what might be the reason for it. The hardware setup photos is a great help in most of similar cases.

[abertier (Andy Bertier)]

@artem.fomenko

It is not likely that the data will be lost during logging and converting stages, most likely it happens at the stage when the RTKLib trims off the signal during the calculation process

I agree, but the questions remain:

• why don’t we see proper G04 observations in the RTCM-data?
• what would be the parameters to get the same results in post-processing (92% FIX). Even with ‘lower quality data’, with same data in, I would expect same data out…

I’ll try to take some pictures of the setup (wanted some for the photo-contest anyway )

[abertier (Andy Bertier)]

@abertier

I’ll try to take some pictures of the setup (wanted some for the photo-contest anyway )

I found some picture of that exact same track, first picture you can see the reach above the cutting machine. second pic gives some idea of the surrounding area. (at this point the machine was driving to the south on the longest, most west track.

[artem.fomenko]

Hi Andy,

The G04 most likely was just out of the observation of the base station, that is why its signal is interrupted.

RTKLib and RS2 may calculate the solution differently. While RS2 can get a fixed solution and maintain it in real-time in such conditions, it looks like RTKLib requires more tuning and higher overall quality of the logs.

In any case, the results that you are getting during post-processing indicate there are sources of interference around for both base and rover. And even when you work in RTK, RS2 can not always hold the solution reliably. So the suggestion here would be to try raising your rover receiver higher to move it a bit further from the machinery.

[abertier (Andy Bertier)]

@artem.fomenko

The G04 most likely was just out of the observation of the base station, that is why its signal is interrupted.

It’s possible, but it’ld be really strange, this sat had such a high elevation, it must have been visible at the base (but maybe it got rejected during calculations because it was a VRS). Still strange there are ‘some’ observations with very good SNR. (maybe I should dig deeper into the RTCM-messages to get used to them)

@artem.fomenko

RTKLib and RS2 may calculate the solution differently.

Differently as in ‘with other parameters’, or is it calculated totally different? By the ublox itself?

@artem.fomenko

there are sources of interference around for both base and rover

The base was a VRS, I think the environment arount the real base-stations is pretty optimal, they are managed by the government, and are placed pretty high above buildings (at least the ones I’ve seen myself). One argument which could have a negative impact is that the rover was around the edge of the area covered by the base stations.
I can agree for the rover, I can perform some tests with an even longer pole for the rover-receiver, but it’s not usable in the field, the higher the mount, the more it is exposed. And I really don’t want a damaged receiver or bent mount-pole.

I’ve seen @PotatoFarmer advising some kind of damping for the tallysman antenna with M2 (Antennas for Reach M2 - #22 by PotatoFarmer) but what about the RS2 ? I guess vibrations are similar to the tractor because of the hydraulic drives, but probably there are some lower-frequency/higher-impact vibrations as well while cutting through branches.

How big is the impact of vibrations on the signal-quality? (I thought it wouldn’t matter that much because the frequency of the carrier-waves is pretty high, and the channels/receiver are probably sampling/tracking at a much faster rate. Would the maximum velocity/acceleration settings have any impact on this?)

[PotatoFarmer]

The vibration I was damping was purely from mechanical oscillation.

Tree topping very cool! I think in your case you would have impact forces as well. Very challenging and dynamic environment.

I have to say this is one of the more creative Emlid RTK uses i have read about so far.

[abertier (Andy Bertier)]

Well ulitmately it’s all mechanical oscilation i guess…
I guess impact is greatly reduced by the mass of the machinery. (but it’ll be there)
But your post just triggered an interesting idea… maybe I should log the accelerometer data, to find some correlations between cycle slips (and potential loss of fix) and impact. Also it could give an idea of the amout of vibration and how it relates to the impact by hitting branches.

Damping the RS2 is probably harder than damping the tallysman. (due to the bigger mass of the device).

RTK-based tree topping/hedge trimming (no idea how it’s called in english), was something I had in mind since a couple of years. I always postponed the project because my experience with single-frequencies receivers wasn’t that good (given suboptimal sky-conditions). But because of covid, I had more time available, and given the more affordable multi-frequency receivers, I gave it a try.
So far little issues in the field, but we’re looking for the best (for a reasonable pricepoint )

Anyways your projects are inspiring me to put AgOpengps on my JD X304

[PotatoFarmer]

Awesome! The more people trying AgOpenGPS the better it will get!

I too have piled extra time due to Covid into some time well spent with Emlid. Funny how spare time leads to innovation.

[artem.fomenko]

Hi Andy,

I am sorry for the delay.

Let me comment on the vibrations in the current setup. Please, take a look at the XY graph from your LLH solution:

I’m afraid I can’t exactly imagine how does your hedge trimming arm moves, but I don’t really seem to see the vibrations on the plot here. Overall, the RS2 can handle vibrations relatively well, that’s why I believe it should not be the reason for the cycle slips.

For me, the biggest obstacle for the signal right now seems to be the placement of the unit itself rather than the vibrations. It would be really great if you could test the RS2 on the higher pole even if it brings some compromises to your setup. Large metal objects could be an obstacle for the GPS signal, even if the receiver is multi-band.

[abertier (Andy Bertier)]

typical movement of the arm is, straight line (driving direction) at fixed height, with intermediate movements perpendicular to the straight line (left, sometimes followed by a small tilt and back to the original place - this is to 'dump branches that were collecting on the blades/machinery).

The vibrations (from the spinning hydromotors/blades) are higher frequency (than position output of 5Hz) and short distance, so I guess they’ll never be noticable in position output, but in the quality of the output (cycle slips and therefore nbSats and solution type).
Anyway you’re way more experienced, so I’ll try to try you suggestion, probably need to convince the machine owner to do some changes again (although from his point of view ‘it works’, and it’s high-season in hedge-trimming…, but he’s a nice guy, i think he’ll agree to try)

Also, I’ll try to create a similar setup with local machinery, so I can do deeper investigations.

So my new/unanswered questions:

• Is it possible to plot the observations/cycle-slips in real time? (easier for quick-tests)
• About the difference of RTKLib/RS2 solutions: is it just different parameters? or is the RS2 using some onchip ublox-rtk-engine? (I’m assuming this because the RS2 seems to miss some settings I do have in my Reach modules, and these are settings I recognize from RTKLib options)
  
  

[artem.fomenko]

Hi Andy,

Sorry for the delay. It would be great if you could carry out these tests, even though it is a high-season in hedge-trimming.

In the meantime, there’s no way to plot the cycle-slips in real-time, but you can check the signal quality in the Status Field by Signal-to-Noise ratio bars and the amount of tracked satellites.

The calculation of the solution by RS2 and RTKLib may be carried out in a different way, but I can’t provide you with details on what is the difference in the processing between the two methods. RTKLib may require some more tweaking, but overall the most essential way to get good accuracy is providing the receiver with a clear sky view.

[abertier (Andy Bertier)]

Just letting everyone know I’ve not forgotten this, I will do the tests and try to nail down the problem, but some other priorities at the moment.