All posts tagged: internet

The Pinoccio platform is based around the Pinoccio “Scout” board – a small, inexpensive microcontroller development board based on the Atmel ATmega256RFR2 microcontroller with built-in 802.15.4 2.4 GHz radio, aimed at quick and easy development of wireless, mesh-networked systems and projects without worrying about common challenges such as efficient battery power management, FCC certification and mesh networking protocols.

This hardware offers an integrated Web platform and API so you can easily get started talking to the Web with your project right out of the box, and a built-in lithium polymer battery on every board that is recharged via the same micro-USB port used for programming, with a battery runtime from days up to over a year depending on the software configuration and how the microcontroller and radio are used.

Pinoccio aims to provide an inexpensive but powerful, FCC-certified, power-efficient, mesh-networked and Internet-ready platform for easily accessible Arduino-style development, wireless sensor networks and Internet-of-Things experimentation.

A network of Pinoccio nodes are connected together via a lightweight 802.15.4 mesh network, using the 802.15.4 radio incorporated in every board to network with any other board that shares its Personal Area Network (PAN) ID.

At one or more nodes in the network, the Pinoccio node is equipped with a Pinoccio Wi-Fi board, based on the Gainspan GS1011MEPS 802.11 WiFi module, that connects the 802.15.4 mesh network to your wireless LAN. This means that every Pinoccio node is connected to the LAN and to the Internet, but with a substantially cost and substantially lower power consumption than would be needed if every node in the network was equipped with an 802.11 wireless LAN chipset.

The ATmega256RFR2 draws less than 20mA of current with its microcontroller and RF transmitter running during active transmission – about 10% of the current consumption of a typical Wi-Fi device. The ATmega256RFR2 can be put into sleep states with far lower power consumption as well, with “wake-on-radio” capability to wake up the microcontroller when the wireless network indicates.

With a WiFi connection on at least one node, every Pinoccio board in the mesh network is connected to the Internet. Routing between nodes is supported, so if board A and board C are out of reach of each other, but they can both reach a board B, then B will route packets for A and C to reach each other.

Even if one of the Scouts is out of WiFi range, the others will route its data up to the Web. Pinoccio uses a lightweight mesh networking stack by default – not ZigBee, for example, although there is no reason why advanced users can’t deploy a ZigBee stack on the Pinoccio hardware if they wish.

This coordinator-less mesh network stack is a lightweight alternative to coordinator-based network architectures. Several network configurations are possible, including the traditional coordinator/router/end-node, as well as a completely decentralised peer-to-peer mesh network with routing.

All Pinoccio Scout nodes can be programmed wirelessly, over the air, in a way that is fully compatible with the Arduino IDE – each node in the 802.15.4 network simply appears, with the Pinoccio networking software installed, as a virtual Arduino-compatible serial port in the Arduino IDE.

Without WiFi connectivity, however, users do still have the option of programming each board directly from a PC, via the USB port, just like any Arduino-compatible device, and more advanced users can talk to the chip via traditional hardware interfaces like ISP and JTAG.

You can have your Pinoccio boards scattered all over an area on a wireless mesh network, each doing their thing, and when you need to update the code on one, some, or all of them you can just do so wirelessly from your computer.

If you have Pinoccio boards within an installation, which are difficult to get to, you can easily update their software over-the-air, post-installation, offering a level of convenience that is hard to achieve with other microcontroller development platforms.

You can update a range of boards by listing several of them, or send an update to all boards in the network at once, sending out a single update broadcast. A single update could be sent out to 100 Pinoccio boards if they all need to be updated, and they would all receive the broadcast and update themselves.

The real value of the Pinoccio platform doesn’t just come from the Pinoccio Scout boards, but from the entire stack – from the physical hardware to the API and Web service and back. This includes features like over-the-air firmware updates, optimised mesh networking and the ability to easily move data between multiple Pinoccio boards across the mesh network, to the Web and back again.

Along with easy routing, discovery and beaconing, provisioning a new Pinoccio WiFi bridge node to the larger Web, and the use of low-bandwidth-friendly protocols like MQTT, Pinoccio is a platform that provides a high level of openness and interoperability.

