Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Timing question

timing counting

  • Please log in to reply
5 replies to this topic

#1 TonyF

TonyF
  • Members
  • 16 posts

Posted 18 September 2013 - 04:19 AM

I am sure that this has been asked before but a search of the manual and forum has failed to yield an answer.

I want to time between pulses in a series of pulses, but I want to catch each period.  The pulse frequency may vary by a ratio of 10 (more likely to be around 3) during a measurement period of say between 5 to 20 secs.  The frequency is not high, say 10 to 100Hz.

I can easily read the period between the last pulse gap, but how do I know when to do the next read?  I could easily do a read faster than the max pulse frequency but then I could be attempting to read the period between any 2 given pulses more than once.

I will have two series of pulses to measure concurrently, the frequency of the two will not be directly proportional but they will follow (roughly) the same pattern of change. i.e. when one stream doubles in frequency then the other will also approximately (within say 10%) double.  

For the more important data series I have considered the alternative method of counting pulses between a fixed period.  The rate of change of frequency is such that I determined that this period would need to be no greater than 0.1 secs but I do have another pulse stream available that is approximately 200 times faster to get more counts per period.  however, I have done an error analysis on this considering how the -i count resolution would affect the results of calculations farther down the line and the error is larger than I want. .Which is why I am looking to use the alternative method of timing between pulses rather than counting pulses in a set period. The relative resolution of counting clock ticks between pulses is much better but I do need to be sure than I am timing each pulse period.

 



#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 18 September 2013 - 07:46 AM

A couple pointers I think you are looking for:

 

 

1. I gather you are using 32-bit or 16-bit period measurement (mode 2/3 or 12/13)?  Note the following from Section 2.9.1.3 of the U3 User's Guide:

 

Mode 2: On every rising edge seen by the external pin, this mode records the number of clock cycles (clock frequency determined by TimerClockBase/TimerClockDivisor) between this rising edge and the previous rising edge. The value is updated on every rising edge, so a read returns the time between the most recent pair of rising edges.

 

Writing a value of zero to the timer performs a reset. After reset, a read of the timer value will return zero until a new edge is detected. If a timer is reset and read in the same function call, the read returns the value just before the reset.

 

 

So, if each time you read the timer you also reset it (by writing value=0), then you will only get a measurement once for each rising edge, and all other reads will return 0.

 

 

 

2.  Since your highest frequency is 100 Hz, you have to read at least every 10ms to make sure you don't miss a cycle.  That is pretty reasonable for command-response mode, but you might consider using stream mode if you want to read the timer values faster.  See Sections 3.0, 3.1, 3.2, and 3.2.1:

 

http://labjack.com/s...3/users-guide/3

 

 

 

Note that the click on the U3 is only 1.5% accurate, so that limits your timing accuracy.  You would need to move up to the U6/T7/UE9 to get a quartz based clock with 20-30 ppm accuracy.



#3 TonyF

TonyF
  • Members
  • 16 posts

Posted 18 September 2013 - 10:04 AM

 

 

Writing a value of zero to the timer performs a reset. After reset, a read of the timer value will return zero until a new edge is detected. If a timer is reset and read in the same function call, the read returns the value just before the reset.

 

So, if each time you read the timer you also reset it (by writing value=0), then you will only get a measurement once for each rising edge, and all other reads will return 0.

 

 

Yes, this is one method that I was considering but I was uncertain if the act of resetting the reading also would reset the count of the clock ticks.  Just so that I am 100% clear. the counting of the clock ticks is only affected by the input pulses and writing zero to the timer only affects what I read from the timer and does not restart the counting or cause a missed count period?


#4 TonyF

TonyF
  • Members
  • 16 posts

Posted 18 September 2013 - 01:21 PM

One more question.  I understand that the U3 timing may be in error by up to 1.5%.  For any given example of a U3 is the error fairly constant or does it vary day to day or hour to hour.

I am just thinking that if it remains fairly constant then it would be easy to measure the error and compensate for it from time to time.



#5 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 19 September 2013 - 11:35 AM

 

 

Just so that I am 100% clear. the counting of the clock ticks is only affected by the input pulses and writing zero to the timer only affects what I read from the timer and does not restart the counting or cause a missed count period?

 

Correct:  The timer reset does not clear out the active tick counting.  It just clears the register where the resulting tick count is stored upon each rising edge.  The result register, which is the timer value you read.

 

 

 

I understand that the U3 timing may be in error by up to 1.5%.  For any given example of a U3 is the error fairly constant or does it vary day to day or hour to hour.

I am just thinking that if it remains fairly constant then it would be easy to measure the error and compensate for it from time to time.

 

I would expect it to be as you described.  That is, if the clock error is +0.8%, it will be steady with that same error over some amount of time if temperature and power supply remain the same.

 

However, last time I looked at it I felt like it was more of a jitter type of error, where over a short amount of time the clock was jittering around within the error band.  If you have a steady frequency source you trust, you could connect it to a timer in Mode 2 (32-bit period measurement) and see how steady the U3 readings are.



#6 TonyF

TonyF
  • Members
  • 16 posts

Posted 19 September 2013 - 02:28 PM

many thanks.  Great Lab Jack support as usual.





Also tagged with one or more of these keywords: timing, counting

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users