Rate of change

[cbutcher]

I'd suggest adding another shift register and storing the date/Time in Seconds output if your timing is coarse, or one of the millisecond clocks if it's finer.

Then you can take the difference as you're doing with the values.

[CQL]

---

@pincpanter wrote:

As you are not polling the data but simply read it whenever available, you need to adapt to the pace of the input.

If you know that you get exactly N samples in a second, you may discard N-1 data out of N.

Alternatively, you may record a time stamp after each read (for example using the Tick Count (ms) function) in a second shift register. The value difference should be divided by the time stamp difference - that is the elapsed time - expressed in seconds.

---

Hi,thanks for the reply.

I've tried using the tick count function and manage to get the difference of 20-25 tick count.Does this mean it take 20-25ms to travel from the first to second shift register?

[GerdW]

Hi CQL,

TickCount outputs values in milliseconds, so a difference of 20 means 20ms.

Could you attach your current VI so we can check your implementation?

[CQL]

Thanks for the reply.
The following is the implementation of the tick count.The indicator show 0,20-25 whenever i pause the program to check the difference.
Since it is 25ms,so for me to get the rate of change of 1sec,do i ÷  the values for the rate of change function by 0.025 to get the rate of change/1s?

[GerdW]

Hi CQL,

The indicator show 0,20-25 whenever i pause the program to check the difference.

So you get values of 200 to 250ms?

Since it is 25ms,so for me to get the rate of change of 1sec,do i ÷  the values for the rate of change function by 0.025 to get the rate of change/1s?

When you get a value each 25ms then the rate of change is calculated by dividing by 25ms…

Simple math, don't you think?

What's the baudrate of the COM port?

How many bytes do you expect per message?

With the default value of 9600 baud it will take ~1ms to transfer 1 byte/char from your device. A typical message of 20 bytes will take 20ms to transfer! (This is just the data transfer and no indication of the sample rate supported by your device!)

[pincpanter]

You are interested in the time difference between two consecutive reads, so the tick count should be sampled within the True case, immediately after (or before) the VISA Read.

Don't initialize the tick count shift register because the initial value is useless: the tick difference - and thus your rate measurement - is only meaningful after the second read. Your code should take into account this.

Further considerations can be done after you get the true output average rate.

[CQL]

---

@GerdW wrote:

Hi CQL,

The indicator show 0,20-25 whenever i pause the program to check the difference.

So you get values of 200 to 250ms?

The value shown on the indicator 0,20-25.

Since it is 25ms,so for me to get the rate of change of 1sec,do i ÷  the values for the rate of change function by 0.025 to get the rate of change/1s?

When you get a value each 25ms then the rate of change is calculated by dividing by 25ms…

Simple math, don't you think?

 Yeap.But when i divide it by 25ms,i read a large number for the change/time,which does not make sense .

What's the baudrate of the COM port?

9600

How many bytes do you expect per message?

With the default value of 9600 baud it will take ~1ms to transfer 1 byte/char from your device. A typical message of 20 bytes will take 20ms to transfer! (This is just the data transfer and no indication of the sample rate supported by your device!)

The following is the message after the VISA read

---

[GerdW]

Hi CQL,

The value shown on the indicator 0,20-25.

 Yeap.But when i divide it by 25ms,i read a large number for the change/time,which does not make sense .

Why do you divide by 25ms when you measure 250ms?

What's the baudrate of the COM port? 9600

How many bytes do you expect per message?

I counted 24 bytes in the shown message. With the pattern "±dd.dd" per value, a space between each value and a CR/LF at the end you will have messages consisting of (up to) 4*6+3+2=29 bytes. With 9600baud it takes ~30ms to transfer the message.

This 30ms is just the transfer time for the data. When you receive a value each 250ms then your device only supports a sample rate of 4S/s…

Why don't you use the measured time interval for your "change of rate" calculation? It might be more accurate than using a constant value…

And why don't you use SpreadsheetStringToArray to convert the received message into your 4 values?