RTK++

Nistorescu Sorin

Active Member
Hi friends,

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.

Regards,

PS: this topic should be moved at "Justin forum".
 

Attachments

  • DSCF7256.JPG
    DSCF7256.JPG
    942.7 KB · Views: 560
  • DSCF7258.JPG
    DSCF7258.JPG
    948.7 KB · Views: 567

Nistorescu Sorin

Active Member
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.
 

Shawn Billings

Shawn Billings
5PLS
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.
 

Nistorescu Sorin

Active Member
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:

OneWeb user terminal.png

https://www.oneweb.world/technology#keyshot-module
(tap USER TERMINAL)
User terminal will vary in size, but I can imagine at least a ATV/backpack configuration with Wi-Fi coverage directly to an external GNSS receiver.

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.
 

Nistorescu Sorin

Active Member
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.

4-Element Array Antenna.png 7-Element Array Antenna.png

Array antenna tripod mounted.png


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.
 

Bryan Enfinger

Active Member
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.

Great software.
 

Bryan Enfinger

Active Member
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 !!
 

Attachments

  • JUSTIN V3 DPOS Report 100620.pdf
    181.8 KB · Views: 357

Bryan Enfinger

Active Member
I also like the fix ratio on the screen for the baselines and the single solution report
 

Attachments

  • JUSTIN V3 SS Report 100620.pdf
    180.6 KB · Views: 325
  • JV3 1.PNG
    JV3 1.PNG
    656.8 KB · Views: 350

Bryan Enfinger

Active Member
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.
 

Nistorescu Sorin

Active Member
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?
Thanks.
 

Nistorescu Sorin

Active Member
At some point, RTPK loop closure could be possible with a (foldable) configuration like this:

GNSS RTK_optical_loop closure RTPK system.png


A software/hardware solution with automatic triangle loop(s) closure analysis could raise the bar for high level confidence right in the field. I think all RTK/optical accessories could work together with RTPK
 

Nistorescu Sorin

Active Member
Array antenna configuration is a step forward for a GNSS receiver in terms of robust PVT: improved availability, multipath mitigation, better accuracy, RF interferences, etc. All tests/innovations from the last decade clearly demonstrated superior performance in a side-by-side comparison between "array" vs single element antenna GNSS receiver:

Multipath 1element antenna.png
Multipath 4element antenna.png


Justin multi constellation RTPK is a great solution compared with simple RTK, it works with single element antenna GNSS receiver, could provide loop closure calculations with dual antenna configuration/single block GNSS receiver, but I think that an "array" will open the path for a more confident surveying solution with multiple loops and probably with beamforming, which was already used by military, now used by some critical infrastructures, long awaited by civilians (more easy to have one in Europe, subject to Controlled Goods Program in Canada and ITAR regulated in the US).

Single antenna.png
Beamforming.png
 
Top