Ohio CORS connection

GPS / RTK / GNSS
1

Hello, I am am having some difficulty getting my AgIO connected to Ohio CORS systems. I signed up, received password etc.

Since I could not figure this out, I used Wireshark to look at the traffic between my machine and Ohio’s systems. Playing around a little bit, I notice the authentication packet from AgIO looks like this:

GET /ODOT_G_R_E_C_RTX_RTCM3 HTTP/1.1
User-Agent: NTRIP AgOpenGPSClient/6.4
Authorization: Basic **************************==
Accept: */*
Connection: close

and this never seems to connect properly.

I tried using RTK lib instead and I noticed the packet is a little different:

GET /ODOT_G_R_E_C_RTX_RTCM3 HTTP/1.0
User-Agent: NTRIP RTKLIB/2.4.2
Authorization: Basic **************************==

Does the “Connection: close” mean AgIO is trying to close the connection as soon as it opens? I tried both 1.1 and 1.0 protocol in AgIO, so I know that is not the issue.
Am I missing anything obvious? Does someone have experience with the Ohio CORS system and can confirm plays nice with AgIO?

image
image773×684 22.6 KB

2

I don’t have any experience with this system, but based on your (quite detailed) investigation, I would check the following:

  • What is the actual response that you get from the server? (Wireshark should show this I think)
  • Does the Authorization header match? (Compare the value of AgIO vs. RTK lib)
  • The Accept header from AgIO does look wrong, it should be */*. Can you confirm that it is only /? (If so, what version of AgIO/AgOpenGPS are you running?)
  • Connection: close is the default for HTTP/1.0 so it should be equivalent to the request from RTK lib
3

Also check the port. In Florida mine is different base on what rtk format you are looking for. If you click for the get source table does it give you a list of mounts?

4

Check also the port in my example it is 2201. At the first attempt, I couldn’t see it (2101 vs 2201)

5

Thanks for the quick replies. I am using AgIO 6.6.2 version. Just to be thorough, I went ahead and tried SNIP as well. It connects fine and is able to act as a pass through to AgIO on the local machine. So, if all else fails, I think this is a workaround.

I can only go off what wireshark tells me, because I am not familiar enough with TCP connections.
All systems receive “ICY 200 OK” in response, but only the RTK lib version has a 7342 byte packet attached. I don’t know how to decode it other than some ascii that says “ADVNULLANTENNA” and “TRIMBLE ALLOY” Maybe this is station identifying info?

yes, they are exactly the same. I removed the data in the original message because it contains my login details.

Here is the same from SNIP (redacted some personal details):

GET /ODOT_G_R_E_C_RTX_RTCM3 HTTP/1.1
Host: nnn.nnn.133.115:2101
User-Agent: NTRIP sNTRIP/3.17.00l
SNIP-Agent: [00000/wLITE/3.17.00/R003] [ / / / ]
Accept: */*
Authorization: Basic *************************==
Ntrip-GGA: $GPGGA,164254.0,xxxx.21082000,N,xxxx.60406000,W,4,10,1.0,0.000,M,0.0,M,*71

you are correct, it is “Accept: */*” I must have typed it wrong the first time. Edit: it appears the Asterisk is markdown character and it was being excluded

Doesn’t this mean the server is to close the connection when it responds? Neither RTKlib or SNIP include this in the connection request.

The port is 2101 (default) for Ohio’s system. This is set correctly.

Yes, I see 7 of them. Ohio seems to use mount points to give different formats. One has _CMRx at the end

6

A long shot but do you use special characters in username or password that wont match in AgIO?
A long time ago my sister had an Apple device that couldn’t connect to the wifi because it had an 0(zero) in the password.

7

nothing crazy, just letters and a couple numbers.

8

For normal HTTP communication, using Connection: close in the request indeed indicates to the server that the connection should be closed. However, it is supposed to do that after it has sent its response.

For NTRIP however, since it uses a custom protocol (not really HTTP if I understand correctly), I am not sure what the protocol dictates regarding this header.

If you can compile AOG yourself, you could try to remove the Connection: close part (SourceCode/AgIO/Source/Forms/NTRIPComm.Designer.cs - Line 400) and see if this is indeed the culprit.

9

When you click get source table you should get a long list of mount points. Like so.

Screenshot_20250126-080142_Firefox
Screenshot_20250126-080142_Firefox1080×2220 141 KB

This is the list of stations.

What you have for a mount point is the data format.

Clear your mount point and click get source table. Select the one closest to you. You can find the list of stations here.

https://ortn.dot.state.oh.us/TrimblePivotWeb/Map/SensorMap.aspx

10

I will try this, but I will need some time to figure out how to do this. Thanks for the line number, it will save me a lot of time.

11

I’ve been using the Ohio CORS network with AgOpen for 5+ years. Will need to download 6.6.2 and try there.

From what you posted up, looks consistent with what I run:
Mount Point: ODOT_G_R_E_C_RTX_RTCM3
Port: 2101

I have had issues when I swapped the username and password as it’s set up on the Ohio system backward from what I’m normally used to.

Note: On the position tab, I select “Use GPS fix”. The Ohio network is a Virtual Reference System, so you don’t need to worry about connecting to a specific station. It creates a reference to your location. Not exactly sure how that works.

12

Makes sense, Florida has a similar network system that takes a different port number and your location to give you a virtual station. You have to send your location every few minutes.

13

Thank you all for your help. I was doing a in depth analysis of the different versions of the TCP/HTTP coms tonight. I found the issue in the GGA message. AgIO’s original version was this:

$GPGGA,230009.00,nnnn.211,N,nnnnn.604,W,1,5,1,,M,46.4,M,0,0*ck

One that worked was this:

$GPGGA,230533.00,nnnn.211,N,nnnnn.604,W,1,5,1,80,M,46.4,M,0,0*ck

I am running some custom hardware that was incorrectly populating the Altitude in the UDP message which was directly translating to AgIO. Even though I had “Use Manual Fix” selected, my bad data was being used. When I fixed my code to send an 80 altitude, you can see that got populated. Ohio’s system was then happy to send me some fix data.

Does it make sense that AgIO is using the GPS fix altitude when Use Manual Fix is selected? If you all think this might be an error, I can see if I can fix this and submit a bug to the Dev team. Maybe there is a default 0.00 that can be sent to make the systems happy?

Sorry to use your time investigating my mistake!

14

Maybe selecting manual fix is your problem. I believe it’s mainly used to set SIM to a place close to your home, so when making fields in SIM they can be used in the field ( standard position is at Brian’s place in Canada)

I accidentally entered a wrong position in my Base (just 500 m off correct position) and I could not get a fix)

So maybe cors do not like that position sent to it differ from actual position.
Could you try and find out if it works with selecting antenna position instead of manual position?

15

I used the new default at 0,0. Florida cords network call me on my cell phone and asked me to change it because it was wreaking the system. I apologized and told them it was at Brian’s house in Canada. They said oh no it is in the Atlantic Ocean outside of Africa. Lol. Do we currently offer elevation as a manual input? I was thinking it does not. Not looking at it right now.

16

Thank you for enlighten me, hadn’t noticed it was changed,:smiley:

17

Yes, it works this way. After I fixed my parsing code for the GPS input it works in both manual and GPS mode.

No, elevation is not one of the input boxes. It seems the Virtual Reference systems care very much about this number as it determines how they calculate the correction data they send. RTK to go or one of the other systems where the mount point correlates directly to a station don’t care about this.

18

Opened an issue on the GitHub repo to capture this.