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)

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