Where did you get this VI? What is its purpose? If the code is uncommented, then it will be hard for anyone to figure it out. If this is an Instrument Driver VI, then please take into account that many of our Instrument Driver VIs are submitted to us. We test them to make sure the functionality works as it should and then place them on the web. This looks like a large, complicated VI. It may just be that you have to do some Highlight Execution to see how the data is manipulated.
Randy Hoskin Applications Engineer National Instruments http://www.ni.com/ask
I found this vi on this ni disscusion forum. It is for a Garmin45 GPS system. I require a vi for the Garmin 35. I presumed this would be the same, but its very complicated, & i dont understand what most of the things do.
I found the discussion you mentioned. I would look back to the info-labview author to see if you can find out who wrote this. Anyone is going to have to take a good deal of time to parse through the code.
It is parsing the NMEA0183 text strings returned from the GPS receiver via the serial port and displaying the information.
I am not sure what you are referring to at the bottom of the diagram page. The sequence structure in the lower right with the trig functions is displaying the satellite lock info on the satellite map.
The set button sets the PC's clock to the satellite time using the System Exec to run a batch file called Timeset.bat
The small while loop executes until it has a full NMEA 0183 sentence then the 'string subset' primitives strip out a portion of text from the sentence that identifies the type of sentence. It then matches the type of sentence to the various types possible (All the pink string stuff at the top). Depending on the type of sentence, it then passes the string to the appropriate part of the diagram where it is further parsed and converted to the relevant type of information.
The sentence for time, lat, long etc. from a Garmin45 must start with a $GPRMC in the string. All sentences start with '$' (and end with -). The '$' is stripped by the while loop, then a match is found between the first 5 bytes of the string and 'GPRMC'.
The first 2 characters, 'GP', identify the talker. GP indicates global positioning system (as opposed to 39 other possible talker devices, icluding depth sounders, voyage data recorders, Loran C, etc. The NMEA standard identifies the means for different marine equipment to communicate with each other.)
The next 3 characters, 'RMC', identifies the type of sentence. RMC is indicative of the "Recommended Minimum Specific GNSS Data". This identifies the structure of the information contained in the sentence.
That particular structure is: $aaRMC,bbccdd.dd,e,ffff.ff,g,hhhhh.hh,i,j.j,k.k,llllll,m.m,n,o*pp
where, aa = 2 character talker identifier RMC = Sentence formatter mnemonic code bbccdd.dd = Universal Time Code of position fix e = status (A=valid V=receiver warning) ffff.ff = lattitude g = lattitude North/South hhhhh.hh= longitude i = longitude North/South j.j = ground speed in knots h.h = course over ground, degrees True llllll = date (mmddyy) m.m = magnetic variation, degrees n = E/W o = mode (A,D,E,M,S,N or V) * = checksum delimeter pp= checksum = sentence terminator (ASCII 13 + ASCII 10 character)
Important: I don't know if this sentence explanation actually is a byte count (as the author is parsing) or an explanation of the data format within the ","'s. Ground speed is identified as x.x knots, which would seem to indicate that 9.9 knots is the fastest if it is a byte count. On the other hand it may indicate that ground speed is a fractional representation between the nth and the nth+1 comma. As I stated in my earlier post) my receiver uses a Rockwell binary protocol (which is a lot more fun than this text - NOT!!) but my OEM software definitely reports ground speeds faster than 9.9 knots.
Anyway you can see where the author is parsing this information for the RMC sentence type, based on byte position in the string, directly under the case statement for setting the PC's time.
As written, er wired, it appears that the while loop continually processes the last received data for each sentence type each time it receives any new sentence and executes, regardless of whether the data for that type of sentence has changed or not. i.e. if a different type of sentence is received the old RMC sentence will again be parsed from the shift register where it is stored. Several types of sentences are identified and stored in their respective shift register but no parsing is performed and no information is gleaned from them.
There are many types of sentences and some manufacturers have additional sentences identified as proprietary for additional info.
Given this information you should be able to examine your received data for the basic GPS information. Note that my Delorme Earthmate receiver transmits some info (sentence types for NMEA 0183 receivers) on a regular basis while some is received only intermitently, so don't assume that what you are seeing coming in from the serial port is all that you will ever see.