All posts tagged: iot

The Internet-of-things market is growing exponentially – and to some observers it may seem to be an unchecked industry with regards to standards and compatibility. However it isn’t too late to define workable standards – and just that is being done with the International Telecommunications Union’s Internet-of-Things Global Standards Initiative.

In case you’re not familiar with it, the International Telecommunications Union is a specialised agency of the United Nations that is responsible for issues that concern information and communication technologies.

This group coordinates the shared global use of the radio spectrum, promotes international cooperation in assigning satellite orbits, works to improve telecommunication infrastructure in the developing world, and assists in the development and coordination of worldwide technical standards – ITU’s standards-making efforts are its best known and oldest activity.

The ITU’s Internet of Things Global Standards Initiative (IoT GSI) is an initiative of the ITU’s standardisation group that promotes a unified approach for the development of technical standards and recommendations to enable the best possible standardisation and interoperability of the Internet of Things on a global scale.

This international initiative of standardisation has the potential to benefit everybody, from the developers and vendors of Internet-of-Things products and solutions through to consumers. Recommendations developed by the IoT GSI are developed in collaboration with other standards developing organisations – allowing developers, vendors and providers working in the emerging Internet-of-Things industry worldwide to offer a wide range of Internet-of-Things technologies in a standardised and interoperable way. The IoT-GSI also aims to act as an umbrella for further development of IoT standards worldwide.

The purpose of IoT-GSI is to provide a visible single location for information on and development of IoT standards, these being the detailed standards necessary for IoT deployment and to give service providers the means to offer the wide range of services expected from the IoT with a high degree of global standardisation.

By building on the work of other ITU standardisation group efforts in other areas such as network aspects of identification, ubiquitous sensor networks and machine-to-machine communications – the ITU can hopefully bring together different IoT-related standardisation groups both within the ITU and in the wider industry to develop detailed standards for IoT deployment.

From the global perspective of technical standardisation, the IoT can be viewed as a global infrastructure for the information society, enabling advanced services by interconnecting physical and virtual things based on new, and existing, interoperable information and communication technologies. ITU sees enormous potential in the Internet of Things, and hence enormous value and importance in these standardisation efforts, harmonising different approaches to the architecture of the IoT worldwide.

The ITU sees the IoT GSI as important because the deep changes to the fundamental approaches being taken to the provision of situation-aware telecommunication services from network-connected things, and the associated breadth of topics that need to be addressed, are well beyond what could be covered within any particular study group following routine standards development processes.
Furthermore the GSI also provides essential external visibility for the ITU standardisation group’s work, and is a clear and obvious place to go for information on the sector’s work in this particular area. Indeed, it serves as a banner under which to unify all the IoT-relevant activities being carried out within the ITU standardisation group.

Once finished, the IoT GSI aims to have developed a consistent definition of what the Internet of Things actually is, to provide a common working platform bringing together different standards-making, industry and academic representatives, and to develop consistent standards for IoT deployments – taking into account the work already done in other standards development organisations, and recognising that global coordination is the key to widespread success of the IoT.

To meet these objectives, the ITU Joint Coordination Activity on the Internet of Things (JCA IoT) was formed in 2006, bringing together representatives from numerous standards developing organisations, including industry forums and consortia, working in IoT-related areas.

The Joint Coordination Activity provides a platform to exchange IoT information and discuss coordination matters, avoiding overlap and duplicated effort. One of the activities of the JCA is to maintain the ITU’s IoT Standards Roadmap that includes standards from the worldwide ecosystem of standards development organisations that are either approved already or presently under development.

ITU’s IoT-GSI acts as an umbrella for the various standardisation efforts worldwide. Founded on the principle of international cooperation between governments and the private sector, ITU represents a unique global forum through which governments and industry can work towards consensus on a wide range of issues affecting the future direction of this increasingly important industry.

The technology community has highlighted a need to focus standards work in one place, distributing expert resources efficiently and avoiding the emergence of competitive approaches and the GSI responds to this, promoting a unified approach for the development of technical standards and recommendations in order to best enable the IoT efficiently and consistently on a global scale.

Recommendations developed under the IoT-GSI by the various ITU standardisation groups in collaboration with other standards developing organisations will enable technology and service providers worldwide to offer the wide range of services and products that are expected to emerge from the Internet-of-Things industry in the most interoperable and consistent way.

Although doing so may be tempting from an economical perspective, ignoring standards in your IoT-enabled product design could cost you more in the long term, by losing interoperability with other systems – or even scaring off potential customers. Therefore it’s important to be aware of the options in the market and how they can benefit your situation.

Here at the LX Group we have experience in developing IoT systems using various platforms, and can help with any or all stages of product design – to bring your ideas to life.

To get started, join us for an obligation-free and 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.

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

Although not the loudest player in the Internet-of-Things market, Microsoft is increasingly pitching its Windows Embedded operating system product family as a central hub of operating system choices for the connected devices, services and data making up the Internet of Things.

Let’s take a brief look at the Windows Embedded product family and the role it can play in embedded computing and Internet-of-Things applications. Not to be outdone by Java, Linux, or other options in the market, Microsoft is staking its own claim in the Internet-of-Things and connected-device operating system space, pitching the Windows Embedded family of operating systems at applications such as vending machines, robotic controls and industrial automation, point-of-sale terminals and registers, and rugged industrial tablets.

As well as selling the Windows Embedded family of operating systems for embedded electronics, Microsoft’s Windows Embedded business group utilises its Intelligent Systems Initiative to help clients leverage the data output of the Internet of Things.

Microsoft is touting its applications such as SQL Server to manage data in the Internet-of-Things environment, Windows Azure cloud solutions to provide common computing and integration, its various business intelligence tools to analyse data from connected devices and networks, and its various system management tools to manage the whole fabric.

