All posts tagged: of

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Although we have recently been focusing on the systems and hardware that can be used in various Internet-of-things applications, there’s much more to learn and understand. One particular aspect is the way in which devices send and receive data between themselves and servers – and an example of that is MQTT.

Message Queue Telemetry Transport, or MQTT, is an open protocol for machine-to-machine (M2M) communications that enables the transfer of telemetry-style data in the form of messages from a network of distributed devices to and from a small message “broker” server – whilst maintaining usefulness over high-latency, expensive or bandwidth-constrained networks. This publish/subscribe messaging transport protocol is designed to overcome the challenges of connecting the rapidly expanding physical world of sensors and actuators as well as personal computers and mobile devices.

The origin of MQTT goes back to the late 1990s, where co-inventor Andy Stanford-Clark of IBM became immersed in M2M communication whilst working with industry partners to mine sensor data from offshore oil platforms, to inform better preventative and predictive maintenance. One of those industry partners was Arlen Nipper of Arcom, an expert in embedded systems for oilfield equipment. Together, Stanford-Clark and Nipper wrote the initial version of MQTT in 1998, and their open-source messaging software has continued to be improved over the following years.

Until recently, one of the challenges limiting widespread development of IoT technologies has been the lack of a clearly accepted open standard for message communication with embedded systems. Today, however, MQTT looks set to play an increasingly significant role in facilitating the Internet-of-Things. In much the same way that the HTTP standard paved the way for the widespread adoption of the World Wide Web as a tool for the sharing of people-to-people information on the Internet, MQTT could set the stage for the machine-to-machine equivalent of the WWW.

MQTT is particularly well matched with networks of small, distributed, lightweight, and pervasive devices – not just mobile phones and personal computers, but embedded computers, sensors and actuators – which can make up the “Internet of Things”. The MQTT protocol specification enables a publish/subscribe messaging model in a very lightweight way, useful for connections with remote devices where a small code footprint is required – low-cost 8-bit micro controllers, for example – and/or where network bandwidth is at a premium.

There is also another standard for sensors – MQTT-S, for which this specification is aimed at embedded devices on non-TCP/IP networks, such as ZigBee/802.15.4 wireless sensor mesh networks. MQTT-S is an extension of the MQTT protocol aimed at wireless sensor networks, extending the MQTT protocol beyond TCP/IP infrastructures for non-TCP/IP sensor and actuator networks. Furthermore, MQTT is already widely supported by servers and brokers including IoT implementations such as cosm, Thingspeak, nimbits, and more.

MQTT is already used in a wide variety of embedded systems. An example documented by IBM demonstrates a pacemaker that communicates via RF telemetry to an MQTT device in the home of a patient – allowing nightly data uploads to the hospital for analysis. This allows recovering patients to leave hospital earlier to recover at home whilst still being monitored by medical professionals. Or if an unexpected event occurs, the system can immediately alert the hospital and emergency services without any patient interaction.

Furthermore IBM has recently announced its’ new “MessageSight appliance”, designed to handle heavy-duty real-time sharing of large amounts of data between sensors and devices and using the MQTT protocol to do so. Finally, IBM and Eurotech have bought MQTT to the open standards process of OASIS – the Organisation for the Advancement of Structured Information Standards. OASIS is a non-profit international consortium that drives the development, convergence and adoption of open standards for the global information society.

The OASIS standardisation process started in March 2013, with the goal of establishing MQTT as an open, simple and lightweight standard protocol for M2M telemetry data communication. The newly established OASIS MQTT Technical Committee is producing a standard for the MQTT Protocol – together with requirements for enhancements, documented usage examples, best practices, and guidance for use of MQTT topics with commonly available registry and discovery mechanisms.

Although MQTT does seem to be championed by IBM, the OASIS recently called for industry representatives earlier this year to sponsor the formation of its MQTT Technical Committee, and was answered by Cisco, the Eclipse Foundation, Eurotech, IBM, Machine-To-Machine Intelligence, Red Hat, Software AG and TIBCO. The group will take the MQTT 3.1 specification, donated to the committee by IBM and Eurotech where it was originally developed, and work to standardise and promote its adoption it as an open standard.

