« Close

Datasheets and User Guides

App Notes

Software & Driver

 

2.9.1.3 - Period Measurement (32-Bit, Modes 2 & 3)

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.  

In this 32-bit mode, the processor must jump to an interrupt service routine to record the time, so small errors can occur if another interrupt is already in progress.  The possible error sources are:

  • Other edge interrupt timer modes (2/3/4/5/8/9/12/13).  If an interrupt is already being handled due to an edge on the other timer, delays of a few  microseconds are possible.
  • If a stream is in progress, every sample is acquired in a high-priority interrupt.  These interrupts could cause delays on the order of 10 microseconds.
  • The always active U3 system timer causes an interrupt 61 times per second.  If this interrupt happens to be in progress when the edge occurs, a delay of about 1 microsecond is possible.  If the software watchdog is enabled, the system timer interrupt takes longer to execute and a delay of a few microseconds is possible.

Note that the minimum measurable period is limited by the edge rate limit discussed in Section 2.9.2.

See Section 3.2.1 for a special condition if stream mode is used to acquire timer data in this mode.

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.

Mode 3 is the same except that falling edges are used instead of rising edges. 

 

Edge Rate Limits

This edge-detecting timer mode requires processing resources as an interrupt is required to handle each edge.  See more about edge rate limits in Section 2.9.2.

 

8 comments

Hi, I have a U3 and I am programming in Visual Studio using C#. I am trying to find the time between electric pulses using mode 2. With this I will determine the rpm of a shaft (this rpm will vary, I do not have to be super accurate). 

This is the line of code that I am using to try to read the pulses.

LJUD.AddRequest(u3.ljhandle, LJUD.IO.PUT_CONFIG, 1, (double) LJUD.TIMERMODE.RISINGEDGES32, 0, 0);

Will this work for what I want it to? Also, Is it written correctly? Do I need to use another timer with it to work correctly? What variable does my double get saved in? Or do I need to stream this instead of just taking a single reading? 

I know this is a lot of questions but I am new at this.

Thank you for your time.

Before you try it yourself in C#, I suggest you first try it in the test panel in LJControlPanel.  That way you can try different timer settings and make sure the hardware side of things is good.

Without looking at your exact syntax, in general what you have is a request to configure the mode of Timer1.  You also need to enable timers, configure the clock as desired, do a go call of some sort, and then do getresult calls to check for errors.  Then you will need a call to read the timer value.  I would read through Sections 4.1 and 4.3.6 of the U3 User's Guide.

I suggest you start with the C# example "U3_TimerCounter".  Make sure it works without changes, then start modifying.

Hi

I wrote this comment in this post because it seems more appropriate. 

I want to get a signal frequency in Hz, initially did not know how but thanks to you I'm in the right spot. 

In LJCP, in Test Panel and configure Timer0 as RISINGEDGE32, TimerClockBase at 1MHz divisor = 1. This way I visualize the wave Period (escaled) and Value. The signal frequency, in Hz, get it dividing 1.000.000 Hz by the Value, can also be done by dividing 1 by the period. 

Do I have to do so? or is there an option to display the frequency directly, without having to load. 

Thank you very much for helping

The test panel displays the raw tick value and also the scaled value which is period.  If you want to display frequency you could use LJLogUD, among other options.  Is the timer working correctly in the test panel?  Confirm that first before you move on to other software.

First, you need to set the desired timer configuration as the power-up default.  Use "Config Defaults" in LJControlPanel to do that, and then power-cycle the U3 so the new defaults take effect.

Next, you can run LJLogUD and use the special channel numbers to get the timer tick value.  In the first row set +Ch to 200 or 230 to get the lower 16 bits of Timer0, and then in the 2nd row set +Ch to 224 to get the upper 16 bits.  To combine them and get total clock ticks use the scaling equation y=a+65536*b.  To get time in seconds use the scaling equation y=(a+65536*b)/TimerClockFrequency.  To get frequency use y=1/((a+65536*b)/TimerClockFrequency).  So if your timer clock frequency is 1MHz, your formula is y=1/((a+65536*b)/1000000).

I have programmed an RPM sensor with this period measurement function. It works well, however when the signal is lost it just shows the last RPM. How do i "write a value of zero to the timer" to reset it? If i set UpdateReset =True it just loses 90% of the data (which are giving unique period measurements as False).

Code(python2.7.6 for U6):

import u6, time, datetime

d = u6.U6()

d.configIO(NumberTimersEnabled=1, TimerCounterPinOffset=3) 

d.getFeedback(u6.TimerConfig(timer = 0, TimerMode = 3, Value = 0))

Period = d.getFeedback(u6.Timer0(UpdateReset = False, Value = 0, Mode = None))

 

Output:

Time                                           ticks                Hz                RPM

2014-06-13 08:52:23.739000       [906416]         52.956          5.296

2014-06-13 08:52:23.940000       [906289]         52.963          5.296

2014-06-13 08:52:24.142000       [906393]         52.957          5.296

2014-06-13 08:52:24.343000       [822828]         58.335          5.834  <-----Frequency source removed

2014-06-13 08:52:24.546000       [822828]         58.335          5.834

2014-06-13 08:52:24.748000       [822828]         58.335          5.834

2014-06-13 08:52:24.951000       [822828]         58.335          5.834

 

The timer has a Value register.  Once the timer is enabled there are 2 things that change the value in the Value register:

    1.  On every rising edge, the U3 takes the current tick count, subtracts the tick count of the previous rising edge, and stores the result as the Timer Value.

    2.  If you use the Timer# iotype and send UpdateReset=1 and Value=0, the Timer Value register will be reset to 0 immediately after the current value is read out.

In your example, once you take away the signal there are no new edges, so unless you write UpdateReset=1/Value=0 you will keep getting back the same value from the last detected edge.

If you only want to get 1 reading per edge, you do 2 things:

    1.  Read the value faster than the max signal frequency.

    2.  Write UpdateReset=1/Value=0 with every read call.

You will get 1 reading per edge, and all other readings will return 0.  You software then should have a test that detects 0 and realizes that really means infinity.

I am using a magnetic pickup to measure RPM of a steel disk. The output is one 5V peak pulse per revolution. It appears that noise, probably caused by irregularities in the steel disk, is causing the timing to vary. On my scope, I cannot get a good reading unless I raise the trigger level above the noise. Is there some way to raise the trigger level for the U3 timer?

The timers use digital inputs where the thresholds are fixed at <0.8V for a low and >2.0V for a high (from Appendix A).  You could start a topic on our forum and provide a screenshot from your scope so we can check it out.  If the problem is noise, then a filter might be needed or the debounce counter might work.  If the problem is that your signal is just not swinging <0.8 and >2.0, then a comparator is a likely solution.  Search labjack.com with the term "comparator" and you will get a bunch of hits that mention the MAX921CPA.

The T7 has more advanced debounce counting (T7) options, and also has a feature on analog inputs that can measure frequency of many signals even when they do hit digital input thresholds.