Internet of things battery device

A method and apparatus for monitoring an internet-of-things (IoT) battery device (IBD). An example IBD includes a radio transceiver to communicate with an IoT charging device (ICD), a battery, and a battery monitor to determine a state of charge (SoCh) for the battery. An alerter is included to send an alert message to the ICD, via the radio transceiver, to indicate that the SoCh is less than an alert threshold.

TECHNICAL FIELD

The present techniques relate generally to Internet of Things (IoT) devices. More specifically the present techniques relate to devices that can monitor and charge IoT batteries.

BACKGROUND

It has been estimated that the Internet of Things (IoT) may bring Internet connectivity to 50 billion devices by 2020. For organizations, IoT devices may provide opportunities for monitoring and tracking other devices and items, including IoT devices and other devices. As the number of these devices increases, the use of techniques to track and monitor the devices will become more important. Further, it is envisaged that a significant portion of the number of the IoT devices will be battery powered devices.

DESCRIPTION OF THE EMBODIMENTS

The internet of things (IoT) is a concept in which a large number of computing devices are interconnected to each other and to the Internet to provide functionality and data acquisition at very low levels. For example, IoT networks may include commercial and home automation devices, such as water distribution systems, electric power distribution systems, pipeline control systems, plant control systems, light switches, thermostats, locks, cameras, alarms, motion sensors, and the like. These devices, termed IoT devices herein, may be accessible through remote computers, servers, and other systems, for example, to control systems or access data. Further IoT devices may include IoT gateways, used to couple other IoT devices to cloud applications.

As described herein, an IoT battery device may be used to track a location of an object, and to activate an alert when the battery power has reached a level indicating that the battery should be recharged. This invention enhances the role of batteries from just power delivery components to an active connected subsystem of the IoT system capable of remotely monitoring its state of charge (SoCh), state of health (SoH) and state of function (SoF).

The SoCh is a value that represents the remaining capacity of the battery, measured by monitoring a voltage output from the battery, taken as a percentage between a maximum voltage output and a functional minimum voltage output. This may be considered as the point at which the battery may fail to power a device, along the discharge curve.

The SoH is a value that represents the capacity of the battery, e.g., the amount of energy a battery is capable of delivering. Over multiple charge-discharge cycle the capacity degrades. The SoH may be estimated by monitoring the charge/discharge cycles of the battery.

The SoF is a value that incorporates the SoCh and SoH of the battery to provide a single operational number. The SoF predicts the ability of the battery to provide sufficient power to maintain operation.

Further, the techniques described herein provide for the localization and ranging of the devices. This may be utilized even when the devices are not themselves battery powered.

The techniques include two types of devices, the first of which is a battery form-factor device that may integrate a low-power microcontroller unit (MCU), and a radio transceiver, for example, compatible with the low power-wide area (LPWA) standard promulgated by the GSMA as part of the “Mobile IoT Initiative.” The LPWA allows low bit rate machine to machine (M2M) communications over long distances, as discussed herein. The battery device, termed an IoT battery device or IBD herein, may also include an inductive power transfer receiver. The second device is a wireless charging station, termed an IoT charging device or ICD herein, is capable of communicating with the IBDs and determining their location. Further, the ICD may be used to recharge the batteries in the IBDs, either wirelessly, or by a wired connection.

The devices enable the power supplies for existing battery powered devices to be monitored remotely, and may allow these devices to become wirelessly rechargeable devices. When an IBD reports a battery needs recharging, the ICDs can locate the device and report the issue and location to a user. When reporting the issue and location, the network of ICDs may also inform the user of the location of a recharged IBD, for example, in case a closest ICD does not currently have one. The user may then carry a charged IBD to the field to replace the depleted IBD, and return the depleted device to the nearest ICD for recharging. In some examples, the user may drive a vehicle powered by an IBD to the ICD for charging or move the ICD to the IBD for charging.

The system addresses the problem of remote monitoring of battery levels and status in battery-powered IoT devices. This may be especially useful for IoT devices in remote or inaccessible locations, such as embedded sensors in equipment, underground sensors, sensors mounted in walls and ceilings, remote environmental monitoring devices, and energy storage units, such as electric vehicles. Further, monitoring the location of unpowered devices may also be important. Such devices may include assets managed by cities, hospitals, companies, or individuals such as gas canisters, rubbish containers and the like.

FIG. 1Ais a drawing of a cloud computing network, or cloud100, in communication with a number of Internet of Things (IoT) devices, at least some of which are IBDs communicating with ICDs. The cloud100may represent the Internet, or may be a wide area network, such as a proprietary network for a company. The IoT devices102may include any number of different types of devices, grouped in various combinations. For example, an IBD group106may include IoT devices102that may be tracking and powering other devices. These IoT devices102may include remote weather stations, integrated sensors, temperature sensors, security sensors, traffic flow monitors, cameras, and any number of other devices. The IoT devices102may be communicating through the cloud100with a server104that provides information to a user, for example, to inform them that an IBD needs servicing, the location of the unit holding the IBD, and the location of a nearest recharged IBD.

The IoT battery devices in the IBD group106may be in communication with the cloud100through a sub-network108, such as a local radio frequency network provided by a group of ICDs110. The ICDs110may determine the battery status and, working as a group, the locations of each of the IoT devices102in the IBD group106. This may occur when an IBD reports a low charge or a battery fault, or may occur when a user queries the location of an IBD.

Other IoT devices102may include remote weather stations111, local information terminals112, alarm system sensors114, and alarm panels116, among many others. Each of these IoT devices102may be in communication with other IoT devices102, with servers104, or both. Further, many of these IoT devices102may be included in an IBD group106to track location, battery status, or both.

