Norm

Once the data is in excel, you can easily create charts or crunch numbers if you need to. We were using plain text files and after switching to tdms, we have never looked back. There is a bit of a learning curve, but making the switch has greatly simplified our lives.

Toby,

I can see why it's much easier. Need to play with the LV help file so that I can learn more about setup of TDMS. It sounds like this will make the data collection end of my life MUCH easier. It's most of what I do, really.

I've been using .txt files formatted csv. Parse the input strings, rearrange, time stamp and write! A little work to post process in Excel if it's needed, of course..

Drop me a note if you're ever in Binghamton, NY!!

Thanks,

Norm

Toby and Ton:

Thanks for your guidance.

Ton, the NMEA routine is pretty much what I'm looking for. Do want to play with it a bit so that I understand what's going on. Where did you find it?

Toby: You are suggesting that I create separate channels (string outputs) for each satellite? Planned on doing that, but how do you get only one spreadsheet? Need to find out more about the TDMS data. Sounds like I'll have a nice evening with a cup of coffee, google and the LV help file!

Will have time to play on Thursday.

Norm

QUOTE (Ton @ May 16 2009, 01:16 AM)

Ton, Thanks for the response.

>>Does the data always start with the header?

Yes it does.

>>Is the header always the same size?

It is. This approach will work.

>>If both answers are true your code is quite easy: Read the header and use that as the selector for a case structure, for every possible header you have a different case that reads the correct amount of bytes.

The only rub here is that the messages are different sizes. Will need to read to the termination character.

>>I think there are several checksum VIs available, where is Microwave Dave's post?

http://decibel.ni.com/content/groups/rf-de...g-nmea-183-data

Dave's post is a utility that does most of what I want to do. Would like to take a peek at it and see how he approached the problem. Unfortunately, it's written with LV 8.6 :-( . I've only got LV 8.0.

Would you be so kind as to point me at the checksum vi's? I'd like to write my own but a look at someone else's approach is always good.

>>I advise you to use TDMS or TDM data, this can be opened by excel with a plugin but makes sure that the data is correct, you will lose no significance data.

Need to do some research here. One of my rules is to use the most general tools possible. Your solution sounds like it fits.

>>Maybe a donation to LAVA is a good idea to keep things running!

Did this. These forums has been a gold mine of information.

Ton (or if you come to the Netherlands we could have dinner)

I'd love to! Too bad it's so far. Love to geek out with other geeks.

Hi all!

Disclaimer: This is a hobby! I'm not an expert, nor do I pretend to be. Bearing that in mind, please use a judicious amount of rigor with explanations. All of what I've taught myself came from example code, tutorials or from forums.

I've written code to gather data from the serial port and log it before. It was always a quick and dirty method based on reading a specified number of bytes from the serial buffer, parsing the resulting strings and logging the data.

This time, I'd like to do it right. Somehow the code needs to select the correct parsing routine by header and verify the string using the checksum.

My code will work like this:

Write the setup string to the gps board to keep the overhead in the buffer down.

Then read the buffer, select the proper routine, check, parse and log the data.

I do understand that to calculate the checksum, I've got to go (input) string to byte array and loop with an XOR to get the number. Not sure how to implement that solution, though.

Microwave Dave posted some code, unfortunately it's in LV 8.6 (I'm using LV 8.0), which I don't have.

Pointers, guidance and ideas are much appreciated.

BTW: This endgame for this code is logging visible satellites by time along with their c/no, az, el and satellite health. I'm thinking 32 individual .txt files would probably be the way to go. Each file can be imported into excel and sorted that way.

Any ideas here? I'd like to log the data by day (0000-2400utc).

Offer of dinner: If you are local to Binghamton, NY (within 100 miles) I'll spring for dinner in exchange for being able to pick your brain about LV and writing code..

Thanks for your time!

Norm M.

And Hey to the OTHER Norm! If you'd like to be Norm and can fix it with the admin, let me know..

Hi!

I'm logging data from an HP 5335a (using it as a time interval counter). and from a Motorola gps board ( text data).

The test setup is comparing the 1pps output from the gps board to a divided down 10 MHz from a Trimble Thunderbolt. The text data is used to post process the measurement from the 5335a reflecting the 1pps error (+/- 15E-9). The ver is LV 8

Code description:

Each instrument has it's own VI and I run them simultaneously, collecting data and storing it in text files. The individual vi's are for loops with the iterations being the number of seconds that I want to log. Inside the loop is obviously a delay. The data is time stamped with seconds enabled.

The problem is that somewhere in the 40k data points some (not all at the same time or sometimes one here and there) arent' collected.

Solutions that I've tried:

Using the 1pps to drive the parallel port so that I've got a hardware time hack. When I had both vi's in the same for loop things didn't go well. Not really sure what happened. Seperated them. Works well now (except for the four or five lost data points in 40k)

Varing the time constant. It's helped lots, but I really dont' want to lose any data.

Solution that I think would work:

A way of firmly triggering a start event. I've got a time server so windoze time (or lack of it!) is not an issue.

I'm not really a programmer. Actually play with trains for a living. Will be on vacation for the next week. Not much to do so I'll be able to play lots.

Thanks for your time,

Norm n3ykf

HA!

Sorry I stepped on anyone's toes! My nickname at work is "normal". Go figure.

My girlfriend managed to grab my attention last night. So much for quality time with LV and my pc.. Back to work tomorrow. Been a nice two week plus vacation.

Have fun!

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

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

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

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