Sounds like TOPCON NTRIP is the issue as he didn’t have issue with TPOS NTRIP. Some sort of incorrect vertical offset on TOPCON’s end? Or VRS issue?
1 Like
That’s not the pole… I have multiple poles, the time of the pictures I was trying the 4.5m pole for a job…
Anyway, I’m into this job for too long for a newbie error like that 
2 Likes
TPOS NTRIP service is working fine, today I’ve tried to measure same points and the errors were 2 to 3cm, acceptable.
Switching to TOPCON and I had 18cm Z errors from points collected yesterday with TPOS (that I’m taking as benchmark)… Signal was FIX, PDOP 1.1, 30 satellites. Optimal situation so far.
Looks like every connection with base something goes wrong, because I get different measure every reboot for each points.
Waiting for TOPCON’S assistance 
1 Like
I have no experience with TOPCON, but hear they are terrible? Good luck.
1 Like
I have my topcon’s subscription expiring in march… it was my first year with them, if they can’t fix this issue i’ll change for sure. On the paper they should be on of the best national NTRIP in Italy… Results says the opposite.
1 Like
One other suggestion using your RTN service :
Occupy 4-5 known government passive control marks , all marks should have at least 1st order values for both horizontal and vertical. Document your rod height and stations occupied with pictures and the official data sheets. Make sure all the control marks are in the same datum/ projection system.
Observe each station for the same length of time along with your raw data logs. A good check would be to PP the files against nearby CORS (<20km) if available. If there’s none available, set a base on one of the known points and log raw data and visit the other control marks using the RTN service. You could then also PP all the rover data against the base point. I would suggest a minimum observation time of 25 minutes for all the rover stations.
PP this data in either Emlid Studio or a commercial PP software; I would suggest the latter.
This process would definitely determine what’s going on
3 Likes
Little update, this morning:
measured some same points… TPOS ntrip perfect as usual:
Tpos measured point over TPOS points
TOPCON was completely out of mind this morning:
Topcon’s measurement over TPOS point
After a reboot it hardly got the fix from float (maybe mainteinance?), and then i had same errors as previous days…
I tried NET_MSM5, RTK_MSM5 mountpoints, then the RTK_RTCM3 but i couldn’t get a FIX, only float.
I can definitely assume is TOPCON’s issue.
3 Likes
Hi everyone, i’d like to share the Emlid’s engineer Ruth, she looked after my data and got the conclusion TOPNET’s ntrip is the issue. This was a false FIX, like answered as first reply in this topic.
I copy the detailed answer she gave me. Thank you Ruth!
QUOTE:
"I checked the files and post-processed the data. With the correction data from TPOS, I got a fix using the default settings in Emlid Studio.
Meanwhile, I need to use extreme Emlid Studio settings with the TOPCON correction data to achieve a fix (elevation mask: 30, SNR L2:40, GPS+GLONASS only, Combined Filter type, Continuous for GPS, On for GLONASS, and Off for BDS for the Integer Ambiguity Resolution).
Otherwise, with the default settings, I would only get a Float.
I also downloaded a RINEX file from this website and used the ROVE base data to check if the issue was with the TOPCON data. I got a fix with the default settings in Emlid Studio using the obs file from the said station.
With this, it is safe to conclude that the issue is with the TOPCON correction data. I read in the Community Forum that you’re already in contact with TOPCON regarding this. I suggest using the TPOS NTRIP service for now to avoid getting high survey errors."
7 Likes
Hi everyone, last update.
From Topcon’s assistance COMPLETE SILENCE, and for me is unacceptable. I’ve been waiting for their answer for 1 week, and after my first super detailed email of the issue (attaching even Ruth’s detailed analysis), the only thing they’ve replied me is “did you try to change mountpoint?”
Anyway, i’ve contacted Hexagon for their NTRIP service, the Full GNSS with multi constellation, i’ve ask them a trial account to test, they give me a 1 day test account.
This morning i’ve tried the HEXAGON Ntrip and is working properly. Repeatability is optimal, with less than 1cm difference between same points measurements (after full reboot of the rover), and the difference between our local Ntrip TPOS is about 2cm over the same 10 points.
Seems far better than topcon, fast fix solution and good precision. I’ve tried another time this afternoon, i had 5mm difference in heights.
For me is a great OK!
5 Likes
Well, there you go.
Really makes one wonder how incorrect things are as I notice a LOT of construction companies use TOPCON equipment and services. Hear they have the worst support.
3 Likes
Each RTN has its strengths and weaknesses. For me in Ontario, Canada Topcon presents the following “pro’s:”
-one of the cheapest prices for access
-cheap access to station RINEX files for static base lines
-wide coverage.
Its “con’s” include:
-many stations are non-compliant. See this link:
https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/data-donnees/rtk.php
Select Topcon on the left and note how many stations are yellow or red
-they do not provide an equivalent to IMAX (ie. they have VRS and single equivalents)
I have used Can-net, Topnet, and Smartnet and they all have their pluses and minuses. If repeatability is a major concern, I would offer the following thoughts:
-use multiple shots throughout the day. I use SurvPC and it has a GNSS Analysis routine to average shots. I have included some snippets of one of my jobs to illustrate below. All of these were done off the Cansel Can-net RTN using a VRS RTK base in an urban/residential setting with leafless deciduous winter trees:
Project : 240216GNSS(240011)
Instrument(s) : Carlson, BRx7, Antenna Type: [BRX7 Internal]
Firmware :
Measurement method :
Software version : SurvPC Version 6.16-6.16; Analysis DLL 2016, ver 2.0, August 01
Coordinate system/Datum : CANADA/NAD83/UTM zone 17N
Height system : Orthometric
Geoid model : Canadian_ht2_0.gsb N41°01'00.0" W141°58'59.0" N83°58'58.0" W048°01'03.0"
Observation period : 24/02/16 16:30:08 - 24/02/16 21:55:53
Documentation date : 24/02/16 17:15:18
GNSSANALYSIS - LEAST SQUARE ADJUSTMENTS AND RELIABILITY ANALYSIS
------------------------------------------------------------------------------------------------------------------------------------
PointID: 600
Code: CC
Description: CC
Blunder detection CHI-Square test:
-Hmax_MDB= 0.034, Max value at obs 1
-Vmax_MDB= -0.041, Max value at obs 5
Antenna Freehand: on
Obs North East Height Anth Status rH rV MDBH MDBV RMS PDOP #Sat Date Time Delay
1 4758819.395 482287.606 249.386 1.870 FIXED 0.032 0.025 0.034 -0.027 0.020 1.069 29 24/02/16 16:30:08 ---
2 4758819.382 482287.576 249.383 1.870 FIXED 0.005 0.029 0.005 -0.030 0.023 1.077 28 24/02/16 16:37:34 00:07:26
3 4758819.381 482287.579 249.390 1.870 FIXED 0.003 0.022 0.003 -0.023 0.021 1.044 29 24/02/16 16:37:56 00:00:22
4 4758819.373 482287.574 249.392 1.870 FIXED 0.007 0.020 0.007 -0.021 0.023 1.083 28 24/02/16 16:38:19 00:00:23
5 4758819.378 482287.569 249.372 1.870 FIXED 0.010 0.039 0.010 -0.041 0.028 1.086 27 24/02/16 16:38:46 00:00:27
6 4758819.371 482287.578 249.408 1.870 FIXED 0.008 0.003 0.008 -0.003 0.022 1.073 30 24/02/16 16:39:09 00:00:23
7 4758819.371 482287.575 249.416 1.870 FIXED 0.008 -0.005 0.008 0.005 0.021 1.080 30 24/02/16 16:39:32 00:00:23
8 4758819.371 482287.583 249.411 1.870 FIXED 0.008 0.000 0.008 0.000 0.032 1.486 29 24/02/16 16:39:54 00:00:22
9 4758819.371 482287.575 249.427 1.870 FIXED 0.008 -0.016 0.009 0.017 0.023 1.118 29 24/02/16 16:40:17 00:00:23
10 4758819.367 482287.579 249.427 1.870 FIXED 0.011 -0.016 0.011 0.017 0.022 1.010 29 24/02/16 16:40:42 00:00:25
11 4758819.368 482287.580 249.428 1.870 FIXED 0.010 -0.016 0.010 0.017 0.021 0.999 29 24/02/16 16:41:04 00:00:22
12 4758819.372 482287.579 249.418 1.870 FIXED 0.006 -0.006 0.007 0.006 0.024 1.161 29 24/02/16 16:41:25 00:00:21
13 4758819.388 482287.598 249.427 1.870 FIXED 0.022 -0.015 0.022 0.016 0.047 1.301 28 24/02/16 16:41:48 00:00:23
14 4758819.384 482287.578 249.417 1.870 FIXED 0.006 -0.005 0.006 0.006 0.025 1.074 27 24/02/16 16:44:59 00:03:11
15 4758819.383 482287.577 249.426 1.870 FIXED 0.006 -0.014 0.006 0.015 0.022 1.041 28 24/02/16 16:45:22 00:00:23
16 4758819.375 482287.577 249.443 1.870 FIXED 0.004 -0.032 0.004 0.033 0.025 1.008 28 24/02/16 16:45:46 00:00:24
17 4758819.383 482287.572 249.416 1.870 FIXED 0.008 -0.005 0.009 0.005 0.021 1.000 28 24/02/16 16:46:09 00:00:23
18 4758819.385 482287.573 249.420 1.870 FIXED 0.009 -0.009 0.010 0.010 0.021 1.018 29 24/02/16 16:46:33 00:00:24
19 4758819.388 482287.576 249.423 1.870 FIXED 0.010 -0.011 0.010 0.012 0.024 0.982 30 24/02/16 16:46:56 00:00:23
Least Square Adjustment and External Reliability -----------------------------------------------------------------------------------
PointID North East Height #m sH sV ExH ExV Status TimeDelay QRank Prob
600 4758819.378 482287.579 249.411 19 0.005 0.005 0.016 0.014 FIXED 00:16:48 1 1:100000000 (10cm)
PointID: 601
Code: CC
Description: CC
Blunder detection CHI-Square test:
-Hmax_MDB= 0.033, Max value at obs 6
-Vmax_MDB= 0.022, Max value at obs 6
Antenna Freehand: on
Obs North East Height Anth Status rH rV MDBH MDBV RMS PDOP #Sat Date Time Delay
1 4758830.485 482284.757 249.477 1.870 FIXED 0.008 0.011 0.009 -0.014 0.020 1.076 29 24/02/16 16:31:21 ---
2 4758830.497 482284.749 249.481 2.070 FIXED 0.007 0.008 0.008 -0.009 0.024 1.103 21 24/02/16 21:48:05 05:16:44
3 4758830.492 482284.747 249.483 2.070 FIXED 0.005 0.006 0.006 -0.007 0.020 1.060 21 24/02/16 21:48:21 00:00:16
4 4758830.494 482284.746 249.494 2.070 FIXED 0.007 -0.005 0.008 0.005 0.021 1.187 20 24/02/16 21:48:38 00:00:17
5 4758830.495 482284.762 249.510 2.070 FIXED 0.011 -0.021 0.012 0.022 0.039 1.149 21 24/02/16 21:48:53 00:00:15
6 4758830.496 482284.782 249.510 2.070 FIXED 0.031 -0.021 0.033 0.022 0.049 1.149 21 24/02/16 21:49:03 00:00:10
7 4758830.489 482284.746 249.500 2.070 FIXED 0.006 -0.011 0.007 0.011 0.034 1.174 21 24/02/16 21:49:33 00:00:30
8 4758830.487 482284.746 249.493 2.070 FIXED 0.006 -0.004 0.007 0.005 0.018 1.335 21 24/02/16 21:49:48 00:00:15
9 4758830.486 482284.747 249.488 2.070 FIXED 0.007 0.001 0.008 -0.001 0.019 1.165 20 24/02/16 21:50:05 00:00:17
Least Square Adjustment and External Reliability -----------------------------------------------------------------------------------
PointID North East Height #m sH sV ExH ExV Status TimeDelay QRank Prob
601 4758830.491 482284.752 249.489 9 0.008 0.007 0.024 0.021 FIXED 05:18:44 1 1:300000000 (10cm)
RELIABILITY
---------------------------------------------------------------------------------------------------------------------------
Reliability refers to the controllability of observations, that is, the ability to detect blunders and to
estimate the effects that undetected blunders may have on a solution.
Internal Reliability
-Capability of a system to detect a blunder (depends on number of redundant observations).
External Reliability
-Impact of an undetected blunder on the coordinates.
PARAMETERS GNSSANALYSIS
---------------------------------------------------------------------------------------------------------------------------
Method: Single Point Adjustment
A Priori Standard Deviation = 1.000
Horisontal blunder detection:
CHI-Square single tail test: tabel value 23.0259, degrees of freedom=2, CHI-significance: 99.999%
Vertical blunder detection:
Normal distribution two tail test: table value ±4.4172, QN-significance: 99.999%
equivalent
CHI-Square single tail test: table value 19.511, degrees of freedom=1
The "Antenna Freehand" setting will impact the least squares adjustment in terms of expected errors.
If "Antenna Freehand" is enabled in the blunder detection, accepted errors from a potentially moving antenna will be larger.
ABBREVATIONS
---------------------------------------------------------------------------------------------------------------------------
*** : Significant outlier; observation removed
** : Significant blunder ground coordinates; observation removed
* : Significant blunder height; height observation removed
ExH : External Reliability - ground coordinates
ExV : External Reliability - height
MDBH : Marginally Detectable Blunder(MDB) of observation - ground coordinates
MDBV : Marginally Detectable Blunder(MDB) of observation - height
Hmax_MDB : Maximum Marginal Detectable Blunder(MDB) ground coordinates
Vmax_MDB : Maximum Marginal Detectable Blunder(MDB) height
rH : Adjustment residual ground coordinates (adjusted parameters-observed )// rH=sqrt((Nadj-Nobs)^2+(Eadj-Eobs)^2)
rV : Adjustment residual height (adjusted parameters-observed ) // rV=Hadj-Hobs
sH : Standard deviation ground coordinates
sV : Standard deviation height
TimeDelay : Time delay between first and last observation included in the solution
QRank : Quality of the adjusted solution is classified as follows:
1 ExHmax <10 cm - probability for wrong classification less than 1 to 3.000.000
3b ExHmax 10-50 cm - - " - 1 to 3.000.000
- ExHmax >50 cm
x External reliability inaccessible (mainly because probability for wrong-classification exceeds 1 to 3.000.000)
Prob : Reciproce likelihood for adjusted coordinates exceeding the limit (10cm or 50cm) - ground coordinates only. Average
PDOP-value (quality) and number of measurements have impact on the judgements. Only FIX-observations included in the
solution counts. External reliability may also be inavailable due to lack of delay and/or poor distributed readings in
time. Judgements based on a dataset containing 113.000.000 logged FIX'es covering a timespan on 16 months.
We have had good repeatability as long as we have values of ExH ExV that are acceptable. We use this routine for cadastral markers, checking into municipal benchmarks, and setting project control. Point 600 was my ground scale point and where I planned to set up my base (side note–we actually didn’t for this job) which leads to my next point
-it may be beneficial to set up a local rtk base. We, often, want a “tight” vertical on our projects so we we will set a control point off the Can-net network, set a check point ~20m away, and set another control point ~250m away. This allows for a quick check point upon base setup and another further away if/when we scale the project to ground coordinates.
-if you set up a local rtk base, log RINEX on it. This will allow you to do a PPP check and/or static baseline check.
We have had vertical variances off a VRS RTN that vary +/-3" which is unacceptable for us. Additional checks may seem a hassle, but they can save a project. Only you know the required precision for your job and whether the extra 30 minutes you spend on checks is worth it. For us, it is.
4 Likes
So that is a report for one point (observation) ? If so, that’s pretty cool !
Javad J-Field also has a great statistical report of each observed point:
As I have said before, this is exactly what Emlid needs for the user to have confidence in their measurement !
Emlid are you looking ?
4 Likes
Yes, I snipped out just two points from the report (point numbers 600 and 601). The Carlson report is rather basic, but it is good enough for our purposes. The main reason we like it is that it is calculated “on the fly.” Javad has a multitude of other options that we are envious of, but we work with “Chevrolet” equipment and not “Ferrari” equipment. We have budgets and if it “gets us there,” we are good with that.
The new version of SurvPC has some fancier options, which would be nice, but 6 seems to do for us.
It seems similar to the Javad reports, but they still do not have the option to do Javad’s Hybrid or RTPK:
https://www.javad.com/jgnss/javad/news/pr20160504.html
Other companies do have something similar. For example, Trimble has their Business Centre where you can create reports. Please note that I think you have to run the adjustment in TBC (ie. not in real time), which the TBC license is yet another additional cost, but it has been a while since I ran Charlie Trimble’s equipment:
https://community.trimble.com/blogs/riley-smith1/2020/11/18/tip-of-the-week-19-investigating-data-with-point-derivation-reports
I imagine Leica and Topcon have something similar.
The early versions of SurvCE did an RTK average by simply doing a mean average of the coordinates. This would be a welcome addition for users of Emlid software. The other options are nice, but they cost quite a bit more. Simply average coordinates would be something relatively easy to implement.
5 Likes
Yes, we have the RTPK in both of our Triumph LS and LS+. It’s pretty cool to process your baselines when you are also using RTK via radio. It’s a great check on your observed point as well as the other methods Javad has developed.
We do a lot of big boundaries with the Triumphs, they have paid for themselves because of the accuracy and time it has saved. Using them literally saves us half the time it would have previously taken. They are truly “scientific” receivers in that it analyzes the GNSS signals and solved ambiguities for a set of observations. There’s a big learning curve but the basics can be learned fairly quickly. Javad was a great signal analyzer.
Emlid could do the basics that we are discussing, they need to make this a priority in Emlid Flow.
3 Likes
I dunno… seems Emlid needs to decide if they also want to bring in the manpower to be a full-fledge survey-grade software developer like Microsurvey, Carlson Software, etc. They have been established for quite some time. Or just concentrate on their great hardware at a fair price, but with advanced features as you mention? Or BOTH?
I know they are doing their best, but seems to me they must be short on developers as the rate of feature implementation is rather slow and a very long and growing “road map”. Especially compared to the likes of Trimble and Leica’s software / hardware solutions.
2 Likes
It’s definitely a “fork in the road moment” for Emlid, I would say. They make fantastic hardware and pretty good software at a very good price point. My issue would be the lack of total station support. That’s a huuuuuuge step up in commitment. For many, lack of total station support is not an issue. As long as Field Genius supports them, they have that fallback.
Personally, I am good with their current offerings (ie. hardware, software, support, etc.). I have an RS2 that I am very satisfied with. I have not bought the RSX or RS3 as it is not enough of a “leap” for me, but if they included a camera like some of these offerings, I would:
CHC i93/i83 or igage i89/i93
https://www.igage.com/VisualSurvey/vs.htm
Satlab Eyr
Javad Triumph-LS
https://www.javad.com/jgnss/javad/news/pr20141208.html
Hi-Target vRTK
I am more interested in the “measuring” camera than I am the “stakeout” camera like in this one:
Gintec G40
I believe Emlid has a golden opportunity to provide an all-in-one solution where:
-they have an RTK antenna with non-magnetic tilt (ie. RS3)
-they have PPK/RTK addons for drones (ie. M2)
-they have Android data collection (ie. Flow)
-they have office software (ie. Studio)
If they updated the RS3 to have the camera (ie. RS4?), they would have a very powerful combo. The “low hanging” fruit for Emlid, IMO, going forward is:
-add camera to RS3. It does not need to have the stake camera or even the ability to create points in Flow. It just needs to take a 5mp to 12mp picture with an RTK stamped coordinate.
-be able to recoordinate those pictures in Studio.
-they can either work out a deal with OpenDroneMap where they “reskin” WebODM Lightning to an Emlid version with a percentage added or just create a process where the pics get uploaded to https://webodm.net/
The “RS4” plus the drone data would be a very powerful combo with not much addition R&D on their end. Another easy product to put out with minimal R&D would be PPK ground control points like these:
Propellor Aeropoints
They already have the “guts” for the target; they would just need to make the target. I know I would purchase an RS4, PPK GCP’s, and Flow if they offered all that.
But circling back to the original question, another option to check on points is to do 1 of the follwoing:
-
Set 3 points in a circle. Take a total station and set in the middle of said points. Perform a resection. If the residuals exceed acceptable, you need to take additional shots with RTK or begin traversing if the cover is poor (ie. under canopy).
-
If you do not have a total station, do the checks with a tape measure. If the +/- is not acceptable, you may need to average more shots or use additional equipment.
3 Likes
Hello, everyone.
Short analysis of TOPCON-2 case:
1 ) Let’s check RTCM3 corrections by WAY service
Well, it is MSM5 GPS+GLO+BGAL+BDS. Availability of 1032 message and DF141 flag raised in 1006 point on VRS Network corrections.
Nearest Physical station is located in Trento, about 16 km away from virtual base station:
Minimal RTCM3 health check reports no any obvious issues:
Satellites availability is limited but probably it is ok for mountain area:
Max and Mean SNR on base are more than fine:
2 ) After that, UBX file from rover and RTCM3 file from base were converted to RINEX by RTools
3 ) Next, these RINEX files were processed by Topaz post-processing:
It gives 100% FIX even w/ default settings.
If RTCM3 file from Reach_20240202143209-TPOS-2 case is checked, than:
- It is VRS as well (according to 1032 and VRS flag in 1006)
- Receiver is LEICA
- Legacy RTCM3.1 (1004, 1012) inside, i.e. no BDS, GAL etc
- However, what is interesting - virtual station coordinates are equal to nearest physical. Probably it is not VRS but just standard RTK corrections were provided