With a broad family of existing product offerings and industry experience mean that Microsoft is well positioned to support a whole fabric of embedded operating systems, database handling, cloud services and Internet-of-Things derived business intelligence products built around the Internet of Things, not just operating systems for isolated embedded devices.

Due to their breadth of experience, Microsoft is one of the few technology providers that can be reasonably be expected to provide a complete technology stack for the Internet of Things, as a one-stop-shop solution provider.

Microsoft’s Intelligent Systems Initiative complements the Windows Embedded product line, helping clients to leverage the data traffic that the Internet of Things generates by providing database, authentication, analytical and visualisation capabilities for IoT data, targeting markets such as the automotive, manufacturing and retail point-of-sale industries.

With their portfolio of Windows Embedded operating systems, you can scale to fit the hardware capabilities available in the embedded devices used, with hardware limitations such as small size, low energy consumption, and limited memory or processing power.

The familiar Microsoft .NET Micro Framework is aimed at very lightweight microcontrollers with significant memory constraints, such as the well-known mbed platform – whilst other offerings in the Windows Embedded family such as Windows Embedded Compact 2013, Windows Embedded Automotive 7, Windows Embedded 8 Handheld and Windows Embedded 8.1 Industry are aimed at different market segments including automotive devices such as in-car entertainment and navigation, industrial applications, or specialised handheld terminals or data entry devices.

Windows Embedded devices can be managed as Microsoft Active Directory objects, allowing good security and also making the administration of a network of portable, embedded devices a relatively familiar task for system and network administrators who already work with Active Directory in a Windows network environment.

Furthermore. Windows Embedded operating systems can also leverage Microsoft’s core development tools and platforms such as C#, Visual Basic, .NET and Visual Studio, meaning that Windows Embedded customers have access to an extremely large worldwide community of developers who already have extensive familiarity and certification in using these common development tools.

Developers can also extend the power beyond the operating system itself by leveraging Microsoft’s portfolio of server and cloud solutions to fuel Microsoft’s services approach for the Internet of Things and to provide analysis and visualisation of the data traffic from the IoT.

Microsoft’s complementary capabilities include SQL Server, System Centre, the Windows Azure platform, Forefront Client Security and Sharepoint Server, among others. The integration of these capabilities with Windows Embedded operating systems enable Microsoft to provide its own internally-developed and in-house supported structured stack of Internet of Things solutions in a way that few other companies can match.

With Windows Embedded, device manufacturers have access to familiar development tools such as Visual Studio 2012 and Expression Blend 5 that help reduce time to market, and support for a variety of security and anti-malware features ensures the solution is secure and stable.

Features like Bitlocker and compatibility with a variety of anti-malware solutions help protect the integrity of the device and the data. Other features such as Windows Secure Boot and Hibernate-Once-Resume-Many protect the device during bootup to prevent the loading of unauthorised apps and to ensure that all devices start up consistently every time, important in a remote embedded deployment where maintenance is impossible or undesirable.

The modular nature of Windows Embedded 8 Standard provides OEMs with the flexibility to tailor their solution precisely to the customer’s needs, with each component addressing a variety of aspects of the platform, including the bootable core, Windows functionality, industry-specific needs, the launching of custom shells and the use of write filters and lockdown features.

Other customisation tools include the Image Builder Wizard and Image Configuration Editor, both of which enable you to omit unwanted functionality and reduce memory requirements as well as potential security vulnerabilities that may exist in unneeded components.

As some of the tools from Microsoft are familiar with a huge proportion of software engineers, developing your IoT product or system’s embedded firmware and other code can be somewhat streamlined – leaving you with the hardware and networking design issues. This is where the LX Group can partner with you to develop any or all stages and bring your ideas to life.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

ThingWorx is a relatively new offering in the Internet-of-Things platform space, offering an Internet-of-Things and Machine-to-Machine application platform which promises very fast application development, scalability, search ability and integration with other data sources such as social media, all in a complete development and runtime platform for rapidly developing sophisticated IoT and M2M applications.

The platform provides all the necessary functionality required to get your solution to market quickly and easily. Let’s take a quick look at what the ThingWorx platform promises for Internet-of-Things developers and engineers.

ThingWorx enables rapid creation of “smart” end-to-end Internet of Things applications, when used in conjunction with hardware from various vendors, for a wide range of application markets such as smart agriculture, telematics, healthcare, “smart cities”, energy efficiency, utility metering and building automation.

The platform is aimed at the building and running of the applications of a “connected world”, reducing the time to market, cost and risk associated with building innovative Internet of Things and Machine-to-Machine applications through the use of ThingWorx’s model-based design and search-based intelligence.

Furthermore, data can be integrated from a multitude of different devices, machines and sensors that make up the “Internet of Things”, collecting, tagging and relating the resulting “Big Data” of different types, creating an operational data store that becomes more valuable over time as the quantity of data and the density of relationships within that data set increases.

ThingWorx collects, tags and relates the unstructured, transactional and time-based “data exhaust” from networks of Internet-connected sensors and devices as well as data from human collaboration, such as from social media for example. This enables your team to create dynamic Internet of Things applications that evolve rapidly as new inputs and insights become available.

Dynamic applications of this kind become more valuable the more they are used and the more data they accumulate, with that data serving as a catalyst for innovation. The ThingWorx environment includes ThingWorx Composer, a unified, model-based development environment aimed at compressing the design-develop-deploy cycle, reducing time to market and spurring easier innovation.

In addition, ThingWorx also offers their “Mashup Builder”, aimed at enabling rapid assembly of applications that integrate the data, activities and events from people, systems and the physical world, in an easily accessible “zero-code” tool that is claimed to offer developers, analysts and business users the ability to create HTML5-based user experiences, analytics and dashboards in minutes, greatly expanding the accessibility of the creation and customisation of these sorts of systems.

