I've been using the RTPK application for a few weeks now. The most recent update to Pre-Release has improved the processing speed significantly over previous versions. Here's what I'm seeing:
RTPK at present, requires corrections from your base in real time. This can be a real base or a virtual base, such as from an RTN. As the Triumph-LS works to acquire a real-time position, it also logs raw data at the rover and creates a raw data file for the base using the received corrections. Once the user stops logging a point, the LS immediately begins processing the data similarly to how DPOS processes PPK data, however this is occurring on the Triumph-LS and does not require an internet connection. With multi-constellation data (GPS, Glonass, Galileo, and Beidou) the RTPK solutions have been extremely robust and can often be obtained with only a few minutes in moderate canopy.
My workflow of late, using a Triumph-LS Plus, is to use the Precise Topo profile in all conditions. This profile acquires five individual fixes, then requires at least 2 engines to fix and log for approximately 10 seconds, and then drops the fix and get another minimum 2 engine fix for validation. This profile has proved to be very successful in the Triumph-LS Plus, particularly in medium canopy or lighter. Centerlines of a country road with trees on both sides and building offsets (both of which can be time consuming with the standard LS) have been pretty quick to acquire with this profile and very reliable. In moderate to heavy canopy, this profile can get bogged down waiting for those 2 engine fixes. So after a couple of minutes, I will manually stop logging, which immediately begins the RTPK process. Within seconds, I have a post processed solution that I can compare with the RTK position. If the two agree, I have found the solution to be very reliable, alleviating the need for me to wait for the 2nd and/or 3rd phase to complete. Many points that would have taken 20+ minutes in the field, I am now collecting in 2-5 minutes with this method... with confidence. If RTK and RTPK don't agree with each other (and I manually stopped the point collection) I can tap the "resume" button and continue logging data. The raw data is added to the existing raw data file and I can stop and process again to see if I can get a better RTK position to match the RTPK or a better RTPK position to match the RTK. This aspect is really impressive. There are few times that the observations do not agree, and slightly more often the RTPK is correct and the RTK is wrong, but sometimes the opposite is true (I would estimate 60% RTPK vs. 40% RTK).
Last week, I was using corrections broadcast over TCP instead of UHF (as I normally work). My project was five miles from the base. I was getting good positions on road centerlines with trees on both sides of the road and sky overhead, with only 20 second observations.
Ultimately, I believe RTPK will change the way we verify RTK in the field. You'll be able to navigate to points in real-time using RTK, but when it's time to get store a reliable, refined position, you'll look to RTPK to prove the position, possibly even opting for the RTPK position over the RTK position once they've proved out.
RTPK is a brand new feature and it is already incredible. No doubt we'll develop it to perform many more tasks in the future.
It's quite possible that it could help GPS and Glonass only users, obviously not with the same power as those with multi-constellation. I highly recommend, at a minimum, acquiring a Javad base that can transmit multi-signal messages or upgrade your Javad base to support all four constellations. This will allow you to feed RTPK with the necessary data to provide these incredible solutions in poor locations. For a limited time, RTPK is available on the Pre-Release version of J-Field. This is a great time to try it out and see what the difference is. The price being floated for RTPK (without insulting our business department) is crazy low for what it can do. Get ready, Javad is about to turn the precision GNSS world on its head again.
RTPK at present, requires corrections from your base in real time. This can be a real base or a virtual base, such as from an RTN. As the Triumph-LS works to acquire a real-time position, it also logs raw data at the rover and creates a raw data file for the base using the received corrections. Once the user stops logging a point, the LS immediately begins processing the data similarly to how DPOS processes PPK data, however this is occurring on the Triumph-LS and does not require an internet connection. With multi-constellation data (GPS, Glonass, Galileo, and Beidou) the RTPK solutions have been extremely robust and can often be obtained with only a few minutes in moderate canopy.
My workflow of late, using a Triumph-LS Plus, is to use the Precise Topo profile in all conditions. This profile acquires five individual fixes, then requires at least 2 engines to fix and log for approximately 10 seconds, and then drops the fix and get another minimum 2 engine fix for validation. This profile has proved to be very successful in the Triumph-LS Plus, particularly in medium canopy or lighter. Centerlines of a country road with trees on both sides and building offsets (both of which can be time consuming with the standard LS) have been pretty quick to acquire with this profile and very reliable. In moderate to heavy canopy, this profile can get bogged down waiting for those 2 engine fixes. So after a couple of minutes, I will manually stop logging, which immediately begins the RTPK process. Within seconds, I have a post processed solution that I can compare with the RTK position. If the two agree, I have found the solution to be very reliable, alleviating the need for me to wait for the 2nd and/or 3rd phase to complete. Many points that would have taken 20+ minutes in the field, I am now collecting in 2-5 minutes with this method... with confidence. If RTK and RTPK don't agree with each other (and I manually stopped the point collection) I can tap the "resume" button and continue logging data. The raw data is added to the existing raw data file and I can stop and process again to see if I can get a better RTK position to match the RTPK or a better RTPK position to match the RTK. This aspect is really impressive. There are few times that the observations do not agree, and slightly more often the RTPK is correct and the RTK is wrong, but sometimes the opposite is true (I would estimate 60% RTPK vs. 40% RTK).
Last week, I was using corrections broadcast over TCP instead of UHF (as I normally work). My project was five miles from the base. I was getting good positions on road centerlines with trees on both sides of the road and sky overhead, with only 20 second observations.
Ultimately, I believe RTPK will change the way we verify RTK in the field. You'll be able to navigate to points in real-time using RTK, but when it's time to get store a reliable, refined position, you'll look to RTPK to prove the position, possibly even opting for the RTPK position over the RTK position once they've proved out.
RTPK is a brand new feature and it is already incredible. No doubt we'll develop it to perform many more tasks in the future.
It's quite possible that it could help GPS and Glonass only users, obviously not with the same power as those with multi-constellation. I highly recommend, at a minimum, acquiring a Javad base that can transmit multi-signal messages or upgrade your Javad base to support all four constellations. This will allow you to feed RTPK with the necessary data to provide these incredible solutions in poor locations. For a limited time, RTPK is available on the Pre-Release version of J-Field. This is a great time to try it out and see what the difference is. The price being floated for RTPK (without insulting our business department) is crazy low for what it can do. Get ready, Javad is about to turn the precision GNSS world on its head again.