A couple of related usage models;
1. Notebooks with docking stations; the docking is a serial connection (the EPS is connected to dock, and then the dock provides power to the notebook). The docking station has its own power consumption which is variable, uncontrollable and not directly
measurable by the notebook.
With HP notebooks, the AC adapter meters the actual output current and signals when the AC adapter is near its output capacity. The message is received by the notebook and the notebook reduces its power consumption.
2. Value in knowing the power source; Under-seat power on an airplane is 15.0vdc, identifying this source is valuable for 2 reasons;
a. HP recommends against charging the notebook on an airplane, and disables charge if we see a voltage that indicates such (as a safety precaution).
b. The power capability of the in-seat power is limited (to 75watts, I think). Unless the airplane is expected to adopt the UPAMD standard, then any adapter that would interface to the in-seat power should identify the source and communicate the capability
of the source.
--Lee Atkinson, HP
-----Original Message-----
From: upamd@xxxxxxxx [
mailto:upamd@xxxxxxxx] On Behalf Of Finch, Mike (GE, Appl & Light)
Sent: Thursday, September 02, 2010 11:52 AM
To: Edgar Brown; upamd@xxxxxxxx
Subject: RE: Topologies and attendance
I would like to register my agreement with Edgar.
-----Original Message-----
Sent: Wednesday, September 01, 2010 3: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