FIG. 1Bis a drawing of a cloud computing network, or cloud100, in communication with a mesh network of IoT devices102, which may be termed a fog120, operating at the edge of the cloud100. To simplify the diagram, not every IoT devices102is labeled.

The fog120may be considered to be a massively interconnected network wherein a number of IoT devices102are in communications with each other, for example, by radio links122. This may be performed using the open interconnect consortium (OIO) standard specification 1.0 released by the Open Connectivity Foundation™ (OCF) on Dec. 23, 2015. This standard allows devices to discover each other and establish communications for interconnects. Other interconnection protocols may also be used, including, for example, the optimized link state routing (OLSR) Protocol, or the better approach to mobile ad-hoc networking (B.A.T.M.A.N.), among others.

Three types of IoT devices102are shown in this example, gateway/ICDs124, ICDs126, and IBDs128, although any combinations of IoT devices102and functionality may be used. The gateway/ICDs124may be edge devices that provide communications between the cloud100and the fog120, and may also function as charging and locating devices for the IBDs128. The ICDs126may provide charging for IBDs128and may also locate the IBDs128. The locations, charging alerts, battery alerts, and other data, or both may be passed along to the cloud100through the gateway/ICDs124. As described herein, the IBDs128may provide power, location services, or both to other devices or items.

Communications from any IoT device102may be passed along the most convenient path between any of the IoT devices102to reach the gateways124. In these networks, the number of interconnections provide substantial redundancy, allowing communications to be maintained, even with the loss of a number of IoT devices102.

The fog120of these IoT devices102devices may be presented to devices in the cloud100, such as a server104, as a single device located at the edge of the cloud100, e.g., a fog120device. In this example, the alerts coming from the fog120device may be sent without being identified as coming from a specific IoT device102within the fog120. For example, an alert may indicate that an IBD128needs to be returned for charging and the location of the IBD128, without identifying any specific ICD126that sent the alert.

In some examples, the IoT devices102may be configured using an imperative programming style, e.g., with each IoT device102having a specific function. However, the IoT devices102forming the fog120device may be configured in a declarative programming style, allowing the IoT devices102to reconfigure their operations and determine needed resources in response to conditions, queries, and device failures. For example, a query from a user located at a server104about the location of an IBD128may result in the fog120device selecting the IoT devices102, such as particular gateways124, ICDs126or IBDs128, needed to answer the query.

If the IBDs128are providing power to a device, sensors associated with the IBD128, such as power demand, temperature, and the like, may be used in concert with sensors on the device, or other devices, to answer a query. In this example, IoT devices102in the fog120may select the sensors on particular IBDs128based on the query, such as adding data from power sensors or temperature sensors. Further, if some of the IoT devices102are not operational, for example, if an ICD126has failed, other IoT devices102in the fog120device may provide substitute, allowing locations to be determined.

Further, the fog120may divide itself into smaller units based on the relative physical locations of the IBDs128and ICDs126, as discussed with respect toFIG. 2. In this example, the communications for an IBD128that has been instantiated in one portion of the fog120may be passed along to IoT devices102along the path of movement of the IBD128. Further, if the IBD128is moved from one location to another location that is in a different region of the fog120, different ICDs126may be identified as charging stations for the IBD128.

As an example, if an IBD128is used to power a portable device in a chemical plant, such as a personal hydrocarbon detector, the device will be moved from an initial location, such as a stockroom or control room, to locations in the chemical plant, which may be a few hundred feet to several thousands of feet from the initial location. If the entire facility is included in a single fog120charging structure, as the device moves, data may be exchanged between ICDs126that includes the alert and location functions for the IBD128, e.g., the instantiation information for the IBD128. Thus, if a battery alert for the IBD128indicates that it needs to be charged, the fog120may indicate a closest ICD126that has a fully charged IBD128ready for exchange with the IBD128in the portable device.

FIG. 2is a schematic diagram200of an IBD202in communications with a number of ICDs204. As described further with respect toFIGS. 4 and 5, the IBD202may include an LPWA, or other, low power transceiver, a small MCU, a rechargeable battery integrated into an enclosure having a battery form factor. The IBD202may also include a wireless power receiver circuit for wireless charging. Although only one IBD202is shown in the schematic diagram200, multiple IBDs may be used with the ICDs204.

As described further with respect toFIGS. 6 and 7, the ICDs204may include a compatible transceiver to communicate with the IBD202, a processor, and a network gateway to communicate with other ICDs204and a server. The ICDs204may also include an integrated wireless power transmitter circuit to charge an IBD202. The ICD204may act as a gateway for the messages transmitted from the IBD202, and may also be used as a wireless charging station for the IBD202. In some example, the ICDs204have multiple charging circuits to enable them to charge and maintain multiple IBDs202for immediate access.

During normal operation, the IBD202may periodically transmit a current state of charge (SoCh) to the ICDs204. This facilitates remote monitoring of the SoCh and enables device localization. When the SoCh of the batteries reach a minimum threshold, or if other problems are detected with the battery, an alert may be sent to a user, and the battery may be recharged by an ICD204, for example, by placing them in close proximity to the ICD204for wireless recharging.

Using low power wide area (LPWA) radio transceivers, the communications between the IBD202and the ICDs204may extend to as much as to 2 kilometers indoors or as much as 25 kilometers outdoors. By comparison, Bluetooth low energy (BTLE) may be limited to 80 meters. Thus, this may provide an improvement of 2400% in range over BTLE based solutions. Further, the transceiver may be selected to operate in multiple frequency bands, e.g., 868 MHz in ITU Region 1, 915 MHz in ITU Region 2 and/or 2.4 GHz ISM bands globally, to decrease interference from other transceivers.

