Darren Clemons
Well-Known Member
I didn't use the pre release version of Jfield as much as I usually do this last update that was, for the most part, a lot of changes in the way rtpk operates.
All comments below are from using T3/LS+ with all 4 constellations.
We've only been using it for a couple weeks now and there are definitely a lot of good improvements, but some that are, I guess, just going to take some getting used to. It certainly "works differently" than what we were used to.
Best of all the improvements is just the overall speed of processing the results has diminished dramatically. Solution #1 after 120 seconds comes back in about 10 seconds compared to probably 35-45 seconds previously, with each increasing solution also completing faster - IF we get a solution.
We work in a lot of very challenging environments and have always pushed this equipment as far as it will go. With our updates to a T3 and an LS+, there aren't many places we don't get very good, reliable, matching rtk shots - when the leaves are off. But, in the summer months, will full leaf coverage it's a bit of a different story. This is where the rtpk addition has made the most difference - getting "those shots" where we can't/don't necessarily get much, if any, rtk at all.
Before the last update, we probably only saw an rtpk result say "float" 1 out of 20 times, even in the roughest of spots. Now, that didn't mean every one of the solutions it gave us that said "fixed" were accurate, they still had to be verified with matching data. That is what this last update has tried to accomplish with the (2), (3) that appears next to matching rtpk solutions.
The issue we are having is, we get a solution on the 1st processing (after 120 seconds), but almost any time we're in much coverage, the next several solutions ALL come back saying "no solution for this vector". Only on a couple occasions have we seen it "come back" after the 2nd, 3rd, 4th, etc. solution keeps giving that no solution message. We are seeing this on 90% of ANY points collected in coverage. Is this supposed to be happening that often? Are there any adjustments that could make our LS do this?
Another issue with it doing this is, the data is "taken away" after the 2nd solution fails removing the readings from distance to last or a Pdelta boxes that were using that 1st solution. That solution needs to stay even if the 2nd, 3rd, etc fails to give one....
As I said, maybe this is just us needing to get used to this different way that the rtpk is working and obviously the goal is for it to only give more fixed solutions and not show us float solutions, which we don't need to see anyway.
I have, however, tested ours in several spots and have seen quite a few of the (2) locations, which is supposed to indicate 2 matching rtpk solutions, turn out to be incorrect. I have also saw one that gave me a (3) in the rtpk that turned out to be incorrect as well, so the rule still stands, as it always will, ALL data needs to still be verified and checked in these types of locations.
All comments below are from using T3/LS+ with all 4 constellations.
We've only been using it for a couple weeks now and there are definitely a lot of good improvements, but some that are, I guess, just going to take some getting used to. It certainly "works differently" than what we were used to.
Best of all the improvements is just the overall speed of processing the results has diminished dramatically. Solution #1 after 120 seconds comes back in about 10 seconds compared to probably 35-45 seconds previously, with each increasing solution also completing faster - IF we get a solution.
We work in a lot of very challenging environments and have always pushed this equipment as far as it will go. With our updates to a T3 and an LS+, there aren't many places we don't get very good, reliable, matching rtk shots - when the leaves are off. But, in the summer months, will full leaf coverage it's a bit of a different story. This is where the rtpk addition has made the most difference - getting "those shots" where we can't/don't necessarily get much, if any, rtk at all.
Before the last update, we probably only saw an rtpk result say "float" 1 out of 20 times, even in the roughest of spots. Now, that didn't mean every one of the solutions it gave us that said "fixed" were accurate, they still had to be verified with matching data. That is what this last update has tried to accomplish with the (2), (3) that appears next to matching rtpk solutions.
The issue we are having is, we get a solution on the 1st processing (after 120 seconds), but almost any time we're in much coverage, the next several solutions ALL come back saying "no solution for this vector". Only on a couple occasions have we seen it "come back" after the 2nd, 3rd, 4th, etc. solution keeps giving that no solution message. We are seeing this on 90% of ANY points collected in coverage. Is this supposed to be happening that often? Are there any adjustments that could make our LS do this?
Another issue with it doing this is, the data is "taken away" after the 2nd solution fails removing the readings from distance to last or a Pdelta boxes that were using that 1st solution. That solution needs to stay even if the 2nd, 3rd, etc fails to give one....
As I said, maybe this is just us needing to get used to this different way that the rtpk is working and obviously the goal is for it to only give more fixed solutions and not show us float solutions, which we don't need to see anyway.
I have, however, tested ours in several spots and have seen quite a few of the (2) locations, which is supposed to indicate 2 matching rtpk solutions, turn out to be incorrect. I have also saw one that gave me a (3) in the rtpk that turned out to be incorrect as well, so the rule still stands, as it always will, ALL data needs to still be verified and checked in these types of locations.