Has anyone had success using the ntrip client setup in either OpenGrade3D or version 4 of AgOpenGPS?
I think I successfully used NTRIP with AoG v4. I expect many people did/do.
Would you be able to point me in the direction the of the INO you used for it. Looking to add it to OGX but running into issues.
I used it in AgIO which sent the RTCM to the F9P via USB so no INO/Arduino involved.
Okay I had saw a UDP port option in the NTRIP Client section, I thought that there must have been an INO involved then, that relayed that information to the F9P. I am attempting to use UDP to transfer the RTCM data wirelessly to the Antenna Module. I am able to get all the byte information to the antenna unit, but when attempt to send it over serial to the F9P on board it doesn’t respond. I’m thinking it may be an encoding problem. I’m sure all the info I need is in the following book but, I would much rather not spend $450 to find out, and hoping someone has implemented RTCM over UDP already.
You should check at the dual gps inos. They use ESP32 and they can use the built in NTRIP. I cant help more, I never used dual or an ESP32!
Maybe this code will give you some hints.
Found this on the dark web. It is one edit earlier. If you understand all that, I’d be interested. My local Ntrip gives 1004, 1006, and 1009 messages. Decoding them is a challenge that I’ve not been able to solve.
RTCM_SC-104_v3.2.pdf (1.1 MB)
@KentStuff Took a look through those documents and my brain started to turn to mush. I don’t think I will look to decode it at all. More so just looking to force feed it into the F9P and leave a lot smarter people than me to parce through it. Thanks @Pat for the pointer to that INO. Unfortunately I had pretty well the identical code it employed so I’ll have to keep looking to find my error.
2 Likes
Just to be sure, is your F9P configured to receive correction over uart1? since radio is typically over uart2.
@Pat I have It to receive on UART 1 Protocol in → RTCM3 (as I know that works through U-center NTRIP client connected via USB for testing). There is definitely some communication happening as all the value OGX react once it connect to NTRIP Caster after startup. Unfortunately not the right communication though. Not sure what I am missing as everything seams to be there just doesn’t work, may need to be encoded to UTF-8 or some other encoding protocol before it is transmitted to the F9P
1 Like
Can you snif your UDP data and compare to the serial output to see if the characters are passing through transparently?
@m_elias Here is a screenshot that may help better explain my problem. Bottom left is the byte array that OGX pulls from the NTRIP Caster. In the center is that Byte data after being sent over UDP to the ESP 32, and then finally on the right is byte data that I was able to snif off the Serial line running to the F9p from U-centers NTRIP client(connect to the same MtPnt of course). as you can see all the byte data appears to come through (as verified by working u center Byte data). The problem then I believe is when I receive the data and then send it off instead of reading and sending 211, 000, 149,-> I believe I am sending instead 2,1,1,0,0,0,1,4,9,->
Edit: the (10005,) that appears on the OGX data is just a header for parsing UDP info in ESP it is removed before being sent to F9P.
What are you using to sniff the serial line to the F9P? Is it displaying hex? If so, then it appears to be grouping the values together into hex. I probably need to see the code to know how you’re relaying it but there’s a difference between Serial.print and Serial.write in the Arduino. Without knowing your level of expertise, I’ll guess at a possible hangup.
If you have variable, byte X = 66, (ASCII letter ‘A’)
then Serial.print(X) sends ‘66’ (two ASCII values of 54)
whereas Serial.write(X) sends the value 66 which translates to the letter ‘A’
Its a program called serial port monitor, it allows you to sniff Into serial connnection data as it’s transmitted between two interfaces. I used it to snif the line of serial data being transmited out of the U-Center Ntrip client connected over usb to the RTK2B board. It can display hex, decimal and a couple other formats. I had it configured to to display decimal format. I have been using Serial.write to send the data to serial as I think that is what I need as it isn’t encoded to ASCII coming from OGX. It is raw byte date (0-255)
Sounds like you’re doing that part correctly.
Here is the code for the relay of information
packetbuffer variable is a char array. Maybe there is something I am missing.
case NTRIP_HEADER:
DEBUG.print(" Start of N TRIP BYTE Data from OGX->|");
for (int i = 6; i < sizeof(packetBuffer) ; i++){ ///sizeof(packetBuffer[0])
if (packetBuffer[i] == '\n' || packetBuffer[i] == '\r' || packetBuffer[i] == _NULL) break;
DEBUG.write(uint8_t(packetBuffer[i]));
//RTK.write(int8_t(packetBuffer[i]));
}
211 is sent as 11010011
0 is sent as 00000000
Etc.
String looks like
110100110000000010100101001111
Then it is decoded inside.
That or similar is how it has to be sent and received. In bits, not bytes the 211 is the carrier marker and happens to be in two bytes. It may also be in three bytes with just leading zeros. The book is not real clear on the 211. But it breaks the long stream into bits and then allocates a certain number of them to the information.
I know that doesn’t help you, but it may give you a direction to look in sending out the information.
Hey any info helps. That’s what I love about forums like this there is such a vast background of knowledge. So from my understanding then I believe I am sending it as
2 - 00000010
1 - 00000001
1 - 00000001
String then being 00000010+00000001+00000001
Instead of the
110100110000000010100101001111 That you mentioned, which I agree with I think is correct from the info I was able to sniff from u Center.
My idea now is the send RTCM from OGX with a delimiter (either blank space or comma) that way I can differentiate between the end of one byte and the beginning of another. Does this make sense?
What I’ve not determined is if the raw data has a break or not. See if your sniffer can just print the raw data without conversions.