While the configuration shown inFIG. 2may allow for a fixed area of coverage, with all of the ICDs204communicating with all of the IBDs202, the examples described are not limited to this fixed configuration. The use of composable devices, e.g., individual IoT devices102that can self-select participation to form virtual devices, may allow the charging system to be larger, more transparent, and more redundant than fixed configurations.

For example, returning toFIG. 1B, the fog120may allow the IoT devices102described herein to reconfigure or compose themselves into different groups or virtual devices to monitor locations of target IBDs128across a massive network of interconnected devices. Thus, any four of the IoT devices102that includes at least one target IBD128may reconfigure themselves to form a virtual device, termed a IBD128location and battery monitoring device (LBMD) herein, to communicate with the target IBD128. Depending on the configuration, the LBMD may also monitor the status and location of the target IBD128.

In the LBMD, the target IBD128is in communication with any three other IoT devices102, including gateways124, ICDs126, and other IBDs128, among other devices. The timestamp on the communications received from the target IBD128at each of the three IoT devices102may be used to locate the target IBD128. If one of the IoT devices102in the LBMD is capable of performing the time difference of arrival calculation, e.g., a gateway124or an ICD126, then the calculation is completed in that LBMD.

If no device in communication with the target IBD128is capable of performing the location calculations, such as if all of the IoT devices102in communication with the target IBD128are also IBDs128, the IoT devices102may compose themselves to form an LBMD that includes five devices, three in communication with the target IBD128, and another device capable of performing the calculations, such as a gateway124or an ICD126. In this LBMD, the IoT devices102in communication with the target IBD128timestamp the communications and pass them on to the calculating device for the location determination. If the calculating device is a gateway124, the results of the location communication may be sent to a server104, for example, in response to a location query from the server104or an alert message from the IBD128. If not, the LBMD may be composed of six elements, for example, including one of the gateways124.

The IoT devices102are not limited to participating in an LBMD for a single target IBD128, but may overlap in any number of LBMD to implement the functions described herein. For example, an IBD128may be in communications with two other IBDs128and a gateway124. In this grouping of devices, three LBMDs may be formed, wherein each one of the three IBDs128is a target IBD128for each of the LBMDs. As a target IBD128moves through an environment, the IoT devices102may compose new LBMDs to monitor the target IBD128.

Further, the LBMD for a target IBD128may be composed from any number of IoT devices102in the fog120, depending on the needs. For example, an LBMD that is only communicating with a target IBD128may be formed using only other IBDs128. If the target IBD128sends out an alert, a new LBMD may be composed that includes an ICD126or a gateway124to perform the location calculations from the timestamp of the alert messages. Further, the new LBMD may include an ICD126that has a charged IBD128for exchange with the current IBD128.

The composability of the IoT devices102to form the LBMDs as needed may provide redundancy in communications as well as transparency to users. In this type of composable system, a user does not have to know any details of the communications infrastructure for the fog120. When an IBD128needs replacing, the user receives an alert and is directed to the nearest ICD126for charging and replacement. The ICD126may have other features to assist in the location, such as flashing alert or an audible tone to assist the user in finding the ICDs126.

As described herein, the gateways124may function as ICDs also, but the examples are not limited to this. In some examples, the gateways124may be merely routers that transfer network communications in the fog120to network communications in the cloud100.

FIG. 3is a schematic diagram300of locating a position of an IBD202from time of arrival of transmissions from the IBD202at each of a number of ICDs204. Like numbered items are as described with respect toFIG. 2. The modulation scheme used by the LPWA technology may be used to identify a specific data frame, and thus, may be used to precisely determine the Time-of-Arrival (ToA) of the radio signal at each of the ICDs204. When the IBD202communicates with at least three ICDs204, the ICDs204may calculate a location for the IBD202. To implement this, the ICDs204perform a fine resolution time-stamping, e.g., to a sub-microsecond arrival time, of the received frame. All of the timestamps302may be collected by one of the ICDs204to perform the calculation, or the calculation may be run on each of the ICDs204. A timestamp filter304can be run to identify the timestamps for a specific data communication from the IBDs202. From this, a time difference of arrival algorithm306may be run to determine the arrival times or distance of the IBD202from each of the ICDs204. Once this is performed, a localization algorithm308can determine the location, for example, by determining the point at which all three distances intersect.

FIG. 4is a block diagram400of components that may be present in an example of an IBD202. Like numbered items are as described with respect toFIG. 2. The IBD202may include an MCU402, which may be a microcontroller unit, an ultra-low voltage processor, or other known low-power processing element. The MCU402may be a part of a system on a chip (SoC) in which the MCU402and other components are formed into a single integrated circuit, or a single package, such as the Edison or Galileo products available from Intel® Corporation of Santa Clara, Calif.

As an example, the MCU402may include an Intel® Architecture Core™ based processor, such as a Quark™ D2000, MCS-96, MCU-1 or another such microcontroller unit available from Intel® Corporation, Santa Clara, Calif. However, other low power processors may be used, such as from the PIC™ family of microcontrollers available from Microchip Technology of Chandler, Ariz., the MSP series of microcontrollers available from Texas Instruments, Inc. of Dallas, Tex., among many others.

The MCU402may communicate with a system memory404over a system bus406. Any number of memory devices may be used to provide for a given amount of system memory. As the functions of the IBD202are generally directed to monitoring and communicating the status of the battery, simple memory devices such as 8 Kb, 16 Kb, or 32 Kb random access memory chips may be used. In some examples, the registers of the MCU402, or memory that is directly incorporated into the MCU402, may be used as the system memory404.

To provide for persistent storage of information such as data, applications, operating systems and so forth, a mass storage408may also couple to the MCU402via the system bus406. To enable a thinner and lighter system design the mass storage may be implemented as part of the MCU402, or an SoC, or as a separate programmable flash memory chip of 128 Kb, 256 Kb, or larger, depending on the software size.