In defining MQTT standards and making them open for all, this allows its’ use and will hopefully guarantee a future standard allowing interaction with devices from all suppliers and manufacturers who choose to work with it. It’s a standard that holds a lot of promise for the future of an efficient and affordable Internet-of-things.

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

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

In this instalment in our series of articles focusing on various Internet-of-things systems, we explore the new Nearbus Open IoT Project. Although not the most complex of systems, Nearbus offers a level of control and interaction with devices and sensors which is ideal for demonstrations, proof-of-concept designs or even simple products where rapid development and low-cost are the main requirements.

Unlike other systems, Nearbus takes a different approach to device control. After loading the Nearbus on the device’s microcontroller, it is considered to be part of the “cloud” and as such transparent to the web services or API. In other words, you can read or write to the MCU’s registers directly from the cloud – which makes control much simpler than other systems. By “virtualising” the hardware in the cloud, it makes it much easier for existing services to interact with the real hardware, and in a more secure manner. Let’s examine the how this is possible with regards to the required hardware and software

Hardware – Due to market forces and age of the system at the time of writing, the Nearbus system only works with the Arduino-Ethernet platform. Thus the end microcontrollers used are Atmel ATmega328 programmed with the Arduino boot loader and interfaced with the Wiznet W5100 Ethernet controller. However this allows you plenty of GPIO, ADCs and CPU speed to complete a variety of tasks, and due to the open-source licensing of the Arduino platform the hardware cost for around A$20 per unit in volume. The main downside to this solution is the inability to use onboard WiFi chipsets, so the agent hardware needs to be connected to a separate WiFi router for true wireless control.

Software – Due to the current hardware requirement, the only code for each Nearbus node is their sketch (code) and the Arduino boot loader – both of which are totally open-source. The rest of the work is in interfacing your own cloud- or server-based applications with the Nearbus hub system. This transfer takes place via HTTP requests.

There are two methods for interfacing applications with the Nearbus system. The first method is the “transparent” mode which allows the agent to send and receive a packet of data over preconfigured periods of time, for example every five or ten seconds. This allows your cloud applications to call functions on the agent hardware as if it was controlling the MCU directly.

The second method is the “VMCU” mode (Virtual Microcontroller) which allows direct control of the basic MCU features such as GPIO, ADC, etc., via a web services API. This is the more complex method that maps the MCU remotely and thus allows direct control of the MCU’s registers and returns data in the raw from for your own web app to work with. The ability to map the registers removes a layer of complexity from the user or designer – as they don’t have to worry about network protocols, instead just be concerned with the microcontroller itself.

Furthermore you can configure, add and remove devices with a web-interface, and also create connections to send data to other IoT services such as cosm or twitter. If you don’t have a server capable of running your own web apps to interface with Nearbus, you can use other free or paid services such as Google Spreadsheet web apps – and demonstrations have been provided to show how easy it is to display, capture and analyse data from the hardware agent.

The Nearbus system is a different paradigm to the usual IoT systems. It may seem awkward or different to more conventional or consumer-oriented ways of doing things, however if you have a strong PHP and networking background it can be implemented easily with your server and applications. Due to the low hardware cost it’s ideal for monitoring or remote-control applications that don’t require complete real-time interaction.

If you’re interested in moving forward with your own system based on the Nearbus, we have a wealth of experience with the required hardware options, and the team to guide you through the entire process – from understanding your needs to creating the required hardware interfaces and supplying firmware and support for your particular needs.

Our goal is to find and implement the best system for our customers, and this is where the LX Group can partner with you for your success. We can create or tailor just about anything from a wireless temperature sensor to a complete Internet-enabled system for you – within your required time-frame and your budget. For more information or a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

Continuing from our previous articles which are focusing on a range of currently-available Internet-of-Things systems, we now move forward and explore another addition to the Internet-of-Things marketplace in more detail – the system known as “ThingSpeak”. Considered to be one of the first openly-available IoT platforms, ThingSpeak operates on their own free server platform, or you can run the software on your own personal servers – and as the entire system is open-source, it’s easier to work with and customise.

