Meh, I like SVN. Besides, I still can’t get TFS to connect,
What edition of VS are you using?
2010 pro from MSDN
Humour me and try ultimate. I could never get the Pro beta to work with codeplex, but ultimate did. I don’t see any reason why it would make a difference as i assume they all use the same libraries…
Back to the topic of GPS: We should really get something working soon. I have done a few experiments, but I would really rather implement the waypoint functions over the NMEA parsing.
It should work, reading GLL and RMC sentences. There’s no reason why you can’t implement waypoints yourself 
The classes are all there, all you need to do is complete the methods to fill out the waypoint list and check for waypoint proximity if the property is set for that.
Hmm very cool work so far guys i need to play with this on my rhino.
Hi Mark,
I see your commit. I’ll start writing code in a few days.
I’m gonna make a sizable commit tomorrow. In them mean time, what’s the deal with RMC? It seems like it has multiple definitions.
Also, I think we should call the parse method will only the sentence string array as an argument. If RMC does have multiple definitions as I suspect, that’s the only way to tell them apart (RE: The length of the sentence array)
Ok, well, I cleaned up the src and codeplex page a little bit.
We need devs, really bad.
Message: RMC
Description: Recommended Minimum data
Number of fields: 15
Message Structure:
$GPRMC,hhmmss,status,latitude,N,longitude,E,spd,cog,ddmmyy,mv,mvE,mode*cs
Example:
$GPRMC,083559.00,A,4717.11437,N,00833.91522,E,0.004,77.52,091202,A*57
Yeah, now look at another page describing it. Sometimes there will be like three different definitions for it.
I’m going off the official NMEA specs.
Also, what happens when a token is not present?
The following is a sample from the LS20033’s output:
Note how certain tokens are blank (IE, there is nothing between the commas). What do we do then? With the current approach, we are going to just get Exceptions thrown when we try to do stuff with zero length strings.
A simple check that it’s not String.Empty would fix that…
I was wandering on this bit of code
string[] split_messages = message_queue[i].Split(',');
switch (split_messages[0])
{
case "$GPRMC":
RMCDataReceived(split_messages[1], split_messages[2], split_messages[3], split_messages[4], split_messages[5], split_messages[6], split_messages[7]);
break;
case "$GPGLL":
GLLDataReceived(split_messages[1], split_messages[2], split_messages[3], split_messages[4], split_messages[5], split_messages[6]);
break;
default:
break;
}
Wouldn’t it be better and more readable to send the whole NMEA sentence to the function and let the function do the split internally?
Hi Geir, that is what I was thinking, too. there is no reason to create $X many new string objects.
On the same lines, I am seeing a lot of string someStr = “”;. Don’t do that!
the proper way to initialize a string like is someStr = String.Empty;
String.Empty doesn’t create a new string object, and is thus faster.
I know, but we need to be doing that now. Right now we blindly parse.
And that’s why we have many developers on this project. So that things can be refined. Feel free to make the changes yourself rather than just talking about them
Geir, i was also thinking it would be good to send the full sentence. I really don’t like over-manipulating strings as it’s so resource intensive.
Also, the double.parse() issue still needs to be fixed. Geir, can you confirm the issue with your GPS?