NTRIP client : Is this dependent on a specific GNSS manufacturer?

I am using NTRIP client code [(ntrip.py)](https://github.com/ArduPilot/MAVProxy/blob/master/MAVProxy/modules/lib/ntrip.py) to use VRS-RTK.

I live in Korea. There are two NTRIP servers in Korea.
One is the solution of the US company **Trimble** and the other is the German company **Geo++** solution.

A = **Trimble**: PIVOT
B = **Geo++** : GNSMART2

---
The issue is as follow.

If I use VRS-RTK through server B, it works without any problem.
But if I use server A, I can connect to the server, but I couldn't receive the data.
I checked if it was a server problem, but it wasn't.

To solve the problem, I first changed the NMEA_GGA message generated by the **ntrip.py** internal function 'getGGAstring' to the message generated by [NMEA generator](https://www.nmeagen.org/) and sent it to the server.
Then I could receive the data from the server A.
However, this data was not reliable. Rather, it only worsened the accuracy of standalone-gps.
This means that data is being received, but something is wrong.
I checked again if there was a problem with the server, but it was not.
And using this method, the opposite happens. (I can receive data from server A, but I cannot receive data from server B.)

The NMEA_GGA message formats are as follows.
I think the number of digits is different.
* getGGAstring func : GPGGA,060644.00,5005.40000000,N,00839.60000000,E,1,05,0.19,+00400,M,1200.000,M,,
* NMEA generator : GPGGA,045338.171,3553.287,N,12836.319,E,1,12,1.0 ,0.0,M,0.0,M,,*68

In summary, if I use the ntrip.py code as it is, I can use VRS-RTK through server B, but not server A.
I don't know why this phenomenon occurs when the same protocol is used. Is the method of data parsing on the server different because the manufacturer is different? So is the ntrip.py code dependent on a specific manufacturer?

I earnestly ask for your help.

Start with MAVProxy/modules/lib/ntrip.py and inspect getGGAstring alongside the two GGA examples in the report. Compare the generated messages and their handling by the Trimble PIVOT and Geo++ GNSMART2 servers, then reproduce the differing behavior if access to both services is available. Done means identifying whether ntrip.py or server-specific requirements cause the failure and documenting a verified fix or limitation.

Written by the indexing model from the issue text.