All posts tagged: lx

Next in our series examining emerging low-power wireless standards, we consider 6LoWPAN, which stands for “IPv6 over Low-Power Wireless Personal Area Network”. This is a set of networking standards and specifications which is designed to address the ideas that the Internet Protocol (IPv6 in particular) can be and should be applied to even the smallest embedded wireless Internet-of-Things connected devices right out to the “end branches” of the network; and that power-efficient embedded devices with limited processing power should be fully able to be a part of the Internet of Things, including the use of IPv6 network connectivity.

Whilst the Internet Protocol is the workhorse for the Internet and local-area networks, the IEEE 802.15.4 standard defines the networking of wireless mesh devices. Although the two different protocols are inherently different, the 6LoWPAN specification defines encapsulation and header compression mechanisms that allow IPv6 packets to be sent and received over IEEE 802.15.4 wireless networks, essentially allowing the two standards to operate together, efficiently bringing the Internet to small, power-efficient, cheap devices without the relatively high cost, complexity and power consumption required to implement IEEE 802.11 wireless LAN connectivity at every wireless network node.

For example, a typical embedded 802.11 Wi-Fi module may consume 250 mA while it is awake and actively transmitting, and it may well require a separate microcontroller to interface it to the sensors or other electronics required for a particular application. On the other hand, a system-on-chip incorporating a microcontroller combined with an 802.15.4/6LoWPAN-compatible radio transceiver may only consume 25 mA when it is awake and actively transmitting RF data – an order of magnitude less power consumption.

6LoWPAN is well suited to small, compact, relatively low-cost embedded Internet-of-Things appliances that require wireless connectivity to the LAN and to the Internet but can accept connectivity at a relatively low data rate. Examples may include embedded automation, building control systems and wireless sensor networks in home, office and industrial environments, as well as smart energy metering, measurement and control networks. Devices such as smart meters may collate their data via a 802.15.4/6LoWPAN mesh network before sending the data back to the billing system over the IPv6 backbone.

Whilst IP networks are typically designed to optimise speed whilst managing traffic issues such as network congestion, 802.15.4 systems are designed to give a higher priority to efficient low-power operation and optimisation of memory use, maximising their utility on small, cheap, memory-constrained microcontrollers.

There are some complexities involved in interfacing the two systems elegantly – for example, whilst IPv6 requires a maximum transmission unit of at least 1280 bytes, the 802.15.4 physical layer allows a maximum of 127 bytes per packet, including the payload. The management of addresses for devices that communicate across both the dissimilar domains of IPv6 and IEEE 802.15.4 is also cumbersome, as is the routing of packets between the IPv6 domain and the PAN domain.

Since IP-enabled devices may require the formation of ad-hoc networks particularly during initial setup and configuration, the current state of neighbouring devices and the services hosted by such devices will need to be known. This requires a mechanism for device discovery of the neighbouring devices present in the network.

All 802.15.4 networks connected to the Internet, using 6LoWPAN or otherwise, do require the hardware and software of a physical “bridge” or “gateway” at some point or points in the network, in order to connect the 802.15.4 wireless mesh network to an 802.11 wireless LAN or wired Ethernet. Multiple such nodes mitigate the possibility of single-point failure of network connectivity for the mesh network, at the price of increased network complexity and hardware cost.

IPv6 nodes are assigned 128-bit IP addresses in a hierarchical manner, through an arbitrary length network prefix. IEEE 802.15.4 devices may use either 64-bit extended addresses or 16-bit addresses that are unique within a PAN (a Personal Area Network, which is a group of physically colocated 802.15.4 nodes) as long as an association between a node and a particular PAN has occurred. A particular PAN can also be identified by giving it a PAN ID, allowing the devices of that PAN to easily be recognised – for example, a particular PAN may be associated with a particular building or a particular room.

IEEE 802.15.4 is specifically intended for compact, cheap devices with a relatively low power consumption, operating efficiently from power sources such as batteries. After all, for networks of numerous Internet-of-Things appliances to become ubiquitous, individual wireless hardware nodes need to be as compact, unobtrusive and as cheap as possible.

Making each hardware device as small as possible also allows for portability and greater flexibility in how the devices are used – in wearable computing, for example. However, devices that don’t need to be wireless can be kept in the IP domain of the network and wired in to copper Ethernet – and if portability isn’t required, this means more bandwidth is available to the device. In such a case, a wired mains power supply may also be used, meaning that a larger amount of power is available.

In applications where wireless networking is required but device cost and power efficiency does not need to be so tightly constrained, or where more network bandwidth is required, 802.11 wireless networking may be chosen instead of 6LoWPAN over 802.15.4, keeping the device in the IP domain.

As you can imagine the 6LoWPAN standard offers new levels of compatibility with upcoming infrastructure and is perfect for low-power applications. And if this meets your needs but you’re not sure how to progress with a reliable implementation, we can partner with you to take care of this either in revisions of existing products or as part of new designs. With our experience in retail and commercial products we have the ability to target your product’s design to the required end-user market and all the steps required to make it happen.

We can create or tailor just about anything from a wireless temperature sensor to a complete Internet-enabled system for you – within your required time-frame and your budget. For more information or a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design. https://lx-group.com.au

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The Bluetooth wireless data protocol has been in use for over ten years, and in recent time the new low energy standard has been introduced. This gives designers another option for wireless connectivity between devices with an extremely low power consumption. In the following we examine what it is, the benefits and implementation examples.

Bluetooth LE (for “low energy”) is aimed at novel applications of short-range wireless communication in connected Internet-of-Things devices for medical, fitness, sports, security and home entertainment applications, and was merged into the main Bluetooth specification as part of the Bluetooth Core Specification v4.0 in 2010.

