If you click on the pushpin icon for a station near you, to open it’s popup, then click the little grey “Info” at the top of popup, it will show you the four digit station code that should correspond with the list you see in SW Maps.
1 Like
That would make sense. I will test this out later with the proper port # and perhaps the list will update and correspond to the towers shown on the WISCORS map. Thanks!
Well, wiscors.dot.wi.gov:2101 returns this mount point table (filtered, removed everything with irrelevant CMR protocol):
All these are “smart” mount points that provide corrections based on the rover’s location (when the rover reports its location to the NTRIP caster correctly).
The “safest” mount point to try is
SingleBase_RTCM31 because it simply acts as an automatic “switch” to send corrections directly from the nearest base station instead of doing any additional “magic.”Otherwise, any failures to obtain a fixed solution are likely due to one of the factors:
- The rover doesn’t recognize RTCM messages specific to a certain protocol.
- The rover doesn’t send its location correctly so the caster can’t send proper data since it doesn’t know the rover’s location.
SW Maps absolutely allows typing in the mount point name by hand on Android, can’t say anything about iOS.
Another port, wiscors.dot.wi.gov:2102 returns a table of individual base stations.
2 Likes
Thats awesome @Bushman_K , I never thought to “try it” from here.
Yeah, that is cool!
By the way, I now have RTK Fix again! Proper port numbers make all the difference. Ha!
2 Likes
My NTRIP Cloud icon is Green, for both Casters that I use, iOS.
But both of Mine are VRS, so maybe that represents baseline length?
There’s nothing really special about reading a mounting point list from a caster if you know the address and port number. RTKlib srctblbrows.exe is a decent tool for that.
However, I should note that the WisDOT’s documentation on this is as typically horrible as of any other DOT-operated network. For instance, there’s this https://wiscorsweb.dot.wi.gov/TrimblePivotWeb/documents/wiscors-faq.pdf but I have no idea what page might be leading to it - I only found it with a web search by “WISCORS NAD83”.
@j_eich18 , by the way, do you realize that the coordinates you are getting from your rover are in NAD83(2011)?
I checked the SW Maps manual, and it says that when the NTRIP button is orange it means that the client is connected, but the age of the differential is high. As a test, I also connected to a mountpoint that is far away (135mi) and the NTRIP icon remained green.
You may have an intermittent connection to the NTRIP server, or maybe the base station you’re receiving data from is unreliable. You should be receiving data about once a second, and you should see that age above the horizontal and vertical error estimates. You can also see it if you tap on the horizontal and vertical readout to get more details.
2 Likes
Interesting! I’ll have to try a different base station and see what happens. I do recall the age differential , station ID and baseline length not populated so that delay in data is likely why the orange color was shown. By the way, thank you for sharing the latest manual. My searches for the manual kept coming up with the old version.
According to the link you provided, the coordinates are closely related to NAD83. And yes, the WI DOT’s documentation is very limited and hard to find. I appreciate the Sparkfun Community and everyone that is willing to collaborate and share ideas and information.
I think that @Bushman_K wanted to bring to your attention that many of these Free State CORS Networks usually broadcast in NAD83-2011, and normally use the 2010 epoch.
These Base Stations are referenced to a snapshot in time 25 years ago. The tectonic plates have been moving all this time 
So are you saying that some base station coordinates may not have been updated in 25 years? It seems to be routine in the surveying world to periodically check into control points and update them semi-routinely - every year or two. And just because they use a dated system doesn’t necessarily mean they are inaccurate or have not been recently updated, does it?
I’m simply saying exactly what these CORS Networks state.
The North American Datum of 1983 (2011) epoch 2010 is a snapshot in time => a frame of reference.
These State networks are impressive for what they accomplish, an adjusted network of control points with published coordinates for a specific reference frame (which includes a date in Time).
The movement vector for a Base station is basically the same for other Control in the broad area, so relative motion is assumed to be zero for the previously adjusted network. The system works Great for what it was meant for - mainly Professional Surveyors.
However, with the other options available today that produce real-time (current epoch) results, comparisons between Today’s actual Coordinates and a 25-year old reference frame obviously won’t match… they aren’t intended to without a time dependant adjustment of the position.
Sorry… I didn’t intend on going down that rabbit hole in this thread
2 Likes
It may be a rabbit hole, but it’s one that folks should think about and study up on. When you have equipment capable of making measurements with precision of fractions of an inch, understanding things like datums, projections, coordinate systems, transformations, and geoids starts to matter really fast if you want those measurements to be repeatable or meaningful to others.
5 Likes
This is great! Thank you for the explanation. It is kind of crazy to think about such precision. I instructed a mapping course for high schoolers and we talked about how latitude was easy to determine and utilize by sailors (& others), but it wasn’t until the invention and production of a reliable clock that longitude could be established. And look at it today!
1 Like
Do you know of good resources on this topic to educate with?
One of the practical implications of what I mentioned is that any data you are going to record and export will have a visible shift when directly overlayed on top of high-resolution (better than 2ft/pixel scale) aerial imagery in SW Maps (because it uses Google Maps satellite/aerial data and those are referenced to respective epochs of WGS84), Google Earth, whatever. The observable discrepancy is around several feet.
So in order to have correct metadata for anything you collect, you’d have to use a data format that includes a specific CRS description, or a “sidecar” projection file. And whatever software or service these files are going to be opened with should be aware of the CRS transformations as well.
That’s because your measurements are going to be referenced from a station that has coordinates in NAD83(2011) while SW Maps doesn’t consider the reference station’s CRS, always assuming it’s WGS84. It’s kind of a major shortcoming, and yet.
1 Like
I would say that having CORS networks referenced to NAD83(2011) in the US isn’t particularly a bad thing for a “civilian” user as well, it just must be correctly understood, data should be handled accordingly, etc.
Otherwise, we see some unfortunate and hard-to-fix errors due to uneducated and yet enthusiastic volunteered work like this:
The red highlighted wireframe is an administrative boundary imported into the OpenStreetMap project database (that uses WGS84) without getting reprojected from NAD83. In the real world, it pretty obviously must match the sound wall along the highway ramp seen at a small but visible distance to the West from its erroneous location.
2 Likes
AMEN.
Your Picture shows a perfect example of an easy fix with the correct .prj file.