Data Interval/Change Trigger: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
[[Category:Programming]] | [[Category:Programming]] | ||
Phidget devices often send streams of sensor and state data to attached channels. The rate at which that data is delivered can be controlled by setting the <code>DataInterval</code> property of a channel. A threshold can be set to filter data that does not deviate more than a defined amount by setting the <code>ChangeTrigger</code> property of a channel. | |||
Phidget device channels are initialized with a <code>DataInterval</code> specific to the device channel, and a <code>ChangeTrigger</code> of zero when they are attached. See the {{Phidget22API}} for more information. | |||
==Data Interval== | |||
The <code>DataInterval</code> property of a channel determines the rate at which the device channel will deliver data to an attached channel. ''data interval'' is handled at the device channel, which means a device channel with more than one channel attached (over the network for example) will have a single ''data interval'', and changing the <code>DataInterval</code> will affect all user channels. For locally attached channels ''data interval'' has a minimal performance impact, but a reasonable ''data interval' should be considered for network attached channels. | |||
<code> | The <code>DataInterval</code> of a channel is valid across a range determined by what the hardware is capable of, and what is reasonable for the data type of the channel. Refer to the {{Phidget22API}} for details about each specific Phidget. See the <code>MinDataInterval</code> and <code>MaxDataInterval</code> properties. | ||
It is important to note that even if an event handler has not been set, the channel is still receiving data at the device channel ''data interval''. If the data is going to be handled by software at a known rate, matching that rate to the device channel ''data interval'' can reduce CPU and network load, and reduce power consumption on some devices (many VINT devices will sleep between data samples if ''data interval'' is large enough). If software is only interested in the data when it changes, setting the <code>ChangeTrigger</code> may be more appropriate. | |||
'' | |||
== Change Trigger == | == Change Trigger == | ||
The <code>ChangeTrigger</code> property of a channel enables a filter that only passes data when that data has changed by an amount greater than or equal to the <code>ChangeTrigger</code>. For example, if the <code>DataInterval</code> was set to 0.7, new data would only be delivered to the channel when that new data differed from the previously delivered data by at least 0.7. | |||
<code> | |||
It is often useful to set a ''change trigger'' to reduce the apparent noise on a channel, or to only receive data change events when meaningful thresholds are reached. For example, an application that displayed temperature on an LCD may only be interested on 0.5°C changes. By setting the <code>ChangeTrigger</code> to 0.5, the only data that would be receive would be data of interest. | |||
== Setting Both Properties == | == Setting Both Properties == | ||
Line 36: | Line 22: | ||
In many cases, it is likely that you'll simply use these properties as follows: | In many cases, it is likely that you'll simply use these properties as follows: | ||
* Keep ChangeTrigger at zero and select | * Keep the <code>ChangeTrigger</code> at zero and select the <code>DataInterval</code> based on how often you want your program to receive data. This configuration is useful in data logging applications and when data will be represented in a graph. | ||
* Keep DataInterval at | * Keep the <code>DataInterval</code> at a minimal interval, and set the <code>ChangeTrigger</code> to the lowest relevant value for the quality you are measuring. This is useful for applications were you want to ignore values below a certain threshold or are displaying sensor values. | ||
However, in some complex situations, you may want to set both ChangeTrigger and DataInterval to non-trivial values. This | However, in some complex situations, you may want to set both the <code>ChangeTrigger</code> and the <code>DataInterval</code> to non-trivial values. This will result in expected behavior: The channel will check at the <code>DataInterval</code> whether or not the new data differs from the last delivered data by an amount greater than or equal to the <code>ChangeTrigger</code>. If the data passes the ''change trigger'' filter, that data will be delivered, if the data does not, the channel will wait until the next ''data interval'' and check again. | ||
The only complication is when you consider a situation where the value has spiked by a large amount and then returned to the baseline, in-between intervals. For example, suppose you have a voltage sensor and you've set the DataInterval to 5 milliseconds an the VoltageChangeTrigger to 3mV. The way this is handled depends on whether you're using a USB Phidget or a VINT Phidget: | The only complication is when you consider a situation where the value has spiked by a large amount and then returned to the baseline, in-between intervals. For example, suppose you have a voltage sensor and you've set the DataInterval to 5 milliseconds an the VoltageChangeTrigger to 3mV. The way this is handled depends on whether you're using a USB Phidget or a VINT Phidget: | ||
Line 81: | Line 67: | ||
[[Polling vs. Events]] - Your program can gather data in either a polling-driven or event-driven manner. Learn the difference to determine which is best for your application. | [[Polling vs. Events]] - Your program can gather data in either a polling-driven or event-driven manner. Learn the difference to determine which is best for your application. | ||
[[Using Multiple Phidgets]] - | [[Using Multiple Phidgets]] - Learn how to use more than one Phidget in your program. This page will guide you through the steps. | ||
[[Logging, Exceptions, and Errors]] - Learn about all the tools you can use to debug your program. | [[Logging, Exceptions, and Errors]] - Learn about all the tools you can use to debug your program. |
Revision as of 15:30, 29 June 2017
Phidget devices often send streams of sensor and state data to attached channels. The rate at which that data is delivered can be controlled by setting the DataInterval
property of a channel. A threshold can be set to filter data that does not deviate more than a defined amount by setting the ChangeTrigger
property of a channel.
Phidget device channels are initialized with a DataInterval
specific to the device channel, and a ChangeTrigger
of zero when they are attached. See the Phidget22 API for more information.
Data Interval
The DataInterval
property of a channel determines the rate at which the device channel will deliver data to an attached channel. data interval is handled at the device channel, which means a device channel with more than one channel attached (over the network for example) will have a single data interval, and changing the DataInterval
will affect all user channels. For locally attached channels data interval has a minimal performance impact, but a reasonable data interval' should be considered for network attached channels.
The DataInterval
of a channel is valid across a range determined by what the hardware is capable of, and what is reasonable for the data type of the channel. Refer to the Phidget22 API for details about each specific Phidget. See the MinDataInterval
and MaxDataInterval
properties.
It is important to note that even if an event handler has not been set, the channel is still receiving data at the device channel data interval. If the data is going to be handled by software at a known rate, matching that rate to the device channel data interval can reduce CPU and network load, and reduce power consumption on some devices (many VINT devices will sleep between data samples if data interval is large enough). If software is only interested in the data when it changes, setting the ChangeTrigger
may be more appropriate.
Change Trigger
The ChangeTrigger
property of a channel enables a filter that only passes data when that data has changed by an amount greater than or equal to the ChangeTrigger
. For example, if the DataInterval
was set to 0.7, new data would only be delivered to the channel when that new data differed from the previously delivered data by at least 0.7.
It is often useful to set a change trigger to reduce the apparent noise on a channel, or to only receive data change events when meaningful thresholds are reached. For example, an application that displayed temperature on an LCD may only be interested on 0.5°C changes. By setting the ChangeTrigger
to 0.5, the only data that would be receive would be data of interest.
Setting Both Properties
In many cases, it is likely that you'll simply use these properties as follows:
- Keep the
ChangeTrigger
at zero and select theDataInterval
based on how often you want your program to receive data. This configuration is useful in data logging applications and when data will be represented in a graph. - Keep the
DataInterval
at a minimal interval, and set theChangeTrigger
to the lowest relevant value for the quality you are measuring. This is useful for applications were you want to ignore values below a certain threshold or are displaying sensor values.
However, in some complex situations, you may want to set both the ChangeTrigger
and the DataInterval
to non-trivial values. This will result in expected behavior: The channel will check at the DataInterval
whether or not the new data differs from the last delivered data by an amount greater than or equal to the ChangeTrigger
. If the data passes the change trigger filter, that data will be delivered, if the data does not, the channel will wait until the next data interval and check again.
The only complication is when you consider a situation where the value has spiked by a large amount and then returned to the baseline, in-between intervals. For example, suppose you have a voltage sensor and you've set the DataInterval to 5 milliseconds an the VoltageChangeTrigger to 3mV. The way this is handled depends on whether you're using a USB Phidget or a VINT Phidget:
USB Phidgets
In this example, the blue data points represent the real value of the voltage at any given time. The thick black bars represent the sampling interval, which is 5 milliseconds. When a USB Phidget samples at a slower rate than its default, it will average the last interval worth of samples together and report that value on each interval. This average is represented by the orange data point that lands on each interval line. It is this average that is compared against the change trigger to decide whether or not a data event fires or not. Let's step through each interval:
Interval 1 (0-5ms): The voltage stays mostly stable throughout this interval. The average at the end of the interval is 20mV, which is no different than our first sample. Since our change trigger is 3mV, an event does not fire at the 5ms mark.
Interval 2 (5-10ms): In this interval, the voltage spikes to 30mV and then drops back down. The average for this interval is 23mV, which is 3mV higher than our last event at 0ms. Thus, the change is sufficient to cause a data even to fire at 10ms.
Interval 3 (10-15ms): In this interval, the voltage drops down to 10mV and then rises close to 30mV. The average for this interval is 21mV, which is only 2mV off from our last event. Since this does not meet our change trigger, an event does not fire.
Interval 4 (15-20ms): In this interval, the voltage remains relatively stable at around 28mV. However, the average for this interval is 29mV, which is much higher than our last data event (23mV). This change of 6mV is greater than our change trigger, so an event fires.
VINT Phidgets
Let's see how a VINT devices behaves in the same example. Now, instead of averaging all of the values in the past interval, the VINT device goes to sleep to save power. That means it only cares about the data values on each interval line, and ignores all others.
Interval 1 (0-5ms): The device wakes up and sees a value of 20mV, which is no different than the starting value of 20mV. No event is fired.
Interval 2 (5-10ms): The device wakes up and sees 22mV, which does not differ enough from the last event of 20mV, as our change trigger is 3mV. No event is fired.
Interval 3 (10-15ms): The device wakes up and sees 29mV, which is enough of a change to fire a data event.
Interval 4 (15-20ms): The device wakes up and sees 30mV, which is only 1mV off from the last event, which is not sufficient to trigger a new event.
Further Reading
Phidget Programming Basics - Here you can find the basic concepts to help you get started with making your own programs that use Phidgets.
Polling vs. Events - Your program can gather data in either a polling-driven or event-driven manner. Learn the difference to determine which is best for your application.
Using Multiple Phidgets - Learn how to use more than one Phidget in your program. This page will guide you through the steps.
Logging, Exceptions, and Errors - Learn about all the tools you can use to debug your program.
Phidget Network Server - Phidgets can be controlled and communicated with over your network- either wirelessly or over ethernet.
Best Phidgets Practices - Good programming habits that will save you from common problems when writing code for your Phidgets.