RE: Topologies and attendance
Edgar,
Totally agree, the adapter output(port?), source, needs to be smart enough
recognize a request for power and to handle the energy transfer to the load
device. It needs to be smart enough to stay out of other transactions that
it is not designed to handle. NOP/NAK can be returned for requests that it
does not know how to handle. The low power communications keeps mismatches
out of the way like adapter<->adapter.
No load needs to know about any other load. It does need to be able to
respond to changes in the adapters ability to supply power, which may change
over time and circumstance.
Adapters, and hubs, have the ability to manage many different configurations
based only on the vendors target market and their creative ability. Adapters
does not know that it is a hub, just that it is a load. Clearly with 100W
input it can support 2x20w and 1x60w loads, with 60w in it can only support
2x30W outputs(assuming perfect efficiency).
Sorry about missing your legacy device interface, please add it.
This diagram is to stimulate ideas and contributions and clearly brings the
earlier suggestions from the committee members into view, to the potential
enhancement and usefulness of the final UPAMD standard.
Respectfully,
Bob
-----Original Message-----
From: upamd@xxxxxxxx [mailto:upamd@xxxxxxxx] On Behalf Of Edgar Brown
Sent: Wednesday, September 01, 2010 12:41 PM
To: upamd@xxxxxxxx
Subject: Re: Topologies and attendance
I think that we should clearly define the 'UPAMD domain' as the output port
of an adapter and the input port a one device.
Any other communications that leave or enter that domain should be clearly
defined.
This way all of the topologies in Bob's diagrams would be covered with one
simple set of rules. Among others, this set of simplifying restriction would
be useful:
- A device does not _need_ to know about the power source of an adapter.
- A device does not _need_ to know about the presence of other devices
(e.g., in other ports on the adapter).
- An adapter does not _need_ to know about other devices down-stream (e.g.,
a device getting power off another device).
- A device does not _need_ to know if it lies off a hub or an adapter.
- A device does not _need_ to know about other types of power ports on the
adapter.
- An adapter does not _need_ to know that a 'device' is really a cable that
connects to a legacy (non-UPAMD) device. (BTW: Bob, this is one of the
missing topologies).
Note that all of this falls into one simple rule: "UPAMD only governs the
exchanges between one device and one adapter" with a very clear definition
of the needed exceptions to this rule (e.g., cable-level indicators or
interfaces, subset of UPS messages, subset of smart grid messages, and
device-software initiated requests).
The only clear exception I see to this view of the 'UPAMD domain' would be
from the point of view of certification. This will require special rules for
a multi-port adapter or device. E.g., "it is UPAMD-compliant if every single
UPAMD-port on the device can be individually certified, with all ports
loaded to capacity."
Edgar
On Sep 1, 2010, at 3:18 PM, Piotr Karocki wrote:
> Oh, some very interesting options...
>
> a) USB power ports on UPAMD adapter - sounds good to me , but it may be
made as "normal" UPAMD port, and special cable-converter (with built-in
logic to communicate with UPAMD adapter, to send messages as "please set 5
V, with limit xx, for as long as you can")
>
> b) such cable-converter could be also made e.g. for my tablet - built-in
logic should only send other parameters to UPAMD adapter. Maybe some company
would manufacture cable-converters with some method of manually setting
parameters as voltage and amperage :)
>
> c) and most important, what you drew on "expansion box" - more than one
concurrent power input. How would such possibility add to cost of
adapter/expansion box?
>
> I think we should vote about "more than one concurrent power input"
configuration - allow or disallow (support or not support) such
configuration.
>
> d) also "expansion box", UPAMD device after UPAMD device. It suggest that
"expansion box" should steer UPAMD adapter after any plugged-in (to
expansion box) device change parameters. It requires more work on
communication protocol.
>
> I think this is another topic for vote - existence of 'active expansion
box', i.e. not simply split power from one socket to more sockets, but also
for e.g. voltage conversion in it.
>
>
>
>
> From: upamd@xxxxxxxx [upamd@xxxxxxxx] On Behalf Of Bob Davis
[bobd@xxxxxxxx]
> Sent: Wednesday, September 01, 2010 8:06 PM
> To: 'UPAMD'
> Subject: Topologies and attendance
>
>
> UPAMD,
>
> Attached is the topology drawing I promised to send out to stimulate ideas
on the things the UPAMD power distribution system can accomplish. These are
just potential thoughts. Feel free to expand and share.
>
> I did not realize that Austin was not on the call and I failed to capture
the attendance. If you were in attendance please send me a quick email to
that effect.
>
>
> Respectfully;
>
> Bob Davis
> UPAMD Chair
> bobd@xxxxxxxx
> 408.857.1273