Pinoccio is aimed at being very easy to use, power efficient, Arduino compatible, and completely open source, providing a complete end-to-end ecosystem for building the Internet-of-Things, but with open standards and without proprietary lock-in.

The Pinoccio API completes the last mile between your network of Pinoccio hardware and the Web, allowing you to send and receive messages between your board and the API. However, using the Pinoccio API is totally optional – you own your data, and you can run your own web server to talk to your Pinoccio devices if you wish. Every Pinoccio board can have its own REST-based URL, and it can respond to HTTP POST and GET requests, with the 802.15.4 mesh network and the WiFi bridge doing all the routing for you.

Pinoccio aims to support websockets and webhooks, allowing easy connectivity with Web services, and saves and logs all the data pushed to the API from your devices.

Unlike some other options on the market such as Electric Imp, Pinoccio offers a pre-baked end-to-end platform and Web service with a tightly integrated web-hardware experience to allow everybody to easily, quickly get up and running with a network of devices talking to a Web service – without locking you in and forcing you to only use their servers and Web services with their hardware.

The Pinoccio Scout is open-source hardware – you can download the hardware schematics, board layout and bootloaders freely. Pinoccio strives to use open, industry-standard protocols that are standardised by groups such as IETF and OASIS where possible.

Pinoccio currently uses MQTT as the core messaging protocol for the Pinoccio API on top of Atmel’s Lightweight Mesh Protocol and the IEEE 802.15.4 MAC and radio physical layer, and is considering moving towards 6LoWPAN and RPL in future once these standards are more mature and more work is done in this area in the IETF working group.

One vision of future work that the Pinoccio team has is to have each board accessible from the Internet with a unique IP address, using IPv6/6LoWPAN and a WiFi bridge at one node. Shying away from non-standard protocols, Pinoccio supports HTTP and MQTT-S (MQTT for Sensor Networks) out of the box – but, again, without locking you into any particular choices, if you’re willing to put a bit of work in yourself to implement other protocols.

Pinoccio has good security capability available in every part of the network stack, which is attractive for automation networks and Internet-of-Things applications. The ATmega256RFR2 microcontroller has hardware-based AES128 encryption, along with a true hardware random number generator.

It’s simply a matter of defining a shared secret in your code to enable encryption for the entire mesh network. With the support for TLS sockets in the Pinoccio WiFi module, complete encryption is supported from the device to the Web.

Although still in the beta stage, the Pinoccio system holds great promise as an inexpensive and open mesh networking system which could be applied to new or existing IoT-enabled products.

If this is of interest, or you need guidance for any or all stages of product design – the first step is to discuss your needs with our team of experienced engineers that can help you in all steps of product design, from the idea to the finished product.

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.

Constrained Application Protocol, or CoAP, is an application-layer networking protocol aimed primarily at application in networks of small resource-constrained embedded devices, wireless sensor networks and similar Internet-of-Things applications – helping to enable efficient networking and Internet connectivity with low overheads.

This protocol is particularly well suited to low-power wireless sensor networks with lossy networking and embedded control and automation systems, where such systems need to be supervised or controlled remotely via standard Internet networks.

CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialised requirements such as multicast support, very low overhead, and simplicity. These are valuable, important features for Internet-of-Things and machine-to-machine networks which tend to be deeply embedded and have much less memory and power available than traditional Internet-connected computers and mobile devices, meaning that efficiency and low overheads are important.

Furthermore CoAP enables embedded web services for even the most constrained devices and networks, while integrating with the web architecture and HTTP. Optimised for applications such as smart energy, home and building automation, asset tracking and cellular M2M, CoAP is emerging as an increasingly popular and important, standardised and interoperable technology in the Internet-of-Things sector.

CoAP includes several HTTP-like functionalities, but they have been fundamentally redesigned for operation in resource-constrained Internet-of-Things and embedded networks. Like HTTP, CoAP identifies resources using a universal resource identifier, and allows resources to be manipulated using HTTP-style methods such as GET, PUT, POST, and DELETE.

