Motorola gps

[Norm]

Hi all!

I'm playing with a Motorola M12+t gps reciever on my serial port. NO problem getting the serial port written to or the string back. The format is Motorola binary. Labview sees it as a Hex string.

When trying to parse the string (17 bytes) all approaches I try ignore byte 5. The maddening fact is that is the month. The recieved string is 4040 4762 0A1D 07D7 0103 0000 F30D 0A. FYI: the first four bytes are the message header and the last two are the termination bytes. In order the bytes of interest are (byte 5 through byte 12) Month, Day, Year(double byte here), hour, minute, second.

I understand that 0A is the ascii carridge return. How do I parse this correctly using LV 8.0?

BTW: My programming skill level is relatively low.

Thanks for the help!

Norm n3ykf

[crelf]

The easiest way is to use "Format into String" wit multiple %s statements in your format specifier - let me know if you're having issues and I'll code something up for you.

PS: at first glance, your string format looks like the standard GPS NMEA 0183 RMB format - you can find more info here.

[Norm]

QUOTE(crelf @ Oct 28 2007, 11:18 PM)

The easiest way is to use "Format into String" wit multiple %s statements in your format specifier - let me know if you're having issues and I'll code something up for you.

PS: at first glance, your string format looks like the standard GPS NMEA 0183 RMB format - you can find more info http://www.kh-gps.de/nmea-faq.htm' target="_blank">here.

Thanks for the reply. I don't think (format into string) that will work. Took a quick peek at LV's help file. What I need to do is parse the string after being read from the buffer. The string VI's ignore 0A. (decimal 10)

The output from the gps board is not NMEA. Moto has their own command set. It can be toggled to be NMEA, though.

Any help is much appreciated

Got to go to bed. 3am coding is BAAADDDDD!

Norm

[Falevoz Y.]

HI!

You probably already thought about that, but by default the Serial config have the 0x0A value as termination char... You may have to put a false on the Enable Termination Char input

By!

Yann

[Anders Björk]

There is an example on reading NEMA183 from a GPS on NI-support pages. A complete set of VIs.

[Justin Goeres]

QUOTE(Norm @ Oct 28 2007, 10:47 PM)

The string VI's ignore 0A. (decimal 10)

I see what you mean. I'd never noticed that behavior.

Just to clarify what Norm is saying, here's a snippet that illustrates it. Basically, the Scan From String function skips over carriage returns (0x0A):

That feels like a bug to me. Why would a function that scans data out of an input string respect newlines? Doesn't that make it impossible to use with a multi-line input string (if you care about the newlines)? Does anybody else have a grip on that rationale that I'm just missing?

EDIT: There's also no mention of this behavior in the LabVIEW Help. The closest it gets is "A space in format string matches any amount of white space, such as spaces, tabs, linefeeds, and form feeds," but the format string in my example doesn't have any spaces in it.

QUOTE(Norm @ Oct 28 2007, 06:37 PM)

When trying to parse the string (17 bytes) all approaches I try ignore byte 5. The maddening fact is that is the month. The recieved string is 4040 4762 0A1D 07D7 0103 0000 F30D 0A. FYI: the first four bytes are the message header and the last two are the termination bytes. In order the bytes of interest are (byte 5 through byte 12) Month, Day, Year(double byte here), hour, minute, second. I understand that 0A is the ascii carridge return. How do I parse this correctly using

LV

8.0?

And to move on to your actual problem...

Since you're dealing with a binary protocol, I would convert the incoming string to an array of bytes before doing the parsing. That will give you the actual numeric value of each byte as an array of integers. Just use the http://zone.ni.com/reference/en-XX/help/371361D-01/glang/string_to_byte_array/' target="_blank">String to Byte Array function. It's in your palettes, under String >> String/Array/Path Conversion.

Once you've got your incoming data as an array of integers, you can use a For Loop, Array functions, and whatever Numeric functions you need to get you home.

[Norm]

QUOTE(Justin Goeres @ Oct 29 2007, 09:07 AM)

I see what you mean. I'd never noticed that behavior.

Just to clarify what Norm is saying, here's a snippet that illustrates it. Basically, the Scan From String function skips over carriage returns (0x0A):

