Jump to content
Sign in to follow this  
Norm

Motorola gps

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

post-2992-1193663477.png?width=400

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)

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.

Share this post


Link to post
Share on other sites

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

post-2992-1193663477.png?width=400

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.