Composer is an end-to-end application modelling environment designed to help you easily build the unique applications of an Internet-of-Things enabled world. Composer makes it easy to model the things, business logic, visualisation, data storage, collaboration, and security required for a connected application.

The “drag and drop” Mashup Builder empowers developers and business users to rapidly create rich, interactive applications, real-time dashboards, collaborative workspaces and mobile interfaces without the need for coding experience.

This next-generation application builder reduces development time and produces high quality, scalable connected applications which allow companies to accelerate the pace at which they can deliver value-added solutions for working with Internet-of-Things data.

ThingWorx’s SQUEAL (Search, Query and Analysis) intelligence tool empowers users to search the data from people, systems and machines in their Internet-of-Things world to find what they want when they want, bringing search to the world of connected devices and distributed data.

With SQUEAL’s interactive search capabilities, users can now correlate data that delivers answers to key business questions. Pertinent and related collaboration data, line-of-business system records, and equipment data get returned in a single search, speeding problem resolution and enabling innovation.

As you can imagine, ThingWorx lets you deploy their service in exactly the way you want to to meet your needs – from deployment in the cloud to local on-premises deployment, federated or embedded deployment.

ThingWorx relies on a significant network of partner companies provide ThingWorx-approved compatible hardware and firmware solutions for Internet-of-Things applications and wireless sensor networks, while ThingWorx itself focuses exclusively on the software platform.

The growing ecosystem of hardware, software and service partners surrounding ThingWorx can be leveraged to allow more rapid innovation in a ThingWorx-based environment, including access to a huge range of sensor hardware and wireless devices to suit diverse needs.

If your organisation is considering the ThingWorx plaftorm – or other systems, our engineers are equipped with the tools and experience to bring your ideas to life. To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

When it comes to developing Internet-of-things systems, a lot of public focus is placed on the hardware and networking infrastructure required to make it a physical reality. However when designing a system, the processing and analysis of collected data requires an equal or increased effort – and anything that can make this easier or more cost-efficient is necessary.

One example of efficient data processing for the Internet-of-things can be provided by the Amazon Kinesis – a new managed service for real-time processing of streaming data at massive scale, adding big-data services to the Amazon Web Services line-up.

Kinesis can collect and process hundreds of terabytes of data an hour from hundreds of thousands of sources, allowing you to write applications that process information in real time from all sorts of different data sources.

Data can be harvested from almost anything- such as sensors and instruments, user interfaces, or other sources of data. Let’s take a quick look at Kinesis and its potential role in Internet-of-Things applications.

Kinesis service accepts real-time data, replicates it and delivers it to applications running on Amazon’s cloud, allowing applications to tap big data in real time. Real-time operations on large amounts of data made possible by Kinesis enable you to collect and analyse information in real-time, answering questions about the current state of your data without waiting.

With Kinesis, developers can get more creative about what to do with large amounts of data flowing in live, and developers building applications on Amazon’s cloud services can now more easily take advantage of sensors collecting data, which is an important development for realising the potential of large-scale analytics on data collected from Internet-of-Things networks.

This certainly makes Amazon Web Services an attractive choice for developers seeking to put large scale data collected from sensor networks to work in the cloud.

The system can be scaled elastically for real-time processing of streaming data on a large or small scale, taking in large streams of data records that can be consumed in real time by multiple data-processing applications running on instances of Amazon’s Elastic Compute Cloud (EC2).

Data-processing Kinesis applications use the Amazon Kinesis Client Library, and these applications can read data from the Kinesis stream and perform real-time processing on the data they read. The processed records can be emitted to dashboards, used to used to generate alerts, or emit data to a variety of other Amazon big data services such as Amazon Simple Storage Service (S3), Amazon Elastic MapReduce (EMR), or Amazon Redshift.

Interoperability and compatibility with existing, established Amazon cloud computing services and products is an important factor which is likely to give the uptake and usability of Kinesis a significant advantage for established Amazon Web Services users. Kinesis applications can also emit data into another Kinesis stream, enabling more complex data processing.

With Kinesis applications, you can build real-time dashboards, capture exceptions and generate alerts, output data to drive user interactions, and output data to Amazon S3, DynamoDB or other cloud computing services.

Kinesis makes it possible to respond to changes in your data stream in seconds, at any data scale – for example, in Internet of Things applications, such a response may take the form of activating a certain device or automation system in a specified way.

You can create a new stream, set the throughput requirements, and start streaming data quickly and easily. Kinesis automatically provisions and manages the storage required to reliably and durably collect your data stream.

Kinesis will scale up or down based on your needs, seamlessly scaling to match the data throughput rate and volume of your data, from megabytes to terabytes per hour.

This allows your systems to reliably collect, process, and transform all of your data in real-time before delivering it to data stores of your choice, where it can be used by existing or new applications. Connectors enable integration with Amazon S3, Amazon Redshift, and Amazon DynamoDB.

Kinesis provides developers with client libraries that enable the design and operation of real-time data processing applications – a new class of big data applications which can continuously analyze data at any volume and throughput in real time.

Kinesis is cost effective for workloads of any scale – you can pay as you go, and you will only pay for the resources you use, like with other Amazon cloud computing services. Initiall you can start by provisioning low-throughput streams, and only pay a low hourly rate for the throughput you need.

Kinesis enables sophisticated streaming data processing, because one Kinesis application may emit Kinesis stream data into another Kinesis stream. Near-real-time aggregation of data enables processing logic that can extract complex key performance indicators and metrics from that data.

Complex data-processing graphs can be generated by emitting data from multiple Kinesis applications to another Kinesis stream for downstream processing by a different Kinesis application. You can use data ingested into Kinesis for simple data analysis, real-time metrics and reporting in real time.