The system bus406may include any number of technologies, including for example, a proprietary bus included in an SoC. Other bus systems may be used instead of, or in addition to an SoC bus, such as an I2C interface, an SPI interface, point to point interfaces, peripheral component interconnect express (PCIe), or any number of other technologies.

The system bus406may couple the MCU402to a radio transceiver410that is used to provide communications414with the ICDs204. A power receiver/charger412may be coupled with the MCU402, via the bus406, to let the MCU402know that a power signal416has been received from an ICD204. The power signal416may be a wireless signal that is received by a loop antennae in the IBD202, or may be a physical connection to a charger in the ICD204, for example, through contacts in a slot on the ICD204designed to hold the IBD202. A battery charging circuit, such as an LTC4020 chip from Linear Technologies of Milpitas, Calif., among others, may be included in the power receiver/charger. The specific charging circuits chosen depend on the size of the battery418, and thus, the current required.

A battery monitor420may be included in the IBD202to track the state of charge (SoCh) of the battery418, as well as the state of health (SoH) and the state of function (SoF). The battery monitor420may include a battery monitoring integrated circuit, such as an LTC4020 or an LTC2990 from Linear Technologies, an ADT7488A from ON Semiconductor of Phoenix Ariz., or an IC from the UCD90xxx family from Texas Instruments of Dallas, Tex. The battery monitor420may communicate the information on the battery418to the MCU402over the bus406. The battery monitor420may also include an analog-to-digital (ADC) convertor that allows the MCU402to directly monitor the voltage of the battery418, or, with appropriate circuitry, the current flow from the battery418. The battery monitor420may include a temperature monitor circuit to determine the temperature in the proximity of the battery418.

The battery418may include any number of different types and sizes, depending on the application. For example, the battery418may include lead acid cells, lithium ion cells, nickel metal hydride cells, and the like. Further, the battery418may be a hybrid type, including both chemical storage cells and a supercapacitor. As described herein, the battery418may provide power422to an external powered device424, as discussed herein. In some examples, the battery418may only be used by the IBD202, for example, if the IBD202is used as a location monitor on an unpowered device, such as a gas cylinder, garbage receptacle, and the like. For larger power demands, such as when the battery418is providing power422to the powered device424, a multi-cell battery, such as a lead acid battery, a nickel-metal hydride battery, a large scale lithium ion battery, or a hybrid battery, among others, may be used. For examples in which only the IBD202is being powered by the battery418, a small lithium ion battery, a nickel-cadmium battery, or a supercapacitor, among others, may be used.

The powered device424may include sensors, such as traffic sensors, radar speed detectors, cameras, flow sensors, temperature sensors, motion sensors, wind speed sensors, pressure sensors, barometric pressure sensors, and the like. Further, the powered device424may include actuators, such as traffic lights, strobe lights, valve actuators, lock solenoids, audible sound generators, visual warning devices, and the like. The selection of the battery418may be determined by the power demand of the sensors and actuators used for the powered device424.

The mass storage408may include a number of modules to direct the MCU402to perform the functions described herein. These may include, for example, a battery manager426that tracks the voltage, temperature, current, charge rate, discharge rate, and other parameters for the battery418, from the battery monitor420and the power receiver/charger412. A metric analyzer428compares the parameters for the battery418to preset thresholds to determine if the battery418is operating within normal limits, or if, for example, an alert needs to be sent by an alerter430. The metric analyzer428may use filter functions, as described with respect toFIGS. 8A and 8B, to smooth transient variations in the parameters, reducing the risk of false alarms.

A communicator432implements the communications protocol and handles the communications through the radio transceiver, for example, using the LPWA protocol. The communicator432may send out the alerts from the alerter430, and may also send out regular communications to inform the ICDs204of the current location of the IBD202.

Once the IBD202has been placed in proximity to the ICD204for charging, a charging controller434may be used to instruct the power receiver/charger412to charge the battery418. The charging controller434may also control other operations of the IBD202during charging, for example, disabling the radio transceiver410or decreasing the reporting increments, to allow for faster charging. Once the IBD202has been taken out of range of the ICD204, stopping the flow of power to the power receiver/charger412, the charging controller434may then enable the radio transceiver410, and initiate communications with the ICDs204.

FIG. 5is block diagram of an example500of an IBD202. Like numbered items are as described with respect toFIGS. 2 and 4. In this example502, a low power MCU502, such as an Intel® Quark X3 is coupled to an LPWA radio transceiver504through a serial protocol interface (SPI)506. The SPI506may directly couple to the MCU502, for example, through a built in SPI module in the MCU502. A radio antenna508is coupled to the LPWA radio transceiver504.

A battery monitoring IC510may couple to the MCU502through an I2C interface512. As for the SPI506, an I2C module may be integrated into the MCU502. In this example, the battery monitoring IC510is a low power IC capable of reading the battery temperature, current and voltage on a battery514, for example, over lines516.

An inductive wireless charging receiver518may receive current transmitted from an ICD via a loop antenna520. The loop antenna520may be wrapped around the enclosure to allow placement in any number of positions proximate to the ICD, while still receiving current. The power522from the inductive wireless charging receiver518is provided to a battery wireless charging IC524, which may alert the MCU502that current is detected over the I2C interface512. The battery wireless charging IC524may automatically start the charging, or may wait until instructed to do so by the MCU502over the I2C interface512.

FIG. 6is a block diagram of an example600of components that may be present in an ICD204. Like numbered items are as described with respect toFIGS. 1, 2, and 4. The ICD204may include any combinations of the components shown in the example600. The components may be implemented as ICs, portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof adapted in the ICD204, or as components otherwise incorporated within a chassis of a larger system. The block diagram ofFIG. 6is intended to show a high level view of components of the ICD204. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

