That’s fairly easy. If your GPS message is a GGA message, then I have C# code that will not only parse out the Lat/Lon but will also convert that to ECEF (Earth-Centered Earth-Fixed) coordinates as well as NED (North-East-Down flat-Earth coordinates).
I think you misunderstood the goal. There are many examples already on how to decode GPS. All of them are C#, not native, not RLP. Decoding is not a problem, that is easy. The question is will adding native GPS decoder (in C not C#) be worth the work?
Ah, gotcha. Hmmm. I guess the question is what will the GPS Lat/Lon ultimately be used for? Because raw Lat/Lon is fairly useless. It would have to be converted to something more useful like ECEF or NED if you’re targeting real-time navigation applications.
The fastest GPS receivers output at 20Hz. And that’s already ludicrously fast for what you would need GPS for (i.e., if you need to sample GPS position at 20Hz, then what you actually truly need is an IMU).
Most real applications I can think of would already be happy with 5Hz GPS. And that really doesn’t require a lot of processing power, I think.
Just speaking purely for myself, if I were a customer, a native GPS parser would be rather boring. I would much rather have a native IMU parser, because then, that’s where speed really is critical.
Here’s a little chip I picked up a while back with the intent of doing some performance comparisons to see if it would be worthwhile as a module. I haven’t done much more than stick it on a DuinoProto so far but I bring it up as an option since it has NMEA parsing built-in as one of it’s features. I was more interested in the 64-bit math but it could be useful for string parsing as well.