Find the GPS com port using DotNet/C# SerialPort.ReadTo("$GP")

0 votes

I am trying to discover the serial port for GPS using Windows/DotNet.
The following is C# psuedocode:
For each com port, for each baud rate starting at the highest, find an open port and perform a SerialPort.ReadTo("$GP").  If this is successful, i'm good. Unfortunately, the ReadTo doesn't work.  
Here's a snippet of actual code:
            var ports = System.IO.Ports.SerialPort.GetPortNames().OrderBy(s => s);
            foreach (var portName in ports) {
                using (var port = new System.IO.Ports.SerialPort(portName)) {
                    List<int> baudRatesToTest = new List<int>(new[] { 115200, 19200, 57600, 38400, 9600, 4800, 2400 });
                    foreach (var baud in baudRatesToTest) {
                        port.BaudRate = baud;
                        port.ReadTimeout = 2000;
                        bool success = false;
                        try {
                            port.Open();
                            if (!port.IsOpen) {
                                continue; //couldn't open port
                            }
                            try {
                                port.ReadTo("$GP");
                                success = true;
                            }
                            catch (TimeoutException) {
                                continue;
                            }
What am i doing wrong?

1/29/2017 - Update
New problem.  Toughbook CF-54 has only U-Blox sensor driver.  With port com4, looking for initial message of “$GP”, we find no satellites.  Without initial search of “$GP”, we find satellites, but no location.  To find location data, we are looking for “GPRMC”.  We tried “GPGGA” also with no luck.  The installed Panasonic GPS Viewer can find GPS on port com4 and return data.
We tried the U-Blox driver without the sensor option checked but our app and Panasonic GPS Viewer app could not see the GPS.
Did the standards change between driver versions for the return data?  Is the U-Blox driver looking for different messages?  Is our NMEA Parser code no longer workable with U-Blox (again, worked with the CF-53’s using the Sierra drivers.)

1/30/2018 - Update. 

I'm looking at the u-blox-M8 Receiver Descr Protocol Spec (https://www.u-blox.com/sites/default/files/products/documents/u-blox8-M8_ReceiverDescrProtSpec_%28UBX-13003221%29.pdf).  On page 121, there's a description for RMC.  The messages in the spec don't line up with my code.  For example, I'm looking for an Active value in message[1] when it's really the status value in message[2].
Please confirm this.  My current sample code base for RMC:
            Active = (message[1] == "A");
            Latitude = NmeaMessage.StringToLatitude(message[2], message[3]);
            Longitude = NmeaMessage.StringToLongitude(message[4], message[5]);
            Speed = NmeaMessage.StringToDouble(message[6]);
            Course = NmeaMessage.StringToDouble(message[7]);
            MagneticVariation = NmeaMessage.StringToDouble(message[9]);           
            if (!double.IsNaN(MagneticVariation) && message[10] == "W")
                MagneticVariation *= -1;
I'm a little confused because this code works with the CF-53's and the Sierra driver.  Is there an explanation for this?  I thought this format was standardized, meaning it wouldn't change per vendor/platform.

by neilgps asked Jan 12
by neilgps edited Jan 30
175 views
Thank you both for your prompt replies.  We resolved the issue by installing the Sierra drivers that were originally on the CF-53's.  
1/30/18 - The above comment was premature...we are still dealing with GPS discovery and parsing issues.
We were able to display some messages received.  Looks like the majority of what we're getting are $GNxxx messages.  One of the first messages we see is "$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E...".  My parser logic doesn't look for any GNxxx messages, only GPxxx.  Your documentation mentions only a few of the GNxxx message, not all we are receiving.  Is it simply a matter of replacing $GP with $GN?

Also, we are parsing for Garmin.PGRME to get the HorizontalError.  I don't see a reference in your documentation for Garmin.  Is there another way to get this info?
I have discovered an explanation for the format discrepancy I was seeing.  Blame it on user error - our inhouse code is parsing the message type out before it is being processed. I hadn't noticed this bit of logic until this morning.

I'm hopefully close to a solution and infinitely more knowledgeable (yet, remaining ignorant) about GPS than I was a few days ago.

I do have a question about Garmin.PGRME.  I understand U-Blox is no longer handling this message type.  We used it to capture the estimated horizontal position error.  We use this value, along with Lat/Long/Course/Speed to reposition our ArcGIS map.  I see that U-Blox has a proprietary message (PUBX) that offers Vertical Accuracy (assuming this is equivalent to horizontal position error) but we don't seem to be picking those $PUBX messages up.  Any suggestions would be helpful.
0 votes
Assuming that - you are running Windows 10, on the toughbook, with embedded GNSS, the problem may be the Windows Location/Sensor driver which provides a single virtual COM port which is sometimes not recognized by some environments.
Remove the Windows sensor USB driver completely and load in the simple CDC-ACM USB driver and see if that works. That USB driver can be downloaded from the u-blox website under Documents and Resources tab on most GNSS module web pages.
Search this forum for "rugged", "tough", etc. to get more hints on solutions.
by grampy answered Jan 12
by grampy edited Jan 12
Thanks you for your help.  I have added new information on a related issue.  Please reread.
We were able to display some messages received.  Looks like the majority of what we're getting are $GNxxx messages.  One of the first messages we see is "$GNTXT,01,01,02,u-blox AG - www.u-blox.com*4E...".  My parser logic doesn't look for any GNxxx messages, only GPxxx.  Your documentation mentions only a few of the GNxxx message, not all we are receiving.  Is it simply a matter of replacing $GP with $GN?

Also, we are parsing for Garmin.PGRME to get the HorizontalError.  I don't see a reference in your documentation for Garmin.  Is there another way to get this info?
I have discovered an explanation for the format discrepancy I was seeing.  Blame it on user error - our inhouse code is parsing the message type out before it is being processed. I hadn't noticed this bit of logic until this morning.

I'm hopefully close to a solution and infinitely more knowledgeable (yet, remaining ignorant) about GPS than I was a few days ago.

I do have a question about Garmin.PGRME.  I understand U-Blox is no longer handling this message type.  We used it to capture the estimated horizontal position error.  We use this value, along with Lat/Long/Course/Speed to reposition our ArcGIS map.  I see that U-Blox has a proprietary message (PUBX) that offers Vertical Accuracy (assuming this is equivalent to horizontal position error) but we don't seem to be picking those $PUBX messages up.  Any suggestions would be helpful.
0 votes
Depending on receiver it might not be sending $GP but rather $GN, suggest looking for "$G" or "\r\n$G"

See if you can open in a generic terminal application, see what's coming out.
by clive1 answered Jan 12
Like I said, a robust parser will handle multiple Talker ID.

It isn't 1980 when you had one constellation with the prospect of 24 satellites, half obscured by the planet at any given time. NMEA sentences tend toward a 12-in-view perspective. Satellite number representations have some inconsistencies between vendors. The awkward Lat/Lon coding relates to the direct-to-display functionality of a simple 8-bit micro from the 80's illuminating a row of seven segment displays, with data provided by a $2K GPS receiver.

The M8 is a multi-constellation device, and reports within the constraints of the NMEA format.

http://www.catb.org/gpsd/NMEA.html#_talker_ids

If you want GPS only, or specific NMEA behaviour you will need to use CFG-NMEA to select that, but something that can handle current formats, and multiple brands of receivers and is forward looking will handle things in a more complete and robust manner.

It's not my documentation, this is a user-to-user forum, and I don't work for u-Blox

At $P message is proprietary, GRM is the Garmin ID, ASH is Ashtech. Perhaps you should review Garmin's docs, but it is not a form the u-Blox receivers will emit.

The GxGST sentence can provide some accuracy estimates, and RMS 68% number by the looks of it. Multiplying HDOP by CEP will give you a good 50% number.
Thanks for your reply.  I had no idea this was  peer to peer forum...I thought, from your handle, you worked for U-Blox since you were a Senior Principal Expert.
No matter.  Again, I appreciate you or anyone helping me out.
I probably should have prefaced my initial message with the  fact that I have nearly zip GPS background or knowledge.  I'm just trying to get some in-house software running on new toughbooks we will soon be supplying to our staff.
Thanks for the link.  I've been on that page.  Maybe I'm not looking close enough but I still do not have an answer to my question regarding the message formats being the same for $GP and $GN.  I will assume they are since apparently, the Talker ID (the 1st 2 char's) identify the 'generic' GPS.  That is my next step in my endeavor - add parsing logic for the $GNxxx messages we need.  The page from the link shows message formats in line with those for U-Blox although neither are the same as the format I currently parse for on the working Sierra/CF-53's.  But that's neither here nor there I suppose.  I need to get the U-Blox/CF-54's working.
I have discovered an explanation for the format discrepancy I was seeing.  Blame it on user error - our inhouse code is parsing the message type out before it is being processed. I hadn't noticed this bit of logic until this morning.

I'm hopefully close to a solution and infinitely more knowledgeable (yet, remaining ignorant) about GPS than I was a few days ago.

I do have a question about Garmin.PGRME.  I understand U-Blox is no longer handling this message type.  We used it to capture the estimated horizontal position error.  We use this value, along with Lat/Long/Course/Speed to reposition our ArcGIS map.  I see that U-Blox has a proprietary message (PUBX) that offers Vertical Accuracy (assuming this is equivalent to horizontal position error) but we don't seem to be picking those $PUBX messages up.  Any suggestions would be helpful.
>> I understand U-Blox is no longer handling this message type.
Can you cite a case where u-Blox has ever supported this proprietary Garmin message?
http://www.gpsinformation.org/dale/nmea.htm#PGRME

Look at the GPGST message I mentioned earlier
https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/NMEA-0183messages_GST.html

You would need to enable the PUBX messages you want emitted via UBX-CFG-MSG, same with GST message.

Vertical accuracy is nominally 2x worse than Horizontal

The receiver doesn't have a fixed reference to determine how accurate it is, it can measure the noise in the solution/measurement as it tracks those 50-60 times a second. The average measurement from a GPS receiver is a metre or so from a truth location. This type of error is hard to resolve without RTK type methods where you're basically nailing one corner of a triangle to a fixed/known location, and tying your other measurements too this reference.

Lacking a specific measure, I'd probably take the fall back position of taking the HDOP and multiply it by 3 metres. This would provide some depth to the implementation rather than being pinned to one specific make/model of GNSS receiver. You should be able to see this with default configurations.
http://www.gpsinformation.org/dale/nmea.htm#GSA
Again, thank you so much for replying and your help.  Because of it, I inch my way through this muck and understand a little bit more with each reply.  
I have made progress in my code - I can get the CF-54 working now, picking up satellites and even locating me, albeit, not as accurately as I'd like, since I still don't have a replacement value for the HorizontalError from Garmin.PGRME.  
You mentioned GST and I looked at that, but it supplies two values - standard deviations for both Lat and Long.  Is there some mathematical formula to use with both those values that will give me one value equivalent to something useful to ArcGIS?  What ArcGIS is expecting, when is relocating, are the following:
                    LocationChanged(this, new Esri.ArcGISRuntime.Location.LocationInfo()
                    {
                        Course = rmc.Course,
                        Speed = rmc.Speed,
                        HorizontalAccuracy = m_Accuracy,
                        Location = new Esri.ArcGISRuntime.Geometry.MapPoint(rmc.Longitude, rmc.Latitude, SpatialReferences.Wgs84)
                    });
The only value I'm missing is the one for HorizontalAccuracy.  With Garmin, we can do this:
double m_Accuracy = double.NaN;
if (message is Garmin.Pgrme)
            {
                m_Accuracy = ((NmeaParser.Nmea.Gps.Garmin.Pgrme)message).HorizontalError;
            }

This is probably more info than you care about.  But again, any help is appreciated.