Also known as “Bluetooth Smart”, it enables new applications of Bluetooth networking in small, power-efficient Internet-of-Things devices that can operate for months or even years on tiny coin cell batteries or other small-scale energy sources. Bluetooth LE devices offer ultra-low power consumption, particularly in idle or sleep modes, multi-vendor interoperability and low cost, whilst maintaining radio link range that is sufficiently long enough for the intended applications.

The Bluetooth LE protocol is not backwards-compatible with the “classic” Bluetooth – however, the Bluetooth 4.0 specification does allow for dual-mode Bluetooth implementations – where the device can communicate using both classic Bluetooth and Bluetooth LE. Whilst Bluetooth Low Energy uses a simpler modulation system than classic Bluetooth, it employs the same 2.4 GHz ISM band, allowing dual-mode devices to share a common antenna and RF electronics for both Classic and Bluetooth LE communication.

Small, power-efficient devices like wearable athletic and medical sensors are typically based on a single-mode Bluetooth LE system in order to minimise power consumption, size and cost. In devices like notebooks and smart phones, though, dual-mode Bluetooth is typically implemented, allowing communication with both Bluetooth LE and classic Bluetooth devices. When operated in Bluetooth LE mode, the Bluetooth LE stack is used whilst the RF hardware and antenna is usually the same set of hardware as used for classic Bluetooth operation.

Devices using Bluetooth LE typically have a power consumption, for Bluetooth communication, which is a fraction of that of classic Bluetooth devices. In many cases, devices can operate for a year or more on a single coin cell. This potentially makes Bluetooth LE very attractive for Internet-of-Things networks, telemetry and data logging from environmental sensor networks, for example.

Since many modern consumer devices such as mobile phones and notebooks have built-in Bluetooth LE support, data can be delivered directly to the user’s fingertips from the Bluetooth sensor network with no need for an intermediary gateway or router as would be required for an Internet-of-Things network employing other technologies such as 802.15.4 ZigBee. This direct interoperability with a large installed base of smart phones, tablets and notebooks could potentially be a very significant attraction of Bluetooth LE networks in wireless sensor network and Internet-of-Things applications.

An active Bluetooth radio has a peak current consumption on the order of about 10 milliamps, reduced to about 10 nanoamps (ideally) in sleep mode. In a Bluetooth LE system, the objective is to operate the radio with a very low duty cycle on the order of about 0.1-0.5%, resulting in average current consumption on the order of 10 microamps. At an average current consumption of 20 microamps, such a system could be operated off a typical CR2032 lithium coin cell (with a charge capacity of 230 milliamp-hours) for 1.3 years without battery replacement.

The lower power consumption of Bluetooth LE is not achieved by the nature of the radio transceiver itself (since the same RF hardware is typically used, in dual-mode Bluetooth devices), but by the design of the Bluetooth LE stack to allow low duty cycles for the radio and optimisation for transmission in small bursts – a Bluetooth LE device used for continuous data transfer would not have a lower power consumption than a classic Bluetooth device transmitting the same amount of data.

The Bluetooth specifications define many different profiles for Bluetooth LE devices – specifications for how a device works in particular families of applications. Manufacturers are expected to implement the appropriate profiles for their device in order to ensure compatibility between different devices from different vendors. A particular device may implement more than one profile – for example one device may contain both a heart rate monitor and a temperature sensor. Here is a non-exhaustive list of a few different Bluetooth LE profiles in use:

Health Thermometer Profile, for medical temperature measurement devices.
Glucose Monitor Profile, for medical blood glucose measurement and logging.
Proximity Profile, which allows one device to detect whether another device is within proximity, using RF signal strength to provide a rough range estimate. This is intended for security applications as an “electronic leash”, allowing the detection of devices being moved outside a controlled area.
Running Speed and Cadence profile, for monitoring and logging athletic performance.
Heart Rate Profile, for heart-rate measurement in medical and athletic applications.
Phone Alert Status Profile, which allows a client device to receive notifications (such as an incoming call or email message) from a smart phone. As an example, this is employed in the Pebble smart watch.

The Bluetooth LE shows a lot of promise, and with a minimal chip set cost gives the designer another cost-effective wireless protocol. And if this meets your needs but you’re not sure how to progress with a reliable implementation, we can partner with you to take care of this either in revisions of existing products or as part of new designs. With our experience in retail and commercial products we have the ability to target your product’s design to the required end-user market and all the steps required to make it happen.

Making the decision to create a new product or the next generation of an existing product is always an exciting time for design engineers and hopefully the entire organisation. There’s always new features, options and technologies that can be integrated for the perceived benefit of the end user.

However as technology marches on, there is the possibility of going too far. At first that may seem like an odd statement, however considering the complexity of some products you may wonder how they’re comprehended by the end-user, let alone sales staff. This phenomena is also prevalent in the Internet-of-things arena, where “features” and usability can get out of hand.

Let’s consider the potential dangers of over-engineering and feature overcomplexity when bringing an Internet-of-Things automation or embedded sensor appliance to the market. With advancements in available technology, increasing miniaturisation and decreasing costs of sensors and components it’s tempting for more and more features and capabilities to be added to your device or product design, just to make your product “the best” or to satisfy the “because we can” motivation of the engineering team.

However, it can be important to keep this kind of over-engineering or “feature creep” under control in order to deliver a product that is easy for consumers and salespeople to understand and offers simple, sensible, intuitive user experience with a sensible amount of functionality – not too little and not too much – from a hardware system that is small enough and simple enough that it can practically be manufactured and offered to the market at an acceptable price for good consumer uptake.

Sure, your design might be “the best” from a technology standpoint, but what if the “best” hardware is significantly more expensive than the competitor’s not quite as whiz-bang product and your design is not considered financially attractive to consumers relative to the level of functionality that the users actually want?

