A discussion concerning GNSS and latency has been going around our office. A definition for latency as it relates to GNSS is as follows.
The delay of the received satellite signal data and correction information at the base, sent to the rover for computing correction values.
One particular area of town is especially annoying in regard to maintaining a fixed solution. My Topcon HiPer SR RTK rover uses a network solution. Recently, I had 15 satellites, PDOP was around 1.5, and a base station was around 3 miles away. Initially, I was autonomous for about 5 minutes. Minimal multipath and a large oak tree in 1 quadrant, about 20 feet from me. As I proceeded down the street centerline, marking ROW offset points, I experienced updated corrections from the base station several times, went to float several times, and was about to lose connection 1 time. There were no large trees close to me at those times.
It has been suggested that the network card in our Topcon FC-5000, running Topcon MAGNET Field, needs to be replaced. Our AT&T modem was replaced about a year ago, I think, with a newer one. Opinions as to a solution for correcting my latency problem, please.
It may be a network capacity issue. Data carriers prioritize the network usage as emergency 1st, voice 2nd and data 3rd. Could there be a lot of network traffic in that part of town? It may throttle your data performance and delay your corrections. Any delay in corrections may either drop or delay your initialization.
Is there an airport nearby? I’ve worked near one and struggled with initialization and keeping it due to incoming/outgoing planes.
KT 88 has hit on both issues. One the cell provider in which you are getting corrections to the rover. The other is the rtk network itself. I assume its semi permanent stations located throughout your areas you work. So if you are in a area where a base station is and it has to stream that raw information to a server so the software can compute and then send out the corrections via a ntrip caster or whatever. The internet connection from the base to the software can have latency as well. I saw this when I operated a VRS network. Some of our stations where located in very rural areas and we would see those base stations having latency feeding the software at times. One of my memories was of a station in a very built up area. Clients would have issues with at a certain time of day. What we finally nailed it down to was kids were out of school and cell latencies increased and so did our line from the station itself to server during that peak time when everyone wast texting calling friends and gaming after school from home. My solution is to use the network to get on datum and then go base and rover via radio on site. You will know doubt see better relative positioning and less battling the air waves.
Food for thought 1 NANO second of error from gps satellites is almost a foot on the ground about.8 ft. 1 second of error in gps satellite error from space on the ground and airplane’s miss by enough to cause harm. When the leap second goes in to adjust you have a few folks sitting at the computers and many more with letters by there names watching and you could hear a mouse fart. Now thats not a joke. No one breathes as it is a hairy sticky situation. And it has been wrong and thank goodness no harm came. Its so crucial it’s prepared for about a year. Now for us latency causes us to buy some concrete and such. For setting control and some topo network rtk is fine as you know with control you have some redundant observations. Location of paint for underground utility is great. If i do something network rtk only. I establish a check on random points throughout what i am mapping. Not just the control. But back of curb and other important points as I don’t like being wrong or someone else calling and saying we miss this by x.
Opinions as to a solution for correcting my latency problem, please.
As others have pointed out, it's not always something that you can control.
You are constrained by the local cell service conditions, the available broadcast formats (set by your RTN operator), and your rover options.
While in theory cell corrections are supposedly lower latency than UHF radio, in practice I have found the reverse to be true, even in the denser urban areas that supposedly have good cell coverage - most likely because they also see a much higher volume of users.
RTNs have to crunch the numbers from multiple stations at a central server plus send out corrections - a single base station right nearby running a UHF radio will usually be faster. But then you might run into problems near airports, military installations, or even ham radio operators.
Personally, I'd have the base-rover option as a backup. But if your outfit is like mine, two receivers for a two-person crew is "overkill" in areas where RTN is available...running two network rovers at the same time (or one rover and the robotic TS) is frowned upon.
Is there an airport nearby?
No, but there is an ER.
I assume its semi permanent stations located throughout your areas you work.
We use what our GNSS network provider describes as:
1. A multi base dual constellation solution (Network RTK) expressed NRTK has been implemented.
• Advantages are fixed solutions with centimeter accuracies in extremely rural areas where other RTN services struggle to acquire or maintain fixed positions
• Extremely rapid precise ambiguity fixes with redundant horizontal and vertical accuracy
• Guaranteed unmatched fixed position and production time
• We now have freedom to tie rovers who are operating on specific NGVD or other datum to a specified NRTKRS (Network RTK Reference Station)
2. The Entire Network reference frame has been updated to NAD 83 (NSRS 2007) & NAVD 88 datum.
• Horizontal accuracies to 0.04; Vertical accuracies to 0.07
• Works seamlessly within our L-Net network, FDOT, and CORS datum with proven better vertical consistencies
• All collection software checks live to NGS NAD 83 (NSRS2007) NAVD 88 adjusted monument within hundredths
3. NRTK-RS (Network RTK Reference Stations).
• All stations have the latest Topcon GNSS software engine.
• Support for all messaging formats including DGPS.
• Extremely clean static data with reliable 24/7 accessibility through our ftp site.
• Remote upgrade and Satellite analysis capabilities.
• GNSS antennas to accompany all stations.
@rover83 Thats what i am pushing for. Have a base rover and extra dc. Now two guys with rovers on a network or one with rover network or base rover and other with robot. But thats in a dream world as i don’t even have a second man half the time unfortunately. I double up my crew chiefs in safety related jobs because not having a i man or extra person. Had to send a laborer out just for a safety person on a site as I needed someone to call or drag my chief off the mountain. He was from another department and was like this surveying thing is hard to much walking. Lol.
