The UEI cards we simulate

direction could not be determined from the documented function names; both paths are exercised - confirm against the board manual before relying on it

no DQ_DIO402_* constant and no DqAdv402* API exist locally. The frame width is the one 32-bit word the sample writes through DqAdv40xWrite; the board's physically populated line count is NOT documented here

no DQ_DIO405_* constant and no DqAdv405* API exist locally. The frame width is the one 32-bit word the sample moves in each direction; the split between input and output lines is NOT documented here

direction could not be determined from the documented function names; both paths are exercised - confirm against the board manual before relying on it

no DqAdv430* API and no sample are documented locally, so the direction is UNVERIFIED and both paths are exercised

direction could not be determined from the documented function names; both paths are exercised - confirm against the board manual before relying on it

the frame is the 4 x 32-bit words of DQ_DIO_440_DATA_WORDS = 128 bits. How many of those lines are physically populated is NOT documented locally - the sample only ever walks bits 0..19 of two of the words

a single-channel board whose only documented API call configures it. The direction is UNVERIFIED and no sample exists locally

the scale is range-dependent and the headers document several; this carries the widest documented range. Pass --amplitude in the units of the range you have actually configured

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

the -300 variant has a different scale (DQ_AI228_300_SPAN = 600.0, OFFSET = 300.0); this simulator carries the base AI-228-1 scale. sensor linearisation - cold-junction compensation, thermocouple and RTD curves, shunt-calibration constants

no DqAdv418* API and no sample are documented locally. Only the 18-channel count is evidence-backed; the multiplexer's own switching behaviour is not reproduced

the scale is range-dependent and the headers document several; this carries the widest documented range. Pass --amplitude in the units of the range you have actually configured

no DqAdv301* API and no sample are documented locally; the direction follows the board family, not a documented function

the scale is variant-specific and the knowledge base documents five: -020 (0.02 A), -420 (0.016 A offset -0.004), -352 (27.034), -353 (80.0) and -354 (120.0). This simulator carries the -020 scale; pass --amplitude in the units of the variant you actually have

span is DQ_AO319_MAX - DQ_AO319_MIN = 16 mA, exactly as the header comment states; the header writes it as an expression rather than a literal

no DqAdv332* API is documented locally; the shape comes from the headers and the direction from the sample program

the only dimensioned path in the headers is the 32-channel ADC READBACK (DQ_AO333_ADC_CHAN); the DAC output channel count is not documented locally, and this simulator assumes the two match

edge and quadrature timing at microsecond resolution

edge and quadrature timing at microsecond resolution

edge and quadrature timing at microsecond resolution. The counter VALUE is carried faithfully; how it was arrived at - quadrature decoding, period and pulse-width measurement, PWM generation - is not

edge and quadrature timing at microsecond resolution. The GPS synchro-serial and pulse-generator FIFOs (DqAdv602SendGPSSMessage, WriteFifoPGen) are not reproduced

edge and quadrature timing at microsecond resolution. Quadrature decoding is the whole point of this board and it is exactly what a value pipe cannot reproduce - the simulator carries the resulting count, not the A/B edge stream

edge and quadrature timing at microsecond resolution

this is an IRIG/GPS timekeeper. The simulator carries a time VALUE on the one documented channel; it reproduces nothing of IRIG-B decoding, GPS tracking, PLL discipline or the timestamping of the nine event channels - which is what the board is for. Treat a pass here as proving your data path, never your time base

edge and quadrature timing at microsecond resolution. Only register get/set is documented for this board, so the simulator moves values on four channels and models no counter behaviour at all

UART bit timing, framing errors and break conditions

UART bit timing, framing errors and break conditions

UART bit timing, framing errors and break conditions

UART bit timing, framing errors and break conditions

UART bit timing, framing errors and break conditions; direction could not be determined from the documented function names; both paths are exercised - confirm against the board manual before relying on it

UART bit timing, framing errors and break conditions

UART bit timing, framing errors and break conditions

arbitration, bus-off state and error frames

arbitration, bus-off state and error frames

a custom bus-access layer: the simulator moves the two channels' data words, and reproduces nothing of the external bus timing, addressing or the script engine behind DqAdv104WriteScript. No sample program is present in the knowledge base for this board

no DqAdv105* API and no sample are documented locally, so the direction is UNVERIFIED and both paths are exercised. Only the channel count is evidence-backed

a custom message layer from DaqLibHLCustom.h. Messages are carried as channel values; the layer's own framing, watermarks and subsystem addressing are not reproduced, and no sample exists locally

a custom message layer from DaqLibHLCustom.h. Messages are carried as channel values; the layer's own framing, watermarks and subsystem addressing are not reproduced, and no sample exists locally

the board groups its 104 lines as 4 x 32-bit ports; the wire format here carries them as 13 x 8-bit ports, so the LINES are faithful but the grouping is not. Being an FPGA layer, whatever logic is loaded into it is by definition not reproducible, and no sample exists locally

a power-supply MONITORING layer: the simulator carries the measured rail values and reproduces nothing of the supply itself - no regulation, no fault or shutdown behaviour, no thermal response. No ADC span is documented for this model, so values are raw counts.

a power-supply MONITORING layer: the simulator carries the measured rail values and reproduces nothing of the supply itself - no regulation, no fault or shutdown behaviour, no thermal response.

a power-supply MONITORING layer: the simulator carries the measured rail values and reproduces nothing of the supply itself - no regulation, no fault or shutdown behaviour, no thermal response.

a power-supply MONITORING layer: the simulator carries the measured rail values and reproduces nothing of the supply itself - no regulation, no fault or shutdown behaviour, no thermal response. No ADC span is documented for this model, so values are raw counts.

a power-supply MONITORING layer: the simulator carries the measured rail values and reproduces nothing of the supply itself - no regulation, no fault or shutdown behaviour, no thermal response. DQ_PC_928_ICHAN is defined as DQ_PC_927_ICHAN, so the count is the 927's. No ADC span is documented for this model, so values are raw counts.

the only sample enables a wireless radio; there is no documented value path at all. The single channel is evidence-backed, the direction is UNVERIFIED, and nothing about the radio link is reproduced