- Generated on Mon Apr 16 2018 21:50:09 for liblabpro by
1.8.14
|
liblabpro
Portable C library for data collection from Vernier LabPro devices
|
Struct representing a "data session" Data sessions are an abstraction over the LabPro's command-oriented data collection system. You create a data session for each channel (running LabPro_check_data_session() every time the user modifies a value), then you "stage" the data sessions with LabPro_stage_data_session(), then run a final check for conflicts with LabPro_check_sessions_for_conflicts() before submitting the sessions to the LabPro with LabPro_start_data_collection(). More...
#include <liblabpro.h>
Data Fields | |
| enum LabPro_Channels | channel |
| The channel to use. More... | |
| enum LabPro_Analog_Chan_Operations | analog_op |
| The type of data to collect (analog channels). For most analog sensors you should use LABPRO_CHANOP_AUTOID. If channel is not an analog channel, set this to zero. More... | |
| enum LabPro_Sonic_Chan_Operations | sonic_op |
| The type of data to collect (sonic channels). I do NOT recommend using anything but LABPRO_DISTANCE_AND_DT_METERS because making the LabPro calculate velocity and acceleration just causes the circuitry to get hot and return inaccurate or jittery data. More... | |
| enum LabPro_Analog_PostProc | postproc |
| Post processing LabPro can perform the first and second derivatives with respect to time for you. However, I do not recommend using this, because it will mean more work for the poor little LabPro, and when the LabPro gets warm, the measurements tend to get inaccurate. More... | |
| enum LabPro_Sampling_Modes | sampling_mode |
| Sampling mode: realtime or non-realtime. The names are a bit misleading, because LabPro itself will always capture in real-time. However, you can think of this setting as the way the host needs to sample the LabPro. In real-time mode, the host has to request data from the LabPro in real-time because the LabPro does not store any data onboard. In non-real-time mode, the LabPro will record data as it collects it to ensure that no data points are lost. More... | |
| bool | use_conversion_eqn |
| char * | onboard_conversion_equation |
| bool | use_sonic_temp_compensation |
| char * | sonic_temp_compensation_equation |
Struct representing a "data session" Data sessions are an abstraction over the LabPro's command-oriented data collection system. You create a data session for each channel (running LabPro_check_data_session() every time the user modifies a value), then you "stage" the data sessions with LabPro_stage_data_session(), then run a final check for conflicts with LabPro_check_sessions_for_conflicts() before submitting the sessions to the LabPro with LabPro_start_data_collection().
Of course, you may wish to have some sort of logic in your application as to when to start collecting from a previously-disabled channel, change sampling rate, etc. LabPro provides some options for triggering, but if those are insufficient, you can simply stop data collection early with LabPro_stop_data_collection(), make any necessary changes to the LabPro_Data_Session structs, re-stage them, re-check them, and start data collection again.
Definition at line 389 of file liblabpro.h.
| enum LabPro_Analog_Chan_Operations LabPro_Data_Session::analog_op |
The type of data to collect (analog channels). For most analog sensors you should use LABPRO_CHANOP_AUTOID. If channel is not an analog channel, set this to zero.
Definition at line 397 of file liblabpro.h.
| enum LabPro_Channels LabPro_Data_Session::channel |
The channel to use.
Definition at line 391 of file liblabpro.h.
| char* LabPro_Data_Session::onboard_conversion_equation |
Definition at line 445 of file liblabpro.h.
| enum LabPro_Analog_PostProc LabPro_Data_Session::postproc |
Post processing LabPro can perform the first and second derivatives with respect to time for you. However, I do not recommend using this, because it will mean more work for the poor little LabPro, and when the LabPro gets warm, the measurements tend to get inaccurate.
This should be LABPRO_POSTPROC_NONE if in realtime sampling mode (Because only one point is stored at a time in realtime mode) or when the channel is not an analog channel.
Definition at line 423 of file liblabpro.h.
| enum LabPro_Sampling_Modes LabPro_Data_Session::sampling_mode |
Sampling mode: realtime or non-realtime. The names are a bit misleading, because LabPro itself will always capture in real-time. However, you can think of this setting as the way the host needs to sample the LabPro. In real-time mode, the host has to request data from the LabPro in real-time because the LabPro does not store any data onboard. In non-real-time mode, the LabPro will record data as it collects it to ensure that no data points are lost.
If you will just be monitoring, not recording data, use non-real-time mode or command 9. (Though if you are monitoring for a condition to start recording, consider setting a trigger.)
If you want to record data but still show the data collection progress, you can use non-real-time mode, but call LabPro_data_sample() to get the last data point.
Definition at line 442 of file liblabpro.h.
| enum LabPro_Sonic_Chan_Operations LabPro_Data_Session::sonic_op |
The type of data to collect (sonic channels). I do NOT recommend using anything but LABPRO_DISTANCE_AND_DT_METERS because making the LabPro calculate velocity and acceleration just causes the circuitry to get hot and return inaccurate or jittery data.
If channel is not a sonic channel, set this to zero.
If the sampling mode is non-realtime, you cannot get velocity and acceleration from the LabPro. This is the opposite of post-processing for analog channels (see below).
Definition at line 411 of file liblabpro.h.
| char* LabPro_Data_Session::sonic_temp_compensation_equation |
Definition at line 447 of file liblabpro.h.
| bool LabPro_Data_Session::use_conversion_eqn |
Definition at line 444 of file liblabpro.h.
| bool LabPro_Data_Session::use_sonic_temp_compensation |
Definition at line 446 of file liblabpro.h.
1.8.14