[time-nuts] labview, gpib, gps , logging data and lost data points!!

[Ulrich Bangert]

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: time-nuts-bounces at febo.com 
> [mailto:time-nuts-bounces at febo.com] 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 at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
> and 
> follow the instructions there.
>