It’s pointless to try and invent more and more features just because it is technologically possible to do so if those features don’t actually accomplish anything that is actually valuable to consumers. For example, providing a washing machine with Internet-of-Things connectivity and remote access and control via email or a smartphone application is quite pointless since a human operator actually needs to be there to load and unload the clothes from the machine.

The features and user experience should be kept intuitive and usable, without dragging the user down into an insane range of different options that most people are probably never going to use most of the time anyway.

Internet-of-Things sensor networks and appliances targeted at home and building automation should be easy to set up and configure, they should be compatible with existing typical household network infrastructure such as single-band 2.4 GHz 802.11b/g Wi-Fi access points (5 GHz might be technically “better”, for example, but users don’t want to upgrade all their existing access points just to use your gadget), and they need to be compact, visually unobtrusive – and as simple as possible in order to keep the hardware cost at a level that is sufficiently small for market acceptance.

This is particularly true for appliances that are designed for use as a network of many distributed devices – the cost of the total set of all the hardware devices needed for a typical network deployment needs to be kept at a reasonable level so that the entire usable system is available to consumers at an overall price point that they’re willing to pay. For Internet-of-Things networks consisting of meshes of multiple wireless devices to become ubiquitous, each node device needs to be as cheap and as small as possible.

For example, suppose that you release a smart email-controlled Internet-of-Things light bulb onto the market and it costs $100. Will customers replace their existing light bulb, which costs say $5, with your new $100 light bulb with the added convenience of control from your PC? Well, some consumers might try a single light bulb or two just to experience the relatively novel idea of a consumer-focussed household Internet-of-Things appliance.

However very few customers are likely to consider it worthwhile to set up a network of a dozen hundred-dollar bulbs to replace every bulb in the home. Such a system might pick up a few customers – the relatively wealthy technology fans who want to be early adopters of advanced, relatively complicated home automation and Internet-of-Things technologies, even if the price is high. But isn’t it better to have a product that is desirable for a broader market beyond just those who are willing to pay lots of money for the most powerful, advanced technology on the market?

Furthermore, realistic testing of your product’s usability and user experience is vital during the development process. Adding too many features can befuddle customers as well as befuddling salespeople whose job it is to help convince customers to buy your product and to demonstrate its user experience with consumers. Over-engineering and feature creep, even if it’s possible to integrate lots and lots of features from a technical engineering standpoint, can negatively affect sales as well as affecting your brand reputation.

The best user interface is “no user interface” – a user interface design that approaches the theoretical ideal of being completely transparent and natural in its interaction with the user. Similarly – although I know it might sound risky – the best documentation design is “no documentation”, or something approaching it. The ideal product is so intuitive and natural in its user experience that it just kind of “documents itself”, with little or no documentation really required. This means that the amount of documentation that the customer needs to read is minimised as well as minimising the amount and the cost of documentation that the manufacturer needs to print for every unit shipped.

With hindsight you can examine your own existing products and that of your competitor’s, and with a fresh perspective perhaps consider how things can be simpler for the end user without sacrificing usability. This is a simple step to initiate, however it can require a total redesign or approach from a fresh set of minds.

As part of our complete product design service, here at the LX Group we can partner with you to work on revisions of existing products or bring new ideas to life. With out experience in retail and commercial products we have the experience to target your product’s design to the required end-user market and all the steps required to make it happen.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

After the initial excitement of generating an idea for a new Internet of Things device, there’s still countless design considerations to take into account – some of which you may not have even heard of. And a fair amount of these will be generated by the needs of specific markets around the world. So let’s consider some of the challenges involved in designing an Internet-of-Things device or appliance and bringing it to the global market.

What are some of the different factors that need to be taken into account when bringing a hardware device to market internationally? The need for multi-voltage off-line power supplies and multi-lingual product manuals are well-known things we’re used to with all our technology products – but with modern Internet-of-Things gadgets employing Internet connectivity, cloud computing and wireless radio-frequency mesh networks, there are some increasingly important factors to consider which may not be as familiar to the design team.

For mains-powered systems, international differences in mains voltage and frequency are an obvious factor to start with to ensure compatibility with the worldwide market. Modern switch-mode power supplies can easily be designed to span the possible worldwide voltage range between 100 V AC and 240 V AC without manual switching or configuration, at grid frequencies between 50 and 60 Hz. However, it should be remembered that the mains voltage is only assured within a tolerance of around plus or minus 10 percent, so an example of a good input voltage specification for a well-designed modern SMPS might be 85-265 V RMS AC at a grid frequency of 50-60 Hz. Extra attention is needed in systems where a clock or timebase is derived from the frequency of the AC grid – in systems of this sort, manual specification of the frequency may be required even if the power supply itself does not care about the AC frequency.

When designing and deploying wireless sensor networks, Internet-of-Things networks and similar modern technologies where radio communication is used, attention also needs to be paid to differing international allocations of RF spectrum and licensing requirements for the use of the RF spectrum. Spectrum allocations and licensing requirements for Industrial, Scientific and Medical (ISM) bands differ between countries – for example, the 915 MHz band should not be used in countries outside ITU Region 2 except those countries that specifically allow it, such as Australia and Israel.

A device that operates with a certain frequency spectrum and power level that requires no license, or falls into a class license, in one country may not be able to be legally operated in another country without specific operator licensing. For example, some devices operating in the 70 cm (433 MHz) spectrum that fall within the Low Interference Potential Device (LIPD) class license in Australia and hence can be freely operated cannot be used in the United States except by licensed amateur radio operators. The European Union’s Reduction of Hazardous Substances (ROHS) directive took effect in 2006, restricting the use of certain substances considered harmful to health and the environment, such as lead and cadmium, except in technological applications where elimination of these elements is not viable.

