Phidgets Support - User contributions [en]

Spatial Guide

2024-01-19T19:58:55Z

Jdecoux: /* Introduction to AHRS/IMU */

{{#seo:|description=Phidget Spatials combine data from accelerometers, magneometers, and gyroscopes into one sensor. This guide explains how the sensors are combined using AHRS, what you can do with this data.}}
{{#seo:|keywords=accelerometer, gyroscope, magnetometer}}

[[Category:IntroGuide]]
{{TOC limit|3}}

==Spatial Sensors and Their Uses==
[[Image:Spatial_Intro.jpg|link=|center]]
===Introduction to AHRS===
Spatial sensors from Phidgets use AHRS (Attitude and Heading Reference System) algorithms to combine data from accelerometers, magnetometers and gyroscopes into a calculation of the device’s orientation more precise than could be achieved by any of the sensors individually.

While this process is by no means straightforward, PhidgetSpatial sensors come with built-in AHRS calculations combining data from all three types of sensors out of the box. By using the Phidget Spatial object in your code, you can get a direct reading of the heading of your device, in both Euler angle and Quaternion form.

===Euler Angles===
[[File:EulerAngles.jpg|330px|link=|thumb|A Representation of Euler Angles]]
Euler angles are a measure of an object’s orientation in the form of pitch, roll, and yaw angles. The advantage of Euler angles in denoting heading is that they are relatively easy to visualise.
You can get the Euler angles of your sensor directly from the Phidgets library.

While they are a human-friendly way of denoting overall orientation, we strongly recommend against using Euler angles in post-processing calculations, as they can be susceptible to problems of [https://en.wikipedia.org/wiki/Gimbal_lock#In_applied_mathematics gimbal lock]. For applications requiring more adjustments than a simple heading offset, we recommend using quaternions.

===Quaternions===
[[Image:quarternion.jpg|thumb|link=|A Visualization of Quaternions]]
For applications that require more complex analysis, PhidgetSpatial devices also provide the orientation of the device using quaternions. Quaternions are a more mathematically complete way of denoting orientation and rotations of a system. For what they lose in intuitiveness, the advantage of quaternions is that they can be used in any number of complex calculations without the risk of the aforementioned gimbal lock.

For most practical purposes, it helps to remember that quaternions are not meant to be visualized, or dealt with directly. Instead, any program or library that uses them will have functions to perform calculations with them behind the scenes. If you don’t yet have such a library in your program, but need to use quaternions, we recommend finding one, rather than wading through the math yourself. In this way, while they are difficult to visualize, you can at least remain comfortable in the knowledge that one does not often need to fully understand quaternions to use them in an application.

Quaternions tend to be the preferred rotation system for programs that deal with 3D objects, like Unity, and their inclusion as an output directly from a PhidgetSpatial is designed to make sensor integration as seamless as possible.

===What Does AHRS Actually Do?===
The AHRS algorithm on Phidgets uses an accelerometer and a magnetometer to keep track of heading over long timescales. When the device is perceived to be at rest, the heading and gyroscopes are gradually aligned and zeroed to reflect that the device is not moving, and pointed towards combined direction from the magnetometer and accelerometer readings. When the device is in motion, the AHRS algorithm starts relying more heavily on the gyroscope for angular rotations, since the accelerometer may no longer be pointing straight down, and the field from the compass may be in flux. By adjusting how much the device relies on the gyroscope in place of the accelerometer and magnetometer, a smoother and more accurate profile of the device’s orientation can be achieved than by using any of the sensors alone.

===Temperature Stabilization===
Electronic accelerometers and gyroscopes are sensitive to changes in temperature to a small but measurable degree. For cases where long term accuracy is a priority, some of our Spatial sensors have a temperature stabilization feature which allows the boards to heat themselves up to a pre-defined constant temperature (typically 45 or 50°C) to reduce or eliminate drift due to temperature effects.

When using the temperature stabilization feature, it is very important to wait for the board to be fully heated and settled before use, as the process of heating the board will change the sensor readings as the temperature rises to the target. Phidgets that allow temperature stabilization are calibrated at their target temperature, so the sensors will produce more accurate results once heated.

If you are using a temperature-stabilized spatial sensor, it is also very important to keep the board in its enclosure or otherwise insulated from outside air, as air moving directly over the warmed sensors will cause worse results than if the board was not heated at all.

==Demonstrations Using the Control Panel Example==
'''''Note: '''If your control panel example does not resemble the following, be sure to update your Phidget Control Panel. If your example still doesn't match, your Spatial Phidget is likely too old to support built-in AHRS calculations.''

[[File:Spatial_Example_AlignModel.jpg|400px|link=|thumb|Click the ''Align Model'' button to align the AHRS model to your screen]]

The spatial example gives you a way to directly visualize the results from the AHRS algorithm used on Phidget Spatial sensors. We recommend using this example with the sensor in hand at your desk to help visualize the effectiveness of the algorithm.

The first thing you might notice is that the model doesn’t appear to match the orientation of the spatial in your hand. To make the AHRS model line up with your physical spatial, point the wire at the screen and click Align Model. Your spatial model should now mirror the movements of the spatial in your hand.

The AHRS compass drawing is also provided as a visual indicator of the Heading, independent of the screen location. Notice that the compass bearing indicates north when the left-hand side of the Phidget is pointed north.

If your sensor has a heating option, be sure to check the ''Heating Enabled'' box, and wait until the temperature reading stays green for best results. In your own programs, wait until the temperature reaches 45C, and then if possible give the sensor an additional minute or two to ensure the whole board is evenly heated.

===AHRS Settings===
[[File:Spatial_Example_AHRS_Settings.jpg|400px|link=|thumb|The AHRS Settings Box]]
Now we can look at the AHRS settings panel:
====Algorithm====
The algorithm setting dictates whether or not the compass is going to be factored into calculations.

*'''AHRS: '''When setting Algorithm to AHRS (the default setting) heading is gradually re-aligned with the compass over time, and all headings will be relative to magnetic north. When you Zero the AHRS algorithm, it will forcibly realign the heading to the compass reading.

*'''IMU: '''When using IMU, the compass readings are ignored, and a heading of 0° corresponds to the direction the device was facing when it was started, or where it was last zeroed. By clicking the Zero Algorithm button, it will realign all calculations to reference the direction it is currently facing as the new 0° heading.

====Zero Algorithm====
The Zero Algorithm button centers the algorithm’s heading either on the compass reading or on the direction it is currently facing (see AHRS Mode). The accumulated gyro biases will also be dropped, reverting to the raw (zeroed) gyro measurements. Note that the initial position in AHRS mode can vary by a couple degrees initially, due to noise inherent in the compass measurements. Click ''Zero Algorithm'' a few times now to see this for yourself. This noise will be averaged out by the rest of the algorithm, and it should settle into a consistent position after a couple seconds.

''If you find the model is drifting more than 2-3 degrees immediately after Zeroing the algorithm (while the spatial is staying still) you may want to try zeroing the gyroscope for better results.''

====Zero Gyro====
Before zeroing the gyroscope, ensure it is securely at rest. Zeroing the gyroscope will average the gyroscope’s readings for a second or two, and automatically subtract the result from subsequent measurements. This is a way to combat drift in the gyros, and we recommend finding a way to zero the gyros before starting AHRS calculations. The results of zeroing the gyro will only persist for as long as it remains open.

''If explicitly zeroing the gyro is not practical in your application, you can consider running the AHRS algorithm briefly with a wide ''Angular Velocity Threshold'', then narrowing said threshold again once the system has a chance to compensate for drift on its own.''

===AHRS Parameters===
[[File:Spatial_Example_AHRS_Parameters.jpg|400px|link=|thumb|The AHRS Parameters Box]]
The AHRS parameters are used to determine certain characteristics of your system so the AHRS algorithm can make better assumptions about the movement in your system. Each of these parameters will have recommended values as a starting point for your Phidget in a [[#Suggested Parameters|table]] below.

All AHRS settings will apply to a system using the IMU algorithm in exactly the same ways, except the compass readings and related settings will be ignored when using IMU.

====Angular Velocity Threshold====
This is the minimum reading from your gyroscopes that the device will use to assume the device is at rest. While the device assumes it is at rest, it will gradually adjust towards making the current gyro readings the new “zero”, compensating for drift over time. This value can be significantly lower if you have zeroed your gyroscope before zeroing the algorithm, as the pre-existing drift of the gyros will have been accounted for. Otherwise, this value will need to be large enough to overcome any pre-existing offsets in your gyro.

''The closer you can set this value to zero, the slower the device needs to turn (or think it’s turning) to stop adjusting the gyro biases. If this value is too high, the gyros can be biased away from what is truly stationary. If this value is too low, the gyros will never adjust their bias, and you will see drift over time.''

====Angular Velocity Delta Threshold====
This is the minimum change between gyroscope samples before the gyro stops thinking it’s at rest. You can get a good value for this from the gyroscope example after installing the gyro in your application. Simply open the graphs for all axes, and set this value near the peak-to-peak noise.

''If this value is too low, the device will never think it's at rest. If it's too high, certain vibrations could affect your gyro biases (though the effects of these may also be limited by the Angular Velocity Threshold).''

====Acceleration Threshold====
The minimum measured acceleration your system will assume it is at rest, minus gravity. This value is also used to determine how much motion is accepted before the device begins to ignore the acceleration vector as a reliable source of “down”, and relies entirely on the gyros for pitch and roll until the device stops again. Again, you can use the noise in the graphs from your accelerometer example to get a baseline of the noise, and choose a value accordingly.

''If this value is too high, your device can adjust to thinking “down” is the wrong direction, or be swayed by fast motions. If this value is too low, the device may never think it is at rest to begin the process of correcting its pitch and roll.''

====Mag Time====
The amount of time (in seconds) your system will take to re-adjust the heading 95% of the way to aligning with the compass bearing, for differences in compass bearing and AHRS heading less than 15 degrees. Outside of 15 degrees of error, this is the time it will take the AHRS heading to correct towards the compass bearing by 45 degrees, to help limit adverse effects of interference. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more (but never entirely) resistant to magnetic interference, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the magnetic field readings. If this value is low enough, white noise in your compass readings will begin to show up in your measured heading.''

====Accel Time====
The amount of time (in seconds) your system will take to realign your pitch and roll to the acceleration vector, once the device believes it is at rest. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more resistant to acceleration affecting orientation, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the accelerometer readings (limited by the above Acceleration Threshold).''

====Bias Time====
If the sensor is deemed to be at rest, a “bias” parameter internal to the algorithm is slowly added to the gyroscope to compensate for any drift. Effectively, this will automatically gradually zero the gyro readings internal to the algorithm, reducing or eliminating the effects of drift. The time specified here (in seconds) is the time it takes to adjust the bias parameters to compensate for 95% of the gyro’s offsets once the device is at rest.

''The speed the gyros should be biased is a balance between getting a solid average and having the zeroing occur quickly enough that biases can be fully compensated for during short periods or rest.''

===Example===
[[File:AHRS_Example_Menu.jpg|400px|link=|thumb|The AHRS Example Parameter Selection]]
To get the best precision we recommend tuning these parameters as best fits your application. However, we have provided some sample values to make a couple demonstrations, and to give you some idea of how to adapt these parameters to certain situations.

To more easily set up these example cases, this dropdown provides a list of settings for generic cases, and demonstrations of how you might adapt these values to certain scenarios.

====General Purpose====
A set of values selected for your device that should work “well enough” out of the box for simple situations, such as moving the device around with your hand.

====No Gyro====
To demonstrate why gyroscopes are an essential part of AHRS, we’ve given some settings that will effectively ignore any input from the gyroscopes, and snap to the magnetometer and accelerometer readings alone. You will notice this is incredibly noisy, especially if you start moving the sensor around.

''We do not recommend using these settings in practice.''

====All Gyro====
For completeness, we have included a selection to set AHRS to more or less ignore input from the magnetometers and accelerometers. By selecting this sample, you can see how the gyroscopes will drift over time and fast motions, clearly demonstrating the need for the accelerometer and magnetometer to bring the gyros back into alignment.

''We do not recommend using these settings in practice.''

====Zeroed====
If you are able to zero your gyroscopes, and your application is relatively free of vibrations, you should be able to use a narrower Angular Velocity Threshold. As a result, you may also be able to relax the ''Mag Time'' and ''Accel Time'' parameters, since you can better trust that the gyroscopes will only be re-biased when they are truly not rotating.

====High Vibrations====
Regardless of whether or not you can zero your gyroscope, if your system suffers from constant large vibrations, the AHRS thresholds will have to be relaxed to allow the gyros to be biased at all. In doing so, we also raise the ''Accel Time'', not because we can trust the gyroscopes more in this scenario, but rather because we must trust the accelerometer less. Assuming there is little magnetic noise, ''Mag Time'' can be decreased to snap the heading closer to the magnetic field.

===Suggested Parameters===
{| class="wikitable" style="text-align: center;"
! !! Angular Velocity Threshold !! Angular Vel Delta Threshold !! Acceleration Threshold !! Mag Time !! Accel Time !! Bias Time
|-
! MOT1102 || 2.0 || 0.6 || 0.1 || 5 || 5 || 1.25
|-
! MOT0109 ''Out of the Box'' || 1.0 || 0.1 || 0.05 || 10 || 10 || 1.25
|-
! MOT0109 ''Heated and Zeroed'' || 0.5 || 0.1 || 0.05 || 120 || 120 || 1.25
|}

===Choosing a Phidget Spatial===
The Spatial Phidget you use in your application will depend on how accurate certain aspects of your measurement need to be. To simplify the decision, we can narrow this down to various kinds of applicaitons:

{|
! Applicaiton !! Phidget
|-
| Navigation or Outdoor Usage || [{{SERVER}}/products.php?product_id=MOT0110 MOT0110 PhidgetSpatial Precision 3/3/3]
|-
| Gestures and Qualitative Effects || [{{SERVER}}/products.php?product_id=MOT1102 MOT1102 Spatial Phidget]
|}

==FAQ==

===Why does the Euler Angle for pitch never exceed 90 degrees?===
The Euler Angles provided by the Phidgets library are calculated directly from a corresponding quaternion. They do not take into account past movements, so the orientation of a board that passes 90 degrees in pitch can just as easily be represented by a pitch of less than 90 degrees, with different roll and heading parameters. This is one reason why Euler Angles are not recommended for use in serious calculations, in favor of using the corresponding quaternions.

===Why do the Euler Angle readings stop working as well near 90 degrees of pitch?===
This is actually a good example of gimbal lock, and why it is not advised to use Euler Angles in calculation. When pitch approaches 90 degrees, the roll and yaw axes start to line up, which makes it hard to distinguish one from the other. In other words, at 90 degrees of pitch, a change in roll could just as easily be a change in heading, and vice-versa. This is another reason we recommend quaternions for all serious calculations.

Spatial Guide

2024-01-19T19:57:47Z

Jdecoux: /* Introduction to AHRS */

{{#seo:|description=Phidget Spatials combine data from accelerometers, magneometers, and gyroscopes into one sensor. This guide explains how the sensors are combined using AHRS, what you can do with this data.}}
{{#seo:|keywords=accelerometer, gyroscope, magnetometer}}

[[Category:IntroGuide]]
{{TOC limit|3}}

==Spatial Sensors and Their Uses==
[[Image:Spatial_Intro.jpg|link=|center]]
===Introduction to AHRS/IMU===
Spatial sensors from Phidgets use AHRS (Attitude and Heading Reference System) or IMU algorithms to combine data from accelerometers, magnetometers and gyroscopes into a calculation of the device’s orientation more precise than could be achieved by any of the sensors individually.

While this process is by no means straightforward, PhidgetSpatial sensors come with built-in AHRS calculations combining data from all three types of sensors out of the box. By using the Phidget Spatial object in your code, you can get a direct reading of the heading of your device, in both Euler angle and Quaternion form.

===Euler Angles===
[[File:EulerAngles.jpg|330px|link=|thumb|A Representation of Euler Angles]]
Euler angles are a measure of an object’s orientation in the form of pitch, roll, and yaw angles. The advantage of Euler angles in denoting heading is that they are relatively easy to visualise.
You can get the Euler angles of your sensor directly from the Phidgets library.

While they are a human-friendly way of denoting overall orientation, we strongly recommend against using Euler angles in post-processing calculations, as they can be susceptible to problems of [https://en.wikipedia.org/wiki/Gimbal_lock#In_applied_mathematics gimbal lock]. For applications requiring more adjustments than a simple heading offset, we recommend using quaternions.

===Quaternions===
[[Image:quarternion.jpg|thumb|link=|A Visualization of Quaternions]]
For applications that require more complex analysis, PhidgetSpatial devices also provide the orientation of the device using quaternions. Quaternions are a more mathematically complete way of denoting orientation and rotations of a system. For what they lose in intuitiveness, the advantage of quaternions is that they can be used in any number of complex calculations without the risk of the aforementioned gimbal lock.

For most practical purposes, it helps to remember that quaternions are not meant to be visualized, or dealt with directly. Instead, any program or library that uses them will have functions to perform calculations with them behind the scenes. If you don’t yet have such a library in your program, but need to use quaternions, we recommend finding one, rather than wading through the math yourself. In this way, while they are difficult to visualize, you can at least remain comfortable in the knowledge that one does not often need to fully understand quaternions to use them in an application.

Quaternions tend to be the preferred rotation system for programs that deal with 3D objects, like Unity, and their inclusion as an output directly from a PhidgetSpatial is designed to make sensor integration as seamless as possible.

===What Does AHRS Actually Do?===
The AHRS algorithm on Phidgets uses an accelerometer and a magnetometer to keep track of heading over long timescales. When the device is perceived to be at rest, the heading and gyroscopes are gradually aligned and zeroed to reflect that the device is not moving, and pointed towards combined direction from the magnetometer and accelerometer readings. When the device is in motion, the AHRS algorithm starts relying more heavily on the gyroscope for angular rotations, since the accelerometer may no longer be pointing straight down, and the field from the compass may be in flux. By adjusting how much the device relies on the gyroscope in place of the accelerometer and magnetometer, a smoother and more accurate profile of the device’s orientation can be achieved than by using any of the sensors alone.

===Temperature Stabilization===
Electronic accelerometers and gyroscopes are sensitive to changes in temperature to a small but measurable degree. For cases where long term accuracy is a priority, some of our Spatial sensors have a temperature stabilization feature which allows the boards to heat themselves up to a pre-defined constant temperature (typically 45 or 50°C) to reduce or eliminate drift due to temperature effects.

When using the temperature stabilization feature, it is very important to wait for the board to be fully heated and settled before use, as the process of heating the board will change the sensor readings as the temperature rises to the target. Phidgets that allow temperature stabilization are calibrated at their target temperature, so the sensors will produce more accurate results once heated.

If you are using a temperature-stabilized spatial sensor, it is also very important to keep the board in its enclosure or otherwise insulated from outside air, as air moving directly over the warmed sensors will cause worse results than if the board was not heated at all.

==Demonstrations Using the Control Panel Example==
'''''Note: '''If your control panel example does not resemble the following, be sure to update your Phidget Control Panel. If your example still doesn't match, your Spatial Phidget is likely too old to support built-in AHRS calculations.''

[[File:Spatial_Example_AlignModel.jpg|400px|link=|thumb|Click the ''Align Model'' button to align the AHRS model to your screen]]

The spatial example gives you a way to directly visualize the results from the AHRS algorithm used on Phidget Spatial sensors. We recommend using this example with the sensor in hand at your desk to help visualize the effectiveness of the algorithm.

The first thing you might notice is that the model doesn’t appear to match the orientation of the spatial in your hand. To make the AHRS model line up with your physical spatial, point the wire at the screen and click Align Model. Your spatial model should now mirror the movements of the spatial in your hand.

The AHRS compass drawing is also provided as a visual indicator of the Heading, independent of the screen location. Notice that the compass bearing indicates north when the left-hand side of the Phidget is pointed north.

If your sensor has a heating option, be sure to check the ''Heating Enabled'' box, and wait until the temperature reading stays green for best results. In your own programs, wait until the temperature reaches 45C, and then if possible give the sensor an additional minute or two to ensure the whole board is evenly heated.

===AHRS Settings===
[[File:Spatial_Example_AHRS_Settings.jpg|400px|link=|thumb|The AHRS Settings Box]]
Now we can look at the AHRS settings panel:
====Algorithm====
The algorithm setting dictates whether or not the compass is going to be factored into calculations.

*'''AHRS: '''When setting Algorithm to AHRS (the default setting) heading is gradually re-aligned with the compass over time, and all headings will be relative to magnetic north. When you Zero the AHRS algorithm, it will forcibly realign the heading to the compass reading.

*'''IMU: '''When using IMU, the compass readings are ignored, and a heading of 0° corresponds to the direction the device was facing when it was started, or where it was last zeroed. By clicking the Zero Algorithm button, it will realign all calculations to reference the direction it is currently facing as the new 0° heading.

====Zero Algorithm====
The Zero Algorithm button centers the algorithm’s heading either on the compass reading or on the direction it is currently facing (see AHRS Mode). The accumulated gyro biases will also be dropped, reverting to the raw (zeroed) gyro measurements. Note that the initial position in AHRS mode can vary by a couple degrees initially, due to noise inherent in the compass measurements. Click ''Zero Algorithm'' a few times now to see this for yourself. This noise will be averaged out by the rest of the algorithm, and it should settle into a consistent position after a couple seconds.

''If you find the model is drifting more than 2-3 degrees immediately after Zeroing the algorithm (while the spatial is staying still) you may want to try zeroing the gyroscope for better results.''

====Zero Gyro====
Before zeroing the gyroscope, ensure it is securely at rest. Zeroing the gyroscope will average the gyroscope’s readings for a second or two, and automatically subtract the result from subsequent measurements. This is a way to combat drift in the gyros, and we recommend finding a way to zero the gyros before starting AHRS calculations. The results of zeroing the gyro will only persist for as long as it remains open.

''If explicitly zeroing the gyro is not practical in your application, you can consider running the AHRS algorithm briefly with a wide ''Angular Velocity Threshold'', then narrowing said threshold again once the system has a chance to compensate for drift on its own.''

===AHRS Parameters===
[[File:Spatial_Example_AHRS_Parameters.jpg|400px|link=|thumb|The AHRS Parameters Box]]
The AHRS parameters are used to determine certain characteristics of your system so the AHRS algorithm can make better assumptions about the movement in your system. Each of these parameters will have recommended values as a starting point for your Phidget in a [[#Suggested Parameters|table]] below.

All AHRS settings will apply to a system using the IMU algorithm in exactly the same ways, except the compass readings and related settings will be ignored when using IMU.

====Angular Velocity Threshold====
This is the minimum reading from your gyroscopes that the device will use to assume the device is at rest. While the device assumes it is at rest, it will gradually adjust towards making the current gyro readings the new “zero”, compensating for drift over time. This value can be significantly lower if you have zeroed your gyroscope before zeroing the algorithm, as the pre-existing drift of the gyros will have been accounted for. Otherwise, this value will need to be large enough to overcome any pre-existing offsets in your gyro.

''The closer you can set this value to zero, the slower the device needs to turn (or think it’s turning) to stop adjusting the gyro biases. If this value is too high, the gyros can be biased away from what is truly stationary. If this value is too low, the gyros will never adjust their bias, and you will see drift over time.''

====Angular Velocity Delta Threshold====
This is the minimum change between gyroscope samples before the gyro stops thinking it’s at rest. You can get a good value for this from the gyroscope example after installing the gyro in your application. Simply open the graphs for all axes, and set this value near the peak-to-peak noise.

''If this value is too low, the device will never think it's at rest. If it's too high, certain vibrations could affect your gyro biases (though the effects of these may also be limited by the Angular Velocity Threshold).''

====Acceleration Threshold====
The minimum measured acceleration your system will assume it is at rest, minus gravity. This value is also used to determine how much motion is accepted before the device begins to ignore the acceleration vector as a reliable source of “down”, and relies entirely on the gyros for pitch and roll until the device stops again. Again, you can use the noise in the graphs from your accelerometer example to get a baseline of the noise, and choose a value accordingly.

''If this value is too high, your device can adjust to thinking “down” is the wrong direction, or be swayed by fast motions. If this value is too low, the device may never think it is at rest to begin the process of correcting its pitch and roll.''

====Mag Time====
The amount of time (in seconds) your system will take to re-adjust the heading 95% of the way to aligning with the compass bearing, for differences in compass bearing and AHRS heading less than 15 degrees. Outside of 15 degrees of error, this is the time it will take the AHRS heading to correct towards the compass bearing by 45 degrees, to help limit adverse effects of interference. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more (but never entirely) resistant to magnetic interference, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the magnetic field readings. If this value is low enough, white noise in your compass readings will begin to show up in your measured heading.''

====Accel Time====
The amount of time (in seconds) your system will take to realign your pitch and roll to the acceleration vector, once the device believes it is at rest. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more resistant to acceleration affecting orientation, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the accelerometer readings (limited by the above Acceleration Threshold).''

====Bias Time====
If the sensor is deemed to be at rest, a “bias” parameter internal to the algorithm is slowly added to the gyroscope to compensate for any drift. Effectively, this will automatically gradually zero the gyro readings internal to the algorithm, reducing or eliminating the effects of drift. The time specified here (in seconds) is the time it takes to adjust the bias parameters to compensate for 95% of the gyro’s offsets once the device is at rest.

''The speed the gyros should be biased is a balance between getting a solid average and having the zeroing occur quickly enough that biases can be fully compensated for during short periods or rest.''

===Example===
[[File:AHRS_Example_Menu.jpg|400px|link=|thumb|The AHRS Example Parameter Selection]]
To get the best precision we recommend tuning these parameters as best fits your application. However, we have provided some sample values to make a couple demonstrations, and to give you some idea of how to adapt these parameters to certain situations.

To more easily set up these example cases, this dropdown provides a list of settings for generic cases, and demonstrations of how you might adapt these values to certain scenarios.

====General Purpose====
A set of values selected for your device that should work “well enough” out of the box for simple situations, such as moving the device around with your hand.

====No Gyro====
To demonstrate why gyroscopes are an essential part of AHRS, we’ve given some settings that will effectively ignore any input from the gyroscopes, and snap to the magnetometer and accelerometer readings alone. You will notice this is incredibly noisy, especially if you start moving the sensor around.

''We do not recommend using these settings in practice.''

====All Gyro====
For completeness, we have included a selection to set AHRS to more or less ignore input from the magnetometers and accelerometers. By selecting this sample, you can see how the gyroscopes will drift over time and fast motions, clearly demonstrating the need for the accelerometer and magnetometer to bring the gyros back into alignment.

''We do not recommend using these settings in practice.''

====Zeroed====
If you are able to zero your gyroscopes, and your application is relatively free of vibrations, you should be able to use a narrower Angular Velocity Threshold. As a result, you may also be able to relax the ''Mag Time'' and ''Accel Time'' parameters, since you can better trust that the gyroscopes will only be re-biased when they are truly not rotating.

====High Vibrations====
Regardless of whether or not you can zero your gyroscope, if your system suffers from constant large vibrations, the AHRS thresholds will have to be relaxed to allow the gyros to be biased at all. In doing so, we also raise the ''Accel Time'', not because we can trust the gyroscopes more in this scenario, but rather because we must trust the accelerometer less. Assuming there is little magnetic noise, ''Mag Time'' can be decreased to snap the heading closer to the magnetic field.

===Suggested Parameters===
{| class="wikitable" style="text-align: center;"
! !! Angular Velocity Threshold !! Angular Vel Delta Threshold !! Acceleration Threshold !! Mag Time !! Accel Time !! Bias Time
|-
! MOT1102 || 2.0 || 0.6 || 0.1 || 5 || 5 || 1.25
|-
! MOT0109 ''Out of the Box'' || 1.0 || 0.1 || 0.05 || 10 || 10 || 1.25
|-
! MOT0109 ''Heated and Zeroed'' || 0.5 || 0.1 || 0.05 || 120 || 120 || 1.25
|}

===Choosing a Phidget Spatial===
The Spatial Phidget you use in your application will depend on how accurate certain aspects of your measurement need to be. To simplify the decision, we can narrow this down to various kinds of applicaitons:

{|
! Applicaiton !! Phidget
|-
| Navigation or Outdoor Usage || [{{SERVER}}/products.php?product_id=MOT0110 MOT0110 PhidgetSpatial Precision 3/3/3]
|-
| Gestures and Qualitative Effects || [{{SERVER}}/products.php?product_id=MOT1102 MOT1102 Spatial Phidget]
|}

==FAQ==

===Why does the Euler Angle for pitch never exceed 90 degrees?===
The Euler Angles provided by the Phidgets library are calculated directly from a corresponding quaternion. They do not take into account past movements, so the orientation of a board that passes 90 degrees in pitch can just as easily be represented by a pitch of less than 90 degrees, with different roll and heading parameters. This is one reason why Euler Angles are not recommended for use in serious calculations, in favor of using the corresponding quaternions.

===Why do the Euler Angle readings stop working as well near 90 degrees of pitch?===
This is actually a good example of gimbal lock, and why it is not advised to use Euler Angles in calculation. When pitch approaches 90 degrees, the roll and yaw axes start to line up, which makes it hard to distinguish one from the other. In other words, at 90 degrees of pitch, a change in roll could just as easily be a change in heading, and vice-versa. This is another reason we recommend quaternions for all serious calculations.

Spatial Guide

2024-01-18T18:40:13Z

Jdecoux: /* AHRS Parameters */

{{#seo:|description=Phidget Spatials combine data from accelerometers, magneometers, and gyroscopes into one sensor. This guide explains how the sensors are combined using AHRS, what you can do with this data.}}
{{#seo:|keywords=accelerometer, gyroscope, magnetometer}}

[[Category:IntroGuide]]
{{TOC limit|3}}

==Spatial Sensors and Their Uses==
[[Image:Spatial_Intro.jpg|link=|center]]
===Introduction to AHRS===
Spatial sensors from Phidgets use AHRS (Attitude and Heading Reference System) as a means of combining data from accelerometers, magnetometers and gyroscopes into a calculation of the device’s orientation more precise than could be achieved by any of the sensors individually.

While this process is by no means straightforward, PhidgetSpatial sensors come with built-in AHRS calculations combining data from all three types of sensors out of the box. By using the Phidget Spatial object in your code, you can get a direct reading of the heading of your device, in both Euler angle and Quaternion form.

===Euler Angles===
[[File:EulerAngles.jpg|330px|link=|thumb|A Representation of Euler Angles]]
Euler angles are a measure of an object’s orientation in the form of pitch, roll, and yaw angles. The advantage of Euler angles in denoting heading is that they are relatively easy to visualise.
You can get the Euler angles of your sensor directly from the Phidgets library.

While they are a human-friendly way of denoting overall orientation, we strongly recommend against using Euler angles in post-processing calculations, as they can be susceptible to problems of [https://en.wikipedia.org/wiki/Gimbal_lock#In_applied_mathematics gimbal lock]. For applications requiring more adjustments than a simple heading offset, we recommend using quaternions.

===Quaternions===
[[Image:quarternion.jpg|thumb|link=|A Visualization of Quaternions]]
For applications that require more complex analysis, PhidgetSpatial devices also provide the orientation of the device using quaternions. Quaternions are a more mathematically complete way of denoting orientation and rotations of a system. For what they lose in intuitiveness, the advantage of quaternions is that they can be used in any number of complex calculations without the risk of the aforementioned gimbal lock.

For most practical purposes, it helps to remember that quaternions are not meant to be visualized, or dealt with directly. Instead, any program or library that uses them will have functions to perform calculations with them behind the scenes. If you don’t yet have such a library in your program, but need to use quaternions, we recommend finding one, rather than wading through the math yourself. In this way, while they are difficult to visualize, you can at least remain comfortable in the knowledge that one does not often need to fully understand quaternions to use them in an application.

Quaternions tend to be the preferred rotation system for programs that deal with 3D objects, like Unity, and their inclusion as an output directly from a PhidgetSpatial is designed to make sensor integration as seamless as possible.

===What Does AHRS Actually Do?===
The AHRS algorithm on Phidgets uses an accelerometer and a magnetometer to keep track of heading over long timescales. When the device is perceived to be at rest, the heading and gyroscopes are gradually aligned and zeroed to reflect that the device is not moving, and pointed towards combined direction from the magnetometer and accelerometer readings. When the device is in motion, the AHRS algorithm starts relying more heavily on the gyroscope for angular rotations, since the accelerometer may no longer be pointing straight down, and the field from the compass may be in flux. By adjusting how much the device relies on the gyroscope in place of the accelerometer and magnetometer, a smoother and more accurate profile of the device’s orientation can be achieved than by using any of the sensors alone.

===Temperature Stabilization===
Electronic accelerometers and gyroscopes are sensitive to changes in temperature to a small but measurable degree. For cases where long term accuracy is a priority, some of our Spatial sensors have a temperature stabilization feature which allows the boards to heat themselves up to a pre-defined constant temperature (typically 45 or 50°C) to reduce or eliminate drift due to temperature effects.

When using the temperature stabilization feature, it is very important to wait for the board to be fully heated and settled before use, as the process of heating the board will change the sensor readings as the temperature rises to the target. Phidgets that allow temperature stabilization are calibrated at their target temperature, so the sensors will produce more accurate results once heated.

If you are using a temperature-stabilized spatial sensor, it is also very important to keep the board in its enclosure or otherwise insulated from outside air, as air moving directly over the warmed sensors will cause worse results than if the board was not heated at all.

==Demonstrations Using the Control Panel Example==
'''''Note: '''If your control panel example does not resemble the following, be sure to update your Phidget Control Panel. If your example still doesn't match, your Spatial Phidget is likely too old to support built-in AHRS calculations.''

[[File:Spatial_Example_AlignModel.jpg|400px|link=|thumb|Click the ''Align Model'' button to align the AHRS model to your screen]]

The spatial example gives you a way to directly visualize the results from the AHRS algorithm used on Phidget Spatial sensors. We recommend using this example with the sensor in hand at your desk to help visualize the effectiveness of the algorithm.

The first thing you might notice is that the model doesn’t appear to match the orientation of the spatial in your hand. To make the AHRS model line up with your physical spatial, point the wire at the screen and click Align Model. Your spatial model should now mirror the movements of the spatial in your hand.

The AHRS compass drawing is also provided as a visual indicator of the Heading, independent of the screen location. Notice that the compass bearing indicates north when the left-hand side of the Phidget is pointed north.

If your sensor has a heating option, be sure to check the ''Heating Enabled'' box, and wait until the temperature reading stays green for best results. In your own programs, wait until the temperature reaches 45C, and then if possible give the sensor an additional minute or two to ensure the whole board is evenly heated.

===AHRS Settings===
[[File:Spatial_Example_AHRS_Settings.jpg|400px|link=|thumb|The AHRS Settings Box]]
Now we can look at the AHRS settings panel:
====Algorithm====
The algorithm setting dictates whether or not the compass is going to be factored into calculations.

*'''AHRS: '''When setting Algorithm to AHRS (the default setting) heading is gradually re-aligned with the compass over time, and all headings will be relative to magnetic north. When you Zero the AHRS algorithm, it will forcibly realign the heading to the compass reading.

*'''IMU: '''When using IMU, the compass readings are ignored, and a heading of 0° corresponds to the direction the device was facing when it was started, or where it was last zeroed. By clicking the Zero Algorithm button, it will realign all calculations to reference the direction it is currently facing as the new 0° heading.

====Zero Algorithm====
The Zero Algorithm button centers the algorithm’s heading either on the compass reading or on the direction it is currently facing (see AHRS Mode). The accumulated gyro biases will also be dropped, reverting to the raw (zeroed) gyro measurements. Note that the initial position in AHRS mode can vary by a couple degrees initially, due to noise inherent in the compass measurements. Click ''Zero Algorithm'' a few times now to see this for yourself. This noise will be averaged out by the rest of the algorithm, and it should settle into a consistent position after a couple seconds.

''If you find the model is drifting more than 2-3 degrees immediately after Zeroing the algorithm (while the spatial is staying still) you may want to try zeroing the gyroscope for better results.''

====Zero Gyro====
Before zeroing the gyroscope, ensure it is securely at rest. Zeroing the gyroscope will average the gyroscope’s readings for a second or two, and automatically subtract the result from subsequent measurements. This is a way to combat drift in the gyros, and we recommend finding a way to zero the gyros before starting AHRS calculations. The results of zeroing the gyro will only persist for as long as it remains open.

''If explicitly zeroing the gyro is not practical in your application, you can consider running the AHRS algorithm briefly with a wide ''Angular Velocity Threshold'', then narrowing said threshold again once the system has a chance to compensate for drift on its own.''

===AHRS Parameters===
[[File:Spatial_Example_AHRS_Parameters.jpg|400px|link=|thumb|The AHRS Parameters Box]]
The AHRS parameters are used to determine certain characteristics of your system so the AHRS algorithm can make better assumptions about the movement in your system. Each of these parameters will have recommended values as a starting point for your Phidget in a [[#Suggested Parameters|table]] below.

All AHRS settings will apply to a system using the IMU algorithm in exactly the same ways, except the compass readings and related settings will be ignored when using IMU.

====Angular Velocity Threshold====
This is the minimum reading from your gyroscopes that the device will use to assume the device is at rest. While the device assumes it is at rest, it will gradually adjust towards making the current gyro readings the new “zero”, compensating for drift over time. This value can be significantly lower if you have zeroed your gyroscope before zeroing the algorithm, as the pre-existing drift of the gyros will have been accounted for. Otherwise, this value will need to be large enough to overcome any pre-existing offsets in your gyro.

''The closer you can set this value to zero, the slower the device needs to turn (or think it’s turning) to stop adjusting the gyro biases. If this value is too high, the gyros can be biased away from what is truly stationary. If this value is too low, the gyros will never adjust their bias, and you will see drift over time.''

====Angular Velocity Delta Threshold====
This is the minimum change between gyroscope samples before the gyro stops thinking it’s at rest. You can get a good value for this from the gyroscope example after installing the gyro in your application. Simply open the graphs for all axes, and set this value near the peak-to-peak noise.

''If this value is too low, the device will never think it's at rest. If it's too high, certain vibrations could affect your gyro biases (though the effects of these may also be limited by the Angular Velocity Threshold).''

====Acceleration Threshold====
The minimum measured acceleration your system will assume it is at rest, minus gravity. This value is also used to determine how much motion is accepted before the device begins to ignore the acceleration vector as a reliable source of “down”, and relies entirely on the gyros for pitch and roll until the device stops again. Again, you can use the noise in the graphs from your accelerometer example to get a baseline of the noise, and choose a value accordingly.

''If this value is too high, your device can adjust to thinking “down” is the wrong direction, or be swayed by fast motions. If this value is too low, the device may never think it is at rest to begin the process of correcting its pitch and roll.''

====Mag Time====
The amount of time (in seconds) your system will take to re-adjust the heading 95% of the way to aligning with the compass bearing, for differences in compass bearing and AHRS heading less than 15 degrees. Outside of 15 degrees of error, this is the time it will take the AHRS heading to correct towards the compass bearing by 45 degrees, to help limit adverse effects of interference. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more (but never entirely) resistant to magnetic interference, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the magnetic field readings. If this value is low enough, white noise in your compass readings will begin to show up in your measured heading.''

====Accel Time====
The amount of time (in seconds) your system will take to realign your pitch and roll to the acceleration vector, once the device believes it is at rest. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more resistant to acceleration affecting orientation, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the accelerometer readings (limited by the above Acceleration Threshold).''

====Bias Time====
If the sensor is deemed to be at rest, a “bias” parameter internal to the algorithm is slowly added to the gyroscope to compensate for any drift. Effectively, this will automatically gradually zero the gyro readings internal to the algorithm, reducing or eliminating the effects of drift. The time specified here (in seconds) is the time it takes to adjust the bias parameters to compensate for 95% of the gyro’s offsets once the device is at rest.

''The speed the gyros should be biased is a balance between getting a solid average and having the zeroing occur quickly enough that biases can be fully compensated for during short periods or rest.''

===Example===
[[File:AHRS_Example_Menu.jpg|400px|link=|thumb|The AHRS Example Parameter Selection]]
To get the best precision we recommend tuning these parameters as best fits your application. However, we have provided some sample values to make a couple demonstrations, and to give you some idea of how to adapt these parameters to certain situations.

To more easily set up these example cases, this dropdown provides a list of settings for generic cases, and demonstrations of how you might adapt these values to certain scenarios.

====General Purpose====
A set of values selected for your device that should work “well enough” out of the box for simple situations, such as moving the device around with your hand.

====No Gyro====
To demonstrate why gyroscopes are an essential part of AHRS, we’ve given some settings that will effectively ignore any input from the gyroscopes, and snap to the magnetometer and accelerometer readings alone. You will notice this is incredibly noisy, especially if you start moving the sensor around.

''We do not recommend using these settings in practice.''

====All Gyro====
For completeness, we have included a selection to set AHRS to more or less ignore input from the magnetometers and accelerometers. By selecting this sample, you can see how the gyroscopes will drift over time and fast motions, clearly demonstrating the need for the accelerometer and magnetometer to bring the gyros back into alignment.

''We do not recommend using these settings in practice.''

====Zeroed====
If you are able to zero your gyroscopes, and your application is relatively free of vibrations, you should be able to use a narrower Angular Velocity Threshold. As a result, you may also be able to relax the ''Mag Time'' and ''Accel Time'' parameters, since you can better trust that the gyroscopes will only be re-biased when they are truly not rotating.

====High Vibrations====
Regardless of whether or not you can zero your gyroscope, if your system suffers from constant large vibrations, the AHRS thresholds will have to be relaxed to allow the gyros to be biased at all. In doing so, we also raise the ''Accel Time'', not because we can trust the gyroscopes more in this scenario, but rather because we must trust the accelerometer less. Assuming there is little magnetic noise, ''Mag Time'' can be decreased to snap the heading closer to the magnetic field.

===Suggested Parameters===
{| class="wikitable" style="text-align: center;"
! !! Angular Velocity Threshold !! Angular Vel Delta Threshold !! Acceleration Threshold !! Mag Time !! Accel Time !! Bias Time
|-
! MOT1102 || 2.0 || 0.6 || 0.1 || 5 || 5 || 1.25
|-
! MOT0109 ''Out of the Box'' || 1.0 || 0.1 || 0.05 || 10 || 10 || 1.25
|-
! MOT0109 ''Heated and Zeroed'' || 0.5 || 0.1 || 0.05 || 120 || 120 || 1.25
|}

===Choosing a Phidget Spatial===
The Spatial Phidget you use in your application will depend on how accurate certain aspects of your measurement need to be. To simplify the decision, we can narrow this down to various kinds of applicaitons:

{|
! Applicaiton !! Phidget
|-
| Navigation or Outdoor Usage || [{{SERVER}}/products.php?product_id=MOT0110 MOT0110 PhidgetSpatial Precision 3/3/3]
|-
| Gestures and Qualitative Effects || [{{SERVER}}/products.php?product_id=MOT1102 MOT1102 Spatial Phidget]
|}

==FAQ==

===Why does the Euler Angle for pitch never exceed 90 degrees?===
The Euler Angles provided by the Phidgets library are calculated directly from a corresponding quaternion. They do not take into account past movements, so the orientation of a board that passes 90 degrees in pitch can just as easily be represented by a pitch of less than 90 degrees, with different roll and heading parameters. This is one reason why Euler Angles are not recommended for use in serious calculations, in favor of using the corresponding quaternions.

===Why do the Euler Angle readings stop working as well near 90 degrees of pitch?===
This is actually a good example of gimbal lock, and why it is not advised to use Euler Angles in calculation. When pitch approaches 90 degrees, the roll and yaw axes start to line up, which makes it hard to distinguish one from the other. In other words, at 90 degrees of pitch, a change in roll could just as easily be a change in heading, and vice-versa. This is another reason we recommend quaternions for all serious calculations.

Spatial Guide

2024-01-18T18:38:22Z

Jdecoux: /* Algorithm */

{{#seo:|description=Phidget Spatials combine data from accelerometers, magneometers, and gyroscopes into one sensor. This guide explains how the sensors are combined using AHRS, what you can do with this data.}}
{{#seo:|keywords=accelerometer, gyroscope, magnetometer}}

[[Category:IntroGuide]]
{{TOC limit|3}}

==Spatial Sensors and Their Uses==
[[Image:Spatial_Intro.jpg|link=|center]]
===Introduction to AHRS===
Spatial sensors from Phidgets use AHRS (Attitude and Heading Reference System) as a means of combining data from accelerometers, magnetometers and gyroscopes into a calculation of the device’s orientation more precise than could be achieved by any of the sensors individually.

While this process is by no means straightforward, PhidgetSpatial sensors come with built-in AHRS calculations combining data from all three types of sensors out of the box. By using the Phidget Spatial object in your code, you can get a direct reading of the heading of your device, in both Euler angle and Quaternion form.

===Euler Angles===
[[File:EulerAngles.jpg|330px|link=|thumb|A Representation of Euler Angles]]
Euler angles are a measure of an object’s orientation in the form of pitch, roll, and yaw angles. The advantage of Euler angles in denoting heading is that they are relatively easy to visualise.
You can get the Euler angles of your sensor directly from the Phidgets library.

While they are a human-friendly way of denoting overall orientation, we strongly recommend against using Euler angles in post-processing calculations, as they can be susceptible to problems of [https://en.wikipedia.org/wiki/Gimbal_lock#In_applied_mathematics gimbal lock]. For applications requiring more adjustments than a simple heading offset, we recommend using quaternions.

===Quaternions===
[[Image:quarternion.jpg|thumb|link=|A Visualization of Quaternions]]
For applications that require more complex analysis, PhidgetSpatial devices also provide the orientation of the device using quaternions. Quaternions are a more mathematically complete way of denoting orientation and rotations of a system. For what they lose in intuitiveness, the advantage of quaternions is that they can be used in any number of complex calculations without the risk of the aforementioned gimbal lock.

For most practical purposes, it helps to remember that quaternions are not meant to be visualized, or dealt with directly. Instead, any program or library that uses them will have functions to perform calculations with them behind the scenes. If you don’t yet have such a library in your program, but need to use quaternions, we recommend finding one, rather than wading through the math yourself. In this way, while they are difficult to visualize, you can at least remain comfortable in the knowledge that one does not often need to fully understand quaternions to use them in an application.

Quaternions tend to be the preferred rotation system for programs that deal with 3D objects, like Unity, and their inclusion as an output directly from a PhidgetSpatial is designed to make sensor integration as seamless as possible.

===What Does AHRS Actually Do?===
The AHRS algorithm on Phidgets uses an accelerometer and a magnetometer to keep track of heading over long timescales. When the device is perceived to be at rest, the heading and gyroscopes are gradually aligned and zeroed to reflect that the device is not moving, and pointed towards combined direction from the magnetometer and accelerometer readings. When the device is in motion, the AHRS algorithm starts relying more heavily on the gyroscope for angular rotations, since the accelerometer may no longer be pointing straight down, and the field from the compass may be in flux. By adjusting how much the device relies on the gyroscope in place of the accelerometer and magnetometer, a smoother and more accurate profile of the device’s orientation can be achieved than by using any of the sensors alone.

===Temperature Stabilization===
Electronic accelerometers and gyroscopes are sensitive to changes in temperature to a small but measurable degree. For cases where long term accuracy is a priority, some of our Spatial sensors have a temperature stabilization feature which allows the boards to heat themselves up to a pre-defined constant temperature (typically 45 or 50°C) to reduce or eliminate drift due to temperature effects.

When using the temperature stabilization feature, it is very important to wait for the board to be fully heated and settled before use, as the process of heating the board will change the sensor readings as the temperature rises to the target. Phidgets that allow temperature stabilization are calibrated at their target temperature, so the sensors will produce more accurate results once heated.

If you are using a temperature-stabilized spatial sensor, it is also very important to keep the board in its enclosure or otherwise insulated from outside air, as air moving directly over the warmed sensors will cause worse results than if the board was not heated at all.

==Demonstrations Using the Control Panel Example==
'''''Note: '''If your control panel example does not resemble the following, be sure to update your Phidget Control Panel. If your example still doesn't match, your Spatial Phidget is likely too old to support built-in AHRS calculations.''

[[File:Spatial_Example_AlignModel.jpg|400px|link=|thumb|Click the ''Align Model'' button to align the AHRS model to your screen]]

The spatial example gives you a way to directly visualize the results from the AHRS algorithm used on Phidget Spatial sensors. We recommend using this example with the sensor in hand at your desk to help visualize the effectiveness of the algorithm.

The first thing you might notice is that the model doesn’t appear to match the orientation of the spatial in your hand. To make the AHRS model line up with your physical spatial, point the wire at the screen and click Align Model. Your spatial model should now mirror the movements of the spatial in your hand.

The AHRS compass drawing is also provided as a visual indicator of the Heading, independent of the screen location. Notice that the compass bearing indicates north when the left-hand side of the Phidget is pointed north.

If your sensor has a heating option, be sure to check the ''Heating Enabled'' box, and wait until the temperature reading stays green for best results. In your own programs, wait until the temperature reaches 45C, and then if possible give the sensor an additional minute or two to ensure the whole board is evenly heated.

===AHRS Settings===
[[File:Spatial_Example_AHRS_Settings.jpg|400px|link=|thumb|The AHRS Settings Box]]
Now we can look at the AHRS settings panel:
====Algorithm====
The algorithm setting dictates whether or not the compass is going to be factored into calculations.

*'''AHRS: '''When setting Algorithm to AHRS (the default setting) heading is gradually re-aligned with the compass over time, and all headings will be relative to magnetic north. When you Zero the AHRS algorithm, it will forcibly realign the heading to the compass reading.

*'''IMU: '''When using IMU, the compass readings are ignored, and a heading of 0° corresponds to the direction the device was facing when it was started, or where it was last zeroed. By clicking the Zero Algorithm button, it will realign all calculations to reference the direction it is currently facing as the new 0° heading.

====Zero Algorithm====
The Zero Algorithm button centers the algorithm’s heading either on the compass reading or on the direction it is currently facing (see AHRS Mode). The accumulated gyro biases will also be dropped, reverting to the raw (zeroed) gyro measurements. Note that the initial position in AHRS mode can vary by a couple degrees initially, due to noise inherent in the compass measurements. Click ''Zero Algorithm'' a few times now to see this for yourself. This noise will be averaged out by the rest of the algorithm, and it should settle into a consistent position after a couple seconds.

''If you find the model is drifting more than 2-3 degrees immediately after Zeroing the algorithm (while the spatial is staying still) you may want to try zeroing the gyroscope for better results.''

====Zero Gyro====
Before zeroing the gyroscope, ensure it is securely at rest. Zeroing the gyroscope will average the gyroscope’s readings for a second or two, and automatically subtract the result from subsequent measurements. This is a way to combat drift in the gyros, and we recommend finding a way to zero the gyros before starting AHRS calculations. The results of zeroing the gyro will only persist for as long as it remains open.

''If explicitly zeroing the gyro is not practical in your application, you can consider running the AHRS algorithm briefly with a wide ''Angular Velocity Threshold'', then narrowing said threshold again once the system has a chance to compensate for drift on its own.''

===AHRS Parameters===
[[File:Spatial_Example_AHRS_Parameters.jpg|400px|link=|thumb|The AHRS Parameters Box]]
The AHRS parameters are used to determine certain characteristics of your system so the AHRS algorithm can make better assumptions about the movement in your system. Each of these parameters will have recommended values as a starting point for your Phidget in a [[#Suggested Parameters|table]] below.

====Angular Velocity Threshold====
This is the minimum reading from your gyroscopes that the device will use to assume the device is at rest. While the device assumes it is at rest, it will gradually adjust towards making the current gyro readings the new “zero”, compensating for drift over time. This value can be significantly lower if you have zeroed your gyroscope before zeroing the algorithm, as the pre-existing drift of the gyros will have been accounted for. Otherwise, this value will need to be large enough to overcome any pre-existing offsets in your gyro.

''The closer you can set this value to zero, the slower the device needs to turn (or think it’s turning) to stop adjusting the gyro biases. If this value is too high, the gyros can be biased away from what is truly stationary. If this value is too low, the gyros will never adjust their bias, and you will see drift over time.''

====Angular Velocity Delta Threshold====
This is the minimum change between gyroscope samples before the gyro stops thinking it’s at rest. You can get a good value for this from the gyroscope example after installing the gyro in your application. Simply open the graphs for all axes, and set this value near the peak-to-peak noise.

''If this value is too low, the device will never think it's at rest. If it's too high, certain vibrations could affect your gyro biases (though the effects of these may also be limited by the Angular Velocity Threshold).''

====Acceleration Threshold====
The minimum measured acceleration your system will assume it is at rest, minus gravity. This value is also used to determine how much motion is accepted before the device begins to ignore the acceleration vector as a reliable source of “down”, and relies entirely on the gyros for pitch and roll until the device stops again. Again, you can use the noise in the graphs from your accelerometer example to get a baseline of the noise, and choose a value accordingly.

''If this value is too high, your device can adjust to thinking “down” is the wrong direction, or be swayed by fast motions. If this value is too low, the device may never think it is at rest to begin the process of correcting its pitch and roll.''

====Mag Time====
The amount of time (in seconds) your system will take to re-adjust the heading 95% of the way to aligning with the compass bearing, for differences in compass bearing and AHRS heading less than 15 degrees. Outside of 15 degrees of error, this is the time it will take the AHRS heading to correct towards the compass bearing by 45 degrees, to help limit adverse effects of interference. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more (but never entirely) resistant to magnetic interference, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the magnetic field readings. If this value is low enough, white noise in your compass readings will begin to show up in your measured heading.''

====Accel Time====
The amount of time (in seconds) your system will take to realign your pitch and roll to the acceleration vector, once the device believes it is at rest. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more resistant to acceleration affecting orientation, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the accelerometer readings (limited by the above Acceleration Threshold).''

====Bias Time====
If the sensor is deemed to be at rest, a “bias” parameter internal to the algorithm is slowly added to the gyroscope to compensate for any drift. Effectively, this will automatically gradually zero the gyro readings internal to the algorithm, reducing or eliminating the effects of drift. The time specified here (in seconds) is the time it takes to adjust the bias parameters to compensate for 95% of the gyro’s offsets once the device is at rest.

''The speed the gyros should be biased is a balance between getting a solid average and having the zeroing occur quickly enough that biases can be fully compensated for during short periods or rest.''

===Example===
[[File:AHRS_Example_Menu.jpg|400px|link=|thumb|The AHRS Example Parameter Selection]]
To get the best precision we recommend tuning these parameters as best fits your application. However, we have provided some sample values to make a couple demonstrations, and to give you some idea of how to adapt these parameters to certain situations.

To more easily set up these example cases, this dropdown provides a list of settings for generic cases, and demonstrations of how you might adapt these values to certain scenarios.

====General Purpose====
A set of values selected for your device that should work “well enough” out of the box for simple situations, such as moving the device around with your hand.

====No Gyro====
To demonstrate why gyroscopes are an essential part of AHRS, we’ve given some settings that will effectively ignore any input from the gyroscopes, and snap to the magnetometer and accelerometer readings alone. You will notice this is incredibly noisy, especially if you start moving the sensor around.

''We do not recommend using these settings in practice.''

====All Gyro====
For completeness, we have included a selection to set AHRS to more or less ignore input from the magnetometers and accelerometers. By selecting this sample, you can see how the gyroscopes will drift over time and fast motions, clearly demonstrating the need for the accelerometer and magnetometer to bring the gyros back into alignment.

''We do not recommend using these settings in practice.''

====Zeroed====
If you are able to zero your gyroscopes, and your application is relatively free of vibrations, you should be able to use a narrower Angular Velocity Threshold. As a result, you may also be able to relax the ''Mag Time'' and ''Accel Time'' parameters, since you can better trust that the gyroscopes will only be re-biased when they are truly not rotating.

====High Vibrations====
Regardless of whether or not you can zero your gyroscope, if your system suffers from constant large vibrations, the AHRS thresholds will have to be relaxed to allow the gyros to be biased at all. In doing so, we also raise the ''Accel Time'', not because we can trust the gyroscopes more in this scenario, but rather because we must trust the accelerometer less. Assuming there is little magnetic noise, ''Mag Time'' can be decreased to snap the heading closer to the magnetic field.

===Suggested Parameters===
{| class="wikitable" style="text-align: center;"
! !! Angular Velocity Threshold !! Angular Vel Delta Threshold !! Acceleration Threshold !! Mag Time !! Accel Time !! Bias Time
|-
! MOT1102 || 2.0 || 0.6 || 0.1 || 5 || 5 || 1.25
|-
! MOT0109 ''Out of the Box'' || 1.0 || 0.1 || 0.05 || 10 || 10 || 1.25
|-
! MOT0109 ''Heated and Zeroed'' || 0.5 || 0.1 || 0.05 || 120 || 120 || 1.25
|}

===Choosing a Phidget Spatial===
The Spatial Phidget you use in your application will depend on how accurate certain aspects of your measurement need to be. To simplify the decision, we can narrow this down to various kinds of applicaitons:

{|
! Applicaiton !! Phidget
|-
| Navigation or Outdoor Usage || [{{SERVER}}/products.php?product_id=MOT0110 MOT0110 PhidgetSpatial Precision 3/3/3]
|-
| Gestures and Qualitative Effects || [{{SERVER}}/products.php?product_id=MOT1102 MOT1102 Spatial Phidget]
|}

==FAQ==

===Why does the Euler Angle for pitch never exceed 90 degrees?===
The Euler Angles provided by the Phidgets library are calculated directly from a corresponding quaternion. They do not take into account past movements, so the orientation of a board that passes 90 degrees in pitch can just as easily be represented by a pitch of less than 90 degrees, with different roll and heading parameters. This is one reason why Euler Angles are not recommended for use in serious calculations, in favor of using the corresponding quaternions.

===Why do the Euler Angle readings stop working as well near 90 degrees of pitch?===
This is actually a good example of gimbal lock, and why it is not advised to use Euler Angles in calculation. When pitch approaches 90 degrees, the roll and yaw axes start to line up, which makes it hard to distinguish one from the other. In other words, at 90 degrees of pitch, a change in roll could just as easily be a change in heading, and vice-versa. This is another reason we recommend quaternions for all serious calculations.

Handling Errors and Logging

2023-07-14T18:51:15Z

Jdecoux: /* Common Errors */

[[Category:Programming]]{{Recommended_Flow_Links|{{Flow Page Number|{{PAGENAME}} }} }}
__NOTOC__
You've written your code, fixed the compiler errors, and yet, the program still isn't behaving as intended. The tools described on this page will help you further debug your program and figure out where in the code things are going wrong.

==Errors and Error Events==

The Phidget library uses errors and error events to communicate information about potential problems in your program. These can happen in-line in the form of an exception or error code (which generally indicate a problem in the code), and as Error Events (which generally indicate a problem with the Phidget's environment).

===Errors from Function Calls===

When a call to a Phidgets function fails it will throw an exception (or return an error code, depending on the language). It is important to check each function call for errors, and to catch and handle any errors.

Common causes of this type of error are the Phidget not being attached, or one of the values provided to the function being outside the valid range.

You can handle exceptions and return codes as follows:

<tabber>
Python=<syntaxhighlight lang=python>
try:
ch.openWaitForAttachment(5000);
except PhidgetException as e:
print("Failed to open: " + e.details)
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
try {
ch.open(5000);
} catch (PhidgetException ex) {
System.out.println("Failed to open: " + ex.getMessage());
}
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
try
{
ch.Open(); //open the device
}
catch (PhidgetException ex)
{
Console.WriteLine("Failed to open: " + ex.Description)
}
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
PhidgetDigitalInputHandle ch;
PhidgetReturnCode res;
...
res = Phidget_openWaitForAttachment((PhidgetHandle)ch, 5000);
if (res != EPHIDGET_OK) {
char* desc;
Phidget_getErrorDescription(res, &desc);
printf("Failed to open: (%d) %s\n", res, desc);
}
</syntaxhighlight>
|-|
JavaScript=
In JavaScript, there are two types of exceptions to handle. The first is used in synchronous functions only, and handled using the traditional try/catch block:
<syntaxhighlight lang=javascript>
try {
var tmp = ch.state
}
catch(err) {
console.log("Failed to get state: " + err.message)
}
</syntaxhighlight>
The second type is used for asynchronous functions, which return "promises", handled using the 'await' keyword in addition to a try/catch:
<syntaxhighlight lang=javascript>

async function main() {
...
try {
await ch.open()
}
catch(err) {
console.log('Error:' + err.message);
})
}
</syntaxhighlight>
When in doubt, check the {{Phidget22API}} to see whether the function you're checking returns a promise or not.
</tabber>

The consequences of not handling errors correctly ranges from improper behavior, to the program crashing due to an unhandled exception. Programs should check for errors on each function call, and handle any errors.

====Error Codes====

Full descriptions of all error codes can be found in the [[Error Code List]] page.

===Error Events===

Error events are asynchronously generated by Phidget devices, and by the Phidget library itself.

These do not necessarily indicate a problem with your program, and often serve as a status update from your device that your program should know. For example, a DistanceSensor might send an OutOfRange error if it does not detect anything in its field of view, or a TemperatureSensor could send a Saturation error indicating its temperature reading is outside the valid range for the sensor.

Error events are also fired when network errors occur, or when the library is unable to handle incoming change events quickly enough (event handlers could be too slow).

We strongly recommend setting up an error event handler for your channels so your program can keep track of these error conditions.

<tabber>
Python=<syntaxhighlight lang=python>
#Declare the event handler
def onErrorHandler(self, code, description):
print("Code: " + str(code))
print("Description: " + description)
...
#Declare your object. Replace "DigitalInput" with the object for your Phidget
ch = DigitalInput()
...
#Assign the handler that will be called when the event occurs
ch.setOnErrorHandler(onErrorHandler)
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
//Declare the event listener
public static ErrorListener onError = new ErrorListener() {
@Override
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode());
System.out.println("Description: " + e.getDescription());
}
};
...
//Declare your object. Replace "DigitalInput" with the object for your Phidget.
DigitalInput ch;
...
//Assign the event listener that will be called when the event occurs
ch.addErrorListener(onError);
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
//Declare the event handler
void error(object sender, Phidget22.Events.ErrorEventArgs e) {
Console.WriteLine("Code: " + e.Code.ToString());
Console.WriteLine("Description: " + e.Description);
}
...
//Declare your object. Replace "DigitalInput" with the object for your Phidget.
DigitalInput ch;
...
//Assign the handler that will be called when the event occurs
ch.Error += error;
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
//Declare the event handler
static void CCONV onErrorHandler(PhidgetHandle ph, void *ctx, Phidget_ErrorEventCode code, const char* description) {
printf("Code: %d\n", code);
printf("Description: %s\n", description);
}
...
//Declare your object. Replace "PhidgetDigitalInputHandle" with the handle for your Phidget object.
PhidgetDigitalInputHandle ch;
...
//Assign the handler that will be called when the event occurs
Phidget_setOnErrorHandler((PhidgetHandle)ch, onErrorHandler, NULL);
</syntaxhighlight>
|-|
JavaScript=<syntaxhighlight lang=javascript>
// Declare your object. Replace "DigitalInput" with the object for your Phidget
const ch = new phidget22.DigitalInput()

// Assign the handler that will be called when the event occurs
ch.onError = function(code, description) {
console.log('Code: ' + code)
console.log('Description: ' + description)
}
</syntaxhighlight>
</tabber>

Full descriptions of all error event codes can be found in the [[Error Event Code List]] page.

==Logging==
You can enable logging to get more debugging information. This would happen at the very start of your program, before even initializing your software object or opening it. Logging lets you get feedback from the Phidget libraries about things happening behind the scenes.

<tabber>
Python=<syntaxhighlight lang=python>
from Phidget22.Devices.Log import *
from Phidget22.LogLevel import *

Log.enable(LogLevel.PHIDGET_LOG_INFO, "path/to/log/file.log")
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
Log.enable(LogLevel.INFO, null);
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
Log.Enable(LogLevel.Info, null);
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
PhidgetLog_enable(PHIDGET_LOG_INFO, NULL);
</syntaxhighlight>
|-|
JavaScript=
Client-side logging is not enabled in JavaScript. For library errors, you can check the console, and for communication errors, you can enable logging on the server side. For information on how to enable and access network server logs, see the [[Network Server Troubleshooting]] page.
</tabber>

When <code>NULL</code> is passed to <code>enable()</code> in the above examples, the logging system will output to <code>STDERR</code>.

For a more comprehensive look at the logging system in Phidget22, you can check out the [[Logging Details]] page.

==Common Errors==
For more information on how to handle common errors, such as sensor data being Out of Range or Invalid, see our page on [[Handling Out Of Range Errors]].

== Other Problems ==

If your Phidget is still not behaving as expected after handling errors and exceptions, have a look at our [[General Troubleshooting]] guide to track down the problem.

{{Flow_Navigation_Buttons|{{Flow Page Number|{{PAGENAME}} }} }}

Handling Errors and Logging

2023-07-14T18:50:38Z

Jdecoux: /* Other Problems */

[[Category:Programming]]{{Recommended_Flow_Links|{{Flow Page Number|{{PAGENAME}} }} }}
__NOTOC__
You've written your code, fixed the compiler errors, and yet, the program still isn't behaving as intended. The tools described on this page will help you further debug your program and figure out where in the code things are going wrong.

==Errors and Error Events==

The Phidget library uses errors and error events to communicate information about potential problems in your program. These can happen in-line in the form of an exception or error code (which generally indicate a problem in the code), and as Error Events (which generally indicate a problem with the Phidget's environment).

===Errors from Function Calls===

When a call to a Phidgets function fails it will throw an exception (or return an error code, depending on the language). It is important to check each function call for errors, and to catch and handle any errors.

Common causes of this type of error are the Phidget not being attached, or one of the values provided to the function being outside the valid range.

You can handle exceptions and return codes as follows:

<tabber>
Python=<syntaxhighlight lang=python>
try:
ch.openWaitForAttachment(5000);
except PhidgetException as e:
print("Failed to open: " + e.details)
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
try {
ch.open(5000);
} catch (PhidgetException ex) {
System.out.println("Failed to open: " + ex.getMessage());
}
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
try
{
ch.Open(); //open the device
}
catch (PhidgetException ex)
{
Console.WriteLine("Failed to open: " + ex.Description)
}
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
PhidgetDigitalInputHandle ch;
PhidgetReturnCode res;
...
res = Phidget_openWaitForAttachment((PhidgetHandle)ch, 5000);
if (res != EPHIDGET_OK) {
char* desc;
Phidget_getErrorDescription(res, &desc);
printf("Failed to open: (%d) %s\n", res, desc);
}
</syntaxhighlight>
|-|
JavaScript=
In JavaScript, there are two types of exceptions to handle. The first is used in synchronous functions only, and handled using the traditional try/catch block:
<syntaxhighlight lang=javascript>
try {
var tmp = ch.state
}
catch(err) {
console.log("Failed to get state: " + err.message)
}
</syntaxhighlight>
The second type is used for asynchronous functions, which return "promises", handled using the 'await' keyword in addition to a try/catch:
<syntaxhighlight lang=javascript>

async function main() {
...
try {
await ch.open()
}
catch(err) {
console.log('Error:' + err.message);
})
}
</syntaxhighlight>
When in doubt, check the {{Phidget22API}} to see whether the function you're checking returns a promise or not.
</tabber>

The consequences of not handling errors correctly ranges from improper behavior, to the program crashing due to an unhandled exception. Programs should check for errors on each function call, and handle any errors.

====Error Codes====

Full descriptions of all error codes can be found in the [[Error Code List]] page.

===Error Events===

Error events are asynchronously generated by Phidget devices, and by the Phidget library itself.

These do not necessarily indicate a problem with your program, and often serve as a status update from your device that your program should know. For example, a DistanceSensor might send an OutOfRange error if it does not detect anything in its field of view, or a TemperatureSensor could send a Saturation error indicating its temperature reading is outside the valid range for the sensor.

Error events are also fired when network errors occur, or when the library is unable to handle incoming change events quickly enough (event handlers could be too slow).

We strongly recommend setting up an error event handler for your channels so your program can keep track of these error conditions.

<tabber>
Python=<syntaxhighlight lang=python>
#Declare the event handler
def onErrorHandler(self, code, description):
print("Code: " + str(code))
print("Description: " + description)
...
#Declare your object. Replace "DigitalInput" with the object for your Phidget
ch = DigitalInput()
...
#Assign the handler that will be called when the event occurs
ch.setOnErrorHandler(onErrorHandler)
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
//Declare the event listener
public static ErrorListener onError = new ErrorListener() {
@Override
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode());
System.out.println("Description: " + e.getDescription());
}
};
...
//Declare your object. Replace "DigitalInput" with the object for your Phidget.
DigitalInput ch;
...
//Assign the event listener that will be called when the event occurs
ch.addErrorListener(onError);
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
//Declare the event handler
void error(object sender, Phidget22.Events.ErrorEventArgs e) {
Console.WriteLine("Code: " + e.Code.ToString());
Console.WriteLine("Description: " + e.Description);
}
...
//Declare your object. Replace "DigitalInput" with the object for your Phidget.
DigitalInput ch;
...
//Assign the handler that will be called when the event occurs
ch.Error += error;
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
//Declare the event handler
static void CCONV onErrorHandler(PhidgetHandle ph, void *ctx, Phidget_ErrorEventCode code, const char* description) {
printf("Code: %d\n", code);
printf("Description: %s\n", description);
}
...
//Declare your object. Replace "PhidgetDigitalInputHandle" with the handle for your Phidget object.
PhidgetDigitalInputHandle ch;
...
//Assign the handler that will be called when the event occurs
Phidget_setOnErrorHandler((PhidgetHandle)ch, onErrorHandler, NULL);
</syntaxhighlight>
|-|
JavaScript=<syntaxhighlight lang=javascript>
// Declare your object. Replace "DigitalInput" with the object for your Phidget
const ch = new phidget22.DigitalInput()

// Assign the handler that will be called when the event occurs
ch.onError = function(code, description) {
console.log('Code: ' + code)
console.log('Description: ' + description)
}
</syntaxhighlight>
</tabber>

Full descriptions of all error event codes can be found in the [[Error Event Code List]] page.

==Logging==
You can enable logging to get more debugging information. This would happen at the very start of your program, before even initializing your software object or opening it. Logging lets you get feedback from the Phidget libraries about things happening behind the scenes.

<tabber>
Python=<syntaxhighlight lang=python>
from Phidget22.Devices.Log import *
from Phidget22.LogLevel import *

Log.enable(LogLevel.PHIDGET_LOG_INFO, "path/to/log/file.log")
</syntaxhighlight>
|-|
Java=<syntaxhighlight lang=java>
Log.enable(LogLevel.INFO, null);
</syntaxhighlight>
|-|
C#=<syntaxhighlight lang=cSharp>
Log.Enable(LogLevel.Info, null);
</syntaxhighlight>
|-|
C=<syntaxhighlight lang=c>
PhidgetLog_enable(PHIDGET_LOG_INFO, NULL);
</syntaxhighlight>
|-|
JavaScript=
Client-side logging is not enabled in JavaScript. For library errors, you can check the console, and for communication errors, you can enable logging on the server side. For information on how to enable and access network server logs, see the [[Network Server Troubleshooting]] page.
</tabber>

When <code>NULL</code> is passed to <code>enable()</code> in the above examples, the logging system will output to <code>STDERR</code>.

For a more comprehensive look at the logging system in Phidget22, you can check out the [[Logging Details]] page.

==Common Errors==
For more information on how to handle common errors, such as sensor data being Out of Range or Invalid, see our page on [[Handling_Out_Of_Range_Errors]].

== Other Problems ==

If your Phidget is still not behaving as expected after handling errors and exceptions, have a look at our [[General Troubleshooting]] guide to track down the problem.

{{Flow_Navigation_Buttons|{{Flow Page Number|{{PAGENAME}} }} }}

Handling Out Of Range Errors

2023-07-14T16:59:15Z

Jdecoux: /* Intro */

__TOC__
==Intro==
All new Phidgets have been designed to seamlessly and informatively communicate problems with measured data. This allows you to more easily debug your systems, while ensuring data events from sensors continue at a steady pace. This makes it possible to use data events as a reliable time-base for your system.

<center>[[Image:OutOfRangeErrorSampleGraph.png|400px|Center|link=|]]</center>

To understand the more technical points of this article, we recommend first learning about [[Phidget Programming Basics]].

==Data Events==
All modern Phidgets guarantee that data events will occur on a channel at the user-defined rate, or will inform you of the actual data rate if it is unable to keep up. This remains true even if the data on the channel is unknown or invalid.

Values from a sensor that are too high or too low to be accurately measured will be capped slightly outside the specified Minimum and Maximum values for the sensor. For example, if a temperature sensor can measure from -30°C to 85°C, you can expect values outside of this range to all read as -31°C and 86°C, respectively. You can monitor for these out-of-range indicators by checking the value from the event against the minimum and maximum values for the sensor.

Values that are strictly unknown for one reason or another, such as a probe being unplugged, will be reported as ''NaN'' in the related event handler. Be sure your code is robust enough to handle this possibility.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def onTemperatureChange(self, temperature):
if(math.isnan(temperature)):
print("Temperature is unknown")
elif(temperature > self.getMaxTemperature()):
print("Temperature is too high")
elif(temperature < self.getMinTemperature()):
print("Temperature is too low")
else:
print("Temperature: " + str(temperature))

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnTemperatureChangeHandler(onTemperatureChange)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addTemperatureChangeListener(new
TemperatureSensorTemperatureChangeListener() {
public void onTemperatureChange(TemperatureSensorTemperatureChangeEvent e) {
try {
if(Double.isNaN(e.getTemperature()))
System.out.println("Temperature is unknown");
else if(e.getTemperature() > temperatureSensor0.getMaxTemperature())
System.out.println("Temperature is too high");
else if(e.getTemperature() < temperatureSensor0.getMinTemperature())
System.out.println("Temperature is too low");
else
System.out.println("Temperature: " + e.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_TemperatureChange(object sender, Phidget22.Events.TemperatureSensorTemperatureChangeEventArgs e)
{
TemperatureSensor ch = (TemperatureSensor)sender;
if (Double.IsNaN(e.Temperature))
Console.WriteLine("Temperature is unknown");
else if (e.Temperature > ch.MaxTemperature)
Console.WriteLine("Temperature is too high");
else if (e.Temperature < ch.MinTemperature)
Console.WriteLine("Temperature is too low");
else
Console.WriteLine("Temperature: " + e.Temperature);
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.TemperatureChange += TemperatureSensor0_TemperatureChange;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
Press Enter to Stop
Temperature: 14.062
Temperature: 14.056
Temperature: 14.16
Temperature: 389.105
Temperature is too high
Temperature is too high
Temperature is too high
Temperature: 504.21
Temperature: -198.721
Temperature is too low
Temperature is too low
Temperature is too low
Temperature is too low
Temperature: -153.69
Temperature: 19.306
Temperature: 17.559
Temperature: 17.637
Temperature: 17.629
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature: 15.55
Temperature: 16.549
Temperature: 16.978
Temperature: 17.214
</syntaxhighlight>
</tabber>

==Polling==
When polling for data, values that are unknown, too high, or too low will give relevant return codes or exceptions, typically '''UNKNOWNVALUE''', '''UNKNOWNVALUEHIGH''', or '''UNKNOWNVALUELOW''' respectively.

In most programming languages (excluding C), specific information about the error will be available to the exception handler to help identify the specifics of the error.

For information on how to see error messages in C, look up ''Phidget_getLastError'' in the API.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.openWaitForAttachment(5000)

for i in range(1, 10):
try:
print(temperatureSensor0.getTemperature())
except PhidgetException as ex:
print("PhidgetException " + str(ex.code) + " (" + ex.description + "): " + ex.details)
time.sleep(1)

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.open(5000);

while(System.in.available() == 0) {
try {
System.out.println(temperatureSensor0.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
Thread.sleep(1000);
}

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Open(5000);

while(Console.KeyAvailable == false)
{
try
{
Console.WriteLine("Temperature: " + temperatureSensor0.Temperature);
}
catch (PhidgetException ex)
{
Console.WriteLine("PhidgetException " + ex.ErrorCode +
" (" + ex.Description + "): " + ex.Detail);
}
System.Threading.Thread.Sleep(1000);
}
temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
24.041
24.052
PhidgetException 60 (Invalid Value - Too High): The value has been measured to be higher than the valid range of the sensor.
PhidgetException 60 (Invalid Value - Too High): The value has been measured to be higher than the valid range of the sensor.
222.166
-132.291
PhidgetException 61 (Invalid Value - Too Low): The value has been measured to be lower than the valid range of the sensor.
PhidgetException 61 (Invalid Value - Too Low): The value has been measured to be lower than the valid range of the sensor.
-132.632
119.862
120.613
PhidgetException 51 (Unknown or Invalid Value): The value is unknown. This can happen right after attach, when the value has not yet been received from the Phidget. This can also happen if a device has not yet been configured / enabled. Some properties can only be read back after being set.
PhidgetException 51 (Unknown or Invalid Value): The value is unknown. This can happen right after attach, when the value has not yet been received from the Phidget. This can also happen if a device has not yet been configured / enabled. Some properties can only be read back after being set.
120.045
</syntaxhighlight>
</tabber>

==Error Events==
In addition to data events, you can use error event handlers to get specific information about error conditions as they happen. A single error event handler will provide meaningful information in text form about each error condition as it happens. These have been standardized to occur once every second for as long as the error condition persists.

If your system has older Phidgets, this method may be the only way to access additional error information.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import time

def onError(self, code, description):
print("Code: " + ErrorEventCode.getName(code))
print("Description: " + str(description))
print("----------")

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnErrorHandler(onError)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.lang.InterruptedException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addErrorListener(new ErrorListener() {
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode().name());
System.out.println("Description: " + e.getDescription());
System.out.println("----------");
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_Error(object sender, Phidget22.Events.ErrorEventArgs e)
{
Console.WriteLine("Code: " + e.Code);
Console.WriteLine("Description: " + e.Description);
Console.WriteLine("----------");
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Error += TemperatureSensor0_Error;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
Press Enter to Stop
Code: EEPHIDGET_OUTOFRANGEHIGH
Description: Temperature is too high to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGEHIGH
Description: Temperature is too high to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGELOW
Description: Temperature is too low to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGELOW
Description: Temperature is too low to be accurately measured
----------
Code: EEPHIDGET_BADCONNECTION
Description: Bad Connection: RTD is likely disconnected
----------
Code: EEPHIDGET_BADCONNECTION
Description: Bad Connection: RTD is likely disconnected
----------
</syntaxhighlight>
</tabber>

File:OutOfRangeErrorSampleGraph.png

2023-07-14T16:56:25Z

Jdecoux:

Handling Out Of Range Errors

2023-07-14T16:34:57Z

Jdecoux:

__TOC__
==Intro==
All new Phidgets have been designed to seamlessly and informatively communicate problems with measured data. This allows you to more easily debug your systems, while ensuring data events from sensors continue at a steady pace. This makes it possible to use data events as a reliable time-base for your system.

To understand the more technical points of this article, we recommend first learning about [[Phidget Programming Basics]].

==Data Events==
All modern Phidgets guarantee that data events will occur on a channel at the user-defined rate, or will inform you of the actual data rate if it is unable to keep up. This remains true even if the data on the channel is unknown or invalid.

Values from a sensor that are too high or too low to be accurately measured will be capped slightly outside the specified Minimum and Maximum values for the sensor. For example, if a temperature sensor can measure from -30°C to 85°C, you can expect values outside of this range to all read as -31°C and 86°C, respectively. You can monitor for these out-of-range indicators by checking the value from the event against the minimum and maximum values for the sensor.

Values that are strictly unknown for one reason or another, such as a probe being unplugged, will be reported as ''NaN'' in the related event handler. Be sure your code is robust enough to handle this possibility.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def onTemperatureChange(self, temperature):
if(math.isnan(temperature)):
print("Temperature is unknown")
elif(temperature > self.getMaxTemperature()):
print("Temperature is too high")
elif(temperature < self.getMinTemperature()):
print("Temperature is too low")
else:
print("Temperature: " + str(temperature))

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnTemperatureChangeHandler(onTemperatureChange)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addTemperatureChangeListener(new
TemperatureSensorTemperatureChangeListener() {
public void onTemperatureChange(TemperatureSensorTemperatureChangeEvent e) {
try {
if(Double.isNaN(e.getTemperature()))
System.out.println("Temperature is unknown");
else if(e.getTemperature() > temperatureSensor0.getMaxTemperature())
System.out.println("Temperature is too high");
else if(e.getTemperature() < temperatureSensor0.getMinTemperature())
System.out.println("Temperature is too low");
else
System.out.println("Temperature: " + e.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_TemperatureChange(object sender, Phidget22.Events.TemperatureSensorTemperatureChangeEventArgs e)
{
TemperatureSensor ch = (TemperatureSensor)sender;
if (Double.IsNaN(e.Temperature))
Console.WriteLine("Temperature is unknown");
else if (e.Temperature > ch.MaxTemperature)
Console.WriteLine("Temperature is too high");
else if (e.Temperature < ch.MinTemperature)
Console.WriteLine("Temperature is too low");
else
Console.WriteLine("Temperature: " + e.Temperature);
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.TemperatureChange += TemperatureSensor0_TemperatureChange;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
Press Enter to Stop
Temperature: 14.062
Temperature: 14.056
Temperature: 14.16
Temperature: 389.105
Temperature is too high
Temperature is too high
Temperature is too high
Temperature: 504.21
Temperature: -198.721
Temperature is too low
Temperature is too low
Temperature is too low
Temperature is too low
Temperature: -153.69
Temperature: 19.306
Temperature: 17.559
Temperature: 17.637
Temperature: 17.629
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature: 15.55
Temperature: 16.549
Temperature: 16.978
Temperature: 17.214
</syntaxhighlight>
</tabber>

==Polling==
When polling for data, values that are unknown, too high, or too low will give relevant return codes or exceptions, typically '''UNKNOWNVALUE''', '''UNKNOWNVALUEHIGH''', or '''UNKNOWNVALUELOW''' respectively.

In most programming languages (excluding C), specific information about the error will be available to the exception handler to help identify the specifics of the error.

For information on how to see error messages in C, look up ''Phidget_getLastError'' in the API.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.openWaitForAttachment(5000)

for i in range(1, 10):
try:
print(temperatureSensor0.getTemperature())
except PhidgetException as ex:
print("PhidgetException " + str(ex.code) + " (" + ex.description + "): " + ex.details)
time.sleep(1)

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.open(5000);

while(System.in.available() == 0) {
try {
System.out.println(temperatureSensor0.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
Thread.sleep(1000);
}

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Open(5000);

while(Console.KeyAvailable == false)
{
try
{
Console.WriteLine("Temperature: " + temperatureSensor0.Temperature);
}
catch (PhidgetException ex)
{
Console.WriteLine("PhidgetException " + ex.ErrorCode +
" (" + ex.Description + "): " + ex.Detail);
}
System.Threading.Thread.Sleep(1000);
}
temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
24.041
24.052
PhidgetException 60 (Invalid Value - Too High): The value has been measured to be higher than the valid range of the sensor.
PhidgetException 60 (Invalid Value - Too High): The value has been measured to be higher than the valid range of the sensor.
222.166
-132.291
PhidgetException 61 (Invalid Value - Too Low): The value has been measured to be lower than the valid range of the sensor.
PhidgetException 61 (Invalid Value - Too Low): The value has been measured to be lower than the valid range of the sensor.
-132.632
119.862
120.613
PhidgetException 51 (Unknown or Invalid Value): The value is unknown. This can happen right after attach, when the value has not yet been received from the Phidget. This can also happen if a device has not yet been configured / enabled. Some properties can only be read back after being set.
PhidgetException 51 (Unknown or Invalid Value): The value is unknown. This can happen right after attach, when the value has not yet been received from the Phidget. This can also happen if a device has not yet been configured / enabled. Some properties can only be read back after being set.
120.045
</syntaxhighlight>
</tabber>

==Error Events==
In addition to data events, you can use error event handlers to get specific information about error conditions as they happen. A single error event handler will provide meaningful information in text form about each error condition as it happens. These have been standardized to occur once every second for as long as the error condition persists.

If your system has older Phidgets, this method may be the only way to access additional error information.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import time

def onError(self, code, description):
print("Code: " + ErrorEventCode.getName(code))
print("Description: " + str(description))
print("----------")

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnErrorHandler(onError)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.lang.InterruptedException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addErrorListener(new ErrorListener() {
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode().name());
System.out.println("Description: " + e.getDescription());
System.out.println("----------");
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_Error(object sender, Phidget22.Events.ErrorEventArgs e)
{
Console.WriteLine("Code: " + e.Code);
Console.WriteLine("Description: " + e.Description);
Console.WriteLine("----------");
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Error += TemperatureSensor0_Error;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
<syntaxhighlight>
Press Enter to Stop
Code: EEPHIDGET_OUTOFRANGEHIGH
Description: Temperature is too high to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGEHIGH
Description: Temperature is too high to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGELOW
Description: Temperature is too low to be accurately measured
----------
Code: EEPHIDGET_OUTOFRANGELOW
Description: Temperature is too low to be accurately measured
----------
Code: EEPHIDGET_BADCONNECTION
Description: Bad Connection: RTD is likely disconnected
----------
Code: EEPHIDGET_BADCONNECTION
Description: Bad Connection: RTD is likely disconnected
----------
</syntaxhighlight>
</tabber>

Handling Out Of Range Errors

2023-07-14T16:14:00Z

Jdecoux: /* Data Events */

__TOC__
==Intro==
All new Phidgets have been designed to seamlessly and informatively communicate problems with measured data. This allows you to more easily debug your systems, while ensuring data events from sensors continue at a steady pace. This makes it possible to use data events as a reliable time-base for your system.

To understand the more technical points of this article, we recommend first learning about [[Phidget Programming Basics]].

==Data Events==
All modern Phidgets guarantee that data events will occur on a channel at the user-defined rate, or will inform you of the actual data rate if it is unable to keep up. This remains true even if the data on the channel is unknown or invalid.

Values from a sensor that are too high or too low to be accurately measured will be capped slightly outside the specified Minimum and Maximum values for the sensor. For example, if a temperature sensor can measure from -30°C to 85°C, you can expect values outside of this range to all read as -31°C and 86°C, respectively. You can monitor for these out-of-range indicators by checking the value from the event against the minimum and maximum values for the sensor.

Values that are strictly unknown for one reason or another, such as a probe being unplugged, will be reported as ''NaN'' in the related event handler. Be sure your code is robust enough to handle this possibility.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def onTemperatureChange(self, temperature):
if(math.isnan(temperature)):
print("Temperature is unknown")
elif(temperature > self.getMaxTemperature()):
print("Temperature is too high")
elif(temperature < self.getMinTemperature()):
print("Temperature is too low")
else:
print("Temperature: " + str(temperature))

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnTemperatureChangeHandler(onTemperatureChange)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addTemperatureChangeListener(new
TemperatureSensorTemperatureChangeListener() {
public void onTemperatureChange(TemperatureSensorTemperatureChangeEvent e) {
try {
if(Double.isNaN(e.getTemperature()))
System.out.println("Temperature is unknown");
else if(e.getTemperature() > temperatureSensor0.getMaxTemperature())
System.out.println("Temperature is too high");
else if(e.getTemperature() < temperatureSensor0.getMinTemperature())
System.out.println("Temperature is too low");
else
System.out.println("Temperature: " + e.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_TemperatureChange(object sender, Phidget22.Events.TemperatureSensorTemperatureChangeEventArgs e)
{
TemperatureSensor ch = (TemperatureSensor)sender;
if (Double.IsNaN(e.Temperature))
Console.WriteLine("Temperature is unknown");
else if (e.Temperature > ch.MaxTemperature)
Console.WriteLine("Temperature is too high");
else if (e.Temperature < ch.MinTemperature)
Console.WriteLine("Temperature is too low");
else
Console.WriteLine("Temperature: " + e.Temperature);
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.TemperatureChange += TemperatureSensor0_TemperatureChange;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
|-|
Sample Output=
Press Enter to Stop
Temperature: 14.062
Temperature: 14.056
Temperature: 14.16
Temperature: 389.105
Temperature is too high
Temperature is too high
Temperature is too high
Temperature: 504.21
Temperature: -198.721
Temperature is too low
Temperature is too low
Temperature is too low
Temperature is too low
Temperature: -153.69
Temperature: 19.306
Temperature: 17.559
Temperature: 17.637
Temperature: 17.629
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature is unknown
Temperature: 15.55
Temperature: 16.549
Temperature: 16.978
Temperature: 17.214
</tabber>

==Polling==
When polling for data, values that are unknown, too high, or too low will give relevant return codes or exceptions, typically '''UNKNOWNVALUE''', '''UNKNOWNVALUEHIGH''', or '''UNKNOWNVALUELOW''' respectively.

In most programming languages (excluding C), specific information about the error will be available to the exception handler to help identify the specifics of the error.

For information on how to see error messages in C, look up ''Phidget_getLastError'' in the API.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.openWaitForAttachment(5000)

for i in range(1, 10):
try:
print(temperatureSensor0.getTemperature())
except PhidgetException as ex:
print("PhidgetException " + str(ex.code) + " (" + ex.description + "): " + ex.details)
time.sleep(1)

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.open(5000);

while(System.in.available() == 0) {
try {
System.out.println(temperatureSensor0.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
Thread.sleep(1000);
}

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Open(5000);

while(Console.KeyAvailable == false)
{
try
{
Console.WriteLine("Temperature: " + temperatureSensor0.Temperature);
}
catch (PhidgetException ex)
{
Console.WriteLine("PhidgetException " + ex.ErrorCode +
" (" + ex.Description + "): " + ex.Detail);
}
System.Threading.Thread.Sleep(1000);
}
temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
</tabber>

==Error Events==
In addition to data events, you can use error event handlers to get specific information about error conditions as they happen. A single error event handler will provide meaningful information in text form about each error condition as it happens. These have been standardized to occur once every second for as long as the error condition persists.

If your system has older Phidgets, this method may be the only way to access additional error information.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import time

def onError(self, code, description):
print("Code: " + ErrorEventCode.getName(code))
print("Description: " + str(description))
print("----------")

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnErrorHandler(onError)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.lang.InterruptedException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addErrorListener(new ErrorListener() {
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode().name());
System.out.println("Description: " + e.getDescription());
System.out.println("----------");
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_Error(object sender, Phidget22.Events.ErrorEventArgs e)
{
Console.WriteLine("Code: " + e.Code);
Console.WriteLine("Description: " + e.Description);
Console.WriteLine("----------");
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Error += TemperatureSensor0_Error;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
</tabber>

Handling Out Of Range Errors

2023-07-13T16:05:50Z

Jdecoux: Created page with "__TOC__ ==Intro== All new Phidgets have been designed to seamlessly and informatively communicate problems with measured data. This allows you to more easily debug your systems, while ensuring data events from sensors continue at a steady pace. This makes it possible to use data events as a reliable time-base for your system. To understand the more technical points of this article, we recommend first learning about Phidget Programming Basics. ==Data Events== All mo..."

__TOC__
==Intro==
All new Phidgets have been designed to seamlessly and informatively communicate problems with measured data. This allows you to more easily debug your systems, while ensuring data events from sensors continue at a steady pace. This makes it possible to use data events as a reliable time-base for your system.

To understand the more technical points of this article, we recommend first learning about [[Phidget Programming Basics]].

==Data Events==
All modern Phidgets guarantee that data events will occur on a channel at the user-defined rate, or will inform you of the actual data rate if it is unable to keep up. This remains true even if the data on the channel is unknown or invalid.

Values from a sensor that are too high or too low to be accurately measured will be capped slightly outside the specified Minimum and Maximum values for the sensor. For example, if a temperature sensor can measure from -30°C to 85°C, you can expect values outside of this range to all read as -31°C and 86°C, respectively. You can monitor for these out-of-range indicators by checking the value from the event against the minimum and maximum values for the sensor.

Values that are strictly unknown for one reason or another, such as a probe being unplugged, will be reported as ''NaN'' in the related event handler. Be sure your code is robust enough to handle this possibility.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def onTemperatureChange(self, temperature):
if(math.isnan(temperature)):
print("Temperature is unknown")
elif(temperature > self.getMaxTemperature()):
print("Temperature is too high")
elif(temperature < self.getMinTemperature()):
print("Temperature is too low")
else:
print("Temperature: " + str(temperature))

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnTemperatureChangeHandler(onTemperatureChange)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addTemperatureChangeListener(new
TemperatureSensorTemperatureChangeListener() {
public void onTemperatureChange(TemperatureSensorTemperatureChangeEvent e) {
try {
if(Double.isNaN(e.getTemperature()))
System.out.println("Temperature is unknown");
else if(e.getTemperature() > temperatureSensor0.getMaxTemperature())
System.out.println("Temperature is too high");
else if(e.getTemperature() < temperatureSensor0.getMinTemperature())
System.out.println("Temperature is too low");
else
System.out.println("Temperature: " + e.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_TemperatureChange(object sender, Phidget22.Events.TemperatureSensorTemperatureChangeEventArgs e)
{
TemperatureSensor ch = (TemperatureSensor)sender;
if (Double.IsNaN(e.Temperature))
Console.WriteLine("Temperature is unknown");
else if (e.Temperature > ch.MaxTemperature)
Console.WriteLine("Temperature is too high");
else if (e.Temperature < ch.MinTemperature)
Console.WriteLine("Temperature is too low");
else
Console.WriteLine("Temperature: " + e.Temperature);
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.TemperatureChange += TemperatureSensor0_TemperatureChange;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
</tabber>

==Polling==
When polling for data, values that are unknown, too high, or too low will give relevant return codes or exceptions, typically '''UNKNOWNVALUE''', '''UNKNOWNVALUEHIGH''', or '''UNKNOWNVALUELOW''' respectively.

In most programming languages (excluding C), specific information about the error will be available to the exception handler to help identify the specifics of the error.

For information on how to see error messages in C, look up ''Phidget_getLastError'' in the API.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import math
import time

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.openWaitForAttachment(5000)

for i in range(1, 10):
try:
print(temperatureSensor0.getTemperature())
except PhidgetException as ex:
print("PhidgetException " + str(ex.code) + " (" + ex.description + "): " + ex.details)
time.sleep(1)

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.util.Scanner; //Required for Text Input
import java.io.IOException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.open(5000);

while(System.in.available() == 0) {
try {
System.out.println(temperatureSensor0.getTemperature());
} catch (PhidgetException ex) {
System.out.println("PhidgetException " +
ex.getErrorCode() + " (" + ex.getDescription() + "): " +
ex.getDetail());
}
Thread.sleep(1000);
}

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Open(5000);

while(Console.KeyAvailable == false)
{
try
{
Console.WriteLine("Temperature: " + temperatureSensor0.Temperature);
}
catch (PhidgetException ex)
{
Console.WriteLine("PhidgetException " + ex.ErrorCode +
" (" + ex.Description + "): " + ex.Detail);
}
System.Threading.Thread.Sleep(1000);
}
temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
</tabber>

==Error Events==
In addition to data events, you can use error event handlers to get specific information about error conditions as they happen. A single error event handler will provide meaningful information in text form about each error condition as it happens. These have been standardized to occur once every second for as long as the error condition persists.

If your system has older Phidgets, this method may be the only way to access additional error information.

<tabber>
Python=
<syntaxhighlight lang=python>
from Phidget22.Phidget import *
from Phidget22.Devices.TemperatureSensor import *
import time

def onError(self, code, description):
print("Code: " + ErrorEventCode.getName(code))
print("Description: " + str(description))
print("----------")

def main():
temperatureSensor0 = TemperatureSensor()

temperatureSensor0.setOnErrorHandler(onError)

temperatureSensor0.openWaitForAttachment(5000)

try:
input("Press Enter to Stop\n")
except (Exception, KeyboardInterrupt):
pass

temperatureSensor0.close()

main()
</syntaxhighlight>
|-|
Java=
<syntaxhighlight lang=java>
import com.phidget22.*;
import java.lang.InterruptedException;

public class Java_Example {

public static void main(String[] args) throws Exception {
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.addErrorListener(new ErrorListener() {
public void onError(ErrorEvent e) {
System.out.println("Code: " + e.getCode().name());
System.out.println("Description: " + e.getDescription());
System.out.println("----------");
}
});

temperatureSensor0.open(5000);

//Wait until Enter has been pressed before exiting
System.in.read();

temperatureSensor0.close();
}
}
</syntaxhighlight>
|-|
C#=
<syntaxhighlight lang=cSharp>
using System;
using Phidget22;

namespace ConsoleApplication
{
class Program
{

private static void TemperatureSensor0_Error(object sender, Phidget22.Events.ErrorEventArgs e)
{
Console.WriteLine("Code: " + e.Code);
Console.WriteLine("Description: " + e.Description);
Console.WriteLine("----------");
}

static void Main(string[] args)
{
TemperatureSensor temperatureSensor0 = new TemperatureSensor();

temperatureSensor0.Error += TemperatureSensor0_Error;

temperatureSensor0.Open(5000);

//Wait until Enter has been pressed before exiting
Console.ReadLine();

temperatureSensor0.Close();
}
}
}
</syntaxhighlight>
</tabber>

DC Motor and Controller Guide

2023-04-21T16:32:34Z

Jdecoux:

[[Category:Primer]]
[[Image:3253.jpg|link=|270px]]
[[Image:DCC1000.jpg|link=|270px]]
[[Image:DC Motor Image 3.jpg|link=|270px]]
{{TOC limit|2}}
==Introduction==
[[File:DC Motor and Controller.jpg|link=|200px|thumb|A DC Motor and Phidgets DC Motor Controller]]
DC Motors are the simplest way to turn electrical power into physical motion.

They can be found in all types of applications, from power tools, to remote control cars, to large industrial machinery.

==Brushless DC Motors vs Regular DC Motors==
[[File:BLDC Motor and Controller.jpg|link=|200px|thumb|A BLDC Motor and Phidgets BLDC Motor Controller]]
Brushless DC (BLDC) Motors are similar enough in control principles to DC Motors when using the right Phidgets that they can be treated the same as basic DC Motors for this discussion.

Brushless DC motors tend to have better efficiency, power and longevity than their standard (brushed) counterparts, while simply requiring more wiring. There are more internal complexities, but these differences are handled automatically by using the correct motor controller.

''Phidgets brushless DC motor controllers only support sensored BLDC motors, which are the most common type for serious applications.''

==Basic Principles==
[[File:DC Motor Basic Image.jpg|link=|200px|thumb|A DC Motor spins when voltage is applied.]]
At the most basic level, a DC motor spins by applying voltage across the motor terminals. Apply more voltage and the motor spins faster. As the motor gets loaded down, it will be forced to spend more energy fighting the load, and will slow down accordingly.

The force applied by a DC motor at a given voltage reduces as it spins faster. We’ll cover the reasons later, but the result is that for any applied voltage and motor loading, the motor will accelerate to a speed that balances the force required to move the motor.
 

The graph below shows the relationship between motor voltage and speed of rotation for a motor we tested, captured in the Phidgets Control Panel.
[[File:DC Motor Simple Control Graph.jpg|link=|500px|center|Controlling a DC Motor]]

==Basic Control==
In this way, you can control a DC Motor’s speed by adjusting the applied voltage. This can be done using DCMotor Phidgets to drive a motor forwards or backwards at different speeds.

[[File:DC Motor Simple Control.jpg|link=|center|Controlling a DC Motor]]

A DC motor controller Phidget allows you to control the relative speed of the motor by setting a fraction of full power to give to the motor. For many applications this is already a good enough approximation of controlling the motor’s speed for basic control.

==Control Methods==
[[File:DC Motor with Encoder.jpg|link=|200px|thumb|An encoder attached to a DC Motor]]
You can pair a DC motor with data from any number of sensors to move mechanical systems in various ways. We won’t cover the specifics of how to use them here, but Phidgets users have had success controlling DC motor based systems using a wide array of sensors, from rotation sensors, to draw-wire sensors, to spatial tilt sensors.

The most direct way of measuring the position of your motor with Phidgets is using an encoder interface. For the purposes of this document, an encoder is simply a device that measures position information in a way that digital systems can understand.

DC Motors sold by Phidgets have the option to attach an encoder to measure their rotation, and most Phidget motor controllers have a plug for an encoder built-in. Modern Phidgets motor controllers have built-in features to use this information to produce smooth motion.

==Phidgets Built-In Position Control==
You can use the built-in encoder input on many recent DC Motor Phidgets to control the position of your system directly, using the MotorPositionController feature provided by Phidgets.
 
<center>{{#ev:youtube|0cQlxNd7dk4|||||rel=0}}</center>
 
This feature allows you to set up your system so you only need to tell the motor where to go with a given speed and acceleration, and it will go there.

==Torque, Current and Power==
Now that we have covered the basics of using DC motors and how easily they can be controlled with Phidgets, we can cover more in-depth concerns, such as torque curves and power consumption.

[[File:DC Motor Current vs Supply.jpg|link=|200px|thumb|A DC Motor Draws More Current Under Load]]
A DC Motor’s torque is proportional to the electrical current flowing through it. The more current, the harder the motor pushes to get moving. A higher supply voltage will try to push more current, and allow a higher maximum torque for a given motor.

As a DC motor spins faster, it begins trying to generate its own current to oppose the motion. So long as the motor is powered, this results in a reduced current driving the motor. Under no load, the motor will spin up to the point where this generated electromotive force (EMF) cancels out the supply, and the system consumes barely any power while spinning as fast as it can.

As the motor gets loaded down, the motor slows allowing more current to flow and generating more torque to fight the load. This tendency of the motor to consume more current at low speeds means that the DC Motor will work harder when it’s weighed down, and when it’s starting up.

[[File:DC Motor Overload.jpg|link=|200px|thumb|Thermal Image of a Stalled DC Motor]]
Once the motor is loaded down to the point it can no longer spin, it will consume as much current as it can, generating maximum torque, but potentially overheating in the process. Overloading an electric motor to this point is called a “stall” and should be avoided.

To prevent problems caused by this kind of runaway current, Phidgets DC Motor Controllers have a current limiting feature. This can be useful in both preventing overheating and/or automatically limiting the available torque if desired.

==Braking==
[[File:DC Motor Braking.jpg|link=|200px|thumb|A DC motor can be made to passively resist fast movement]]
Another result of the electromotive forces (EMF) caused by the spinning motor is that by connecting the motor terminals together when it’s spinning, the motor will produce a current (and thus a force) opposing the rotation of the motor. This method of using the motor’s own rotation against itself is called braking.

When braking, a faster rotation generates a higher EMF, resulting in a higher braking current, and the motor will brake harder when it’s spinning faster.

A DC Motor that is not moving will generate no passive braking, as no motion results in no EMF being generated, and thus no current and no torque.

A Phidgets DC Motor controller can be used to control the braking force applied by your DC motor.

File:DC Motor Braking.jpg

2023-04-21T16:31:26Z

Jdecoux:

File:DC Motor Overload.jpg

2023-04-21T16:31:09Z

Jdecoux:

File:DC Motor Current vs Supply.jpg

2023-04-21T16:30:57Z

Jdecoux:

File:DC Motor with Encoder.jpg

2023-04-21T16:30:40Z

Jdecoux:

File:DC Motor Simple Control.jpg

2023-04-21T16:30:23Z

Jdecoux:

File:DC Motor Simple Control Graph.jpg

2023-04-21T16:30:09Z

Jdecoux:

File:DC Motor Basic Image.jpg

2023-04-21T16:29:54Z

Jdecoux: Jdecoux uploaded a new version of File:DC Motor Basic Image.jpg

File:BLDC Motor and Controller.jpg

2023-04-21T16:29:44Z

Jdecoux:

File:DC Motor Basic Image.jpg

2023-04-21T16:28:09Z

Jdecoux:

File:DC Motor and Controller.jpg

2023-04-21T16:27:30Z

Jdecoux:

File:DC Motor Image 3.jpg

2023-04-21T16:27:09Z

Jdecoux:

Spatial Guide

2022-07-19T22:55:40Z

Jdecoux: /* Temperature Stabilization */

[[Category:Primer]]
{{TOC limit|2}}

==Spatial Sensors and Their Uses==
[[Image:Spatial_Intro.jpg|link=|center]]
===Introduction to AHRS===
Phidgets Spatial sensors use AHRS (Attitude and Heading Reference System) as a means of combining data from accelerometers, magnetometers and gyroscopes into a calculation of the device’s orientation more precise than could be achieved by any of the sensors individually.

While this process is by no means straightforward, PhidgetSpatial sensors come with built-in AHRS calculations combining data from all three types of sensors out of the box. By using the Phidget Spatial object in your code, you can get a direct reading of the heading of your device, in both Euler angle and Quaternion form.

===Euler Angles===
[[File:EulerAngles.jpg|330px|link=|thumb|A Representation of Euler Angles]]
Euler angles are a measure of an object’s orientation in the form of pitch, roll, and yaw angles. The advantage of Euler angles in denoting heading is that they are relatively easy to visualise.
You can get the Euler angles of your sensor directly from the Phidgets library.

While they are a human-friendly way of denoting overall orientation, we strongly recommend against using Euler angles in post-processing calculations, as they can be susceptible to problems of [https://en.wikipedia.org/wiki/Gimbal_lock#In_applied_mathematics gimbal lock]. For applications requiring more adjustments than a simple heading offset, we recommend using quaternions.

===Quaternions===
[[Image:quarternion.jpg|thumb|link=|A Visualization of Quaternions]]
For applications that require more complex analysis, PhidgetSpatial devices also provide the orientation of the device using quaternions. Quaternions are a more mathematically complete way of denoting orientation and rotations of a system. For what they lose in intuitiveness, the advantage of quaternions is that they can be used in any number of complex calculations without the risk of the aforementioned gimbal lock.

For most practical purposes, it helps to remember that quaternions are not meant to be visualized, or dealt with directly. Instead, any program or library that uses them will have functions to perform calculations with them behind the scenes. If you don’t yet have such a library in your program, but need to use quaternions, we recommend finding one, rather than wading through the math yourself. In this way, while they are difficult to visualize, you can at least remain comfortable in the knowledge that one does not often need to fully understand quaternions to use them in an application.

Quaternions tend to be the preferred rotation system for programs that deal with 3D objects, like Unity, and their inclusion as an output directly from a PhidgetSpatial is designed to make sensor integration as seamless as possible.

===What Does AHRS Actually Do?===
The AHRS algorithm on Phidgets uses an accelerometer and a magnetometer to keep track of heading over long timescales. When the device is perceived to be at rest, the heading and gyroscopes are gradually aligned and zeroed to reflect that the device is not moving, and pointed towards combined direction from the magnetometer and accelerometer readings. When the device is in motion, the AHRS algorithm starts relying more heavily on the gyroscope for angular rotations, since the accelerometer may no longer be pointing straight down, and the field from the compass may be in flux. By adjusting how much the device relies on the gyroscope in place of the accelerometer and magnetometer, a smoother and more accurate profile of the device’s orientation can be achieved than by using any of the sensors alone.

===Temperature Stabilization===
Electronic accelerometers and gyroscopes are sensitive to changes in temperature to a small but measurable degree. For cases where long term accuracy is a priority, some of our Spatial sensors have a temperature stabilization feature which allows the boards to heat themselves up to a pre-defined constant temperature (typically 45 or 50°C) to reduce or eliminate drift due to temperature effects.

When using the temperature stabilization feature, it is very important to wait for the board to be fully heated and settled before use, as the process of heating the board will change the sensor readings as the temperature rises to the target. Phidgets that allow temperature stabilization are calibrated at their target temperature, so the sensors will produce more accurate results once heated.

If you are using a temperature-stabilized spatial sensor, it is also very important to keep the board in its enclosure or otherwise insulated from outside air, as air moving directly over the warmed sensors will cause worse results than if the board was not heated at all.

==Demonstrations Using the Control Panel Example==
'''''Note: '''If your control panel example does not resemble the following, be sure to update your Phidget Control Panel. If your example still doesn't match, your Spatial Phidget is likely too old to support built-in AHRS calculations.''

[[File:Spatial_Example_AlignModel.jpg|400px|link=|thumb|Click the ''Align Model'' button to align the AHRS model to your screen]]

The spatial example gives you a way to directly visualize the results from the AHRS algorithm used on Phidget Spatial sensors. We recommend using this example with the sensor in hand at your desk to help visualize the effectiveness of the algorithm.

The first thing you might notice is that the model doesn’t appear to match the orientation of the spatial in your hand. To make the AHRS model line up with your physical spatial, point the wire at the screen and click Align Model. Your spatial model should now mirror the movements of the spatial in your hand.

The AHRS compass drawing is also provided as a visual indicator of the Heading, independent of the screen location. Notice that the compass bearing indicates north when the left-hand side of the Phidget is pointed north.

If your sensor has a heating option, be sure to check the ''Heating Enabled'' box, and wait until the temperature reading stays green for best results. In your own programs, wait until the temperature reaches 45C, and then if possible give the sensor an additional minute or two to ensure the whole board is evenly heated.

===AHRS Settings===
[[File:Spatial_Example_AHRS_Settings.jpg|400px|link=|thumb|The AHRS Settings Box]]
Now we can look at the AHRS settings panel:
====Algorithm====
The algorithm setting dictates whether or not the compass is going to be factored into calculations.

*When setting Algorithm to AHRS (the default setting) heading is gradually re-aligned with the compass over time, and all headings will be relative to magnetic north. When you Zero the AHRS algorithm, it will forcibly realign the heading to the compass reading.

*When using IMU, the compass readings are ignored, and a heading of 0° corresponds to the direction the device was facing when it was started, or where it was last zeroed. By clicking the Zero Algorithm button, it will realign all calculations to reference the direction it is currently facing as the new 0° heading.

====Zero Algorithm====
The Zero Algorithm button centers the algorithm’s heading either on the compass reading or on the direction it is currently facing (see AHRS Mode). The accumulated gyro biases will also be dropped, reverting to the raw (zeroed) gyro measurements. Note that the initial position in AHRS mode can vary by a couple degrees initially, due to noise inherent in the compass measurements. Click ''Zero Algorithm'' a few times now to see this for yourself. This noise will be averaged out by the rest of the algorithm, and it should settle into a consistent position after a couple seconds.

''If you find the model is drifting more than 2-3 degrees immediately after Zeroing the algorithm (while the spatial is staying still) you may want to try zeroing the gyroscope for better results.''

====Zero Gyro====
Before zeroing the gyroscope, ensure it is securely at rest. Zeroing the gyroscope will average the gyroscope’s readings for a second or two, and automatically subtract the result from subsequent measurements. This is a way to combat drift in the gyros, and we recommend finding a way to zero the gyros before starting AHRS calculations. The results of zeroing the gyro will only persist for as long as it remains open.

''If explicitly zeroing the gyro is not practical in your application, you can consider running the AHRS algorithm briefly with a wide ''Angular Velocity Threshold'', then narrowing said threshold again once the system has a chance to compensate for drift on its own.''

===AHRS Parameters===
[[File:Spatial_Example_AHRS_Parameters.jpg|400px|link=|thumb|The AHRS Parameters Box]]
The AHRS parameters are used to determine certain characteristics of your system so the AHRS algorithm can make better assumptions about the movement in your system. Each of these parameters will have recommended values as a starting point for your Phidget in a [[#Suggested Parameters|table]] below.

====Angular Velocity Threshold====
This is the minimum reading from your gyroscopes that the device will use to assume the device is at rest. While the device assumes it is at rest, it will gradually adjust towards making the current gyro readings the new “zero”, compensating for drift over time. This value can be significantly lower if you have zeroed your gyroscope before zeroing the algorithm, as the pre-existing drift of the gyros will have been accounted for. Otherwise, this value will need to be large enough to overcome any pre-existing offsets in your gyro.

''The closer you can set this value to zero, the slower the device needs to turn (or think it’s turning) to stop adjusting the gyro biases. If this value is too high, the gyros can be biased away from what is truly stationary. If this value is too low, the gyros will never adjust their bias, and you will see drift over time.''

====Angular Velocity Delta Threshold====
This is the minimum change between gyroscope samples before the gyro stops thinking it’s at rest. You can get a good value for this from the gyroscope example after installing the gyro in your application. Simply open the graphs for all axes, and set this value near the peak-to-peak noise.

''If this value is too low, the device will never think it's at rest. If it's too high, certain vibrations could affect your gyro biases (though the effects of these may also be limited by the Angular Velocity Threshold).''

====Acceleration Threshold====
The minimum measured acceleration your system will assume it is at rest, minus gravity. This value is also used to determine how much motion is accepted before the device begins to ignore the acceleration vector as a reliable source of “down”, and relies entirely on the gyros for pitch and roll until the device stops again. Again, you can use the noise in the graphs from your accelerometer example to get a baseline of the noise, and choose a value accordingly.

''If this value is too high, your device can adjust to thinking “down” is the wrong direction, or be swayed by fast motions. If this value is too low, the device may never think it is at rest to begin the process of correcting its pitch and roll.''

====Mag Time====
The amount of time (in seconds) your system will take to re-adjust the heading 95% of the way to aligning with the compass bearing, for differences in compass bearing and AHRS heading less than 15 degrees. Outside of 15 degrees of error, this is the time it will take the AHRS heading to correct towards the compass bearing by 45 degrees, to help limit adverse effects of interference. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more (but never entirely) resistant to magnetic interference, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the magnetic field readings. If this value is low enough, white noise in your compass readings will begin to show up in your measured heading.''

====Accel Time====
The amount of time (in seconds) your system will take to realign your pitch and roll to the acceleration vector, once the device believes it is at rest. The better the gyros in your system, the higher this value can be.

''By setting this value higher your device can become more resistant to acceleration affecting orientation, at the expense of placing more weight on accurate gyroscope readings. By setting this value lower, the device’s orientation will more quickly adjust to the accelerometer readings (limited by the above Acceleration Threshold).''

====Bias Time====
If the sensor is deemed to be at rest, a “bias” parameter internal to the algorithm is slowly added to the gyroscope to compensate for any drift. Effectively, this will automatically gradually zero the gyro readings internal to the algorithm, reducing or eliminating the effects of drift. The time specified here (in seconds) is the time it takes to adjust the bias parameters to compensate for 95% of the gyro’s offsets once the device is at rest.

''The speed the gyros should be biased is a balance between getting a solid average and having the zeroing occur quickly enough that biases can be fully compensated for during short periods or rest.''

===Example===
[[File:AHRS_Example_Menu.jpg|400px|link=|thumb|The AHRS Example Parameter Selection]]
To get the best precision we recommend tuning these parameters as best fits your application. However, we have provided some sample values to make a couple demonstrations, and to give you some idea of how to adapt these parameters to certain situations.

To more easily set up these example cases, this dropdown provides a list of settings for generic cases, and demonstrations of how you might adapt these values to certain scenarios.

====General Purpose====
A set of values selected for your device that should work “well enough” out of the box for simple situations, such as moving the device around with your hand.

====No Gyro====
To demonstrate why gyroscopes are an essential part of AHRS, we’ve given some settings that will effectively ignore any input from the gyroscopes, and snap to the magnetometer and accelerometer readings alone. You will notice this is incredibly noisy, especially if you start moving the sensor around.

''We do not recommend using these settings in practice.''

====All Gyro====
For completeness, we have included a selection to set AHRS to more or less ignore input from the magnetometers and gyroscopes. By selecting this sample, you can see how the gyroscopes will drift over time and fast motions, clearly demonstrating the need for the accelerometer and magnetometer to bring the gyros back into alignment.

''We do not recommend using these settings in practice.''

====Zeroed====
If you are able to zero your gyroscopes, and your application is relatively free of vibrations, you should be able to use a narrower Angular Velocity Threshold. As a result, you may also be able to relax the ''Mag Time'' and ''Accel Time'' parameters, since you can better trust that the gyroscopes will only be re-biased when they are truly not rotating.

====High Vibrations====
Regardless of whether or not you can zero your gyroscope, if your system suffers from constant large vibrations, the AHRS thresholds will have to be relaxed to allow the gyros to be biased at all. In doing so, we also raise the ''Accel Time'', not because we can trust the gyroscopes more in this scenario, but rather because we must trust the accelerometer less. Assuming there is little magnetic noise, ''Mag Time'' can be decreased to snap the heading closer to the magnetic field.

===Suggested Parameters===
{| class="wikitable" style="text-align: center;"
! !! Angular Velocity Threshold !! Angular Vel Delta Threshold !! Acceleration Threshold !! Mag Time !! Accel Time !! Bias Time
|-
! MOT1102 || 2.0 || 0.6 || 0.1 || 5 || 5 || 1.25
|-
! MOT0109 ''Out of the Box'' || 1.0 || 0.1 || 0.05 || 10 || 10 || 1.25
|-
! MOT0109 ''Heated and Zeroed'' || 0.5 || 0.1 || 0.05 || 120 || 120 || 1.25
|}

===Choosing a Phidget Spatial===
The Spatial Phidget you use in your application will depend on how accurate certain aspects of your measurement need to be. To simplify the decision, we can narrow this down to various kinds of applicaitons:

{|
! Applicaiton !! Phidget
|-
| Navigation or Outdoor Usage || [{{SERVER}}/products.php?product_id=MOT0109 MOT0109 PhidgetSpatial Precision 3/3/3]
|-
| Gestures and Qualitative Effects || [{{SERVER}}/products.php?product_id=MOT1102 MOT1102 Spatial Phidget]
|}

==FAQ==

===Why does the Euler Angle for pitch never exceed 90 degrees?===
The Euler Angles provided by the Phidgets library are calculated directly from a corresponding quaternion. They do not take into account past movements, so the orientation of a board that passes 90 degrees in pitch can just as easily be represented by a pitch of less than 90 degrees, with different roll and heading parameters. This is one reason why Euler Angles are not recommended for use in serious calculations, in favor of using the corresponding quaternions.

===Why do the Euler Angle readings stop working as well near 90 degrees of pitch?===
This is actually a good example of gimbal lock, and why it is not advised to use Euler Angles in calculation. When pitch approaches 90 degrees, the roll and yaw axes start to line up, which makes it hard to distinguish one from the other. In other words, at 90 degrees of pitch, a change in roll could just as easily be a change in heading, and vice-versa. This is another reason we recommend quaternions for all serious calculations.

Control Panel Graphing

2022-02-24T19:56:13Z

Jdecoux: /* More Complex Graphing */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|600px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid.

You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data. In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search the internet for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T19:55:04Z

Jdecoux: /* Fast Fourier Transform (FFT) */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|600px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid.

You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data. In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T19:50:09Z

Jdecoux: /* Fast Fourier Transform (FFT) */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|600px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T19:48:39Z

Jdecoux: /* Other Chart Types */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|600px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:ChartTypes.jpg

2022-02-24T19:48:02Z

Jdecoux: Jdecoux uploaded a new version of File:ChartTypes.jpg

File:ChartTypes.jpg

2022-02-24T19:46:51Z

Jdecoux: Jdecoux uploaded a new version of File:ChartTypes.jpg

Control Panel Graphing

2022-02-24T19:45:37Z

Jdecoux: /* Other Chart Types */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|400px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T19:45:21Z

Jdecoux: /* Other Chart Types */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

[[Image:ChartTypes.jpg|400px|center|link=]]

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:ChartTypes.jpg

2022-02-24T19:44:34Z

Jdecoux:

Control Panel Graphing

2022-02-24T19:41:22Z

Jdecoux: /* Filtering */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:Filtertype.jpg

2022-02-24T19:38:01Z

Jdecoux: Jdecoux uploaded a new version of File:Filtertype.jpg

Control Panel Graphing

2022-02-24T19:36:21Z

Jdecoux: /* Raw Data Graph */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Chart Length ===

You can adjust the amount of time displayed on your graph by adjusting the Chart Length slider. This can be helpful for setting up your graph to display data on timescales you are most interested in.

[[Image:chartLength.jpg|400px|center|link=]]

=== Longer Graphs ===

If you want to monitor a sensor over a period of hours using the Phidget Control Panel Graphing tool, you can do so by slowing down the ''Data Interval'' of your device, which will increase the amount of time that you can display on the graph.

[[Image:GraphingLongInterval.jpg|600px|center|link=]]

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|400px|center|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:Filtertype.jpg

2022-02-24T19:35:53Z

Jdecoux: Jdecoux uploaded a new version of File:Filtertype.jpg

File:ChartLength.jpg

2022-02-24T19:31:42Z

Jdecoux:

File:GraphingLongInterval.jpg

2022-02-24T19:27:44Z

Jdecoux:

Control Panel Graphing

2022-02-24T18:30:04Z

Jdecoux: /* Fast Fourier Transform (FFT) */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from; is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source; in this case, the signal wire was left disconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T18:27:53Z

Jdecoux:

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

== Raw Data Graph ==

The default graph is the Raw Data graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing sensor data in a much more concrete way than just reading numbers from the '''Control Panel Example'''.

=== Filtering ===

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

==== Low-Pass Filter ====

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

==== High-Pass Filter ====

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Other Chart Types ==

You can change the Chart Type selection to apply transforms to the data that may provide further insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from- is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source- in this case, the signal wire was left unconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T18:20:42Z

Jdecoux: /* Fast Fourier Transform (FFT) */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

The default graph is the '''Raw Data''' graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing a sensor's behaviour in a much more concrete way than just reading the numbers from the main '''Control Panel Example'''.

== Filtering ==

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

=== Low-Pass Filter ===

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

=== High-Pass Filter ===

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Graph Type ==

You can perform a transform on the incoming data to get different graph types that may provide insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this raw voltage data:

[[Image:voltage-badConnection-raw.jpg|600px|center|link=]]

It's clear that there's just under 1mV of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from- is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:voltage-badConnection-fft.jpg|600px|center|link=]]

The FFT plot reveals that a significant fraction of the noise is coming from a 60Hz source- in this case, the signal wire was left unconnected and picking up noise from the power grid. You can increase the graph length to sharpen the frequency spikes, just know this will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:Voltage-badConnection-fft.jpg

2022-02-24T18:12:45Z

Jdecoux:

File:Voltage-badConnection-raw.jpg

2022-02-24T18:12:23Z

Jdecoux:

File:Lowpass.jpg

2022-02-24T17:30:32Z

Jdecoux: Jdecoux uploaded a new version of File:Lowpass.jpg

Control Panel Graphing

2022-02-24T17:27:38Z

Jdecoux: /* High-Pass Filter */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

The default graph is the '''Raw Data''' graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing a sensor's behaviour in a much more concrete way than just reading the numbers from the main '''Control Panel Example'''.

== Filtering ==

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

=== Low-Pass Filter ===

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

=== High-Pass Filter ===

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals. As a rule of thumb, be sure the time on the filter is longer than the period of the signal you are interested in, or you will see distortions.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Graph Type ==

You can perform a transform on the incoming data to get different graph types that may provide insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this accelerometer raw data:

[[Image:accel-raw.jpg|link=]]

It's clear that there's around ±0.002g of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from- is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:accel-fft.jpg|link=]]

The FFT plot reveals that the noise is mostly coming from something vibrating at 9Hz- in this case, a nearby motor was running. You can increase the graph length to sharpen the frequency spikes, just know it will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

Control Panel Graphing

2022-02-24T00:42:11Z

Jdecoux: /* High-Pass Filter */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

The default graph is the '''Raw Data''' graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing a sensor's behaviour in a much more concrete way than just reading the numbers from the main '''Control Panel Example'''.

== Filtering ==

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

=== Low-Pass Filter ===

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

=== High-Pass Filter ===

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency components of your signal. This can be used on very short timescales to characterize the high-frequency noise in the system, or it can be used over longer timescales to remove offsets to more easily gauge the scale of periodic signals.

Select "High Pass Filter" from the drop down menu to remove low-frequencies and offsets from your data.

[[Image:highpass.jpg|850px|center|link=]]

== Graph Type ==

You can perform a transform on the incoming data to get different graph types that may provide insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this accelerometer raw data:

[[Image:accel-raw.jpg|link=]]

It's clear that there's around ±0.002g of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from- is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:accel-fft.jpg|link=]]

The FFT plot reveals that the noise is mostly coming from something vibrating at 9Hz- in this case, a nearby motor was running. You can increase the graph length to sharpen the frequency spikes, just know it will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:Highpass.jpg

2022-02-24T00:41:30Z

Jdecoux:

Control Panel Graphing

2022-02-24T00:15:18Z

Jdecoux: /* Low-Pass Filter */

__NOTOC__

In the [[Phidget Control Panel]], open the channel for your device and click on the [[Image:plot.jpg|link=]] icon next to the data type that you want to plot. This will open up a new window:

[[Image:plot2.jpg|link=]]

The default graph is the '''Raw Data''' graph. This graph displays the readings from your sensor over time. This can be very helpful in visualizing a sensor's behaviour in a much more concrete way than just reading the numbers from the main '''Control Panel Example'''.

== Filtering ==

You can perform filtering on the raw data in order to reduce noise in your graph.

[[Image:filtertype.jpg|link=]]

=== Low-Pass Filter ===

This filter reduces and removes high frequency components of the graphed data. It's generally used to smooth out your graph, since high-frequency noise can make a graph harder to read. Select "Low Pass Filter" from the drop down menu and move the slider to select the averaging window. The larger the averaging window, the smoother the line will be.

Note that if your filter is comparable to or longer than the period of the signal you are trying to measure, you will start to filter out the data you want along with the noise.

[[Image:lowpass.jpg|820px|center|link=]]

=== High-Pass Filter ===

Unlike the low-pass filter, this filter is used specifically to look at the high-frequency noise in your signal. Select "High Pass Filter" from the drop down menu to see the noise.

== Graph Type ==

You can perform a transform on the incoming data to get different graph types that may provide insights into your sensor data.

=== Fast Fourier Transform (FFT) ===

The FFT graph type will transform your data into a frequency plot, which can sometimes reveal hidden information about your data. For example, if you look at this accelerometer raw data:

[[Image:accel-raw.jpg|link=]]

It's clear that there's around ±0.002g of noise in the signal, but just from looking at the raw data it may be unclear where the noise is coming from- is it the sensor itself, or something external? Switching to the FFT plot gives us a clue:

[[Image:accel-fft.jpg|link=]]

The FFT plot reveals that the noise is mostly coming from something vibrating at 9Hz- in this case, a nearby motor was running. You can increase the graph length to sharpen the frequency spikes, just know it will take the graph longer to react to changes in the incoming data.

In general, the FFT plot is most useful for analyzing sensor data where frequency has useful real-world implications, such as measuring vibrations of an accelerometer, or checking for 50/60Hz interference form the power grid.

=== Allan Deviation ===

[[Image:gyro-allan.jpg|link=]]

Allan Deviation is a very specialized type of graph used to compare noise characteristics between sensors. Interpreting the Allan Deviation plot is outside the scope of this guide, but in general your sensor should be stabilized (e.g. if it's a spatial, it should be stationary. If it's a temperature sensor, the ambient temperature should be kept at a static level).

==More Complex Graphing==
If you need more complex functionality such as logging multiple sensors to the same sheet or performing calculations on the data, you'll need to write your own program. This graphing tool is intended as a jumping-off point to better understand your sensors individually, so you can get a feel for how to use them in your applications.

The quickest way to get started is to download some [{{SERVER}}/?view=code_samples sample code] for your desired programming language and then search Google for information on logging or plotting data in that language (e.g. "how to log to csv in python").

File:Lowpass.jpg

2022-02-24T00:14:14Z

Jdecoux: Jdecoux uploaded a new version of File:Lowpass.jpg