Main Site Documentation

Native GPS decoder


#1

While decoding GPS is a very simple task, it requires a lot from NETMF due to a lot of string work and possibly checking every single byte.

I am really curious on how much does this wastes from a system and how much a native implementation would help, or not!

Any thoughts on this? Any GPS NEMA stream experts here? Interest?


#2

I could convert my driver to RLP and see what difference it makes.


#3

@ Gus - what do you mean by decoding GPS? What kind of input(s) and what kind of output(s) are you looking to have?


#4

something like

GPSDecode.event += myEvent;
while(true)
{
GPSDecode(readUART());
}

myEvent( long, lat, time…)
{

}


#5

Maybe time it on 1000 GPS lines and see how long it takes in each case?


#6

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).

What kind of GPS update rate were you looking at?


#7

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?


#8

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.


#9

See this please http://www.ghielectronics.com/community/forum/topic?id=11480


#10

I’ll get on this over the weekend. Tomorrow I have a 3D printer to setup and the Motif replacement to finish over tomorrow and Friday


#11

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.


#12

@ Ian - That’s pretty cool!


#13

It will be great to see the performance of this. And im looking forward to the motif replacement too. :slight_smile:


#14

Man… you do more cool maker stuff in a week than I get done in a month. I really need to get out of this 9-5 gig…


#15

@ Skewworks is one of the most prolific software guys here. @ Justin is the same with modules :slight_smile: machines all of em.