While RoHS compliance is not required for all electronic equipment sold throughout the world and is only strictly required for devices sold into the EU market, it is achieving widespread acceptance throughout the electronic manufacturing industry worldwide. However, in some specialised applications where extremely high reliability and resilience against factors such as tin-whisker formation is required, such as space and defence technology, these factors may take precedence over ROHS compliance and the use of lead-containing solder alloys and platings may be specified.

Different testing organisations are responsible for setting and enforcing the standards for electrical safety and RF spectrum usage in different countries, and it can be challenging to keep track of the different testing requirements needed before bringing your product to market in every market country.

For example, Underwriters Laboratories is well known in the United States for their role in drafting safety standards and providing compliance testing procedures for safety-related factors, whilst approval from the FCC is required to recognise compliance with RF spectrum and electromagnetic interference requirements – a completely separate thing to safety certification. And for another example, the TUV provides a similar role in the verification of safety-related standard compliance in the German market.

Other social and socio-economic factors that might not be as obvious can affect the user experience your product provides in different customer markets – for example, a device that constantly needs to “phone home” to an Internet-connected service may not function effectively in a country without widely available, or reliable, Internet access. In a situation like this, it may be beneficial to have a system designed to store and buffer its collected data locally on a storage device and only synchronise with an Internet service occasionally when connectivity may be available.

In conclusion, there’s a myriad of not only standards but also operational considerations to take in account when designing your next product for the global market. However don’t let that put you off – the greater the challenge, the greater the possible success. But if you’re not sure about testing, standards, compliance, markets abroad or any other factor – parter with an organisation that does: the LX Group.

Here at the LX Group we have the experience and team to make things happen. With our experience with connected devices, embedded and wireless hardware/software design, and ability to transfer ideas from the whiteboard to the white box – we can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The Internet of Things holds great potential, and much has been written about the final applications and the possibilities – however one major factor of any device is how it will be powered. It’s all very well to have the latest sensors or interactive devices, if they don’t have a suitable power supply. It’s easy to consider a battery – however there’s many more options that can increase lifespan, reduce maintenance calls and therefore the running costs. Let’s review a few options that can provide a portable power supply for your IoT nodes where mains power or cabled-in power supplies are not available.

First, consider solar photovoltaic – a common choice for sensing, control or measurement devices that are located outdoors where sunlight is available, and that consume a relatively small amount of power. For a small, low-power embedded device that receives a reasonable amount of sun each day, a moderately small solar panel is perfectly capable of supplying sufficient power – on average – to run a small, basic wireless network node consisting of a microcontroller, some sensors and an embedded low-power Wi-Fi, Bluetooth or 802.15.4/ZigBee radio transceiver. However this is assuming that the overall system is designed for a reasonable degree of power efficiency.

However, solar power is intrinsically intermittent and is only available on average for a fraction of the day. To allow the system to have access to the current it needs to function when needed, solar-powered wireless devices almost always need to incorporate a small amount of energy storage in the form of a battery or supercapacitor in conjunction with the solar cell. Furthermore, solar cells or solar panels typically have a relatively low output voltage if a small number of cells are used, and their non-linear V-I curve makes it desirable to employ Maximum Power Point Tracking (MPPT) where practical.

This is necessary to keep the system operating near the maximum power point so that the limited energy available is harvested most efficiently. A solar power supply for a remote wireless system ideally tracks the maximum power point of the cell along the V-I curve and is able to charge a small battery or supercapacitor to fill in the demand when sufficient sunlight is not available.

As an example of a controller IC one may use for the power supply in a small solar powered system, the Linear Technology LTC3105 is a high efficiency step-up DC/DC converter that can operate from input voltages as low as 225 millivolts, with a built-in maximum power point controller (MPPC). As well as solar cells, this device is well suited to other low voltage, high impedance energy harvesting transducers such as thermoelectric generators and fuel cells.

Whilst it is not a true maximum power point tracker, the user-programmable maximum power point setting helps to optimise the efficiency of energy extraction from any energy source, such as a thermoelectric pile or a solar cell, where the voltage across the transducer may vary with changing environmental conditions as well as with the load current. The LTC3105 is capable of supplying 70 mA of output current at 3.3V from an input voltage of 1 volt – this is sufficient power to run a small, well designed basic sensor node consisting of a microcontroller, RF transceiver and a sensor or two.

Another type of power supply is known as energy harvesting, made possible by parts such as the Linear LTC3108, which is designed to accommodate energy harvesting from transducers with extremely low output voltages, as low as 20 millivolts. This makes it particularly well suited for use with thermopiles and thermoelectric generators which can generate a very low potential difference from a realistic temperature difference – a potentially convenient energy source for remote sensing in industrial automation or process monitoring in high-temperature systems where wired communications and power are not convenient.

Energy can also be derived from vibration, and using a part such as the Linear LTC3588 – a piezoelectric energy harvesting power supply controller which connects to a piezoelectric crystal to harvest mechanical energy in the form of vibrations from the ambient environment. This IC incorporates a low-loss, full-wave bridge rectifier and is capable of accommodating the rapidly changing AC voltage output and high source impedance of a piezoelectric crystal subject to mechanical stress and converting this energy into a DC current with relatively high efficiency.

Output voltage selections between 1.8V and 3.6V are available with a continuous output current capability of up to 100 milliamps, compatible with a range of modern power-efficient microcontrollers and RF mesh systems-on-chip.

An electromechanical energy harvester of this sort can be employed to provide a continuous source of a small amount of “free” energy for a small, efficient wireless network mote, particularly in applications such as vehicles and industrial machinery where plenty of vibrational energy is available to be harvested in the environment.

