I've spent the last 3 hours trying to set up my equipment with my new Nomad with SurvCE 3.0 ... and all I can say is that I'm very disappointed.
In the course of 3 hours, I've had at least 50 instances (and that's not exaggerating) where I was kicked out of the program, or had a "screen freeze" to the point that I had to reset the Nomad. I think I need to shelf this and wait for the bug fixes ...
The biggest problem was with setting up the RTK network. It would go through the automated connection processes, then either get hung up on the "Connection Sucessful" screen (It would just sit there forever, until I rebooted the Nomad), or after "Connection Sucessful", it would kick me out of the program by itself (and save me the trouble). I got it actually connected to the RTN 3 times total, after messing with it for 3 hours.
Version 3.01 was released mid July. I looked through the changes and it seemed that most were GPS related. Might take care of your problems.
I confirmed that I've got 3.01.
Oh well ... I checked the Florida DOT Network web page, and the system isn't in great shape at the moment. The two closest CORS to me are shown as "down", so that might be part of the problem. Whatever it is, SurvCE's 'error handling' is not great since it seems to want to kick me out of the program an awful lot. I'll probably try again tonight when it's cooler outside...
The baddest bug that I've found is doing a two point offset with rtk, it uses 0.0 for the horizontal distance when you store it. However, when you exit the routine, it will tell you the last shot hasn't been stored. If you elect to store it, it will store it correctly.
What I have started doing is take my two shots, enter the distance, exit and store when prompted. There are some other bugs, typical with a new software release, but this one has the most bite to it that I've found.
TCP/IP vs. UDP/IP
Ok ... so this is weird. After beating my head against a rock for several hours today, on a lark, I switched the Network type seting (in SurvCE) from "TCP/IP Direct" to "UDP/IP Direct", and it actually seemed to work better ... still not perfect, but better. The reason I had been using TCP/IP is because that is what the FDOT print-out says for the port assignments.
I've heard of TCP/IP, but never heard of UDP/IP.
Here is a description on UDP/IP:
Short for User Datagram Protocol, a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides a direct way to send and receive datagrams over an IP network.
It's used primarily for broadcasting messages over a network. As UDP has no error reporting built in and contains no information to allow packets of information to be re-assembled, it can only work with a single packet. If the information you wish to transmit is larger than one packet then all but the first packet will be lost.
The "no error reporting" is interesting. I wonder if TCP was detecting a problem, sending an error message, and confusing the heck out of the software to the point of it crashing.
TCP/IP vs. UDP/IP
> The "no error reporting" is interesting. I wonder if TCP was detecting a problem, sending an error message, and confusing the heck out of the software to the point of it crashing.
UDP typically doesn't require a reply to complete a message or handshake. TCP usually responds with an ACK packet (I forget what ICMP sends). Perhaps, like you say, an unexpected response was gumming up the works? It sounds perfectly feasible.
