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
Norman,
what you are going to do requires a tight timing:
-
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. -
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. -
The pps is 200 ms long.
-
30 ms after the start of the pps the M12+ starts the serial
transmission for the NEXT pps. -
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. -
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@febo.com
[mailto:time-nuts-bounces@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-> bin/mailman/listinfo/time-nuts
and
follow the instructions there.
Hi Norman:
The way to do it in LabVIEW is to have a single VI running by itself that's the
sole connection to the GPS data. This VI looks for the end of one message AND
the start of the next message, i.e. for Motorola <CR><LF>@@
Although it's possible for that to occur in the middle of data it only causes a
hiccup at the beginning and will sort itself out.
Once you have found it, then the characters after the @@ are used to route the
rest of the packet into a global table. Note that there may be two or four
message ID characters for the Motorola receivers. Once you know which packet
it is then you know how long it is so start looking for <CR><LF> where it's
supposed to be then keep looking in case there's been some character stuffing.
Now you can have another VI running in parallel that just reads the global
table of packets and processes each one (calls the @@ VIs). This can be
greatly simplified since the same VI can read many different packets because
they all have the same number of variables of the same data types. So you end
up with a VI named for each @@ message and those call generic VIs that read the
global table.
I did this many years ago to compare a hardware 1 PPS sawtooth corrector with
the software method.
http://www.prc68.com/I/timefreq.shtml#Sawtoooth
Have Fun,
Brooke Clarke, N6GCE
http://www.prc68.com/P/Prod.html Products I make and sell
http://www.prc68.com/Alpha.shtml All my web pages listed based on html name
http://www.PRC68.com
http://www.precisionclock.com
http://www.prc68.com/I/WebCam2.shtml 24/7 Sky-Weather-Astronomy Web Cam
Norman J McSweyn wrote:
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.
Ulrich,
Does EZ-GPIB support visa? I know there was a thread a few months back
kicking around the idea.
The way the code is written now, I'm getting a response to @@Hn and
parsing that.
The idea was to save the data in text files and post-process with excel.
Using the SRQ (and your idea as from the counter to generate a timing
mark (to start the serial vi). This makes a lot of sense because I'll
know that the data in the message will be for the next second
(timestamped with this second)
Based on my observations, the gpib routine takes 300ms to complete. It's
just setup, trigger and read. I'll have to change this.
There are two reasons for Labview. One is it's used quite a bit. The
other is that the learing curve isn't quite as steep as C++ or VB.
Either way, you've given much to think about!
Thanks,
Norm n3ykf
Norman,
Does EZ-GPIB support visa?
Yes, it is not a complete implementation but it should be enough for
tasks like that.
The idea was to save the data in text files and post-process
with excel.
Sure possible, but if the decoding can be done in realtime why not do
it.
Based on my observations, the gpib routine takes 300ms to
complete.
For my HP counters the rule applies: Once they are configured and you
can be sure that they have terminated a measurement (either because they
triggred the bus SRQ line or by knowing that they received a signal on
the stop input) you can ask for the result and you get it with high
speed, merely microseconds then milliseconds.
There are two reasons for Labview. One is it's used quite a bit. The
other is that the learing curve isn't quite as steep as C++ or VB.
As I did already say: There is a readey to go example that performs the
complete decoding. The only prerequisite is a positive going pps on
either of the RS232 status input lines.
73s and my best regards
Ulrich, DF6JB
P.S.
I just received an feedback that the version of 2008-10-29 may contain a
bug. Please wait with a test of EZGPIB until a later version is
available.
-----Ursprungliche Nachricht-----
Von: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] Im Auftrag von Norman J McSweyn
Gesendet: Mittwoch, 29. Oktober 2008 17:40
An: Discussion of precise time and frequency measurement
Betreff: Re: [time-nuts] labview, gpib, gps ,logging data and
lost data points!!
Ulrich,
Does EZ-GPIB support visa? I know there was a thread a few
months back
kicking around the idea.
The way the code is written now, I'm getting a response to @@Hn and
parsing that.
The idea was to save the data in text files and post-process
with excel.
Using the SRQ (and your idea as from the counter to generate a timing
mark (to start the serial vi). This makes a lot of sense because I'll
know that the data in the message will be for the next second
(timestamped with this second)
Based on my observations, the gpib routine takes 300ms to
complete. It's
just setup, trigger and read. I'll have to change this.
There are two reasons for Labview. One is it's used quite a bit. The
other is that the learing curve isn't quite as steep as C++ or VB.
Either way, you've given much to think about!
Thanks,
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.
Ulrich,
I'll give ezgpib a try! Unfortunately it won't be until Feb. My vacation
is coming to an end. Have about 15 or 20 more hours budgeted to play
with my toys.
Have fixed the dropped data points, however. Used a timed sequence
structure inside a for loop. The sequence structure has two frames. The
first is the gpib routine. When that completes, Moto gps routine runs.
Does it all in less than a second!!! How's that for precise timing? :-)
The way the gps routine is set up, I'm polling the board, rather than
setting it up to output every second. The m12+t user's guide says the
buffer on the gps board is read every second. How is that true if I poll
the board and get a response in 200ms?
I'm presently polling the @@Hn. Think I'll add @@Gb and parse that.
It'll give me the time stamp from the moto board. That along with the
time stamp from the pc ought to get me more troubleshooting data at least.
BTW: I'm flushing the serial buffer prior to reading it, so the data is
in response to my query, rather than being data that is in response to
the previous poll.
tnx es 73 de Norm n3ykf