For example, metrics and reporting for system and application logs ingested into the Kinesis stream are available in real time, allowing data-processing application logic to work on such data as it is streaming in, rather than wait for data bunches to be sent to the data-processing applications later.

Data can be taken into Kinesis streams, helping to ensure ensure durability and elasticity. The delay between the time a record is added to the stream and the time it can be retrieved is less than 10 seconds – in other words, Kinesis applications can start consuming the data from the stream less than 10 seconds after the data is added – this is useful in applications where real-world actuation or control of automation devices needs to happen relatively quickly.

By using such a powerful and scalable system such as Kinesis, you can get the power you need without paying for surplus processing capacity – but still have reserves ready on demand. But how to get started with Kinesis and your Internet-of-things plans?

Simply join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

Contiki is a lightweight, multitasking operating system aimed primarily at memory-constrained embedded systems, wireless sensor networks, low-power networked embedded devices and the general “Internet of Things”. Contiki is resource efficient, highly portable, and it is free, open-source software.

Although Contiki is free software and its underlying source code is freely downloadable, some commercial companies such as ThingSquare provide professionally supported solutions for the deployment of Contiki-based Internet-of-Things applications and products in the commercial sector, just as is the case with the Linux ecosystem.

Designed to run on embedded hardware platforms that are severely constrained in terms of memory, processing power and communication bandwidth, Contiki still offers a multitasking kernel and a built-in TCP/IP stack, and a real-world Contiki deployment can be run on an 8-bit microcontroller, for example, with only about 10 kilobytes of RAM, 30 kilobytes of flash, a clock on the order of 10 MHz and a power budget on the order of 10 milliwatts.

Thanks to these low system requirements, Contiki has been or is being ported to many common microcontroller platforms – such as Atmel AVR, Microchip dsPIC and PIC32, TI’s MSP430 low-power microcontrollers, and ARM-based systems such as the TI CC2538.

Networking is easy with Contiki, as it provides three lightweight, memory efficient networking stacks – the uIP TCP/IP IPv4 stack, the uIPv6 stack, providing support for IPv6 networking, and the Rime stack, which is a set of custom lightweight networking protocols designed specifically for low-power wireless sensor networks.

The IPv6 stack also contains the RPL routing protocol for increased tolerance of packet loss in low-power IPv6 radio networks and the 6LoWPAN header compression and adaptation layer for IEEE 802.15.4 radio networks. Contiki is particularly well suited to use with microcontroller systems-on-chip incorporating an IEEE 802.15.4 radio transceiver on board, such as the Atmel ATmega128RFA1 family or the Texas Instruments CC2538.

Such hardware platforms, combined with Contiki, provide highly integrated, cost-efficient, power-efficient single-chip wireless sensor network or Internet-of-Things platforms with wireless IPv6 802.15.4/6LoWPAN networking support on board, allowing IPv6 internet connectivity to be routed right down to the wireless, power efficient end nodes of an Internet-of-Things network.

The Rime stack is an alternative network stack that is intended to be used in applications where the overhead of the IPv4 or IPv6 stacks is prohibitive. The Rime stack provides a set of communication primitives intended for very lightweight applications in low-power embedded wireless networks, which by default include single-hop unicast, multi-hop unicast, network flooding and address-free data collection.

These primitives can be used on their own or combined to form more complex protocols and mechanisms whilst still maintaining the most lightweight mechanism possible to perform the networking task required.

Contiki also provides a set of mechanisms for reducing the power consumption of the system on which it runs, including the ContikiMAC radio duty cycling protocol for improving power efficiency in radio-networked platforms, keeping the radio powered down or running in a low-power mode for as much time as possible while still being able to receive and relay network messages.

These mechanisms enable powerful Contiki-based solutions in severely power-constrained environments such as battery-operated wireless sensor network devices that are expected to operate unattended for long periods of time without battery maintenance or replacement.

To run efficiently on memory-constrained systems, the Contiki programming model is based on protothreads, which are thread-like memory-efficient programming abstractions that share features of both multi-threading and event-driven programming to attain a low memory overhead.

The kernel invokes the protothread of a process in response to an internal or external event. Examples of internal events are timers that fire or messages being posted from other processes, whilst examples of external events could include external interrupts that are triggered by external sensor inputs, or radio-triggered interrupts created by incoming packets on the wireless network.

These protothreads are cooperatively scheduled, meaning that a Contiki process must always explicitly yield control back to the kernel at regular intervals. Processes may use a special protothread construct to block waiting for events while yielding control to the kernel between each event invocation.

Contiki supports per-process optional pre-emptive multi-threading, interprocess communication using message passing through events and an optional GUI subsystem with either direct graphic support for locally connected terminals or networked virtual displays via VNC or Telnet. However, the use of a graphical user interface does increase memory requirements a little, from a minimum of 10 kilobytes of RAM up to a minimum of about 30 kilobytes of RAM.

The Contiki system includes a network simulator called Cooja. The Cooja Contiki Network Simulator simulates networks of nodes running Contiki which may belong to one of three classes – emulated nodes, where the entire hardware of each node is emulated, Cooja nodes, where the Contiki code for the node is compiled for and executed on the simulation host, or Java nodes, where the behaviour of the node must be reimplemented as a Java class.

A single Cooja simulation may contain many nodes from a mixture of any or all of the three classes. Emulated nodes can also be used to include non-Contiki nodes in a simulated network environment. Cooja can also be used to simulate real-world physical effects in large wireless mesh networks, such as packet loss and network degradation in RF networks.

With the combination of low-powered embedded wireless hardware, Contiki and the tools included – you have the foundation for a scalable, efficient and contemporary Internet-of-things.

To get started with your own ideas and Contiki, or to explore other options to solve your problems – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

