• Lower and upper limit for sample rate and data rate
• Error coefficient (linear error part)
• Lower and upper limit frequency of signal
  • guaranteeeing measurement precision
  • 3 dB drop (maybe rise)
  • custom drop (maybe rise)

• 0x3001 1000 (Hz for example)
• 0x03E8 1000 (Hz for example, prefered coding)
• 0x0000 0 (zero value; while the exponent is not important here, it should be 0 for –2046 upto +2846)
• 0xD00A 0.01 (relative uncertainty of measurement value: 1 %)

• Omitting data to items should be the same as putting a null value.
  • 15 00   // Logical Minimum (0)
  • 14      // Logical Minimum ()
  Should be interpreted as the same. The Windows HID driver rejects such items, the driver won't load successfully.

• Null values for Report Count indicate disabled items.

• Values larger than 1 for Report Count (Report size > 1) may indicate buffered data with constant sample rate.

• Extra values defined for signed integers for encoding NaN, +∞, –∞:
  • 8 bit: 0x7F, 16 bit: 0x7FFF, 32 bit: 0x7FFFFFFF = +∞
  • 8 bit: 0x80, 16 bit: 0x8000, 32 bit: 0x80000000 = NaN (no measured value, empty slot)
  • 8 bit: 0x81, 16 bit: 0x8001, 32 bit: 0x80000001 = –∞
  Same procedure for any other bit size. It's important for the host software to handle these 3 cases while sign-extending, range-compressing, or converting to a float value! Here a procedure for sign-extension of 8 or 16 bits to 32 bits:
  1. Load the value to a 32-bit register
  2. Flip sign bit
  3. Sign-extend
  4. If (unsigned)(value+1) ≥ 3 (Have regular value)
     • Flip bits from sign bit towards MSB, or
     • Get value again and sign-extend it as usual
  5. else (have denormal value)
     • Flip MSB

  long expand(char x) { long t=(char)(x^0x80); if ((unsigned long)(t+1)>=3UL) return x; return t^0x80000000L; }

  long expand(short x) { long t=(short)(x^0x8000); if ((unsigned long)(t+1)>=3UL) return x; return t^0x80000000L; }

  float expand(long x) { switch (x) { case 0x7FFFFFFF: return -INF; case 0x80000000: return NaN; case 0x80000001: return +INF; } return x; }

• Some Set_Feature requests can change the Report Descriptor!
  Note that the same features may be volatile. In this case, all pipes react sending STALL until cleared.
  Example: Multimeter with non-lockable dial for measurement mode and range.
  The client software has to clear the stall condition by re-reading the report descriptor, interpret for changed values and to resume the measurement and recording process with changed units, range, uncertainty etc.
  String descriptors are assumed to be static.

• 0x21 Report Descriptor (one)
• 0x22 Physical Descriptors (multiple)

• 0x23 Conditioner Descriptors (multiple, count can be variable)
• 0x24 Uncertainty Descriptors (multiple, count can be variable, for more complex uncertainty description)
• 0x25 Factory Certification Descriptor (zero or one)
• 0x26 User Certification Descriptor (zero or one)

Bridge technologies

• least as possible overhead
• Same or mostly the same descriptors
• Same or almost the same transportation
• Synchronization measures as good as it can

• Inter-process communication between PnPSA client and a PnPSA server. The PnPSA server's purpose is converting a non-PnPSA device to be PnPSA compliant. So it's merely a driver. This will ensure evolution towards PnPSA.
• True networking between computers, for remote sensing
• A pseudo-driver for converting USB to TCP should be available for all major host systems (is a task for me)

This bridge has the following capabilities:

• A TCP socket based bridge has one connection transferring SETUP, OUT and IN data the same way as done in USB. However, the preamble and acknowledge is omitted for simplicity. SET_ADDRESS is not supported. FIFO sizes can be assumed to be quite large, at least 4096 bytes.
• The “USB” configuration descriptor's endpoint descriptor is extended to contain a socket number instead of the USB endpoint number.
• STALL is emulated by closing the data pipe by device
• USB RESET = host closes and re-opens control TCP connection
• SET_ADDRESS unsupported (not needed)
• No remote wakeup feature
• Surprise removal = device closes control TCP connection

• Sophisticated devices that need (or don't need):
  • low data transfer rate and no synchronization (i.e. per-sample polling)
  • longer cables
  • isolation
• Migration for measurement devices with changeable firmware

This bridge has the following capabilities:

• PnP negotiation, as documented in Serial PnP documentation, starting with 1200,7,n,1 (possibly not possible for RS485 buses)
• Baud rate negotiation: To be defined!
• The data rate should support 115200 Baud, to use the maximum possible rate for most PC equipment
• All other serial settings are fixed to
  • 8 data bits, no parity, 1 stop bit, true binary mode
  • no handshake (it's done within the USB-alike layer)
  • idle-timeout should be 30 bit times, for detecting missing answers
  • end-of-transmission timeout should be 10 bit times, for detecting short packets
  • DTR at +12V, RTS at –12V, to feed low-power equipment like mice or other HID
• Single-Device Mode (RS232, RS422) and Multiple-Device Mode (RS485) via SET_ADDRESS
• Full-Duplex operation support is not intended for now
• Functionality compatible to USB Low-Speed devices:
  • FIFO size: 8 bytes (plus header, 1 byte, plus checksum, 2 byte)
  • Only control endpoint EP0, interrupt endpoints, no bulk or isochronous endpoints
  • Optional: KeepAlive simulated by short BREAK (10 .. 20 bit times)
• USB RESET = long BREAK (50 ms)
• SET_ADDRESS supported (needed for RS485)
• No remote wakeup feature
• No true support for surprise removal

While drivers for TCP and Serial Line has to be written by the Standard maker, other drivers are intended to be vendor specific.