The ICD204may include a processor602, which may be a microprocessor, a multi-core processor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. The processor602may be a part of a system on a chip (SoC) in which the processor602and other components are formed into a single integrated circuit, or a single package, such as the Edison™ or Galileo™ SoC boards from Intel. As an example, the processor602may include an Intel® Architecture Core™ based processor, such as a Quark™, an Atom™, an i3, an i5, an i7, or an MCU-class processors, or another such processor available from Intel® Corporation, Santa Clara, Calif. However, other processors may be used, such as available from Advanced Micro Devices, Inc. (AMD) of Sunnyvale, Calif., a MIPS-based design from MIPS Technologies, Inc. of Sunnyvale, Calif., an ARM-based design licensed from ARM Holdings, Ltd. or customer thereof, or their licensees or adopters. The processors may include units such as an A5/A6 processor from Apple® Inc., a Snapdragon™ processor from Qualcomm® Technologies, Inc., or an OMAP™ processor from Texas Instruments, Inc.

The processor602may communicate with a system memory604over a bus606. Any number of memory devices may be used to provide for a given amount of system memory. As examples, the memory can be random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) low power double data rate (LPDDR)-based design such as the current LPDDR2 standard according to JEDEC JESD 209-2E (published April 2009), or a next generation LPDDR standard to be referred to as LPDDR3 or LPDDR4 that will offer extensions to LPDDR2 to increase bandwidth. In various implementations the individual memory devices may be of any number of different package types such as single die package (SDP), dual die package (DDP) or quad die package (Q17P). These devices, in some embodiments, may be directly soldered onto a motherboard to provide a lower profile solution, while in other embodiments the devices are configured as one or more memory modules that in turn couple to the motherboard by a given connector. Any number of other memory implementations may be used, such as other types of memory modules, e.g., dual inline memory modules (DIMMs) of different varieties including but not limited to microDIMMs or MiniDIMMs. For example, a memory may be sized between 2 GB and 16 GB, and may be configured as a DDR3LM package or an LPDDR2 or LPDDR3 memory, which is soldered onto a motherboard via a ball grid array (BGA).

To provide for persistent storage of information such as data, applications, operating systems and so forth, a mass storage608may also couple to the processor602via the bus606. To enable a thinner and lighter system design the mass storage608may be implemented via a solid state disk drive (SSDD). However, the mass storage608may be implemented using a micro hard disk drive (HDD) in some ICDs204. Further, any number of new technologies may be used for the mass storage608in addition to, or instead of, the technologies described, such resistance change memories, phase change memories, holographic memories, or chemical memories, among others. For example, the ICD204may incorporate the 3D XPOINT memories from Intel® and Micron®.

The components may communicate over the bus606. The bus606may include any number of technologies, including industry standard architecture (ISA), extended ISA (EISA), peripheral component interconnect (PCI), peripheral component interconnect extended (PCIx), PCI express (PCIe), or any number of other technologies. The bus606may be a proprietary bus, for example, used in a SoC based system. Other bus systems may be included, such as an I2C interface, an SPI interface, and point to point interfaces, among others.

The bus606may couple the processor602to a radio transceiver610, for example, using an LPWA protocol for communications. In some examples, the radio transceiver610may be the same as the radio transceiver410used in an IBD202. However, the radio transceiver610in the ICD204does not have to be the same, merely compatible. As the ICD204is likely to include a power supply612that is connected to grid power614, an environmental power supply, or both, the radio transceiver610may be higher power unit than that used in the IBDs202to facilitate communications.

The ICD204may include a charger/power transmitter616to provide power signal416to an IBD202, for example, by inductive coupling or through physical contacts. The charger/power transmitter616may alert the processor602when an IBD202is within charging range. In some examples, the processor602may instruct the charger/power transmitter616to start the charging, while in other examples, the charging may be automatically started. The charger/power transmitter616may also implement communications with the IBD202, for example, through backscatter or through high frequency signals imposed on a lower frequency power signal, among others. The charging may be performed using the Airfuel standard promulgated by the Airfuel Alliance, the Qi wireless charging standard promulgated by the Wireless Power Consortium, the Rezence charging standard, promulgated by the Alliance for Wireless Power, among others.

A digital signal processor (DSP)618may be included to perform the location calculations. A graphics processing unit (GPU) or other high speed processing unit, may be used instead of, or in addition to, to DSP618.

While not shown, various input/output (I/O) devices may be present within, or connected to, the ICD204. For example, a display may be included to show information, such as IBD202locations and charge status. An input device, such as a touch screen or keypad may be included to accept input, for example, to enter a query to find a location of an IBD202.

The ICD204can communicate with a cloud100through a network interface620, for example, to exchange data with other ICDs204. The network interface620may be a network interface card for an Ethernet connection, may include a wireless modules, or both. Any number of radios, configured for a particular wireless communication protocol, may be used as the network connections. For example, a WLAN unit may be used to implement WiFi™ communications in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. In addition, wireless wide area communications, e.g., according to a cellular or other wireless wide area protocol, can occur via a WWAN unit. The ICD204is not limited to these types of radio transceivers, but may include any number of other radio communications equipment, such as transceivers compatible with the Bluetooth® standard as defined by the Bluetooth® special interest group, for example, the ICD204may communicate over a wireless personal area network (WPAN) according to the IEEE 802.15.4 standard, among others.