Without too much fanfare another Internet-of-Things platform has been introduced to the market which deserves some exploration. Called XOBXOB (pronounced “zob-zob”), it is claimed to provide users with an easy to use Internet platform for building distributed networks of devices that communicate with the Internet and with each other.

XOBXOB is aimed particularly at ease of use in conjunction with Arduino or Arduino-compatible platforms, providing a cloud service for “Simple Internet for Things” in conjunction with the Arduino environment.

XOBXOB can be used in conjunction with an Arduino or compatible and Ethernet Shield, a Roving Networks WiFly module, or any Arduino-compatible hardware connected to a PC. If you don’t have any appropriate Ethernet or Wi-Fi connected hardware suitable for use with XOBXOB then the Arduino can use a downloadable “Connector”.

This is a small application from XOBXOB, available for Windows, Linux or OSX, which provides Internet connectivity between the XOBXOB service and your microcontroller board via your PC, without requiring the use of embedded Ethernet or Wi-Fi hardware.

Getting started with XOBXOB requires a physical thing, like an Arduino, or a virtual thing, like a web browser running on a smartphone or PC. Although you can get started with only one thing, XOBXOB is more interesting to get started with if you have multiple things that can talk to each other via XOBXOB, such as both an Arduino and a smartphone.

Although it’s easiest to get started with XOBXOB using an Arduino, you do not have to use an Arduino. More experienced users can use XOBXOB’s RESTful API to implement XOBXOB connectivity for essentially any device that can connect to the Internet.

Furthermore, the XOBXOB team continues to work on libraries and sample projects to make it easy to use other popular embedded computing platforms and single-board computers such as BeagleBone and Raspberry Pi.

Once you’ve got suitable hardware, you can register for an account on the XOBXOB website and get the private API token from your XOBXOB dashboard. You’ll also need to download and install the XOBXOB Arduino library.

XOBXOB makes it very easy to get started by including simple examples in the XOBXOB Arduino sketch library, such as a basic Internet-connected LED control program, using the XOBXOB service to control a LED (or any digital device) remotely via the Web.

These basic examples provide a quick way to test the network connectivity between your Arduino, your LAN and the Internet. When getting started with a XOBXOB Arduino sketch, remember that you’ll need to put your private XOBXOB API token (available via the XOBXOB dashboard) and the MAC address of your Ethernet device into the Arduino sketch.

There are three different libraries to use, depending on whether you’re using an Ethernet-equipped Arduino, a WiFly-equipped Arduino, or an Arduino connected to a PC with the Connector software.

With this example, you can then use the on/off panel on the XOBXOB dashboard to set the state of the LED on or off, and then click “SET”. You can also do a “GET” to retrieve the status of the digital output, which is useful if multiple users are controlling the state of the system. These kinds of set and get methods are likely to be familiar to users with some Java or other object-oriented programming experience.

More advanced example code is also included, for example to allow you to demonstrate Internet-connected control of a MAX7219-based 64-pixel LED display via the XOBXOB cloud service.

You can also send serial data to the microcontroller, for example, from a smartphone or any device with a web browser, anywhere in the world, connecting your physical world to the web in a very accessible way.

These more advanced examples are still simple to use and fast to get started with – you can use the XOBXOB service and XOBXOB’s sample projects and resources to get an elaborate demonstration of cloud-based control of a LED display or other device up and running in minutes.

The functions of the XOBXOB Arduino libraries are well documented in XOBXOB’s Arduino library guide, making it easy to move past the basic examples provided and implement XOBXOB connectivity for your own specific application.

For example, your Arduino code can control whatever you want to happen in the handler that corresponds to the ON/OFF button being used on the XOBXOB dashboard. XOBXOB works by creating small “mailboxes” called XOBs. To control additional devices from your XOBXOB dashboard, you create a new device in the dashboard, and give it a name.

Your Arduino code then needs to request that XOB by name in the “requestXOB” function, meaning that it will respond to that device on the cloud side when needed – multiple different devices can be independent of each other, or they can talk to each other if you like.

Your physical things can send and receive messages through a XOB, and by sharing XOBs, things can send messages to each other. In this regard, XOBXOB is a true Internet-of-Things platform, allowing machine-to-machine communications with packets of data travelling between connected devices.

The machine-to-user control and communications provided by the Web interface is only a part of the overall system – it is not just providing Web-based datalogging of temperature or other data collected from the hardware devices, it also provides the capability for machine-to-machine communications and basic bidirectional control of the hardware from the Web service.

Although the platform is skewed towards the Arduino-compatible hardware platform, this is still perfectly acceptable for a wide range of products and allows for rapid development due to the open-source nature of the platform. This allows us to bring your IoT product ideas to market in a much shorter period of time.

To find out if XOBXOB is an ideal fit, or to explore other options to solve your problems – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

Today, Internet-of-Things networks (and, more generally, Wireless Sensor Networks, which are wirelessly networked but not necessarily Internet-connected) are finding use in an increasing range of consumer, industrial and medical applications. Such networks often employ a large number of distributed nodes without interconnecting wires, which can’t practically be connected to the power grid, and therefore it is attractive to keep the need for battery recharging and replacement to an absolute minimum.

This can be achieved with the use of efficient, careful battery design choices as well as ambient energy harvesting technology to self-power small, efficient wireless network nodes from energy sources such as light, waste heat and vibration in the environment and highly energy-efficient design practices both at the hardware and software layers to keep the overall need for power to a minimum.

For some systems it is practical to use batteries alone – 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.

When it comes to choosing different battery chemistries for a particular application environment, non-rechargeable alkaline batteries are very cheap, widely available and are ideal for low-current applications at room temperature.

If a particular application system consumes very little power then it may be economically viable to choose disposable alkaline batteries that require user replacement once or twice a year.

