Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Device classes



There have been several attempts at defining device classes and how these interact with communications, we started by defining one byte for device classes with one nibble for 'major' class and one nibble for 'minor' sub-class. Under this definition the header was defined to only represent the 'major' class. Further discussions have led to consider individual bits to define 'orthogonal' meaning to class definitions. This is part of such proposal:


The sender classes are a fixed set of class elements.  It would appear that more might be needed due to the non-interaction of the properties.  
 
Bit 0 = Source/Sink; 0= Source, 1= Sink; at the current time (has meaning under the specific connection)

Bit 1 = Bidirectional Capability; 1=no, 0= yes capable of changing sink-source role 

Bit 2 = intermittent source; 1=no, 0= yes – Solar, Wind, Human etc powered where it cannot be relied upon for steady power.

Bit 3 = Internal power storage 1= no, 0= yes;  Can be local battery of a laptop or internal uninterruptable power source battery.

Bit 4 = Restricted/special requirements; 1=no, 0=yes;  Further information is needed to establish compatibility.  Aimed at identifying possible medical or hazardous or other safety type issues that require additional coordination before use. (Perhaps an added message type for the negotiation of the special requirements?)

Bit 5 = Hub or Docking station; 1=no, 0=yes;  a re-distributor of power. Priority issues? There can be many ports behind this device, or layers of ports, and how are they treated in overall power priority?  Think about USB discovery process in walking the multiple layers. Requires probing secondary ports.

Bit 6 = Reserved for expansion; 1=no expansion, 0= see expansion message.  This is the escape clause for future expansion.  This may want to be the first bit as it may redefine the others.
 
I believe this puts a default 111111 as a test equipment or such.  It can however use a HIGH request priority. A dumb device/non-communicating device does not answer in any way.
 
Hubs or Docking stations need to be flagged in both directions because of the tree structure of the distribution.  The hub/dock may have multiple power sources including internal storage.

Notes:
- The current communication working proposal has a separate priority channels for different types of communications types. The 'test channel' has the lowest communications priority.
- I have attached an _older_ class proposal for reference (note that only the 'high' nibble is defined).

Attachment: PastedGraphic-1.pdf
Description: Adobe PDF document


Edgar