Re: Effect of a universal power connector on Energy Star and EPEAT compliance
Ooops I just realized that we took this conversation off-line...
On Jul 16, 2010, at 12:30 PM, Piotr Karocki wrote:
>
> Edgar,
>
>> - include communication messages to allow for high-efficiency modes of operation (e.g., deep-sleep / soft-off).
> Do you mean that power supply should send such messages?
I mean that the power supply should be able to understand such messages. It could be the exact same as 'set-output to 0V', but the standard should specify what is the expected behavior of the power supply (from the device perspective) under those conditions.
>> include guidelines for sleep/soft-off modes and standard way to display them (i.e., LED color, blink pattern)
> If you mean such modes for power supply - what should it mean for it? (which changes in operation)
Possible modes I see:
- Supply is in standby. Nothing plugged in, but waiting.
- Supply is in operation. Everything A-OK.
- Supply is in operation, but device requested more power than I can give "I reached an agreement with the device."
- Device is in a 'green mode' of some type. Running in a low-consumption mode.
- Fault conditions of some type...
> And if you mean such modes for devices - should UPAMD standard specify such things about devices?
I don't think so...
>> Allow the communication of power-throttling messages to pass through the system.
> Pass through, but what is possible sender and what is possible listener to such message?
Possible listener, the device. Possible sender, the power grid/ups/home control system attached to some (non-UPAMD-specified) communication system on the adapter. On a smart-enough adapter, with future UPAMD-compliant ICs in both the device and adapter, a standard message can handle power throttling across a large range of devices.
This provides a point of convergence for routing a very specific class of messages between otherwise incompatible devices. E.g., the maker of a laptop computer does not need to make it compatible with all of the power-line communications standards to implement some green features in the computer itself. The user just needs to have an expensive UPAMD-compliant power adapter that is compatible with the specific communication system inside their house/power-grid.
>> A message can tell all connected devices when it is safe to turn-on or turn-off their WiFI radios.
> Great idea - using UPAMD messaging system as envelope to passing another messages.
> But, at same time, not such great idea - do you want relay some malevenient messages, e.g. from hacked phone to air-plane avionics, or from hacked avionics to all devices?
The security would only be as high as the weakest link in the system. If the UPAMD only specifies pass-through capabilities, then the avionics supply can take care of the security (here I am assuming an UPAMD plug on the plane seat itself). The UPAMD standard does not have to specify what the adapter does with generic messages coming from a device, just a standard way to relay them between adapter and device.
> And throughput of communication system should be greater to allow other messages transmitted.
I think this is the hardest issue to address:
- High-speed: complexity, cost, power requirements.
- Low-speed: not enough bandwidth to relay today's communication standard.
A possible compromise is a dual-band specification.
- Baseband communications for all UPAMD-related messages.
- Manufacturers are free to use the >500kHz cable bandwidth any way they like, as long as the interference with <500kHz does not exceed some set parameters.
>> In an off-the grid system. A message can tell all devices how much power is available
>> and how to throttle their use depending on power production
>> (e.g., only charge your batteries when the sun is shining).
> Something like "You are working on UPS, you have 10 minutes left" ?
>
> I think UPAMD should not transfer any not-own messages. Probably also from legal reasons :)
I guess that as long as the communications part of the standard:
- Only deals with adapter-to-device and device-to-adapter communications.
- Specifies standard behaviors for specific messages received from outside this adapter-device boundary.
- Serves the same functions as a dumb cable for other types of communications.
The legal issues should not be that problematic.
Edgar