As with the other systems examined, ThingSpeak gives your devices the opportunity to interact with a server for simple tasks such as data collection and analysis, to integration with your own custom APIs for specific purposes. Due to the open-source nature the start-up cost can be almost zero, and unlike other systems ThingSpeak is hardware agnostic – giving your design team many hardware options. However as always, let’s consider the main two components in more detail.

Hardware – You don’t need to purchase special base units or proprietary devices. As long as your hardware is connected to the Internet and can send and receive HTTP requests – you’re ready to go. For rapid prototyping, examples are given using many platforms including netduino, Arduino, mbed, and even with the competitive Twine hardware. This gives you a variety of MCU platforms from Atmel and ARM Cortex providers to work with, and as these development platforms are either open-source or inexpensive, your team can be up and running in a short period of time.

Furthermore creating your own devices can be quite inexpensive – a simple device based on an Atmel AVR and Ethernet interface can be manufactured for less than $20 in volume, and doesn’t require any software licensing expenses. To save on hardware costs, it could be preferable to have various sensors in a group communicate back to one connected device via inexpensive Nordic NRF24L01 wireless transceivers – and the connected device can thus gather the data into the require fields for transmission back to ThingSpeak.

Software – Thanks to the open-source nature of ThingSpeak either working with the existing server software or creating your own APIs isn’t a challenge. Interaction is easy with simple HTTP requests to send and receive data, which has a useful form. Each data transmission is stored in a ThingSpeak “channel”. Each of these channels allows storage and transmission of eight fields with 255 alphanumeric characters each, plus four fields for location (description, latitude, longitude and elevation – ideal for GPS), a “status update” field and time/date stamp. Data sent over the channels can be public or private – with access via your own devices and software finalising the security.

Once sent to the server this data can be downloaded for further analysis, or monitoring using various HTTP-enabled entities – from a simple web page, mobile application or other connected device. Various triggers can be created to generate alerts for various parameters, and can be sent using email, twitter, or other connected services such as an SMS gateway. After being in operation for almost three years, the platform has matured to a reliable service that has exposed many developers to its way of doing things, so support and documentation is becoming easier to find.

Overall the ThingSpeak system offers your organisation a low barrier to the Internet of Things. Creating a proof-of-concept device or prototype hardware interface can be done with existing or inexpensive parts, and the use of ThingSpeak’s free server can make an idea become reality in a short period of time. And once you device on the service, by internalising the server software, you can have complete control and security over your data.

If you’re interested in moving forward with your own system based on the ThingSpeak, we have a wealth of experience with the required hardware options, and the team to guide you through the entire process – from understanding your needs to creating the required hardware interfaces and supplying firmware and support for your particular needs.

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

As the “Internet of Things” becomes increasingly prevalent this year, much has been written and systems devised to allow all manner of data to be gathered, analysed and devices controlled via wireless data networks. However these systems aren’t limited to items of a technological nature, as the broad IoT can also be of great benefit to primary producers and agriculture of almost any type. But how?

It’s simple – if more data about a particular item of interest is available, you can make better decisions concerning that item. If that data was available in real-time, you can make informed decisions faster. Let’s consider four areas in the farming arena that can benefit from this technology with some example possibilities.

Horticulture – There’s much more to achieving profitable returns on horticulture than just planting a seed and hoping it will grow. Apart from monitoring the weather – wireless sensors can be used to monitor soil temperature and moisture (even for multiple depths), greenhouse temperature and humidity, leaf wetness levels, solar radiation, and rain levels. Real-time data from these types of sensors can be useful to change crop maintenance procedures from regularly-scheduled to “when required” – saving time and money. Furthermore as data is gathered over time, more accurate predictions can be made with regards to crop success with regards to external factors.