Finally, for some systems it is also practical to use just batteries – for example, lithium-ion, lithium-polymer or nickel-metal hydride batteries – and rely on user intervention to simply
recharge and replace the batteries where needed. The batteries may be left internally, inside the device, with the system being plugged into a power supply via a charging port
– perhaps using a low-power standard power-supplying interface such as USB – when the device requires a recharge, as opposed to the traditional method of removing and swapping the batteries.

In this sort of application, battery management and charging ICs such as the Microchip MCP73833 Li-polymer / Li-ion charge management controller can be of use to control the recharge of a Li-ion cell, as can buck/boost converters such as the Texas Instruments TPS63031. A buck/boost converter like this allows a regulated output voltage to be generated from input voltages both higher and lower than the desired output voltage – an output of 500mA at 3.3V, in this case, from an input voltage anywhere from 2.4 to 5.5 volts. This allows a battery such as a two-cell NiMH, three-cell NiMH, or single-cell Li-ion / Li-polymer to be used efficiently and charged and discharged across the entire usable part of its discharge curve without hitting the minimum input voltage of a LDO or buck regulator.

No matter what your device or where it will be located, finding an appropriate source of power is possible, and easier than you realise. It just takes a little research and a team of dedicated engineers with the experience and knowledge to understand your requirements. Here at the LX Group we have the experience and team to make things happen. With our experience with connected devices, embedded and wireless hardware/software design, and ability to transfer ideas from the whiteboard to the white box – we can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

The fact that the Internet of Things shows a lot of promise both now and in the future is certain – and your customers, designers and the public will have an almost limitless amount of ideas with regards to new products and their implementation. However when the time comes to select the hardware to drive these innovations, choosing from one of the wireless chipsets can be a minefield – and more so when WiFi is involved.

802.11 wireless LAN is an attractive technology for building networks of wireless sensors and embedded devices due to its widespread use and the availability of nearly ubiquitous existing network infrastructure. Let’s take a look at a few existing chipsets on the market today that can be used to add wireless networking to existing embedded designs with relatively low complexity and cost.

First there’s the RN131 802.11b/g WiFi module by Roving Networks – a complete low-power embedded networking solution. It incorporates a 2.4 GHz radio, processor, TCP/IP stack, real-time clock, crypto accelerator, power management and analogue sensor interfaces into a single, relatively power-efficient module. In the most simple configuration, the hardware requires only 3.3V power, ground, and a pair of serial UART lines for connection to an existing microcontroller, allowing wireless networking to easily be added to an existing embedded system.

The module incorporates a U.FL connector for connection of an external antenna, without any microwave layout or design needed to use the module. This module has a current consumption of 40mA when awake and receiving, 200mA when actively transmitting, and 4µA when asleep, and the device can wake up, connect to a WiFi network, send data, and return to sleep mode in less than 100 milliseconds. This makes it possible to achieve a runtime on the order of years from a pair of standard AA batteries – an ideal solution for power-efficient, battery powered wireless sensor network and Internet-of-Things solutions.

Next there’s the Texas Instruments CC3000 Wireless Network Processor – which allows WiFi to be added to any existing microcontroller system relatively easily, and at a low cost. The CC3000 integrates an entire IPv4 TCP/IP stack, WiFi driver and security supplicant on the chip, making it easily portable to lightweight microcontrollers without the memory burden of implementing a TCP/IP stack in the host microcontroller where relatively low-power, low-cost microcontrollers such as 8-bit AVR or PIC devices are used. And this compact module measures only 16.3mm x 13.5mm.

CC3000 reference designs available from TI demonstrate chip-antenna based designs that are already FCC, IC and CE certified, which can make it easier to develop bespoke solutions that can pass compliance testing for products going into markets where such compliance is needed. The CC3000 requires no external crystal or antenna balun, and in fact requires almost no external components at all except for an SPI interface to the host microcontroller and an antenna – and the device costs less than $10.

The flexible 2.7-4.8V power supply requirement offers great flexibility when combined with battery power or energy harvesting solutions. However, this chip is not a PCB-based module, meaning that a 50 ohm 2.4 GHz antenna must be added externally – so the designer must have a little familiarity with microwave design, such as microstrip transmission line layout and the choice of the right antenna connector. However, this offers the designer complete flexibility to choose the most appropriate antenna type for the size, range and gain requirements of the design – a larger external antenna, a compact chip antenna, or a microstrip antenna fabricated on the PCB with no bill-of-materials cost.

Our final subject is the Redpine Signals’ Connect-IO-n series of modules which allow 802.11 wireless LAN connectivity to be added relatively easily to an embedded microcontroller system. In collaboration with Atmel these modules have been optimised for use with Atmel microcontrollers, particularly the Atmel AVR XMEGA and AVR UC3 series microcontrollers.

Some modules in this family provide 802.11a/b/g/n Wi-Fi connectivity, whilst all modules provide the TCP/IP stack on board and are FCC certified, making RF compliance certification of your entire design easier. These modules are aimed at providing the ability to add 802.11 wireless connectivity to 8-bit and 16-bit microcontrollers with low integration effort and low memory footprint required in the host microcontroller to support the WiFi device, especially where 802.11n support is desired.

Like the other chipsets we’ve discussed, the modules in this series can be interfaced to the host microcontroller over a UART or SPI interface, and similarly to their competitors, a standby current consumption of only a few microamps potentially allows for years of battery life with no external energy source as long as the radio is only briefly enabled when it is needed.

The RedPine RS9110-N-11-28 module from the Connect-IO-n family in particular is relatively unusual in that it provides dual-band 2.4GHz/5GHz 802.11 a/b/g/n connectivity for your embedded device – supporting connection to any WiFi device or network and potentially avoiding congestion in the 2.4 GHz band as used with 802.11b/g devices.