The protocol’s transaction layer can include four types of messages: confirmable, where acknowledgement is required, non-confirmable, where acknowledgement is not required, acknowledgement for a confirmable message, or reset, which indicates that a confirmable message is received but the information that would provide the context to allow it to be processed is missing.

CoAP makes use of two message types, requests and responses – using a simple binary header format that is not demanding to parse, and it is at this request/response layer where the REST-based communication occurs. This request/response model may be contrasted with other models such as the publish/subscribe model employed by other significant transport protocols in Internet-of-Things technologies, such as MQTT.

The base header may be followed by further options in an optimised Type-Length-Value format. CoAP is bound to UDP by default and optionally to datagram transport layer security or DTLS, meaning that CoAP can run on many common devices that support UDP or a UDP analogue, whilst providing the optional capability for secure CoAP, which mandates the use of DTLS as the underlying security protocol, providing the potential for good security in applications where authentication and security is an important requirement.

The Internet Engineering Task Force’s Constrained RESTful environments (CoRE) Working Group has done the majority of formal standardisation work with CoAP so far, with a set of IETF Requests for Comments soon to be released surrounding CoAP standards. The standardisation of CoAP by the IETF is in its final stages, and the protocol is soon entering into IETF Internet Standards documents that are aimed at standards-building to better enable the Internet of Things.

In order to make the protocol best suited to Internet-of-Things and and machine-to-machine applications, various new functionalities have been added. The CoRE working group has proposed low header overhead and low parsing complexity as key goals of the CoAP standard-building effort, along with support for the discovery of resources provided by known CoAP services, and mechanisms for simple subscription to a resource and resulting push notifications from that resource.

The mapping of CoAP with HTTP is defined, with RESTful protocol design, allowing proxies to be built to provide access to CoAP resources via HTTP in a uniform way without difficulty.

Access to CoAP resources via RESTful HTTP over TCP is particularly attractive for connecting embedded devices in consumer premises to the Internet, given the near universal availability of HTTP stacks for various diverse platforms.

The RESTful HTTP approach has found success in smaller-scale networks, particularly low-power and lossy wireless networks where message latencies are required to be within the order of seconds, for example for home automation and smart energy management networks.

As some examples of significant adoption of CoAP by major commercial players in the emerging Internet-of-Things industry, CoAP has already found success as a key enabling technology for Advanced Metering Infrastructure (AMI) applications for electricity utility companies deployed within Cisco Systems’ Field Area Network ecosystem.

Sensinode’s NanoService solution uses CoAP, together with their semantic web linking, resource directory and EXI technology, to provide end-to-end embedded web services for the Internet of Things.

If CoAP appeals as a protocol for your next IoT-enabled product or design revision – or you’re interested in any or all stages of the process and need a partner to help meet your goals – the first step is to discuss your needs with our team of experienced engineers that can help you in all steps of product design, from the idea to the finished product.

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.

XMPP or the Extensible Messaging and Presence Protocol, formerly known as Jabber, is a communications protocol based on XML (Extensible Markup Language), aimed at message-oriented middleware and applications such as near-real-time instant messaging and presence information. XMPP is designed to be extensible, and has been used for publish-subscribe systems, file transfer, and communication in embedded Internet-of-Things networks.

As XMPP is defined as an open standard and uses an open systems approach of development and application – anyone may implement an XMPP service and interoperate with other implementations. And thanks to its open protocol, XMPP implementations can be developed using any software license and many implementations of the XMPP standards exist for clients, servers, components and code libraries – both open-source and proprietary.

XMPP is well supported as an open standard under ongoing development by standards-makers and organisations such as the Internet Engineering Task Force, which formed an XMPP working group in 2002 to formalise the core protocols of XMPP. No royalties are required to implement support of these specifications and their development is not tied to any single vendor.

In addition to these core protocols standardised by the IETF, the XMPP Standards Foundation (formerly the Jabber Software Foundation) is active in developing open XMPP extensions, including a new series of extensions aimed at allowing Internet-of-Things communications of sensors and actuators using XMPP.