Livestock – The monitoring of livestock is crucial, especially for expensive breeds that require a higher level of maintenance. Tracking individual beasts via a GPS connected to a local wireless network makes it easy to locate animals in a hurry, alarm you if one or more range too far from home – or if one hasn’t moved during the day, which could either mean an animal has become injured or isn’t getting enough exercise. With RFID technology counting and tracking the animals individual statistics from birth to sale becomes faster and simpler. Furthermore as animals come and go the hardware can be reused for new births or acquisitions, reducing recurring costs and further hardware investment.

Security – This is often overlooked due to the nature of the prevailing surroundings and personal relationships built over generations. However as the rest of society has an increasing number of unsavoury elements, so too does the agricultural sector. There are many ways to keep track of assets, such as: adding GPS tracking devices to expensive machinery; intrusion-monitoring sensors to sheds, gates, pump boxes and greenhouses; ultrasonic motion sensors to detect vehicle movement on out of the way tracks and access roads; tank water level sensors can detect when the level drops too quickly – alerting you of a leak or water theft; and closed circuit television cameras are now digital, and can send images that are legible during day and night allowing monitoring of any asset of interest – as well as record passers-by helping themselves to popular vegetable crops.

Water management – In some areas the supply of water is costly. As water rights are reduced and transport costs increase, monitoring water use and wastage is crucial. Water levels can be monitored across all storage tanks, flow sensors can monitor creek and river water movement and speed, and with data from soil moisture sensors, your system can supply the minimum required for agricultural purposes instead of timed watering sessions. Furthermore automated systems can indicate faults in water supply, tank leaks, and faults with irrigation systems – letting you know immediately before wastage becomes too serious and expensive.

All of the sensors and devices mentioned can communicate via wireless networks using WiFI or Zigbee-based technology. For remote situations or multiple-site use these WiFi devices can then communicate via the mobile broadband modems and existing cellular networks. Whether you’re in town or abroad, the data can be accessed via the Internet from almost anywhere.

The examples mentioned above may sound like overkill – or replacement of the work of an experienced farmer. However by automating systems and gathering data remotely you can reduce the time required to stay on top of routine tasks, increase efficient use of expensive resources, become immediately aware of any problems – which leaves you with more time to grow your business.

As an Australian organisation led by a team with a diverse background and industry experience, the LX Group can partner with you for your success. With wireless data and bespoke hardware experience in a wide variety of industries we can help you make the most of your business with our expertise and the best technology from around the world. For more information or a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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

Continuing from our previous articles which are focusing on a range of currently-available Internet-of-Things systems, we now move forward and explore another successful addition to the Internet-of-Things marketplace in more detail – the system known as “Ninja Blocks”. An Australian invention, developed only last year and originally released via the ubiquitous Kickstarter crowd funding system – Ninja Blocks are now a commercial product and available for use. It is billed as the “ Internet of things for the rest of us” – however anyone person or organisation can make good use of it.

Like other systems the Ninja Blocks consist of two major elements – the hardware devices and attached I/O devices, and the software environment. Using this combination you can create sets of “rules” that allow interaction between the hardware and the end user with a variety of methods. For example temperature can be monitored remotely, alerts can be sent when a button is pressed, or an image can be emailed from the connected webcam – ideal for remote monitoring, security or personal interest applications.

Furthermore the entire system is open hardware, and can be modified at whim – all the design files are available for download and examination. So creating your own devices to interact using the system is a possibility, and we can easily help you integrate your existing hardware to make use of Nina Blocks connectivity. Now let’s examine the hardware and software in more detail.

Hardware – Housed inside an enclosure (that you’re encouraged to open) is a “BeagleBone”, which is a single-board Linux-based computer running a 720 MHz super-scalar ARM Cortex-A8 processor. Attached is a daughter board which contains an Arduino-compatible microcontroller and a 433 MHz wireless data link. There’s also three USB ports to connect various sensors (such as temperature, motion detectors), actuators (such as radio-controlled AC outlets) and the aforementioned USB webcam. Connection to the Internet is via a typical RJ45 connection or a Wi-Fi USB adaptor.