Whilst 802.11n offers a significant increase in the maximum net data rate from the 54 MBit/s of 802.11b/g to 600 Mbit/s, do you really need 600 Mbit/s of data to your wireless sensor network or embedded appliance? I doubt it. However, one case where you might want an 802.11n radio supporting operation in the 5 GHz spectrum for your wireless sensor network device is if your wireless LAN infrastructure is a pure 5 GHz 802.11n network – whilst this breaks compatibility with legacy devices, it delivers maximum network performance.

As you can see the possibilities for low-power connected devices are plentiful and the hardware is available on the open market. It’s then up to your team to turn great ideas into great products. Furthermore modifying existing products to become connected is also a possibility. However if wireless or Internet-connectivity is new to your team – and you’re in a hurry, have a reduced R&D budget, need guidance or want to outsource the entire project – it can be done with the right technology partner.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Wearable computing – the use of personal computers, displays and sensors worn on one’s person – gives us the potential for advancement in human-computer interaction compared to traditional personal computing – for example the ability to have constant access and interaction with a computer – and the Internet, whilst going about our daily activities.

This could be considered the ultimate in multitasking – the use of your computing device at any time without interrupting your other activities. For example, the ability to read an email or retrieve required information while walking or working on other tasks. Wearable computing potentially offers much greater consistency in human-computer interaction – constant access to the computer, constant connectivity, without a computing device being used in an on-and-off fashion in between other activities.

Once contemporary example of this is the new Google Glass, which represents an advanced, sleek, beautifully designed head-mounted wearable computer with a display suitable for augmented-reality applications – or just as an “ordinary” personal head-mounted display. Even before its public release, the frenzy surrounding Google Glass amongst technology enthusiasts demonstrates the potential level of market demand for wearable computers.

However, with a price of at least US$1500 price tag of Google Glass, (at least for its “Explorer Edition” beta version) this leads many to consider what potential might exist for the deployment of wearable computing and wearable sensor-network technologies – however at a lower cost.

One example is the category known as “Smart Watches” such as the Sony SmartWatch and Pebble Technology’s “Pebble” e-Paper watch – which both offer constant, on-the-go access to information from the Internet – and thus become a member of the Internet of Things – at a glance of the wrist. Text messages and email notifications are amongst the most simple, common examples of data that can be pushed to a smart watch, but the display of information from a multitude of other Internet-connected data streams is possible.

With the growing popularity and increasing hardware capabilities of smart phones, it is increasingly taken for granted that a smart phone carried on one’s person can act as a gateway between the Internet (connected via the cellular networks) and other smaller, lower-power wearable computer or sensor devices worn on the body and connected back to the smartphone via standard data links such as WiFi or Bluetooth. In using the smart phone as an Internet connection, the size, price and weight of the wearable device can be significantly reduced – which also leads to a considerable reduction in cost.

Furthermore, apart from providing mobile Internet connectivity, the smart phone can also provide a large display and an amount of storage capacity – which can be harnessed for the logging, visualisation and display of data collected from a network-connected sensor node wearable on one’s body, or a whole network of such sensor nodes distributed around different personal electronic devices carried on the person and different types of physical sensors around the body.

The increasing penetration of smart phones in the market and the increasing availability and decreasing cost of wireless radio-networked microcontroller system-on-chips, MEMS
sensors and energy efficient short-range wireless connectivity technologies such as Bluetooth 4.0 are among some of the factors responsible for increasing the capabilities of,
and decreasing the cost of, wearable computing and wearable Internet-of-Things and sensor platforms.

Speed and position loggers, GPS data loggers and smart pedometers intended for logging and monitoring athletic performance, such as the Internet-connected, GPS-enabled,
Nike+ system; along with biomedical instrumentation and sensor devices such as Polar’s Bluetooth-connected heart rate sensors are other prominent examples of wearable Internet-of-Things devices which are attracting increasing consumer interest on the market today.

Combined with display devices such as smart watches, smart phones and head-mounted displays such as Google Glass. these kinds of wearable sensors create a complete wearable machine-to-machine Internet-of-Things network that can be self-contained on one’s person. Which leads us to the next level of possibilities – what do your customers want a device to do? And how can it be accomplished? And do you have the resources or expertise to design, test and bring such a system to the market?

It isn’t easy – there’s a lot of technology to work with – however it can be done with the right technology parter. Here at the LX Group we have the experience and team to make things happen. With our experience with sensors, embedded and wireless hardware/software design, and ability to transfer ideas from the whiteboard to the white box – we can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Recently an increasing number of networked devices are finding their way into consumer, industrial and medical applications. Such networks often employ distributed nodes which cannot practically be connected to the power grid – through design or through necessity. Therefore powering such devices can possibly be a challenge – due to the costs of either running from battery or solar power, sending technicians for maintenance visits to replace batteries – or having to install one’s own power network for the IoT system.

This is where energy efficiency is key – by using highly energy-efficient design practices in both the hardware and software levels, the power requirements can usually be reduced significantly. In doing so the power supply paradigm can be altered to one of lower cost and higher efficiency. Especially for remote or portable devices that use RF/microcontroller chipsets – the smaller the power requirement the better.

High-power and efficient wireless network nodes can be engineered using modern RF microcontroller system-on-chip devices, activating sensors and peripheral hardware devices only when they are required, and then putting them into low-power sleep modes when not in use. Similarly, the RF transceiver can be switched into a very-low-power sleep state until the microcontroller decides that a transmission of collected sensor data is required. The microcontroller can then wake up the radio, perform the required transmission, and then revert to sleep mode.

In some cases, a burst of data transmission across the wireless network might only occur when a small, intermittent energy-harvesting power supply has accumulated enough energy in a capacitor to power a transmission. Alternatively, a low-power wireless sensor node can “wake-on-radio”, only taking the microcontroller out of its sleep state when a message is received over the wireless network requesting a sensor readout and only powering up the sensors and microcontroller at this time.