Furthermore, the IEEE is working to define a “Standard for a Smart Transducer Interface for Sensors, Actuators and Devices – Extensible Messaging and Presence Protocol (XMPP) Standard for Networked Device Communication” which, with the backing of the IEEE behind it, is likely to be an influential new standard.

Another advantage of XMPP is that it offers good security, since private XMPP servers can be isolated from the public Intranet, for example on a company Intranet, and strong SASL and TLS security is built into the core XMPP specifications.

The XMPP protocol uses a decentralised client-server architecture where clients do not talk directly to one another, but there is no central server either. By design there is no central authoritative server, but anyone can run their own XMPP server on their own domain or intranet.

Because XMPP uses the XML text format, interfacing machine-to-machine Internet-of-Things networks to machine-to-person communications, where needed, comes naturally.

XMPP features such as federation across domains, publish-subscribe communications, strong authentication and security and XMPP’s name-domain addressing scheme, which helps to navigate the huge breadth of the Internet to get the data where it is needed, are being used to develop XMPP as a powerful tool for implementing the Internet of Things.

XMPP’s easy addressing of a device is especially useful if the data going to or from a device is going between distant, mostly unrelated points, just as in the traditional person-to-person case of XMPP-based instant-messaging communication.

Most XMPP implementations use polling, or checking for updates only on demand. A protocol called BOSH (Bidirectional streams over Synchronous HTTP) lets servers push messages. However, XMPP is not designed to be extremely fast, and XMPP’s idea of near-“real time” communication is close to “real time” on human scales, on the order of a second.

Whilst consideration of timing is important in the choice of Internet-of-Things protocols, this sort of timing is suitable for most applications and is comparable to the timing overheads generally seen in practical systems with other choices of messaging protocols such as MQTT.

Some of the open XMPP specifications under development are specifically aimed at enhancing XMPP standards for Internet-of-Things applications, for example describing how to manage and get information from concentrators of devices over XMPP networks.

Concentrators are devices in sensor networks concentrating the management of a subset of devices to one point. They can be small, such as Programmable Logic Controllers managing a small set of sensors and actuators, medium-sized, for example mid-level concentrators, controlling branches of the network which may use different communication protocols, or entire large systems.

Because XMPP assumes a persistent TCP connection and lacks an efficient binary encoding, it has traditionally not been practical for use over lossy, low-power wireless networks associated with Internet-of-Things technologies. However, recent work in the development of XMPP standards aims to make XMPP better suited for the Internet of Things.

Even though many of the existing and emerging XMPP specifications relating to sensor networks are generally written and can be used by other implementations not based on sensor networks, many of the requirements used to define these specifications come from the requirements of sensor networks and Internet-of-Things applications and infrastructure. These specifications provide a common framework for sensor data interchange over XMPP networks.

One new XMPP specification aimed towards Internet-of-Things applications defines a general concentrator profile that can handle all different types of concentrators available in sensor network architectures, working with multiple data sources.

The XMPP Publish-Subscribe model, comparable to the publish-subscribe model of other protocols such as MQTT of interest in Internet-of-Things applications, describes a system where a tree structure of nodes is published and users can browse this tree structure, publish items on these nodes, and syndicate this information.

XMPP, and the standards and extensions built around it, can enable efficient publication of data collected from large sensor networks, federation of disparate platforms, service discovery and invocation, interoperability of machine-to-machine communications with machine-to-person and person-to-person communications and other advantages in addressing, security and scalability that make it a very promising technology for Internet-of-Things applications. Its strengths in addressing, security, and scalability make it ideal for consumer-oriented IoT applications.

If XMPP appeals as a protocol for your next IoT-enabled product or design revision – or you’re interested in any or all stages of the process and need a partner to help meet your goals – the first step is to discuss your needs with our team of experienced engineers that can help you in all steps of product design, from the idea to the finished product.

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.xmpp, internet, of, things, protocol, iot, messaging,xml, lx, group, embedded hardware

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.

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.