 |
Barst
2.0
A server that controls lab hardware.
|
|
Barst
2.0
A server that controls lab hardware.
|
#include <cpl defs.h>
Public Attributes | |
| SBaseIn | sDataBase |
| SBase | sBase |
| DWORD | dwPos |
| DWORD | dwCount1 |
| DWORD | dwChan2Start |
| DWORD | dwCount2 |
| DWORD | dwChan1S |
| DWORD | dwChan2S |
| float | fSpaceFull |
| float | fTimeWorked |
| float | fDataRate |
| unsigned char | ucError |
| double | dStartTime |
The struct that the ADC device sends to the client filled with DWORD data read from the ADC. The DWORD data immidiatly follows this struct.
Definition at line 375 of file cpl defs.h.
| double SADCData::dStartTime |
See dwChan1S description.
Definition at line 437 of file cpl defs.h.
| DWORD SADCData::dwChan1S |
Each USB transection with the ADC device gets time stamped (uncertainty of the time stamp is a few ms, depending on the USB communication uncertainty). The time stamp is given in the dStartTime parameter. Because the data in one USB transection can be broken down and sent in multiple packets based on the dwDataPerTrans parameter. The timestamp then is associated with a particular data point within the buffer, because that data point would have been the first data point read in a new USB transection. dwChan1S tells you the index of this data point for channel 1 and dwChan2S is the index for channel 2 (they should be very close to each other). If this packet doesn't have a data point that was timestamped, e.g. because this is the second packet of a single USB transection then dStartTime will be zero.
Definition at line 416 of file cpl defs.h.
| DWORD SADCData::dwCount1 |
Everytime that we send this struct we always send this many bytes: sizeof(SADCData)+sizeof(DWORD)*SADCInit.dwDataPerTrans*(SADCInit.bChan2?2:1), that is because we are expected to send dwDataPerTrans data points per channel for each transmission we always send the same amount of data. However sometimes, the last packet might not have enough data to fill up the full dwDataPerTrans data points. Consequently, even though we still send the same number of bytes, dwCount1 and dwCount2 tell you how much actual data points is in this data buffer.
Immidiatly following the SADCData struct follows channel 1 data, the total buffer length for channel 1 is dwDataPerTrans, the first dwCount1 points of which is the actual channel 1 data. dwChan2Start tells you where channel 2 data starts. Because channel 2 data follows channel 1 data, dwChan2Start must always be equal to dwDataPerTrans (the max number of data points for channel 1). If channel 2 is active, the buffer length in data point units is also dwDataPerTrans. So dwCount2 tells you how many actual data points is in this buffer.
Definition at line 406 of file cpl defs.h.
| DWORD SADCData::dwPos |
For each SADCData struct we send to the client, dwPos is incremented by one. This allows to keep track if user lost a packet.
Definition at line 393 of file cpl defs.h.
| float SADCData::fDataRate |
Estimates the data rate of the ADC. It should be near the ADC sampling rate.
Definition at line 429 of file cpl defs.h.
| float SADCData::fSpaceFull |
As mentioned in fUSBBuffToUse, we can select different size for the buffer length that is written to the USB device at once. If it's very small, than most of the buffer read would be full with ADC data. If it's very large, then it should be mostly empty because it's more efficient. This parameter tells you the percentage of the buffer that was filled with ADC data read. If it's close to 100, that means you're close to losing data because the buffer might be too small or clock too slow to be able to read the data fast enough. So you should increase the buffer size or set a smaller smapling rate in the ADC hardware device.
Definition at line 424 of file cpl defs.h.
| float SADCData::fTimeWorked |
Tells you the percentage of time from one read to another that the ADC thread spent extracting the ADC data from the buffer.
Definition at line 427 of file cpl defs.h.
| SBase SADCData::sBase |
sBase.eType is eADCData and sBase.dwSize is sizeof(SADCData)-sizeof(SBaseIn).
Definition at line 390 of file cpl defs.h.
| SBaseIn SADCData::sDataBase |
According to the rules, each communication starts with an SBaseIn/Out and is possibly followed by an SBase and other structs. In ordeer to be able to send ADC more easily all these structs are included at once in this SADCData struct. sDataBase is the SBaseIn, sBase is the SBase struct and the stuff following is considered as the struct following the SBase struct.
For this struct, sDataBase.nError is not an error code, instead, the lower 16 bits indicate how many times the data the ADC sent to the USB bus was bad. The upper 16 bits in nError indicates how many times the ADC device overflowed, i.e. how many times the USB bus was too slow to collect the data from the ADC device and the ADC device therefore overwrote data.
eType should be eTrigger.
Definition at line 388 of file cpl defs.h.
| unsigned char SADCData::ucError |
When we read from the ADC status register, we get additional error info. Bit 0 (for channel 1) and/or bit 4 (for channel 2) is set if the input voltage sensed by the ADC is out of range, e.g. it's outside of the +/- 20v range if that's the allowable range. Bit 2 (for channel 1) and/or bit 6 (for channel 2) is set if the voltage reference on the chip is not sensed. This simply means there's a hardware error.
Definition at line 435 of file cpl defs.h.
1.8.13