Norman, what you are going to do requires a tight timing:
1) Because of the nature of the M12+'s messages their end is not easily detected (<cr> and/or <line feed> may be WITHIN the messages due to their halfbinary nature). A method would be to detect "no activity" on the M12+'s transmit line for a time and then to decide that all messages are received. 2) You need an fixed exact relation between the pps and the serial messages, because the serial messages describe the situation for exactly the NEXT pps. 3) The pps is 200 ms long. 4) 30 ms after the start of the pps the M12+ starts the serial transmission for the NEXT pps. 4) Depending on which messages are send the duration of the messages may vary, for the typical case of @@Ha, @@Hn and @@Bb the total duration is abt 370 ms. 5) Due to 1)-5) a save way to do your measurement is: Make the start of the pps to the start of your software activity, i.e.: a) Use the M12+'s pps as the STOP for your time interval counter, so when you detect the start of the pps you can be sure that the TIC has already performed it's last measurement. b) When you detect the the start of the pps immediately read Windows's serial Buffer to have the complete messages available for the next pps. I am sure this can be done with Labview but I know that problem solving in Labview can sometimes be very tricky specially when tight timing is necessary. Time as a physical entity is not well represented within the "graphic programming language". I would encourage you to go for a completely different way. The latest version of my EZGPIB utility contains an example where the script a) waits for the pps of a M12+ (must be applied as an positive going RS232 pulse on either DSR, CTS, DCD or RI) b) reads and then completely decodes @@Ha, @@Hn and @@Bb messages so that for example the gps time and the sawtooth correction value are readily available without hassle. c) has a precise point at which the counter should be read Best regards Ulrich, DF6JB > -----Ursprungliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Im Auftrag von Norman J McSweyn > Gesendet: Dienstag, 28. Oktober 2008 01:14 > An: Discussion of precise time and frequency measurement > Betreff: [time-nuts] labview, gpib, gps , logging data and > lost data points!! > > > 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 (Thank you Dave Partridge!!!!!!) 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 or sometimes a bunch at > once) aren't' 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. Separated them. Works well now > (except for the four or five lost data points in 40k) > > Varying the time constant. It's helped lots, but I really > don't' want to > lose any data. > > Have tried timed loops. Works fine with one process. Try to > do two (gpib > and serial for the gps) and it hangs the PC. > > Solution that I think would work: > A way of firmly triggering a start event with labview. I've > got a time > server so windoze time (or lack of it!) is not an issue. > (This may be an > issue. Played around with it. Turning off polling made a difference.) > > 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. > Thoughts, questions, comments and humor greatly appreciated. > Thanks for your time, Norm n3ykf > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts > and > follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.