With most of the components of the system, such as the microcontroller, radio and sensors – each kept off-line or asleep for the largest practical amount of time – efficiently designed wireless sensor nodes may achieve operating timescales as long as years off a single battery. Today’s typical wireless RF microcontroller system-on-chips targeted at IoT applications typically consume about 1-5 microwatts in their “sleep” state, increasing to about 0.5-1.0 mW when the microcontroller is active, and up to around 50 mW peak for brief periods of active RF transmission.

However when considering the design of energy-efficient, low-power IoT sensor networks, it can sometimes be advantageous to think not just in terms of power consumption, but in terms of the amount of energy required to perform a particular operation. For example, let’s suppose that waking up a MEMS accelerometer from sleep, performing an acceleration measurement and then going back to sleep consumes, say, 50 micro joules of energy; or that waking up an RF transceiver from sleep, transmitting a burst of 100 bytes of data and then going back to sleep consumes 500 micro joules.

If we know the specific energy consumption of each operation, then the average power consumption is simply the energy per operation multiplied by the frequency of that operation, summed over the different kinds of operations. Of course, this assumes that the continuous power consumption of each device when it is asleep is very small and can be ignored. Alternatively, if we have a certain known power budget available and a known energy budget for each sensing, computation or transmission operation – we then know the maximum practical frequency at which a sensor node can perform sensor measurements and transmit its data.

Additionally, efficient wireless sensor nodes can take advantage of some form of energy harvesting power supply – employing energy sources such as solar cells, vibrational energy harvesters or thermoelectric generators to minimise maintenance and extend battery life – with the possibility of completely eliminating external power supplies, but only if the power consumption of the system is small enough and a capacitor is employed for energy storage.

In many applications, solar cells are the most familiar and relatively mature choice for low-power network nodes operating outdoors or under good indoor light conditions. However, other technologies suitable for extracting small amounts of power from the ambient environment exist. For example, a wireless sensor node set up to monitor bearing wear in a generator could employ a piezoelectric crystal as a vibrational energy harvester, converting motor vibration into usable energy, or a thermoelectric generator mounted on a hot exhaust could harvest a small amount of otherwise wasted energy from the thermal gradient.

Typical vibrational energy harvesters usually operate with a cantilever of piezoelectric material that is clamped at one end and tuned to resonate at the frequency of the vibration source for optimal efficiency – although an electromagnetic transducer can be used in some cases. Whilst the electrical power available is dependent on the frequency and intensity of the vibrations, the cantilever tip mass and resonant frequency can generally be adjusted to match the machinery or system that energy is to be harvested from.

Furthermore, energy harvesting management ICs that manage the accumulation of energy in a capacitor over a period of time can enable short bursts of relatively high power consumption, such as when a node wakes up and transmits a burst of data, and are particularly well suited to low-power wireless sensor nodes.

Even with the examples mentioned above, the energy-efficiency possibilities are significant and can be a reality. When designing prototypes or proof-of-concept demonstrations you may put energy use to one side, however when it comes time to generate a real, final product – you can only benefit from taking energy-efficiency into account.

If you are considering creating or modifying existing designs and not sure about the energy-saving and generating options that are available, be efficient and discuss your needs with an organisation that has the knowledge, experience and resources to make your design requirements a reality such as here at the LX Group.

At the LX Group we have a wealth of experience and expertise in the embedded hardware field, and can work with the new and existing standards both in hardware and software to solve your problems. Our goal is to find and implement the best system for our customers, and this is where the LX Group can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

As the Internet-of-things industry and products is justifiably booming – like any emerging market or technology area there are several challenges and pitfalls to work through and hopefully avoid. As with the boom in personal computer types in the early 1980s, through to various standards in video and audio media towards the end of the last decade – making the right choices now can be a challenge.

When choosing IoT platforms – do you face problems with privacy, security, or expensive over-engineering of technology for technology’s sake? Are you considering replacing existing systems that aren’t really broken in a way that offers no real return in terms of user experience or economic value – just to be on the “latest craze”? With the standards of the IoT not being entirely prevalent or fixed, issues such as reliability, privacy, security, ownership and control of private data still pose questions that are barely beginning to be worked out.

The Internet of Things is not just something that is hidden away – out of sight somewhere inside an embedded control system. The growth in this field is also represented in a growth in the use of smart devices and technologies that are directly facing the domestic or industrial consumer.

One of these challenges is security of end-user data. As various devices enter the domestic arena, increasingly-enlightened consumers will have be concerned and have various questions about their privacy and security. And as these Internet of Things devices start to generate detailed real-time data about how much electrical power you’re using, which lights and appliances you have turned on at particular times, or even personal medical data logged directly from biomedical sensors – customers and end-users expect to know where that data is being collected and used, by whom, and why. To achieve confidence and acceptance amongst consumers, companies collecting data through Internet-of-Things systems must do so only with the consumer’s consent and only in a secure and controlled fashion.

The next challenge to meet is demonstrable financial benefit. Consumers expect that if they’re paying for new technology that they serve them – and not just the utility or manufactured. For example, if residential electricity consumers are paying for new smart metering infrastructure – then consumers expect to see how the new technology actually benefits them, not just providing a financial benefit to the energy provider who can save money by removing the number of meter readers.

Do the new technologies actually show a clear financial benefit, to corporate, industrial and household users? It has been said, for example, that one Australian electricity distribution company is “building its own Internet” to collect electricity billing data from residential smart meters. It seems ostensibly absurd to “build your own Internet” instead of building solutions that operate – with appropriate security and reliability – on top of the established Internet.