Alkaline batteries do have two major disadvantages – poor low-temperature performance and relatively limited high-current performance. The available current from an alkaline battery is limited significantly in cold-weather environments, and at high discharge currents the total energy capacity available from the battery is limited.

Non-rechargeable lithium batteries tend to offer substantially increased performance at low temperatures as well as higher discharge current capability.

When it comes to rechargeable batteries, nickel metal hydride (NiMH) cells are the workhorse chemistry of modern rechargeable batteries, with a better lifetime across many charge and discharge cycles without the “memory effect” that affects nickel-cadmium cells.

A typical NiMH cell will have a cell voltage of 1.2 volts instead of the usual 1.5 volts expected from an alkaline battery – this may be significant in some designs but is generally acceptable. Despite this, NiMH batteries generally perform better than alkaline batteries at low temperatures and don’t decline quite as quickly as current draw increases, as well as providing the benefit of being rechargeable.

Lead-acid batteries can provide very high discharge currents for demanding applications such as mechatronics, with good energy density, but can perform poorly at low temperatures and can be subject to permanent damage through cell sulfation if they are kept discharged for any significant length of time.

Lithium-ion cells provide good energy density and many convenient cycles of repeated charge and discharge, but this battery chemistry requires precise control to avoid over-discharge or over-charge conditions which can permanently damage the battery. Despite their risk of fire and damage if mishandled, lithium-ion batteries provide very good discharge current capability, good energy density, and the ability to survive many repeated charge cycles, embedded inside devices which are charged and used without their battery ever being removed or replaced.

Power-efficient wireless sensor nodes can take advantage of some form of energy harvesting power supply, employing energy sources such as solar photovoltaics, vibrational energy harvesters or thermoelectric generators to minimise maintenance and extend battery life – possibly completely eliminating batteries entirely, if the power consumption of the system is small enough and a capacitor is employed for energy storage.

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

In many applications, solar photovoltaics are the most familiar, relatively mature choice for low-power network nodes operating outdoors, for example in agricultural and meteorological instruments. 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.

Solar photovoltaics are 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 lightweight wireless network node consisting of a microcontroller, sensors and an embedded low-power radio such as an 802.15.4 system.

However, solar power is intrinsically intermittent and is only available for a fraction of the day, on average. 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.

At this point you may start to wonder what the most appropriate power solutions are for your IoT or other products, and it’s no secret that the options are wide and varied. However the success of your product is predicated on its usability and thus autonomy from mains power.

For more guidance on this matter, from consulting to total product design from idea to delivering to the end user, the LX Group can be your partner in success. To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

JSON, or JavaScript Object Notation, is a lightweight open standard format that uses human-readable text to transmit data objects in the form of pairs of attributes and values. It is used primarily to transmit data between a server and a web application as an alternative to formats and languages such as XML for lightweight, flexible formatting of data for Internet communication in a way that is both machine-readable and human-readable.

Let’s look briefly at how JSON can be used, how it compares to XML (Extensible Markup Language), and the role JSON can play as a lightweight format for information transport in Internet of Things and embedded applications. In an Internet-of-Things application, every “Thing” connected to the network should have an API that allows access to key data elements.

This data needs to be streamed at an appropriate rate over the Internet to a server directly, or to a gateway or other device in the local network. Near-real-time access to sensor data at the gateway or at the server allows contextual information derived from that data to be served up in a timely manner, so minimising network overheads is clearly valuable.

Although originally derived from the JavaScript scripting language, JSON is a language-independent data format and code for parsing and generating JSON data is readily available in a large range of programming languages, making it easy to get up and running with the language of your choice. JSON objects are human readable – they are basically freeform text documents. Whilst JSON objects contain rich information and are a highly flexible way to represent data, they are easy for programmers and database administrators to use.

XML is well established as a language of choice to describe structured data and to serialise objects, and various XML-based protocols exist to represent the same kind of data structures as JSON for the same kind of data interchange purposes. When data is encoded in XML, the result is typically larger than an equivalent encoding in JSON, mainly because of the presence of closing tags in XML.

While the API is a key consideration in implementing a RESTful solution for moving around and accessing your data, the format of the payload is also equally as important. XML is one traditionally popular language in these sorts of applications, but JSON is not as verbose as XML and does not contain detailed processing instructions. Being a more lightweight data interchange format, it is faster to use JSON to send bits of data, such as data from a sensor for example, around the Internet of Things.

JSON is promoted as a lower-overhead alternative to XML, providing similar data exchange capabilities with support for creation, reading and decoding of data in the real world with lower overhead. The increasing popularity of REST over SOAP in modern APIs also promotes greater use of and support for JSON as the preferred data exchange format, since you are no longer limited to only returning XML.

JSON-RPC is an RPC protocol built on JSON, as a replacement for XML-RPC or SOAP. It is a simple protocol that defines only a handful of data types and commands. JSON-RPC allows for notifications – information sent to the server that do not require a response – and for multiple calls to be sent to the server that may be answered out of order. This flexibility in choosing messaging options to get the data where it is needed with the priority that is needed in the most lightweight possible way is attractive in resource-constrained and bandwidth-constrained Internet-of-Things networks or embedded systems.

Modern web browsers incorporate native JSON encoding and decoding, increasing performance due to the fact that functions no longer need to be parsed as well as eliminating potential security vulnerabilities where JSON is evaluated as Javascript. Native JSON is generally faster compared to the JavaScript libraries used in the past to parse JSON, as well as more secure.

As an example of JSON in use for an existing embedded Internet-of-Things solution, the “Razberry” platform. This adds the hardware required for the Z-wave wireless home automation protocol to the Raspberry Pi single-board computer, turning an inexpensive device into a Z-wave home automation gateway and exposing control of your home automation network via a JSON interface.