The mass storage608may include a number of modules to implement the data transfer functions described herein. These modules may include an IBD communicator622that controls communications with the IBD202, for example, through the radio transceiver610. The IBD communicator622may time stamp the packets or frames as they arrive. An intracharger communicator624may be used to send timestamped packets to other ICDs204as well as other control information. A difference-of-arrival solver626may be used to determine the location, distance, or both of an IBD202from each of the ICDs204. A localizer628may then determine the location of the IBD202from the arrival time of the same frame at each of the ICDs204. A reporter630may be used to send alerts to a user, for example, through a server. The alerts may include the issue, e.g., an SoCh, SoH, or SoF alert, and a location for an IBD202.

FIG. 7is block diagram of an example700of an ICD204. Like numbered items are as described with respect toFIGS. 2 and 6. The ICD204in this example700has a processor702from Intel®, such as an Atom®. The processor702may be coupled to a serial protocol interface (SPI)704over the bus606. The SPI704may interface to the LPWA radio transceiver706, which is coupled to an antenna708.

An I2C interface710may be coupled to the processor702via the bus606. The I2C interface710may couple to a battery wireless charging IC712, which, in turn, couples to a coil716for transfer of power to an IBD.

The IBDs may periodically transmit their SoCh and internal temperature to the ICD204. The ICD204has a WiFi interface718to obtain date from other ICDs, e.g., for calculating a location of an IBD, and to alert the user when a battery requires a charge and its current location. The temperature indication can also be used by the end-user to assess the battery condition. A display may be included on the ICD204to show the same information locally.

FIG. 8Ais a plot800A of battery state percentage versus measurement number. The x-axis802represents a measurement number over time, while the y-axis804represents the battery charge state in %, for example, as determined from the voltage level on the battery. Battery-powered IoT devices that use radio transceivers may have bursts of current usage associated with the radio transmitter when it is dispatching data, which may result in transient reductions in voltage. As seen inFIG. 8A, the voltage fluctuates while, for example, when the radio transmitter is in use. This may lead to false low-battery detections. To reduce the effect of transient voltage dips, a low pass filter may be used to smooth out the fluctuations.

FIG. 8Bis a plot800B of the battery state percentage versus measurement number after a filtering function was applied. To generate the plot800B, a 4-pole infinite impulse response (IIR) low pass filter was applied to the output of the ADC measurement data shown as plot800A. InFIG. 8A, a line806is placed at 44.5% to highlight the differences. This line806is inFIG. 8Balong the x-axis802. While a number of the unfiltered values drop below the 44.5% value, none of the filtered values drop below that value.

FIG. 9is a process flow diagram of an example of a method900for alerting that an IBD needs service. The method900begins at block902, when the IBD initiates communications with the ICDs. This may take place when the IBD is inserted into a powered device, or when the IBD is removed from proximity of the ICD. The IBD requests an acknowledgment from the ICDs to confirm the connection. At block904, a determination is made as to whether the connection was successful. If not, process flow returns to block902to try the connection again. Not all of the ICDs in a charging network need to confirm the connection. The ICDs may determine that the nearest ICD responds or the first ICD to respond may stop other ICDs in the network from responding, among other configurations.

If, at block904, the connection is confirmed, the IBD joins the ICDs wireless network. The IBD then enters normal operation.

During normal operation, the internal circuits of the IBD check the state of charge (SoCh) on the battery at block906. At block908, the state of health (SoH) of the battery is determined. At block910, the state of function (SoF) of the battery is determined. As described herein, the measurements for the SoCh, SoH, and SoF may be determined using a dedicated IC on the board or may be determined by an MCU using an ADC to measure the battery parameters. At block912, an analysis of the metrics is performed.

At block914, a determination is made as to whether any of the metrics exceeds an alert threshold. If not, process flow returns to block906to continue monitoring the battery. This may be performed at predetermined intervals, such as a second, five seconds, fifteen seconds, one minute, five minutes, fifteen minutes, or longer depending on the rate at which the battery is depleted. During the monitoring process, the information that the battery management IC measures may be periodically verified by the MCU.

If at block914, it is determined that a metric has exceeded an alert threshold, at block916an alarm is sent to the ICDs. For example, if the battery voltage level or SoCh is less than the configurable threshold level, an alert is triggered by an alarm IRQ to the MCU. This MCU creates an alert message and then dispatches the alert message through the radio transceiver. An example of an alert message in JSON format is shown below. In this example, the message type denotes a battery alert, the payload includes a battery, or IBD, identifier, a timestamp in Unix epoch time format representing the time when the alert was generated, and a measured voltage level of the battery

The alert message may also include other information, such as values for the SoH and SoF parameters, the location of the IBD, and a location for a nearest charged IBD, among others. At block918, the IBD is removed to be wirelessly recharged or the device, if small enough, is brought to the wireless charging station to recharge the battery.

FIG. 10is a block diagram of a non-transitory machine readable medium1000for directing an MCU1002to alert when a battery needs to be recharged in an IBD. The MCU1002can access the machine readable medium1000over a bus1004, such as the proprietary bus in an SoC, among others. The MCU1002may be as described for the MCU ofFIGS. 4 and 5. The non-transitory machine readable medium1000may include code1006to direct the MCU1002to communicate with gateways, such as ICDs. The communications may be configured to occur at regular intervals, such as every half hour, every hour, every few hours, and the like. Code may be included to direct the MCU1002to determine the SoCh1008, the SoH1010, and the SoF1012of the battery. This may be performed by the MCU1002directly, for example, using measurements from an ADC, or may be performed by obtaining some or all of the measurements from a battery monitoring IC. Code1014may be included to direct the MCU1002to analyze the metrics to determine if any have exceeded predetermined thresholds for the battery. Code1016may be included to direct the MCU1002to create and send an alert to the ICDs. Further, code1018may be included to direct the MCU1002to monitor the charging process, for example, turning off the radio transceiver during the charging process, determining if charging is complete, and the like.