That feels like a bug to me. Why would a function that scans data out of an input string respect newlines? Doesn't that make it impossible to use with a multi-line input string (if you care about the newlines)? Does anybody else have a grip on that rationale that I'm just missing?

EDIT: There's also no mention of this behavior in the LabVIEW Help. The closest it gets is "A space in format string matches any amount of white space, such as spaces, tabs, linefeeds, and form feeds," but the format string in my example doesn't have any spaces in it.

And to move on to your actual problem...

Since you're dealing with a binary protocol, I would convert the incoming string to an array of bytes before doing the parsing. That will give you the actual numeric value of each byte as an array of integers. Just use the String to Byte Array function. It's in your palettes, under String >> String/Array/Path Conversion.

Once you've got your incoming data as an array of integers, you can use a For Loop, Array functions, and whatever Numeric functions you need to get you home.

Justin,

I thought I was crazy! It smelled like a bug, but as I've often found out, apparant bugs turn out to be operator error. Using String to byte array would be natural with one exception. How do I deal with the double bytes? I didn't see a setup terminal on that icon in the help file.

I have a feeling I'm missing something basic.

Thanks again,

Norm

[Justin Goeres]

QUOTE(Norm @ Oct 29 2007, 08:05 AM)

How do I deal with the double bytes? I didn't see a setup terminal on that icon in the help file.

I have a feeling I'm missing something basic.

Take a look at Join Numbers. It will turn your 2 U8s into a single U16. You'll find it in Numeric >> Data Manipulation.

Actually, another option might be to just Type Cast your "array of two U8s" to a single U16. I forget whether that works or not (and using Join Number is probably more readable), but it feels familiar. It's in Numeric >> Data Manipulation, too.

This is all stuff I usually just end up working out on the fly for any given situation. Once you start to get comfortable in the Data Manipulation palette the sky is kinda the limit :ninja: .

[Mellroth]

QUOTE(Norm @ Oct 29 2007, 02:37 AM)

...When trying to parse the string (17 bytes) all approaches I try ignore byte 5. The maddening fact is that is the month. The recieved string is 4040 4762 0A1D 07D7 0103 0000 F30D 0A. FYI: the first four bytes are the message header and the last two are the termination bytes. In order the bytes of interest are (byte 5 through byte 12) Month, Day, Year(double byte here), hour, minute, second...

QUOTE(Justin Goeres @ Oct 29 2007, 04:48 PM)

Actually, another option might be to just

Type Cast

your "array of two U8s" to a single U16. I forget whether that works or not...

Hi Norm,

as Justin pointed out, you can use TypeCast to convert two U8s to a single U16, but you can even go further by typecasting the U8-array directly into a cluster with the elements in the same order as your parameters.

Have a look at the attached code, and see if it might help you.

Download File:post-5958-1193674539.vi

PS. there are still 2 bytes not accounted for in the string "...00 F3...", do you need to parse these as well?

/J

[Norm]

QUOTE(JFM @ Oct 29 2007, 12:18 PM)

Hi Norm,

as Justin pointed out, you can use TypeCast to convert two U8s to a single U16, but you can even go further by typecasting the U8-array directly into a cluster with the elements in the same order as your parameters.

Have a look at the attached code, and see if it might help you.

Download File:post-5958-1193674539.vi

PS. there are still 2 bytes not accounted for in the string "...00 F3...", do you need to parse these as well?

/J

J, Justin, Andres, Falevoz and crelf,

Thanks for the ideas. I had to pull out the textbook and acquaint myself with clusters.

BTW: Bytes 12 through 17 aren't important at this time (in order: signed byte of gmt offset, hour of gmt offset, minutes of gmt offset, checksum, and of course 0D0A). The technique I just learned can be applied across most of this project. I used the code idea provided by J. Had to rewrite (icon) the code for LV8.0. GOOD LEARNING EXPERIENCE. Diddled the icon, dropped it on the block diagram of my serial i/o VI, added a indicator and it worked like a charm. One comment. I finally found where you can expressly state what type and format the string/number is. Highlight (a constant, say), right click, go to Properties, Format and precision, advanced editing mode.

Now, the challenge is to build a larger, more complete driver. Next project is to do file i\o. such that I can read it with excel or 123.

Girlfriend won't be happy tonight. I smell a 3am wireing run coming.

Happy coding!

Norm