Although everyone may seem to have an education with regards to IoT devices, another challenge is educating potential and existing customers to the benefit of the devices. For example, as Internet-of-Things devices must be relatively inexpensive if they are to become truly ubiquitous in the home and not only adopted by early adopters who see past the initial price tag. For example, if an IoT-enabled light fixture costs $100 against a few dollars for a conventional bulb, it is not clear how widely adopted such a product will be. Although it’s worth noting that the total cost of ownership should be considered by the consumer – including the necessary cloud or software services, and not just the cost of the hardware node.

Another larger challenge, and one that needs to be overcome (or prepared for) before any final sales and installation is the hardware or software standards being used in the device. For example can the device work with IPv6 addressing? With the upcoming exhaustion of IPv4 addresses the address space represents a significant limit for the Internet of Things, for example there is no way that every refrigerator can have an IPv4 address exposed out to the Internet. However, with the introduction of IPv6 the problem is solved. Thus hardware needs this support.

Although the Internet-of-things will eventually prevail – the example challenges listed above and many more still exist. Improvements for the end-user and operator still introduce design problems and perhaps a little “fortune-telling” just as any new wave of technology or standards.

But how do you ensure your hardware will meet upcoming or new standards? Will your Internet-of-things ideas translate into profitable, desired systems by all stakeholders – not just your design team. Or can your existing systems be enhanced to benefit from the Internet-of-things without a total redesign? All these and many more questions can be answered by a design house with the expertise and experience such as here at the LX Group.

At the LX Group we have a wealth of experience and expertise in the IoT field, and can work with the new and existing standards both in hardware and software to solve your problems. Our goal is to find and implement the best system for our customers, and this is where the LX Group can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Recently Google announced their new Cloud Platform services, which allow almost anyone to build applications, websites, store and analyse data using Google’s infrastructure. This is an exciting development for those looking to implement a scalable Internet-of-things system at a minimal cost – so we’ll take an overview of the system as it stands today.

Almost everyone is aware of the researched information, computing power and infrastructure available for Google’s myriad of services, and now it’s possible to harness some of this for your own needs. With the introduction of their “Cloud Platform”, you can harness this power that Google has used internally for years to provide Google’s familiar high-speed, high-scale big-data products and services such as Search, YouTube, Google Docs and GMail and make it available as cloud computing services for use with your own Internet-of-Things projects.

Large-scale, high-speed, distributed “cloud” storage and computation with large amounts of data is at the heart of everything that makes Google what it is, so it’s clear that they have substantial opportunities to offer external cloud-computing customers.

Whilst Google is not the first major player in the cloud computing market, their substantial infrastructure and “Big Data” experience represents a significant source of potential competition with other established cloud computing providers such as Amazon Web Services. The capability to use Google’s data centre infrastructure for cloud storage and computation, their data tools such as BigQuery to process very large scale data sets – and integration with Google’s data, services and apps are increasingly attractive.

The Google Cloud Platform is made up of a couple of different core components – Compute and Storage being two of the most important. The Compute component includes the Google Compute Engine, which is an Infrastructure-as-a-Service platform designed to run any application on top of Google’s infrastructure – which offers fast networking, scalable processing and storage, and the App Engine, a platform for developing and hosting web applications. The Storage component includes Google Cloud Storage and the BigQuery large-scale query system.

As with most cloud computing platforms, end users access cloud-based applications and infrastructure through a relatively lightweight local computer – via a web browser, lightweight desktop software, or a mobile device application – with the data and most of the software are stored on remote servers in the cloud. Therefore, the hardware requirements for the user to leverage the power of applications and data on Google Cloud Platform-hosted applications and services are almost trivial.

Many components of the Google Cloud Platform support open standards and protocols such as REST-based APIs. The Google Compute Engine is built atop a JSON RESTful API which
can be accessed via numerous different libraries, command-line utilities and GUI front-end tools. Google’s BigQuery, a cloud-based fully managed interactive query service specifically designed for work with massive datasets, is operated via an SQL-like query language.

Google Cloud Storage complements the Compute component of the Google Cloud Platform and serves to glue together all Google Cloud Services. Google Cloud Storage is a HTTP service that serves data directly over HTTP with high performance and resumable transfers of objects up to the terabyte scale. It offers support for two different APIs – one that is compatible with the XML standard used by competing providers such as Amazon Web Services and another API built around JSON and OAuth, consistent with the Google Compute Engine’s API.

The Google App Engine is a “Platform-as-a-Service” cloud computing platform for the development and hosting of web applications in Google’s managed data centres. Applications are sand-boxed and distributed across multiple servers. One of the major benefits of using the Google App Engine is that it can offer automatic scaling for web applications – that is, automatically allocating more resources for the web application to handle the increased demand as the number of requests for a particular application increases.

All that sounds quite useful, however why would your organisation use the Google Cloud Platform? Whilst it requires an initial investment to import your data (especially on a large scale) into the cloud, this is offset by the substantial advantages offered by the platform. By offering fully managed services that remove the requirement for upfront capacity planning, provisioning, constant monitoring and planning software updates. This can significantly reduce the total cost of ownership of large-scale data handling solutions.

Furthermore there’s one thing in particular that sets the Google Cloud Platform apart – the network that connects the company’s data centres so data can be processed and delivered where it is needed in milliseconds. Google has a private distributed backbone between all its data centres – so if you’re moving data around within Google’s cloud, even within geographically diverse data centres (although this is essentially invisible to the user) your data travels over Google’s backbone, and not over the Internet – providing substantially improved performance.

Whilst the Compute and Storage components of the Google Cloud Platform are separate offerings, the performance of Google’s networks make it appear as though they integrated seamlessly, thus allowing integration of Google’s cloud storage and computation with no obvious slowdown.

At the LX Group we have a wealth of experience and expertise in the IoT field, and can develop new or modify existing hardware and software to integrate your system with the Google Cloud Platform. As always, our goal is to find and implement the best system for our customers, and this is where the LX Group can partner with you for your success.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.