FIG. 11is a block diagram of a non-transitory machine readable medium1100for directing a processor1102to locate and monitor an IBD. The processor1102may access the machine readable medium1100over a bus1104. The processor1102and bus1104may be as described with respect toFIGS. 6 and 7.

The non-transitory machine readable medium1100may include code1106to communicate with an IBD, for example, to receive alerts from the IBD, or to send confirmations of communications to the IBD. Code1108may be included to direct the processor to communicate with other ICDs, for example, to send time stamped communications received from the IBD.

Code1110may be included to direct the processor1102to solve a time difference of arrival algorithm for timestamped frames received from the IBD by three or more ICDs. The code1110may direct a DSP or GPU in communication with the processor to implement the location algorithm. This may be used to locate the IBD at the intersection of the distance of the IBD from each of the ICDs.

Code1112may be included to direct the processor1102to receive an alert status from the IBD, and create an alert message. Further, code1114may be included to direct the processor to provide the alert to a user, for example, over a network connection to a cloud server.

Code1116may be included to direct the processor1102to manage charging of an IBD, for example, initiating the charging once an IBD has been detected in proximity of the charging loop. The code1116may also control the flow of current to the charging device, or monitor a specialty IC that controls the charging. The code1116may reduce the current once the IBD has been moved out of range, for example, leaving a small current to detect placement of IBDs in proximity to the ICD.

EXAMPLES

Example 1 provides an internet-of-things (IoT) battery device (IBD). The IBD includes a radio transceiver to communicate with an IoT charging device (ICD), a battery, and a battery monitor to determine a state of charge (SoCh) for the battery An alerter in included to send an alert message to the ICD, via the radio transceiver, to indicate that the SoCh is less than an alert threshold.

Example 2 includes the subject matter of example 1. In this example, the IBD includes a power receiver to wirelessly receive power from the ICD, and a charger to use the power to charge the battery.

Example 3 includes the subject matter of any of examples 1 to 2. In this example, the battery is to power a device external to the IBD.

Example 4 includes the subject matter of any of examples 1 to 3. In this example, the battery monitor includes an integrated circuit to monitor the SoCh.

Example 5 includes the subject matter of any of examples 1 to 4. In this example, the battery monitor includes an analog-to-digital (ADC) convertor to convert an output voltage of the battery to a digital value, and the IBD includes a battery manager to determine the SoCh from the digital value.

Example 6 includes the subject matter of any of examples 1 to 5. In this example, the IBD includes a case that is the same size and shape as a battery for a device.

Example 7 includes the subject matter of any of examples 1 to 6. In this example, the IBD includes a microcontroller unit (MCU).

Example 8 includes the subject matter of any of examples 1 to 7. In this example, the IBD includes a system on a chip (SoC).

Example 9 includes the subject matter of any of examples 1 to 8. In this example, the apparatus includes the ICD, which includes an ICD radio transceiver and a network interface. The ICD also includes an IBD communicator to communicate with an IBD through the ICD radio transceiver and an inter ICD communicator to exchange messages with other ICDs via the network interface. A localizer is included to determine a location of the IBD based, at least in part, on communications between the IBD and the ICD.

Example 10 includes the subject matter of any of examples 1 to 9. In this example, the ICD includes a DSP, wherein the DSP performs a time difference of arrival calculation on messages received from the IBD to determine a location for the IBD.

Example 11 includes the subject matter of any of examples 1 to 10. In this example, the messages exchanged with the other ICDs include frame identifiers and timestamp information for frames received at each of the other ICDs from the IBD, and the localizer determines the location of the IBD as an intersection of distances between the IBD and at least three ICDs.

Example 12 includes the subject matter of any of examples 1 to 11. In this example, the messages exchanged with the other ICDs include a distance from each ICD to the IBD.

Example 13 includes the subject matter of any of examples 1 to 12. In this example, the ICD includes a wireless power transmitter to charge an ICD.

Example 14 includes the subject matter of any of examples 1 to 13. In this example, the apparatus comprises a location and battery monitoring device (LBMD) that includes a plurality of internet of things (IoT) devices self-selected from a fog of IoT devices. The LMBD includes a target IoT battery device (IBD), and at least three other IoT devices in communication with the target IBD. Each of the three other IoT devices timestamps the communications received from the target IBD.

Example 15 includes the subject matter of any of examples 1 to 14. In this example, one of the plurality of IoT devices in the LBMD comprises an IoT charging device (ICD) that can use the timestamped communications from the target IBD to determine a location for the target IBD.

Example 16 includes the subject matter of any of examples 1 to 15. In this example, one of the plurality of IoT devices in the LBMD devices comprises a gateway device to pass communications on to a cloud.

Example 17 includes the subject matter of any of examples 1 to 16. In this example, the LBMD is reconfigured to add an IoT device for providing an additional function, wherein the additional function comprises a location calculation function, a cloud communication function, or both.

Example 18 includes the subject matter of any of examples 1 to 16. In this example, the LBMD is reconfigured to eliminate an IoT device providing a function that is no longer needed.

Example 19 provides a method for monitoring an Internet of Things (IoT) battery device (IBD). The method includes initiating communications from the IBD to an IoT charging device (ICD), determining a state of charge (SoCh) of a battery in the IBD, and analyzing the SoCh to determine if a threshold limit has been crossed. An alert message is sent to the ICD if the threshold has been crossed.

Example 20 includes the subject matter of examples 19. In this example, the method includes determining a state of health (SoH) of the battery, determining a state of function (SoF) of the battery, and analyzing the SoH and the SoF to determine if the SoH or the SoF or both crosses a relevant threshold limit. The alert message is sent to the ICD if the SoH or the SoF or both have crossed the relevant threshold limit.

