Same point shot on different days shows a 6' shift

[oajioka]

As the title says. Our setup is Triumph-3 base with TLS+ rover.

Observations on point 1 from both days met the thresholds for confidence, consistency and variety and showed RTPK solutions within <0.24'

Other points that were also shot on both days (Points 2 and 9) do not show this shift.

Attached is the .pdf report for this project.

 

[Nate The Surveyor]

One difference I can see between the panels, (If I am reading it right) is that Point 1.2 is on PAGE0, and point 1.9 is on PAGE5.
The GIVEN SPC values are nearly the same. So, MAYBE the localize is changed for one page, but not the other?
N

 

[oajioka]

Page 0 and Page 5 are both set to the same coordinate system, and there was no change to the localization between day 1 and day 2. On day 2 we reopened the same project, set up the base on the same physical point and used the coordinate from day 1 (unprocessed). We never re-localized on day 2.

 

[Shawn Billings]

The base coordinate is different in the report on 1.4 vs the report on 1.1, 1.2, and 1.3.

 

[Shawn Billings]

It appears there are at least three different base coordinates I notice in the points report. For example, points 1.1, 1.2, and 1.3 use base coordinates: N 2137970.1918, E 5990072.5068, U 20.9381. Points 1.4, 1.5, and 1.6 use base coordinates: N 2137968.0312, E 5990078.3999, U 22.6389. Point 2.1 uses N 2137967.9754, E 5990078.504, U 22.6389.

The last two base coordinates are "close" to each other, but the difference is still significant.

 

[ken larson]

I misunderstood something and do not know how to delete...long winter

 

[John Rosco]

Page 0 and Page 5 are both set to the same coordinate system, and there was no change to the localization between day 1 and day 2. On day 2 we reopened the same project, set up the base on the same physical point and used the coordinate from day 1 (unprocessed). We never re-localized on day 2.

Your TLS project data clearly shows ‘Point 1_AVG’ has a different ‘base coordinate’(from day 1) than ‘Point 2_AVG and Point 9_AVG’ (on day 2) . . .

The difference in the ‘base reference positions from Day 1 to Day 2’ is approximately 6.4’

 

[ken larson]

Day 2 maybe you occupied the same physical point with a short observation time instead of picking the point from the list...this would all be washed out when you post process the base locations. For both days.

 

[oajioka]

Here is the project report for a different project that had a similar issue.

This was our first time on the site, we set up the base autonomous.

We set up the rover on point 5007 and let it cook for ~30 minutes. We ended up with 6 shots of varying quality. Some did not meet the variety threshold.

Looking at base station coordinates for shots 5007.1 and 5007.5, they show a different coordinate compared to point 5000.

We used the total station at this site also, and we have ties from the total station on the GPS base and a few other points that were collected with GPS.

The distances between rover shots check with the total station, but when we align the robot data to the GPS data, the base station points don't match. The total station puts the base coordinate ~6.8' westerly of the GPS coordinate.

Points 5007.1 and 5007.5 show a base coordinate that matches the total station data. These shots met the variety threshold.

Points 5007.2, .3, .4, and .6 all show a base coordinate that matches 5000, and did not meet variety. These are the only shots in the project that show a base coordinate that matches 5000, and are shifted 6.8' from 5007.1 and 5007.5.

Needless to say, we didn't stop or move the base in between these shots.

It has come to my attention that back in July when these issues began to crop up, the base station was blown over by the wind. I don't know how that could cause these issues, but the timing is such that I can't rule it out.

 

[oajioka]

Shawn: Is it normal to have more than one base station coordinate in the report like this? It seems as though there's no reason for the base coordinate to change. This is exactly what I'm trying to get to the bottom of.

Ken: I specifically chose not to post-process the base between day 1 and day 2, and on day 2 when I set up the base I chose the point from day 1.

 

[oajioka]

Per my co-worker on a different project:

"So I used this same base and rover earlier this week, on Monday and Wednesday, at the same site.