Furthermore Google BigQuery added support for JSON a few years ago, explicitly mentioning the potentially useful role of JSON in connecting data collected from sensor networks and the Internet of Things to BigQuery, bringing the power of Google’s Big Data manipulation expertise together with the Internet of Things and sensor networks as the sources for that Big Data.

JSON is one of many tools available in the Internet-of-things toolbox, and can easily be used with many applications. And here at the LX Group our engineers have an excellent understanding of the standards required for effective communciation between devices within Internet-of-things platforms, and are ready to integrate it with your new and existing products.

To get started, join us for 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.

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 Special Interest Group has recently announced the publication of the Bluetooth 4.1 Specification with some interesting improvements to the standard, which greatly increase the usability of this wireless technology in devices for the “Internet of Things”, which offers new applications that allow such devices to serve as both hub and peripheral devices.

This paves the way for Bluetooth 4.1-enabled devices such as sensors to connect directly to the Internet. It also allows devices such as fitness dataloggers and headsets to collate data from sensors such as temperature sensors and heart rate monitors over Bluetooth networks then report back to a smartphone or tablet with their collected data. In turn, those devices could be used as sensors that other devices can communicate with and pull data from.

This new profile is the first major update of the Bluetooth specification since version 4.0 was released in 2010, including the Low Energy specification, a subset of version 4.0. The version 4.1 updates are all software related, so it is possible for over-the-air firmware updates to upgrade existing Bluetooth 4.0 systems with new firmware, with no hardware changes or replacement, to make them Bluetooth 4.1 compatible.

Bluetooth 4.1 adds support for bulk data transfers at higher data rates, so that information collected from sensors over a period of time can be downloaded in bulk from multiple sensors. Bluetooth is still a low data-rate protocol compared to, say, Wi-Fi or Ethernet, but as Bluetooth is expected to handle ever-larger streams of data from embedded sensors this is a useful improvement – downloading data from sensors to a datalogging appliance might take, say, a few seconds instead of 10 or 20 for existing systems.

Bluetooth 4.1 allows Bluetooth devices to act as both a peripheral device and a hub at the same time, allowing a Bluetooth device that may have previously been networked with a smartphone or tablet to itself act as hub for other Bluetooth peripheral devices.

For example, your Bluetooth 4.1 enabled smart watch might be able to grab weight information logged from a Bluetooth-enabled scale and display it for you as well as being able to pass that data along to a smartphone. Bluetooth 4.1 also adds improvements to the sleep-wake cycle of the Bluetooth radio, allowing Bluetooth devices to automatically connect more easily (if allowed) without manual intervention.

Another example could be a bathroom scale that can automatically connect and download the distance walked from your Bluetooth-enabled pedometer or exercise tracker when you walk into the bathroom.

Bluetooth 4.1 improves coexistence between Bluetooth devices and 4G Long Term Evolution (4G LTE) cellular devices, to prevent potential interference. Although this is not a significant problem for Bluetooth 4.0 devices today this was considered to be a potential problem in future as more and more Bluetooth 4.0 devices are in use, talking to 4G connected smart-phones or tablets.

The new specification also increases the time-out period between devices, so that removing a Bluetooth device (such as your phone, for example) outside the proximity of another Bluetooth device it is connected to for a short moment and then back again may not mean that the Bluetooth connection has to be reconnected, improving user experience.

Furthermore it also lays the groundwork for IP-based connections between Bluetooth devices, in the same way a Wi-Fi router connects to multiple Wi-Fi devices, giving Bluetooth devices a way to talk directly to the Internet. Plus version 4.1 adds a standardised way to create a dedicated channel which could be used for IPv6 communications over Bluetooth in the future, enabling the possibility of native IPv6 networking from the Internet down to the LAN right down to wireless sensor nodes, in a similar way to how 6LoWPAN enables this type of connectivity for 802.15.4 wireless networks.

However, adding IPv6 connectivity to Bluetooth devices may substantially increase the power budget of battery-operated devices, especially Bluetooth Low Energy devices designed for extreme power efficiency, so this may not be an appropriate choice in all cases.

Such Internet connectivity directly to Bluetooth devices opens up interesting potential for the future development of Bluetooth, for example phone calls made over VoIP directly to a person’s Bluetooth headset, or the remote viewing of health data from medical sensor devices by healthcare professionals.

These improvements to the Bluetooth standard, such as IPv6 support, the ability to act as a hub instead of only as a peripheral, better radio sleep-wake cycles, timeout changes and improved data rates make Bluetooth 4.1 easier to use in the development of networks of wireless, power-efficient networked devices that aren’t intended to always be paired directly to a single Bluetooth enabled smartphone or tablet – in other words, Internet-of-Things networks and devices.

As you have just read, the new Bluetooth profile offers a great amount of promise in terms of functionality and convenience for the end user. Here at the LX Group our engineers have an excellent understanding of many wireless platforms – including Bluetooth – and are ready to integrate it with your new and existing products.

To get started, join us for 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.

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 new ZigBee Smart Energy 2.0 (SEP2.0) ZigBee Application Profile brings with it powerful new ZigBee capabilities for smart energy metering and control networks. With its ability to transport rate, demand, and load management messages to and from networks of smart energy appliances and the “Smart Grid” across a wide variety of wired and wireless media, the profile promises to be a key element of residential energy management systems.

Capable of passing energy-related messages across a HAN, or Home Area Network, using numerous different types of wired or wireless physical media, SEP2.0 is aimed at enabling the next generation of interactive smart appliances, HVAC, lighting and energy management systems – a “Smart Grid” of energy-efficient technology.

An IP-based HAN enabled by ZigBee Smart Energy 2.0 makes it possible to manage every aspect of the energy consumption and production of a home or building, whilst moving the information around a network built entirely around the Internet Protocol and interconnected with existing networks and the Internet.