Example 21 includes the subject matter of either of examples 19 or 20. In this example, the method includes exchanging messages between a plurality of ICDs, wherein the messages include timestamped communications from the IBD. The timestamped communications are filtered to determine a time of arrival of a communication from the IBD at each of the plurality of ICDs. A time difference of arrival calculation is performed on the communication to determining a location for the IBD.

Example 22 includes the subject matter of any of examples 19 to 21. In this example, the method includes transmitting a location of the IBD from the ICD to a user.

Example 23 includes the subject matter of any of examples 19 to 22. In this example, the method includes transmitting the alert message and the location of the IBD from the ICD to a user.

Example 24 includes the subject matter of any of examples 19 to 23. In this example, the method includes transmitting a location for a recharged IBD from the ICD to a user.

Example 25 includes the subject matter of any of examples 19 to 24. In this example, the method includes wirelessly transmitting power to an IBD that is proximate to an ICD.

Example 26 includes the subject matter of any of examples 19 to 25. In this example, the method includes detecting by the IBD that it is in range of the charging coils of the ICD, and powering off a radio transceiver in the IBD.

Example 27 includes the subject matter of any of examples 19 to 26. In this example, the method includes detecting by the IBD that is no longer in range of charging coils in the ICD, and initiating communications with the ICD via the radio transceiver.

Example 28 includes the subject matter of any of examples 19 to 27. In this example, the method includes detecting by the IBD that the ICD is no longer in range of charging coils in the ICD, and reducing power to a sensing level in the charging coils.

Example 29 includes the subject matter of any of examples 19 to 28. In this example, the method includes forming a virtual device from a plurality of IoT devices that are self-selected to perform functions, wherein the virtual device adds or removes IoT devices from the plurality of IoT devices as needed.

Example 30 provides instructions, which when executed by one or more processors, cause the one or more processors to perform any one of the methods of claims19to29.

Example 32 provides an apparatus that comprises means for performing any one of the methods of claims19to29.

Example 32 provides a non-transitory, machine readable medium including instructions to direct an MCU in an internet of things (IoT) battery device (IBD) to communicate with an ICD, determine a state of charge (SoCh) of a battery, and analyze the SoCh to determine if a threshold limit has been crossed. Instructions are also included to direct the MCU in the IBD to create an alert message including the SoCh, and send the alert message to an ICD.

Example 33 includes the subject matter of example 32. In this example, the non-transitory, machine readable medium includes instructions to direct the MCU in the IBD to determine a state of health (SoH), a state of function (SoF) or both for the battery create the alert message including the SoH, the SoF, or both, and send the alert message to the ICD.

Example 34 includes the subject matter of either of examples 32 or 33. In this example, the non-transitory, machine readable medium includes instructions to direct the MCU in the IBD to monitor the charging of the battery.

Example 35 provides code to direct a processor in an internet of things (IoT) charging device (ICD) to communicate with an IoT battery device (IBD), exchange timestamped communications from the IBD with other ICDs, filter the timestamped communications to identify a communication received by at least three ICDs, and solve a time difference of arrival on the communication received by the at least three ICDs to locate the IBD.

Example 36 includes the subject matter of example 35. In this example, the non-transitory machine readable medium includes code to direct the processor in the ICD to receive a battery status alert from the IBD, and provide the alert to user.

Example 37 includes the subject matter of either of examples 35 or 36. In this example, the non-transitory machine readable medium includes code to direct the processor in the ICD to manage power transmission to an IBD to charge the battery.

Example 38 provides an internet-of-things (IoT) battery device (IBD). The IBD includes a radio transceiver to communicate with an IoT charging device (ICD), a battery, a battery monitor to determine a state of charge (SoCh) for the battery, and a means to send an alert message to indicate that the SoCh is less than a relevant alert threshold.

Example 39 includes the subject matter of example 38. In this example, the apparatus includes the ICD, which includes an ICD radio transceiver, a network interface, an IBD communicator to communicate with an IBD through the ICD radio transceiver, an inter ICD communicator to exchange messages with other ICDs via the network interface, and a means to determine a location of the IBD based.

Example 40 includes the subject matter of either of examples 38 or 39. In this example, the apparatus includes a means to wirelessly charge the IBD.

Example 41 includes the subject matter of any of examples 38 to 40. In this example, the apparatus includes a means to monitor the SoCh.

Example 42 includes the subject matter of any of examples 38 to 41. In this example, the apparatus includes a means to perform a time difference of arrival calculation to determine a location for the IBD.

Example 43 provides a location and battery monitoring device (LBMD) that includes a plurality of internet of things (IoT) devices self-selected from a fog of IoT devices. The LMBD includes a target IoT battery device (IBD), and at least three other IoT devices in communication with the target IBD. Each of the three other IoT devices timestamps the communications received from the target IBD.

Example 44 includes the subject matter of example 43. In this example, one of the plurality of IoT devices comprises an IoT charging device (ICD) that can use the timestamped communications from the target IBD to determine a location for the target IBD.

Example 45 includes the subject matter of either of examples 43 or 44. In this example, one of the plurality of IoT devices comprises a gateway device to pass communications on to a cloud.

Example 46 includes the subject matter of any of claims43to45. In this example, the LBMD is reconfigured to add an IoT device for providing an additional function, wherein the additional function comprises a location calculation function, a cloud communication function, or both.

Example 47 includes the subject matter of any of claims43to46. In this example, the LBMD is reconfigured to eliminate an IoT device providing a function that is no longer needed.

An embodiment is an implementation or example. Reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” “various embodiments,” or “other embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least some embodiments, but not necessarily all embodiments, of the techniques. The various appearances of “an embodiment”, “one embodiment”, or “some embodiments” are not necessarily all referring to the same embodiments. Elements or aspects from an embodiment can be combined with elements or aspects of another embodiment.