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.