The ZigBee Smart Energy 1.0/1.1 Profile was originally developed to allow 802.15.4/ZigBee low-power wireless mesh networks to support communication between smart meters and products that monitor, control and automate the delivery and consumption of electricity – and potentially other household utilities such as gas and water, moving into the future.

The functionality of the Smart Energy 1.x Profile was primarily intended to support the functional requirements of smart meters being used by electricity, gas and water utilities to manage their distribution networks, automate their billing processes, and communicate with customers’ energy management systems.

ZigBee-enabled smart meters act as communications gateways between the utility and the consumer, enabling the exchange of messages about pricing, demand response and peak load management. At least this technical capacity exists in theory, but electricity retailers will only bother with it if they have a revenue model in implementing such technology.

The ZigBee Smart Energy 2.0 Profile was created in response to the need for a single protocol to communicate with the growing universe of energy-aware devices and systems that are becoming common in homes and commercial buildings. For that reason, a diverse range of Function Sets were defined under SEP2.0, including Demand Response and Load Control, Metering, Billing, Pre-Payment, Directed Messaging, Public Messaging, Price Information, Distributed Energy Resource Management and Plug-in Electric Vehicle Management.

One or more of these Function Sets can be used to implement one of the Device Types defined in SEP2.0, such as Meters, Smart Appliances, Load Controllers, Smart Thermostats, In-Premises Displays, Inverters and Plug-in Electric Vehicles to name just a few.

ZigBee Smart Energy 1.x access the MAC/PHY layers of the 802.15.4 radio hardware via the ZigBee Pro protocol stack, but SEP2.0 replaces the ZigBee Pro protocol stack with the ZigBee IP stack, which uses the 6LoWPAN protocol to encapsulate the proprietary ZigBee packet structure within a compressed IPv6 packet. At the transport layer, IP packets bearing messages containing standard ZigBee command and data packets are exchanged using the familiar HTTP and TCP protocols.

When used in combination with the SEP2.0 Application Profile, the ZigBee IP stack provides a media-independent interface between the network and MAC layers of the stack that allows SEP2.0 packets to be carried across nearly any IP-based network.

A recent version of SEP2.0 includes support for communication across ZigBee and 802.11 wireless LANs as well as powerline communication (PLC) networks. SEP2.0 will also have improved future support for 802.15.4g, where the physical layer of the ZigBee/802.15.4 network is a sub-gigahertz radio at, say, 900 MHz for long-range outdoor telemetry or environments where the 2.4 GHz spectrum is congested. Support is also improving for other popular network technologies such as Ethernet.

Amongst the first SEP2.0 enabled products to hit the market will be Energy Service Portals (ESPs) which serve as a bridge between an energy utility’s communication infrastructure and the IP-based Home Area Network. These portals are provided to consumers by utility companies, and use the SEP2.0 Energy Services Interface profile to provide a bridge between the SEP1.x protocol used by most existing smart meters and the home’s IP-based network.

A ZigBee-enabled home energy management system can employ multiple Application Profiles to provide unified control of all home energy systems. For example, a smart home energy management system may use the Smart Energy (SE) profile to pass the utility’s load management and demand response messages to the home’s major loads and energy sources.

The Home Automation (HA) and RF for Consumer Electronics (RF4CE) profiles may then be used to communicate with Smart Appliances, lighting systems and other consumer-controlled products. Energy-aware homes will also employ a large number of end-point applications such as smart thermostats, in-home energy displays (IHDs), and tablet-based control panels that use SEP2.0-enabled ZigBee or Wi-Fi radio links to communicate with the home’s ESI and other elements of its energy management system.

SEP2.0-equipped network endpoints may also be implemented with the physical layer of the network using power line communications, networking smart appliances without RF spectrum congestion.

The ZigBee Alliance has created well-defined provisions for interoperability with, and upgrade paths from, the earlier SEP1.x standard to SEP2.0, which is good news for engineers looking to upgrade or to interoperate with existing SEP1.x technology. There is no significant increase in the processing power required in your hardware, although the key generation and exchange functions in the SEP2.0 security layer may be tough for 8-bit microcontrollers to handle unless they have security acceleration capability, handling the cryptographic maths in dedicated hardware.

Unfortunately, in terms of memory, SEP2.0 and the applications it supports require significant increases in both flash and RAM over what is required for most SEP1.x applications. Storing the code for a SEP1.x stack, a small application profile and a simple user application requires roughly 160 kb of flash in a typical microcontroller, plus 10-12 kb of RAM. Implementing comparable functionality under SEP2.0 requires about 256 kb of flash and 24-32 kb of RAM.

As an example of an existing hardware reference solution targeting SEP2.0, Texas Instruments provides an example consisting of the CC2533 802.15.4 RF system-on-chip, which runs the MAC/PHY layers of the SEP2.0 stack on its built-in 8051 core, combined with one of TI’s ARM7 Stellaris 9000-series microcontrollers as the application processor, running the remainder of the network stack and the application code.

Most of the microcontrollers in this powerful family include a fully-integrated Ethernet MAC, CAN interface, USB host controller, and enough memory and processing power to implement many simple SEP2.0 applications.

It is also worth considering some of the highly integrated single-chip solutions on the market such as the Texas Instruments CC2538, which integrates a 2.4 GHz 802.15.4 radio, ARM Cortex-M3 32-bit microcontroller core, hardware security acceleration for SEP2.0 and plenty of flash and RAM to support the ZigBee IP stack, SEP2.0 profile and application code with support for over-the-air firmware flashing capability for updates in the field, all in a single chip.

As you have just read, the new profile offers a great amount of promise in terms of functionality and convenience for the end user. Here at the LX Group our engineers have an excellent understanding of the Zigbee platform and have put this to use to create various systems for a wide range of customers – and we can do this for you too.

To get started, join us for 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.

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