Included in the Ninja Blocks retail package is a wireless passive infra-red motion detector, a wireless button (similar to a doorbell button), a wireless temperature/humidity sensor and a wireless door sensor (which is a magnet/reed switch, ideal for doors and windows). This allows experimentation and a rapid method of getting familiar with the system.

The wireless hardware operates in the consumer product 433 MHz frequency area, which allows integration with a wide variety of commercially-available products. If you can decode or understand the protocols used by such hardware it can be used with Ninja Blocks. For example the use of wireless AC outlets is a perfect example of how quickly (and safely) almost any device can be controlled remotely. In doing so this also removes the requirement for customised AC wiring and certification.

Software – Getting started is incredibly simple, as the cloud-based environment allows you to create sets of rules that generate actions based on the data coming from the hardware. Like any other IoT system you can also create specific applications for your own needs to work with the cloud service. Further you can also update the firmware on the Arduino-compatible hardware inside the Ninja Block to allow for customised hardware interactions.

Just like the hardware design, there’s no secrets to the software and the Ninja Blocks API is documented including various examples that is growing over time. Any programmer with contemporary experience can get up to speed within a reasonable amount of time. However the system can remain “code-less” as the owner can simply work with the graphical cloud interface if need be.

The Ninja Blocks system spans almost every user type, from the interested beginner to the organisation who knows what they want and doesn’t have the resources to “reinvent the wheel”. It may look like a simple product however there is a huge scope for customisation and adapting existing hardware is a genuine possibility.

If you’re interested in moving forward with your own system based on the Ninja Blocks, we have existing experience with the platform, a relationship with the Ninja Blocks organisation and thus can guide you through the entire process – from understanding your needs to creating the required hardware interfaces and supplying firmware and support for your particular needs.

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

Continuing from our article last week which examined the Twine wireless sensor blocks, we now move forward and explore another recent addition to the Internet-of-Things marketplace in more detail – the “Electric Imp”. Although the name sounds somewhat toy-like, the system itself is quite the opposite. It’s a unified hardware, software and connectivity solution that’s easy to implement and quite powerful. It offers your devices WiFi connectivity and an incredibly simple development and end-user experience.

That’s a big call, however the system comprises of a relatively simple hardware solution and software development environment that has a low financial and learning entry level yet is quite customisable. Like other systems it comprises of a hardware and software component, so let’s examine those in more detail.

Hardware – Unlike other IoT systems such as Twine or cosm, the Electric Imp has a very well-defined and customisable hardware structure that is both affordable and incredibly compact. Almost all of the hardware is in a package the size of an SD memory card, and the only external parts required are a matching SD socket to physically contain and connect with the Imp card with your project, and supporting circuitry for an Atmel ATSHA204 authentication chip which enables Imp cards to identify themselves as unique unitsin the system.

Connection to the cloud service is via a secure 802.11b/g/n WiFi network and supports WEP, WPA and WPA2 encryption, however due to the size of the Imp there isn’t an option for a wired connection. The external support schematic is made available by the Imp team so you can easily implement it into almost any prototype or existing product. But how?

Imagine a tiny development board with GPIO pins, an SPI and I2C-bus, a serial UART, and a 16-bit ADC inside your project that is controlled via WiFi – this is what the Imp offers. It’s quite exciting to imagine the possibilities that can be introduced to existing projects with this level of control and connectivity. From remote control to data gathering, system monitoring to advanced remote messaging systems – it’s all possible. Furthermore, due to the possibility of completely internal embedding of the Imp system inside your product, system reliability can be improved greatly as there’s no points of weakness such as network cables, removable parts or secondary enclosures.

Software – As each Imp is uniquely identifiable on the Imp cloud service, you can use more than one in any application. Furthermore, your Imp firmware is created and transmitted to each Imp card online – which allows remote firmware updates as long as the Imp has a network connection; and a cloud-based IDE to allow collaboration and removes the need for customised programming devices, JTAGs, or local IDE installations. This saves time, money, development costs and offers a more portable support solution.

