NMEA Adapter

[KeithNightlinger]

I am working with the new NMEA adapter and using the socket connector it only appears to be processing the GPGGA message.  I have GeoEvent definitions for for all three (GGA, RMC, and GLL) and I know my GPS device is sending all three by sending it to another port.

Would there be a reason why only one message type is coming through the GeoEvent Processor?

Also, how is the DeviceID assigned?  I have 30 vehicles that will be sending in a NMEA signal.  Using the GGA message, the device ID shows as 4.  How can I correlate this device ID with a Vehicle ID?

Thanks in advance.

Keith

[SamuelRichmond]

I've been doing more testing and tried using the GPS 2 IP application that was shown in the NMEA connector documentation for testing. It works with no issues for RMC, GLL, and GGA. Here is a sample of the data it is sending to GEP.

$GPRMC,063815,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*4F
$GPRMC,063817,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*4D
$GPRMC,063819,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*43
$GPRMC,063821,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*48
$GPRMC,063823,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*4A
$GPRMC,063825,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*4C
$GPRMC,063827,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*4E
$GPRMC,063829,A,3029.918,N,09032.527,W,0.00,217.3,060614,003.1,W*40

The differences I noticed are in the time stamp field. The GPS2IP doesn't send a decimal number (seconds), the GPS device does. The app also gives True Course, and Variation where the GPS leaves them blank. The last thing I noticed is the app has 12 fields, where the GPS device has 13. I may be on to something!

Line 55-56 of the NMEAGPRMCMessageTranslator.java code has this snippet:

if (data == null || data.length != 12)
       throw new ValidationException("NMEAGPRMC message data is invalid.");

If I'm not mistaken, it is counting fields to validate that the format is correct. I've been doing some digging and the number of fields varies on just about every manufacturer's documentation for the RMC NMEA sentence between 12 and 13 fields. I haven't gone as far as purchasing the official paper from NMEA to get all of the possible sentences because it's kind of pricey, but I did find this http://www.catb.org/gpsd/NMEA.html#_rmc_recommended_minimum_navigation_information and it seems very complete.

If you disregard the "count" that the document gives the fields, remove the field for "FAA mode indicator" (#12) because it seems like a lot of equipment follows an old version of the specification that doesn't include it and THEN hand count ALL of the fields including the $--RMC field, you have 13.

I guess my point is that for RMC sentences you may have 12, 13, or even 14 fields in there and the code doesn't account for that which is causing an error for me and probably others.

Thoughts? Do you think the RMC message translation code needs to take this into account?

P.S. After looking at the GLL message translator code, it counts 7 fields and the NMEA document I found for the GLL sentence has 9 total. If you remove the FAA mode indicator, it's 8. The same problem (assuming it is the problem) is probably happening with it as well.

[SamuelRichmond]

I downloaded the source, modified the code, and recompiled the module this morning and was able to get the adapter to accept RMC sentences from my device. I submitted a pull request to the project on github to patch the source. Let me know if i can help in any way with testing things further.

BTW, the device I'm using is a CradlePoint IBR-600LE-PWR mobile router with GPS. The planned application is to track police cars as well as provide in-car data to laptops and other equipment in the car.

[RJSunderman]

Hello Samuel �??

I apologize for not replying sooner to your posts to the forum.  Thank you for your initiative in downloading and reviewing the source available [url=https://github.com/Esri/nmea-for-geoevent]here[/url] on GitHub. I noticed from the exchanges on GitHub that you are working with Vlad, who is the developer you want to be in touch with.

I think that you are spot on with all of your observations. The NMEA specification is quite detailed and contains many different message sentence variants. What the GeoEvent Processor team put up on GitHub is only an example of how the product's SDK can be used to develop a custom adapter. As you've observed, the number of fields in a GPRMC message can vary. Because GeoEvent Processor requires a GeoEvent Definition to allow an adapter to parse a payload (e.g. NEMA message) from received event data, we would have to provide a potentially large number of event definitions if we were to advertise comprehensive support for all the different NMEA sentence variants. The initial offering only provides samples for three (GPGGA, GPGLL, and GPRMC).

It appears, based on your message from 5-June that the validation code has a bias for �??North�?? and �??East�?? coordinate values. I�??m considering this a bug and will submit an issue against it. The validation logic which checks the number of fields, however, is tied to what the adapter plans to do with the data in those fields. I�??ve a feeling that if we were to simply relax the validation to allow GPRMC sentences with 12, 13, or 14 fields that other users might want to know why the adapter was ignoring data values in the extended fields, which goes back to what I was saying about needing a potentially large number of event definitions to satisfy a large variety of potential NMEA sentences.

Thank you for your observations and the technical detail in your posts. If we do not immediately integrate your pull request on GitHub it is most likely because we want to maintain the NMEA adapter offering as a sample which folks can tailor for their specific devices (as you were able to do) rather than trying to maintain an adapter which supports "all possible" sentence structures.

Best Regards �??
RJ

[SamuelRichmond]

RJ,

I agree that due to the size of the NMEA catalog, making an adapter that includes all of the available sentences is a huge task. Perhaps a separate connector for each RMC sentence size would be in order then and they could be included in the basic NMEA adaptor download. The basic sample adapter covers the majority of what most people will use as far as sentences go, and my personal opinion is that if ESRI wants to offer a sample that with with RMC, they should get it right so it works with ANY RMC sentence. Maybe leave it up to the end user to figure out the number of fields their equipment is reporting and allow them to chose the proper one.

As for the wonder by end users as to why certain fields are being ignored, as far as I know, the fields that exist in the range of 12-14 aren't used in the sample RMC connector either. My code just extends the ignoring to the extra fields. I'm far from an expert, but the fields most will need are still covered. RMC sentences are for GPS tracking and the only fields one should need for that are UTC Time, Status, Lat, Lat Direction, Lon, Lon Direction, Speed over ground (knots), and date. All of these are still picked up with the modification I made.

Having sample adapters is great and I appreciate having something to look at to get me started, as it did with the custom adapter I made for my CradlePoint routers to add System IDs to identify which device is which between 60 separate vehicles in the fields. I feel like most users would expect basic NMEA RMC sentences to work, no matter the number of fields when downloading a sample program that says that's what it does. It didn't for me and I had to troubleshoot it to fix it myself. A lot of the products users don't have the time or possibly knowledge to do what I did. Please consider this in any of your internal discussions regarding this issue. I'm not saying my code is 100% right. It works, but it's my own personal hack, for my own application. I submitted the pull request to bring attention to the problem and possibly get it fixed for everyone's benefit, whether my modification is used or not.

Again, thanks for responding to me an taking a look at the problem. Let me know if I can be of any assistance working this out. I'd also share the CradlePoint Router adapter I made if ESRI wants to make it available for others to use. I know there are a lot of people out there trying to do the same thing I am and it would save them several all-nighters and stress to just be able to plug it in and go.

[Lorena_AndreaPeñuela]

Hi,

I´m working with Geoevent and the app GPS2IP, but I have a problem:

The app doesn’t updated the coordinates, due to the app always use the same coordinate (+27.5578,-122.778), although this coordinate is the EEUU  but  I’m in Colombia.

Any of you had this same problem?

The NMEA connector works perfectly, but Geoevent always get the same coordinate.

May you help me please?

Regards,

Lorena