As mobile devices become ever more ingrained into everyday life, consumers have an ever-increasing need for access to power. Yet, recharging a battery is typically difficult while travelling or anywhere on the go. Most locations built before the digital revolution—like most airports—do not have enough outlets to serve the modern consumer's insatiable demand for electricity. Even where some airports, coffee shops, and the like have introduced charging stations, they can rarely handle the increasing demand and do not usually integrate well into the rest of the building's design and aesthetics.
The disclosed low voltage power system uses a universal, low profile charging rail. The low voltage power system can be used in, for example, dorm rooms, restaurants, homes, hotels, cafés, mass transit stations, libraries, entertainment venues or the like. It can be adapted into existing spaces or designed into new projects. It can be installed in many colors and many locations including in walls, furniture, windows etc.
In general, the following disclosure relates to a connector module provided by a user. The connector module can be attached anywhere along the length of a charging rail with an electrical bus that has a carrier and at least a pair of electrically conductive elements. The pair of electrically conductive elements in the rail extend linearly along a length of the carrier and at least a portion of each of the least a pair of electrically conductive elements is exposed at a surface of the carrier. Magnets within the connector module secure the connection to the rail. The connector module has at least a pair of electrically conductive contacts for engaging with the electrically conductive elements at any desired location along the length of the carrier. Low friction between the connector module and the rails and the continuous design of the rail allow the attached module to slide without disconnecting the device from the flow of power. The module's electrical connections are fully rotatable so that the user can face the module in any direction that they need.
The electrical bus in the rail further includes a data carrying element for communicating with the connector module and, as needed, with the device coupled to the connector. The rail system communicates with the modules to determine the optimal load to each device. If too many devices are connected to the rail, an intelligent load arbitration system reduces the power delivered to devices that are not utilizing the full amount of power available. Additional circuitry protects the rail from misuse and distributes power among the connected devices if there is a shortage.
With reference to the figures, an example conductive bus system using the low voltage power distribution system is now described. In general, the conductive bus system includes a charging module 100 that is intended to be electrically coupled to a conductive bus 200. The charging module 100 includes a plurality of electrical contacts 102 that are arranged such that a first circle 104 can be visualized to generally connect the plurality of electrical contacts 102 as shown in
As further illustrated in
The conductive bus 200 to which the charging module 100 is to be coupled includes an elongated carrier 202 constructed from a non-conductive material. In an example, the carrier 202 includes a channel 203 in which is disposed a ferromagnetic rail 204. When disposed within the channel 203, a surface 4 of the ferromagnetic rail 204 will preferably be exposed from the conductive bus 200 whereby the electrical contact 2 will be able to directly engage with the ferromagnetic rail 204 when the charging module 100 is disposed upon the conductive bus 200. While not required, the ferromagnetic rail 204 may be used to carry a communication signal, received from a controller that is coupled to the conductive bus 200, for provision to the charging module via the electrical contact 2 as described above. The carrier 202 further includes channels 205 and 206 for carrying conductive rails 207 and 208, respectively. When disposed within the channels 205 and 206, a surface 3 of the conductive rails 207 and 208 will preferably be exposed from the conductive bus 200 whereby at least one of the plurality of electrical contacts 102 will be able to directly engage with the conductive rail 207 and at least one of the electrical contacts 102 will be able to directly engage with the conductive rail 208. The carrier 202 may further include, additionally or alternatively, channels 209 and 210 for carrying conductive rails 211 and 212, respectively. When disposed within the channels 209 and 210, a surface 3 of the conductive rails 211 and 212 will preferably be exposed from the conductive bus 200 whereby at least one of the plurality of electrical contacts 106 will be able to directly engage with the conductive rail 211 and at least one of the electrical contacts 106 will be able to directly engage with the conductive rail 212. It will be understood that different configuration for the carrier 202 may be utilized as required and, as such, the carrier 202 illustrated in
The charging rail has two charged portions that run along the length of the track. The rail is connected to the building's power via a universal input power supply that steps the voltage down to 24V of direct current. The voltage potential between these charged portions is thereby kept low so that it is safe to touch and meets NEC Class 2/CE requirements. Power is delivered along the length of the rail, which is customizable. In one example, it is twenty-five feet long. In this example, 100 W is delivered to the twenty-four devices attached to the rail.
To ensure that the charging module 100 will engage with the conductive bus 200 to thereby allow the charging module 100 to be electrically coupled to the conductive rails regardless of the use orientation of the charging module 100 when positioned upon the conductive bus 200, i.e., in any orientation of the charging module 100 throughout the full 360 degrees of the visualized circles 104 and/or 108 when the contact 2 is engaged with the rail 204 as shown in
Other exemplary bus systems—in which the communication protocols and software described hereinafter may be utilized—are disclosed in U.S. application Ser. No. 14/986,225, filed on Dec. 31, 2015, U.S. application Ser. No. 14/857,918 filed on Sep. 18, 2015, U.S. application Ser. No. 14/030,768, filed on Sep. 18, 2013, U.S. Provisional Application No. 61/725,795, filed on Nov. 13, 2012. U.S. Provisional Application No. 61/768,907, filed on Feb. 25, 2103, U.S. Provisional Application No. 61/744,777, filed on Oct. 3, 2012, and U.S. Provisional Application No. 61/744,779, filed on Oct. 3, 2012, the disclosures of which are incorporated herein by reference in their entirety.
Referring now to
In this shown example of
Referring now to
The data bus 64 characteristic impedance is −120 ohms. A 120 ohm of resistance is placed within the CCM 62 and within the bus “terminator” at the other end of the bus. Together, these equalize the resistance of the circuit elements and are confirmed in IEM simulations of the bus. In the example used, bus voltage is set to a nominal −2.8V. The bus voltage is typically chosen as a compromise between high voltage for noise immunity and low voltage for minimum electromagnetic interference. The CCM 62 typically holds the data bus line in the “high” state (−2.8V) while the device (CCM 62 or CM 64) that is communicating on the bus. The CCM 62 is configured to pull the line low when necessary, such as for communications to prevent signal noise from impairing the flow of communications between the CCM 62 and the connector.
The CM includes a diode bridge 65. The Diode bridge 65 is necessary to support rotation of the CM 62 and causes the CM 64 ground to be −0.2-0.4V (Vd) above the CCM 62 ground. Signal levels may vary through the system due to the fact that the CM modules contain a diode bridge in the ground path as well as the ground path resistance of the bus rails. Ground path resistance causes up to an additional −0.3V drop (lgnd*Rgnd). Therefore, altogether data low and high voltages vary up to −0.7V between the CCM 62 and the worst case CM 64.
Referring to
Within the example data bus 66, the bus speed has been set to approximately 230,400 bits per second. At this speed, the example e-data bus can handle a maximum number of devices and their respective modules 64 connected to the rail based on worst case simulation of maximum bus traffic. In this shown example, the speed is supported by the example processors Microchip 8-bit PIC16LF18345 for the CM NXP LP1769, 32-bit ARM Cortex M3 for the CCM for the simulations. Other suitable processors for data bus communication and processing are considered.
Data byte framing within the data bus 66 follows a standard universal asynchronous receiver-transmitter (“UART”) protocol. The communication protocol includes one start bit and one stop bit for every packet of information and requires ten bits to send each eight bit data byte with the least significant bit sent first. When transmitting, the bytes are sent with most significant byte first. The data bus 66 utilizes the UART protocol implemented via processor hardware.
Turning more specifically to the communication bus protocol, the CCM 62 through its processor controls when each device can access the communication bus. The control by the processor is used to prevent bus collisions. Along the bus, at least three types of messages are sent: 1) direct messages, 2) broadcast messages, and 3) request messages.
In a direct message, the CCM 62 addresses a specific CM 64 with a message to which the CM must immediately respond within a specified time limit (e.g. 1.5 ms in the example data bus). Only the addressed CM may respond to the direct message to prevent collision. All other CMs ignore messages to which they are not addressed. In this situation, the CCM 62 may, for example, be instructing the CM 64 how much current to draw or asking for a device type identification.
In the broadcast message situation, the CCM 62 sends a “Broadcast” message to all devices on the bus for which there is no response expected from any CM 64. This message could be communicating timing or rail related information.
In a request message scenario, the CCM 62 sends an access broadcast message with numerous “time slots” within which a CM 64 may respond. This is used only for the initial bus access by a newly added CM 64. Each CM 64 randomly selects one of the time slots in which to respond. The CM 64 is programmed to select a new time slot if CCM 62 does not receive the message from the CM 64. The lack of response could occur due to a collision with another CM 64 that happened in the event that two or more CM 64 randomly select the same time slot.
Each message structure contains four elements: 1) 8 bit Bus Address, 2) 16 bit Message Header, 3) an optional Data Bytes Number, and 4) Cyclic Redundancy Check.
The 8 bit Bus Address directs the message to the correct device. The CCM 62 bus address is typically the first possible digit, in the 256 bit example this would be 0. Broadcast messages also get an assigned address, in the 256 bit example the broadcast message will use bus address 255. Each CM 64 is assigned a bus address by the processor of the CCM 62. In one example, the CMs 64 will each be assigned an address. All CMs “listen” for the bus address they have been assigned. In the 256 bit example, each CM is assigned a bus address from 1 to 254. The CM's 64 assigned number may change each time the CM 64 is added to the bus. The CM 64 ignores any messages addressed to anything other than its assigned address.
The Message Header provides the basic information about the following message needing for processing, including the size of the message, the message identifier, and the message type. The message size is expressed in a number of bytes. In a 16 bit header example, the number of data bytes is a 6-bit identifier of the up to 63 byte message. The identifier of the message is a number used to distinguish distinct messages, for example those sent to the same recipient device. In the 16 bit header example, a 3-bit MessagelD Value cycles from 0 to 7 as a unique ID for each message.
Finally, the message type is identified. In the 16 bit header example, this is a 6-bit identifier. The message type identifier may, for example, be a specific type of message like an initialization, a disconnection, or an error report. Some specific types of messages are: Authentication messages verify that a device is not a duplicate of an existing device. Specification queries are messages to obtain slave device capabilities including determining the type of device and whether the device supports modules other than charging modules. Power management messages control the amount of power drawn by the CM 64, for example setting the power setting for 7.5 W, 15 W or no power at all. Roll call messages obtain current measurements at each connected CM 64. These roll call messages can be used to detect “alien devices” drawing current without being linked into the system. Quality assurance messages can be used for testing purposes, for example to measure bit error rate.
Following the message header, a number of data bytes may be sent. For some messages, like error reports, the system may not need to send more information than the message type. However, other messages may require information is sent along. An optional number of data bytes, which were indicated in the header, include the data sent along the bus. In the example data bus, the messages range from 4 to 37 bytes in length.
Each message ends with an error checking feature such as a cyclic redundancy check (CRC). Error checks are a mathematical derivation of the bits of the message contents to verify the correct transmission of the bits. In the example message, the error check is an 8-bit or 10-bit depending on the number of bytes in the message. In the shown example data bus, the error checking is designed for a minimum Hamming distance of 4.
Referring to
At block 81, the CM 64 randomly selects one time slot in which to respond, for example 1 of the 128 available slots. When the time slot occurs, CM 64 sends its 72-bit device address to the CCM 62 within the time slot with the “Send/D” message. At block 82, the CCM 62 responds to the “Send/D” message with a “SetBusAddress” message with its identity information, for example with the 72-bit device address and an assigned 8-bit Bus Address (e.g. 1 to 254). At block 83, the CM 64 replies with an Acknowledge message. All future communications with the CM use the 8-bit Bus Address. Once the CM 64 has been registered with the CCM 62 using the process shown in
In order to interact with the CCM and monitor the power use of the connected device, software is loaded onto a local processor on the CM 64 itself. The CM software supports a bootloader to load new code through the data bus. As discussed above, initially, the CM software only responds to the “GetNewDevices” message sequence by randomly selecting a time slot to send the “Send/D” message. In the example system, the bus software supports communication at near full capacity (230,400 bits per second) and not miss any message. The CM software also performs alarming functions to alert the system in the event of physical or technical errors, including confirming that the messages are periodically received from the CCM.
After this registration is complete, the CM software monitors the data bus and identifies messages to which it is addressed. As discussed above, the CM 64 is assigned an address by the CCM 62. The CM software receives all messages, performs the CRC check/correction, and then determines if the address matches its Bus Address or if it is an applicable broadcast message. In the event that the message is not for the CM 64, the data is discarded. If the message is correctly addressed, the CM software processes the message and responds accordingly within the allocated time window which is approximately 1.5 ms in the example system. Message responses may include responding to messages to which it is addressed with an acknowledgement or providing information. Other message responses may include performing the requested action based on the message type received from the CCM 62.
The CM software monitors and verifies system attributes such as module temperature, CM output voltage, input voltage, and current. Current measurement is performed periodically. The timing of current measurement is set by a “StartCurrentMeasure” broadcast message periodically sent by the CCM 62. When that broadcast message is received, the CM 64 measures input current. The measurement data is reported to the CCM 62 when requested by the “GetCurrent” message sent specifically to each CM 64. In response to “SetMaxPower” messages, the CM software can enable the five volt DC output as instructed by the CCM Output setting, which in the shown example is 15 W, 7.5 W, or 0 W. The CM software also participates in bit error rate (BER) measurements as instructed by the CCM 62.
Turning to the CCM 62, a data port provides a means to load new code into the system and in particular the CCM software. In the example CCM 62 shown above the data port is a USB port on the side of the device. New code is loaded into the system as in this example, using a file contained on a flash drive which is automatically installed by the CCM software when the drive is connected. The CCM validates new code load and transfers new code into its memory. The new code is not initialized and run on the system until the CCM is reset, to prevent the system going offline while in use. Upon a reboot, the CCM runs the new code. The previous code is stored in the CCM in case the user needs to restore the device using a mechanism to revert back to a previous version.
The CCM software receives all messages sent by the CMs 64. The CCM software receives and processes all messages, performs the CRC check/correction, and then determines if the address matches its Bus Address (0 in the example). In some examples, the CCM 62 does not handle all communications and some CMs 64 communicate with each other. Like the CM software, the CCM software supports a bus at full capacity (230,400 bits per second in the example) and not miss any messages. The CCM software also performs the alarming function in coordination with the CMs 64.
The CCM software provides an isolation detection procedure to prevent users from tapping power from conductors without communicating with the bus and an alien detection procedure to prevent counterfeit connectors from being used to recharge a device coupled thereto. As discussed above, the CCM software also periodically send out “GetNewDevices” message sequences to effect the registration method set forth above as well as “StartCurrentMeasure” to instruct the measurement of input current. When the CMs have all reported a current measurement, the CM software adds up all current measurements and compares sum to the current measurement made by the CCM to determine if any alien device is drawing current from either of the two System Power Supplies. In some example low voltage distribution systems, the alien or other unresponsive devices are sent 0 W messages to prevent them from drawing power. In other example LVPD systems, the CCM software can shut down current flow to the entire bus or a section thereof where the alien device is detected.
The CCM software also provides managements of the device and power consumption of the system as a whole. The CCM software includes a non-sequential transmit message queue which is used to send messages in order of priority. The queue maintains a list of messages to transmit, but the CCM software sets a priority to each message. The messages are sent in order of priority to maximize bus capacity.
Referring to
At block 91, a margin reserve of power is defined and maintained by the ILA. The margin reserve of power which is a difference between the total current permitted to be distributed among the CMs 64 and the maximum current load that the system can handle. The margin reserve serves to protect against a sudden increase in power demand that will cause the short circuit protection to shut-down the system if an overload occurs. The margin reserve is tuned to maximize the number of connected devices and minimize unexpected shutdowns in a specific location/use case. The power consumption limits by the CMs 64 may not respond instantaneously in some example LVPD systems. Because the LVPD system does not have immediate control of the user devices with respect to how much power they draw and when they draw it. A user device may change its power consumption at any given time and the system must be able to accommodate it without shutting down.
The CCM can shut down the power supply units if the current exceeds a safe level and is restarted automatically. The CCM provides fast short detection and a shutdown procedure to minimize sparking as a result of a detected short. At block 91A, the current power is measured. If the current power draw level exceeds the preset safe limits, the device is reset at block 91B. However, this system may interrupt users' experience by disabling power flow until the device is reset.
To prevent users from losing power while using the rail of the LVPD system, the ILA can also maintain a safe maximum current by distributing the power evenly amongst the devices. To do so, the ILA manages an available maximum power during the addition of each new device, such as a CM 64 connected to a device. By default, a CM 64 is set to draw 0 W until it communicates with the CCM 62, but in other examples another default amount of power could be drawn such as 15 W.
At block 92, when the new module is connected which initiates the load management system in the example implementation of the ILA. The system retrieves a base power setting for each new device at block 93. As discussed above, this can be through communication with the connected devices or determined by the type of CM 64 purchased by the user. At block 94A, the available power, which is the difference between the current power utilized by the CMs 64 and the maximum safe power level, is compared to the power requested by the new device. In other examples, the available power may be computed as the difference between the maximum safe power level and the sum of the power allowed all the connected devices. If the available power is sufficient, the new module is assigned the full amount of power requested, the base power setting, at block 95.
If the available power is not sufficient, the system can adjust to allow the new device to draw some power by limiting the power of the other connected devices. At block 94B, the system detects the amount of power drawn by the connected modules in total and individually. At block 94C, the system sends commands to each of the modules to lower their total available wattage such that the available power is increased to allow the new module at least some of its requested power. At block 94D, the new module is assigned an allowed power maximum that is at least part of its originally requested base power setting. While redistributing the maximum power settings, the ILA algorithm may set CM available power a discreet amount such as 15 W, 7.5 W or 0 W, or a specific number. In some examples, the ILA can dynamically scale the power limitations of each module.
If the rebalance cannot be completed or, in some other examples of the device, the system does not rebalance, the modules power draws and the additional newly added devices are prevented from drawing power. By sending 0 W commands to the modules and preventing the modules from drawing power, the low voltage power system does not exceed the safe total current. In either case, the example LVPD system can continue to provide uninterrupted power to the previously connected devices.
At block 97A, the ILA performs an error check. If a CM 64 is detected as sending errors the CCM may send a 0 W command to prevent it from drawing further power at block 97B. This method ensures that maximum capability of the bus power supplies are not exceeded and power is shared by the various devices connected to the CMs. In some examples, the CMs can detect the type of device it is connected to and provide the right amount of current needed for maximum efficiency. In other examples, the CMs are bought specifically for certain types of devices to target the right amount of current.
At block 98, the ILA performs a current check to determine if the power assigned is still within the set parameters before the system returns to block 91. The ILA and CCM software provides historical performance information about the system logging this current information as well as other data. The CCM software records statistics on CM usage such as tracking the number of connected devices, the number of blocked devices (0 W setting), or other operating statistics. Statistics are saved to determine performance of the ILA algorithm as well as provide users data about their installations. This data can be removed through the data port either continuously to allow a connected PC to monitor CCM activity or downloaded onto a USB drive. Continuous monitoring also allows the user to conduct BER measurements.
As described herein, the Low Voltage Power Distribution System is designed to accept standard universal AC input power and convert it to a “touch safe” +24V DC Voltage in order to satisfy industry such as UL and NEC Class-2 requirements. The system also provides for distributing the +24V DC on an exposed rail system which allows easy access to power for a user's device charging and concurrent operation thereof. The system natively provides control and configuration functionality to enable the maximum number of users per system and allows the rail to handle fault management of the connected devices.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
This application is a non-provisional applications claiming priority to Provisional Application No. 62/488,241 entitled “Low Voltage Bus System” filed Apr. 21, 2017, and assigned to the assignee hereof and hereby expressly incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
62488241 | Apr 2017 | US |