The firmware is written in a C-like language named “Squirrel”, which is created using the aforementioned online IDE. Once uploaded to the Imp card the firmware can still operate if it loses a network connection – or if a run-time error occurs and a network is available, the details will be sent back to the IDE. This allows developers the ability to remotely debug Imp applications in real-time – saving on-site visits and unwanted client-supplier interactions.

Furthermore, Imps have an inbuilt LED which can be utilised to display status modes if an application fails or other information which can be used to a clients’ benefit, helping them describe possible issues if a network connection isn’t available. There is a detailed language description, a wide range of tutorials and example code to help developers get started – and although some features are still in the beta-stage, the core advertised features are available at the time of writing.

If you’re interested in moving forward with the Electric Imp, we can guide you through the entire process, from understanding your needs to creating the required hardware interfaces and supplying firmware and support for your particular needs. The up-front hardware cost is much lower than other systems, and with volume pricing the implementation costs can be reduced further.

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 considering an Internet-of-Things framework for an existing or new project, one of the greatest challenges is getting the system running within what is most likely a tight deadline. And part of the greater challenge is the choice of interface between you devices and the network – and how will they interact? At this juncture your decision can be to create a bespoke solution, or use an existing product. The latter is ideal for proof-of-concepts, quick jobs or just when you need to get a MVP (minimum viable product) through the door. With this in mind, we’ll check out one example of an existing solution that you may make use of – called “Twine”

Although originally an idea that was brought to fruition using crowdfunding via Kickstarter, Twine has now become one of many viable choices in the IoT marketplace. As usual, it consists of a hardware and software component – so let’s examine those and then see how they can work together to solve your problems.

Hardware – The Twine devices are quite unassuming and compact, measuring approximately 70×71×20mm and can fit in the palm of your hand. With an elastomer coating they’re quite robust, however not water resistant or proof. These devices provide the link between the cloud-based software and a variety of hardware options. Inside each device already exists temperature, vibration and orientation sensors – and a port for external sensors. It connects via an 802.11b wireless network and is powered via a micro USB socket or 2 AAA cells.

You can also acquire a range of external sensors covering moisture, magnetic switches (for doors, etc) and also a breakout board to connect your own hardware. You can connect any device that outputs an analogue or digital signal with a 0~3.3 V range. Furthermore there’s also an Arduino shield for connection to that ubiquitous line of hardware. The last two options then give you the ability to quickly connect your own sensor or interface via an Arduino-compatible board other hardware with which you’d like to interact with over the cloud system. Therefore development costs of this additional hardware will be restrained due to the ease of interfacing with the sensor port or Arduino interface.

Software – There are two primary methods for interacting with the Twine hardware, with their proprietary cloud-based system or via HTTP to your own applications. Using the cloud-based method – you create a series of rules that can monitor incoming sensor data then make decisions based on the results. From simple things like email alerts notifying you of temperature changes to SMS text messages when a device has been physically moved – there are many possibilities that can be constructed in a short period of time. There’s also the option of receiving messages via twitter and text-to-voice call.

The process of creating applications for Twine doesn’t require any coding at all, so demonstrations of the system can be created and modified by general employees and management. Using an online drag-and-drop interface with simple condition parameters is used to generate actions based on the status of the connected sensors. However there is also the opportunity to have Twine directly interact with your own infrastructure using HTTP GET and POST requests. This is also preferable for those looking to keep their data within internal systems.

It can be said that Twine is not the most complex or customisable system on the market at the time of writing, however if your needs meet the capabilities then it can be a valid option. You can get a basic system operating in a few hours, and integrate other hardware in no time at all.

If you’re interested in moving forward with Twine or other platforms, we can guide you through the entire process, from simple installations for demonstration purposes to a complete system with customised external sensors and programming support. Our goal is to find and implement the best system for our customers, and this is where the LX Group can partner with you for your success.

We can discuss and understand your requirements and goals – then help you navigate the various hardware and other options available to help solve your problems. We can create or tailor just about anything from a wireless temperature sensor to a complete Internet-enabled system for you. For more information or a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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