California reaL time network
Since November 2018, I've had a near impossible time logging in, or staying connected to the CRTN using an ATT hotspot with a Carlson system latest SurvCE THE system indicates receiving corrections, yet the DC shows autonomous. The DC also flashes to a "reconnecting" screen, then connected , then receiving corrections but remains autonomous. I've even used my phone as a hot spot .
Maria T indicates the network is up and running. I've double checked IP address password etc. Is anyone else having issues ?
any known resolve ? Thank you
Have you spoken with anyone other than Maria to get technical assistance? There are several folks available to help troubleshoot your issue if you ask Maria to connect you with them.
I don't know where you are working, but there is a cluster of USGS stations in the LA area that have been down for some time. The CSRC is working with them to get this corrected. Several PBO stations around the state went down in the past couple of days and they are working to get them back up, but because you have had this problem for some time, that likely isn't the source of your problem.
I don't use CRTN often, but I've not had any problems using it with my Javad/Verizon system in recent years. It sounds like a Carlson/AT&T problem to me.
Are you sure you have the latest version of SurvCE?
Some of the early releases of 6.0.x had issues as you describe. I believe that they were addressed around 6.01 or before in the interim releases.
The current version of SurvCE is 6.02 (today is 7 Feb 2019).
It is highly unlikely that the CRTN is suddenly casting some format that would be incompatible... if so it would have affected many folks. RTCM 3.1 is a generic standard (accommodating GPS and GLN where applicable) such as available from PBO stations that are streaming via their caster. The CTRN would not supplant that with anything proprietary, and the next standard RTCM format is RTCM3.2-MSM (multi-constellation support). And on RTN that offer RTCM3.2-MSM that is typically an additional set of mount-points and not a replacement for 3.1.
I have run an RTN for many years and here are some basic steps to determine if it is something up with your rover setup or if it is an RTN problem. I'll skip the ones you have already tried:
1. Call the RTN. Ask if they can see you connected to the caster. If you cannot get a hold of them, try the following:
2. Find another person with a rover. Put yours next to theirs and see if they can connect. If you can't find another user, try this:
3. Call the dealer who sold you the gear. Ask them to take one of their demo rovers outside and connect with the same credentials and to the same source.
4. Try different mount-points, even if they are farther away, just to see if you can connect.
I've skipped all of the initial steps (as you say you can connect to the PBO Ok). We find that 90% of all support calls are the rover not begin able to connect to the internet (by whatever connection/modem/hotspot/etc and connection to the DC (but that does not sound like your problem). We ask users to open a browser on their DC and see if they can open web pages, and/or open the source table by entering the caster IP:port in the browser. it sounds like you have your DC connected to the internet Ok, but a good step to keep in mind for other situations.
Users also test their login credentials with simple free apps like the Lefebure NTRIP client on their phone. They can also download the source table on the same app and test individual mountpoints. Again, this does not sound like your issue, but good to keep in mind.
If everything else is working , the only sure fire way to isolate the issue as being on the rover side or RTN side is to connect with a different rover or have your dealer connect at the same time, with the same credentials, to the same sources. I pack a simple rover setup with me pretty much at all times to be able to The folks that sold you the gear should be willing to provide such support. Eliminating potential points of failure one at a time is a good practice, sounds check for a user who calls with support questions (isolates the issues real fast).
Looks like you've done several of those steps, but a few more to go before concluding it is definitely something wrong with the CRTN.