In my opinion Justin looks good even on a cheap 7'' tablet (sorry for the quality of photos).
Among other capabilities it configures the rover for RTK++ and process static data using RTCM 3.0 messages with a powerful engine in real time. Works with static IP address.
Adding two Triumph-2 receivers with raw data only (one in the field and other to the office or two in the field) and I expect that the system can do the work.
Maximum rms in position SX, SY, SZ (ex: 0.010m) and the time in minutes (3min), during which the information is accumulated for solutions can be set.
Coordinate computation is carried out in a “reverse RTK” mode of operation. This involve some quality assurance aspects of server-based RTK processing.
I wonder if it can be an alternative (or competitor) to the classical base-rover/NTRIP RTK system.
RTK++ is a powerful function from inside Justin. Processing static data using RTCM 3 messages from the base, through "relay service" will work in the field, I think. Just need a RTK/RTK++ comparison screen at the rover. Also multi-base static data processing will be possible.
That is fantastic. As you say, multi-base processing opens up a lot of possibilities. It's like server based processing except that the server is with you.
I suppose it could be done in a way that the incoming raw data and rover raw data could be processed again and again until enough data is acquired to get a reliable fixed solution. In most cases we collect much more than we need when performing static observations to insure we will not need to return due not enough data. However, in this regard, perhaps a scheme could be in place that we keep collecting, Justin keeps processing until accuracy and quality is achieved.
Last month, a Russian Soyuz ST-B rocket has launched from the French Guiana space base in Kourou carrying the first ever six OneWeb satellites. OneWeb is a planned 648 constellation of satellites providing satellite internet globally. https://www.oneweb.world/newsroom#filter-pressrelease
And a possible OneWeb user terminal. Looks familiar:
This means that Justin will be able to process multi-constellation static data using RTCM 3.x messages from CORS or any other base, right in the field, anywhere in the world. The processing power from the server side could eliminate some actual "tryings to move the processing for the extra constellations to the Linux system instead of the GNSS chip". And the "strategy for dividing the work between the six engines in the most productive way" could be handle by the server with any scenario we want.
Dear friends, I was able to saw the power of 5G network during a live holographic rock concert, here. Now I doubt that a 2.5kg GNSS receiver is the right device for surveying in the field, after 2020. 5G ready network and broadband from space could change everything. I love and respect Javad receivers but right now I think we could better focus for some proof-of-concept demos/videos with Justin multi-signal multi-constellations RTK++ processing engine through a "relay service" in a broadband configuration.
Keeping the LS form factor with some minimal inside interface and server side RTK++ will increase processing power with multi-signals/multi-constellations/limitless channels and will reduce weight/price, also keeping in use a slightly modified J-Field onboard software.
RTPK (RTK++) is a "natural evolution" at Javad GNSS, LS-plus is now some kind of a LINUX computer with on-board processing capabilities (RTPK), but a real computer + office post-processing software (ex: Justin) can perform loop closure analysis between at least three measured vectors.
Today, I believe that RTPK with one miniaturized 4-element antenna array receiver (about 30cm) as a base + single antenna rover, could be more robust in challenging environments, RTPK loop closure analysis could be a great user instrument, simply outperforming RTK/RPTK field comparison.
I think it is a trade-off between expected benefits and increased complexity/costs for such base-rover antenna array RTPK/RTK GNSS sistem with near real-time loop closure calculations right in the field.
Justin is a great processor, better than anything I've used in the past including "T's" software. I've been using a lot lately testing and learning.... Even a 3 minute observation in high multi-path areas using T2 with updated GNSS on short baselines (<1km) results in <2cm accuracy in both horizontal and vertical.
Wow ! Jusin 3 is cool ! It seems more streamlined and faster.... Here's the generated DPOS file from a 6 minute observation in a wooded area with pines and hardwoods processed against 3 CORS. I like the new style of the software.
Thanks Alexey. When I first started using Justin, I went through the manual and honestly I was a little lost. It explained all the many features, but was lacking in actually how to use it. I just started fumbling around and it became pretty intuitive once something was completed via a function.
My advice to new users, is to have a known point for the observation data you are PP in the software.
For many reasons the T2-RTK with GAL/BDS - E1/B1 enabled, will not improve the RTK solution.
Could Justin make any difference using T2 with all (GPS/GLO L1+L2 and GAL/BDS E1/B1) constellations enabled? Would it E1/B1 be a benefit with RPTK more than in classic RTK?