I set the base on existing coordinates that we had previously DPOS'd back in 2020, and have since used as a base for other jobs over the last few years with no issue. It might be worth noting that I initially had trouble CDFing once I got to the job site, so I had to toggle our SIM card on and off, which seeming fixed the connection issue. I set a bunch of control for the robotic total station and as drone targets, but was having NO luck with my stakeouts. So I get back out there Wednesday, set up the base EXACTLY the same, and all of a sudden my stakeouts are getting me within a couple 10ths of the monuments I was looking for, which were -of course- about 6.5' away from where I had been searching two days earlier (trust me, I was pretty upset with myself for still not being able to dig these up regardless of the bad stakeout, but the magnetic locator wasn't working that great in the sandy beach soil and I was under time pressure, ok!). I then re-tied some of the control I had set and that, too, was about 6.5' away from the coordinates I had from Monday.

Digging into the PDF reports between each day, we noticed that not only were the base coordinates on all of my rover shots on Monday different from the ones on Wednesday, they differed from the coordinates the base had before taking any rover shots on Monday. Luckily I didn't have any issues with the base changing coordinates mid-survey like we've had on past jobs.

The difference in coordinates is similar in all these circumstances though: between 6'-7', and the "incorrect" shots are always easterly of the "correct" ones. There is literally no indication during the field survey that anything is changing - no warning message, no prompt, no flashing red lights telling me the base has sprouted legs to take a smoke break - nothing."

Attached are the .pdf reports from both days.

 

[ken larson]

Maybe different pages are using dif definition of a foot...see old post where a base issue for around 5 foot was discussed

Thread 'J-Field not using it's own DPOS report position? Take a look.' https://support.javad.com/index.php...ts-own-dpos-report-position-take-a-look.6057/

 

[Shawn Billings]

Shawn: Is it normal to have more than one base station coordinate in the report like this? It seems as though there's no reason for the base coordinate to change. This is exactly what I'm trying to get to the bottom of.

Ken: I specifically chose not to post-process the base between day 1 and day 2, and on day 2 when I set up the base I chose the point from day 1.

The reports are helpful, but don't really tell me the whole story. The screen captures for each base station session would help. And that may be in the report, but I can't tell from the report which points belong to which base point. Second, I would want to see the coordinate list. Are some points translated (such as from AU to CP), and others aren't? I've seen this happen. I don't really have the time to explore it, but I think you have all of the tools there to at least see what the problem is. I haven't worked the math out myself, but I suspect it is safe to say that the regarding the points with varying coordinates, the vectors from the base to the rover that created those points were likely good, just as the quality indicators said they were. I think your step now is to look at the point list and see what the solution type for the base of each of those points is (AU, KN, CP), and to see if that matches the coordinate that you started the base with in base rover setup (this can be seen in the screen capture of the base point - that's why we added that feature a long time ago). If it doesn't match, then we have to look at why they don't.

Also, look at all of the points collected in a session. Do they each use the same base coordinate? They certainly should. When I say "base session" I'm referring to starting the base, collecting points, and then stopping/downloading the base, as being a session. You can have many sessions in a day.

 

[Shawn Billings]

Perhaps you should provide the archive of the project here and someone can dig into it a bit deeper.

 

[Nate The Surveyor]

I think the user fundamentally is not understanding the importance of the BASE station, being ASSIGNED and REMAINING the same, throughout the "Survey".
My flow chart is: 1st time on the base, it is based upon a "here". Autonomous source. This typically results in a location, within 7 feet of the "TRUE" or real location.
Then, Post Process it. and update it and all it's sideshots. This is day one.
Day 2, now gets assigned via picking this same base value (That is the updated one, from the DPOS session) , and remains the same, EVERY time on this job.

Now, how to fix what you have?
Shawn or someone else can flow chart this. Fundamentally, you MUST assign all base sessions, On that particular base point the same coord values. Then, all of it works right.
I could flow chart it, but I have not been feeling real great.... (Kidney stone joy!) For me to remember the steps, I'd have to turn mine on, and carefully step through it. This NEEDS to be done on your job. AND... there is an incomplete portion of the programming in the LS. Once you use this assign base coord values, you loose the ability to use RTK vs PPK, or to switch between these. This is very frustrating to me. But, hey, Javad did alot for us. You can MANUALLY add or subtract the differences on these sideshots, and enter them manually, and they will show as computed values. So, you can work around this too.

Gotta go....

 

[Shawn Billings]

I think the user fundamentally is not understanding the importance of the BASE station, being ASSIGNED and REMAINING the same, throughout the "Survey".
My flow chart is: 1st time on the base, it is based upon a "here". Autonomous source. This typically results in a location, within 7 feet of the "TRUE" or real location.
Then, Post Process it. and update it and all it's sideshots. This is day one.
Day 2, now gets assigned via picking this same base value (That is the updated one, from the DPOS session) , and remains the same, EVERY time on this job.

Now, how to fix what you have?
Shawn or someone else can flow chart this. Fundamentally, you MUST assign all base sessions, On that particular base point the same coord values. Then, all of it works right.
I could flow chart it, but I have not been feeling real great.... (Kidney stone joy!) For me to remember the steps, I'd have to turn mine on, and carefully step through it. This NEEDS to be done on your job. AND... there is an incomplete portion of the programming in the LS. Once you use this assign base coord values, you loose the ability to use RTK vs PPK, or to switch between these. This is very frustrating to me. But, hey, Javad did alot for us. You can MANUALLY add or subtract the differences on these sideshots, and enter them manually, and they will show as computed values. So, you can work around this too.

Gotta go....

I've dealt with a few kidney stones over the years, my friend. I'll be praying for you. I stopped drinking cokes a few years ago and haven't had any since. I've been told that lemon juice helps dissolve them, so I put a little squeeze of lemon in my water when it's available. Hope you feel some relief soon.

 

[oajioka]

I think the user fundamentally is not understanding the importance of the BASE station, being ASSIGNED and REMAINING the same, throughout the "Survey".
My flow chart is: 1st time on the base, it is based upon a "here". Autonomous source. This typically results in a location, within 7 feet of the "TRUE" or real location.
Then, Post Process it. and update it and all it's sideshots. This is day one.
Day 2, now gets assigned via picking this same base value (That is the updated one, from the DPOS session) , and remains the same, EVERY time on this job.

Now, how to fix what you have?
Shawn or someone else can flow chart this. Fundamentally, you MUST assign all base sessions, On that particular base point the same coord values. Then, all of it works right.
I could flow chart it, but I have not been feeling real great.... (Kidney stone joy!) For me to remember the steps, I'd have to turn mine on, and carefully step through it. This NEEDS to be done on your job. AND... there is an incomplete portion of the programming in the LS. Once you use this assign base coord values, you loose the ability to use RTK vs PPK, or to switch between these. This is very frustrating to me. But, hey, Javad did alot for us. You can MANUALLY add or subtract the differences on these sideshots, and enter them manually, and they will show as computed values. So, you can work around this too.

Gotta go....

Nate:
Thanks for your replies, what you outlined in the first paragraph was our normal workflow until we started having issues around 6 months ago.

Shawn:
Thank you too for taking a look, on this project I DPOS'ed the base file from the first day and it gave me a new coordinate for the base point, but none of the side shots taken that day showed a shifted coordinate. This is something we've seen before, I don't know what is causing it but that's not how I remember it working in the past.

When I DPOS'ed the base file from the second day, all the side shots from that day showed a shifted coordinate.

The DPOS'ed coordinates for the base from both days are within ~0.1'

I took the average of the two base coordinates and using M-Local, assigned this average coordinate to both bases. When I do this, the side shots from the first day show shifted coordinates, and the solution type changes from AU to ML.

When I inverse between day-1 shots on point #1 and day-2 shots on point #1, I still see ~6.3' of difference. When I look closer at the day-1 shots on point #1, the "manually shifted base station" coordinate is still ~6.3' away from the computed average base coordinate. This appears to only be true for the shots on point #1, other side shots from day-1 show a different "manually shifted base station" coordinate that is close but not the same as the computed average.

The file was too big to attach, here's a drop-box link to the project .zip for anyone who's interested:

Dropbox

www.dropbox.com

 

[ken larson]

Any chance the base and rover lost contact with each other after the first set up?

I have had this happen multiple times and if you just reboot the base and continue on without creating a new base setup it causes data to be shifted.

 

[oajioka]

Any chance the base and rover lost contact with each other after the first set up?

I have had this happen multiple times and if you just reboot the base and continue on without creating a new base setup it causes data to be shifted.

Thanks for your reply, Ken.

We have both the base and the rover set up with a SIM card so we get corrections over the cell network.

While at this project (project .zip above) we noticed the cell coverage was quite spotty. After losing connection and rebooting the rover several times, I ended up putting my phone into hot-spot mode since I have a different cell service provider and had better signal.

Just to be clear, I never rebooted the base only the TLS+ rover. The shots that have the problem were taken early in the day before I switched to the hot-spot.

What do you mean by "reboot the base"? Do you mean you connected to it with the rover, stopped it, then restarted it? Or did you power cycle it off and on?

 

[ken larson]

I use the ls+ and the t3 base and it will slip into ..I can not remember the letters cdf maybe and will not continue without restarting the base and the rover both. This means just reboot Ls and power of power on the base. Because there is a broken connection I can not connect it the base and stop it. When this first started I would just let them power up and the LS would find the base and away I would go... unfortunately the data I would now collect would be shifted. I have to remember to start a new base setup on the prior location of the base before it deep sixed.

Been too long since I have used my phone for a hotspot, but is that a processed position? And your base an autonomous position? Base rover is so much faster I have not had to use my phone in years. Seems like that was back before rtpk and we post processed everything so it all came out in the wash.