What does it take to be an IoT engineer?

[Andrew at MEA]

When all is said and done, there has usually been more said than done!

This is surely true of the IoT.

I agree with IoT’s promise, but see few of its practitioners.

Much of the IoT hype talks about connecting the fridge to the stove, although why, I can’t imagine.

Business cannot thrive without customers, and who are they in IoT land, once the Early Adopters have tired of its promise?

I can claim some small expertise in this area, having successfully launched an On-Farm Internet-of Sensors system called Plexus three years ago, moving soil moisture and climate data using solar-powered mesh networks across the farm and up to a web-application in the cloud that allows farmers to access their irrigation data from anywhere, at any time.

To break into this field required a huge investment of funds over three years, a multi-disciplinary approach that hauled together electronic, mechanical, communications and software engineers, plus external industrial design skills, a manufacturing link into China, all sorts of technical skills to set up the production line, and some thirty years of previous environmental measurements in the bush merely to battle-harden the troops.

Then you have to sell it and keep it working until you’ve crossed the ‘valley of death’ between early adopters and the early majority.

So the hard reality is that breaking into the whole IoT technological arena is non-trivial; it’s no place for the faint-of-heart or the weak-of-purse or the inexperienced-yet-hopeful.

But it is fun, and at last, slightly lucrative.

 

Dr Andrew Skinner FIEAust CPEng NER

South Australian Professional Engineer of the Year, 2015

[Geoff Sizer]

Hi Andrew, the topic you raise is spot on, and is a core item I will address in my webinar on 5th July.

The IoT when considered top-to-bottom - ie from the Cloud down to deloyed Things - encompasses just about every facet of ICT, software engineering and and electronics engineering.  There are at least a dozen technology elements, each of which has a steep learing curve.  And add to that the required knowledge of the system where IoT is to be applied.

That said, many aspects of IoT technology are not new - just used in and integrated manner, often by engineers who are expert in the field where they wish to use IoT, but not in the actual IoT technologies themselves.

One of the primary drivers for forming this community was the need to provide a means for those involved in IoT - both technology providers and technology adopters - to come together to help build critical mass.

[Justin Blows]

Hi Andrew,

You and Geoff raise important points about successful IoT enterprises.

Because this is an engineering and not a IOT business forum, my response is brief.

I agree it is necessary:

• to understand the application and the underlying IoT technology
• have access to multidisciplinary skills, including engineering and design
• to focus on sales and marketing
• have a route to manufacture
• have a route to market
• involve capital partners if necessary

The following may also be needed:

• a great business plan supported by a network of business advisers
• strategic intellectual property planning, including
  • freedom to operate
  • patent filing strategies (which may be to file nothing)

I've started a blog on this site about IoT intellectual property strategy.

Justin

[Justin Blows]

Hi Andrew,

You said:

Quote

Much of the IoT hype talks about connecting the fridge to the stove, although why, I can’t imagine.

I agree that "merely" connecting a fridge to a stove is not very inventive. 

The creative challenge for IoT engineering: There are many yet to be invented ways in which the fridge and the stove are synergistically connected, in ways that is only possible with IoT technologies (i.e. not simply control from a distance etc).

Some of these may add real value and consequently commercial opportunities.

Justin

 

 

[Andrew at MEA]

Hi Geoff

Three of us at MEA listened to your inaugural talk this morning on the IoT and thoroughly enjoyed it.

You handled question time with panache and told us a few things we didn't know (SigFox - whatever that is - heading the list...)

You also mentioned that folks likely to field a 'top-to-bottom' solution for an IoT application were still in the future, and likely to need a team of about 20 good folks to pull it off.

Even counting our sales, marketing and administration folk - plus external industrial design and manufacturing support - brings us no-where near that number of staff. Yet we have built and are operating over a thousand on-farm IoT nodes across Australia, moving soil moisture and climate data to the cloud (our 'Green Brain' web app) with data available 'any time, anywhere' on an irrigator's mobile.

But your point is valid - the IoT is a multi-disciplinary field requiring a very broad approach to engineering, product development and customer support.

To end on a lighter note, one of our engineers found this IoT quote somewhere on-line: -

“IoT is like teenage sex:   

Everyone talks about it, nobody really knows how to do it.

Everyone thinks everyone else is doing it, so everyone claims they are doing it too.”

Andrew (at MEA in Adelaide)

 

 

[Ollencio D'Souza]

Application "engineering" at its best - in the field!!!  Awesome.

I think IoT is an environment that existed in a hardwired way in many industries. Now it is getting interesting when we see "devices" communicating with a common protocol. a centralised and decentralised "command and control" where data can be gathered, analysed and then actioned.  From automation (home and industry) to security systems, to networks of "community" devices that will allow us to "get" data when we need it to improve awareness on a number of fronts.

I think this is just a great start!

[Geoff Sizer]

Andrew,

Thanks for the kind words

I'd like to reiterate an earlier call on another forum thread, for MEA to present your achievements via a Community webinar.

In particular, I would like to hear how your team were able to tackle the challenges and learning curves in getting your application off the ground.

BTW, I was born and bred in Adelaide, but managed to escape to Sydney after leaving Uni  ....  

Good to see some "high tech" action in the old home town.

 

 

[Andrew at MEA]

Folks - I've lifted this 'sidebar' about our Plexus IoT development story from an application note I'm writing about powering IoT devices using solar energy.

We named the product (in the photos above) - after the 'Solar Plexus' in the human body - two puns intended - is a mesh network delivering data from across the farm (where cellular access is not always present or reliable) via 2.4 GHz ZigBee radio.

Hope you enjoy the story 

Andrew (at MEA)

 

‘Plexus’ - an On-farm Internet of Things

Designing and operating an ‘Internet of Things’ on-farm requires a multi-disciplinary approach to product development involving electronics, firmware, software, mechanical engineering and industrial design, web design, communications engineering, manufacturing skills, good field people and a deep understanding of just how tough an environment it really is when trying to keep measurement technology running year-round for a decade despite the hazards of weather, farm machinery and the occasional rogue human. That we came into this business with thirty years of data-logging experience and environmental measurements helped, but we needed to learn new skills on all fronts to pull this off, innovating our business model as we switched from a custom engineering base to that of a manufacturer.

Driving this development was a sense that the old days of storing data in data loggers - then unloading it the farm computer - were at an end, and that modern farmers needed access to their sensor data at any time and from anywhere. This required the power of the Internet to move, store and present this data on PCs, tablets and smart phones without any proprietary software in the mix. It was a new world. Data needed to be collected using energy gathered on-site, ‘hopped’ by cooperative radios across the property to some master controller then automatically fed via a modem to an Internet server that would store data and serve it up to the farmer whenever he logged in. Temporary data storage was needed all along the chain to patch over the usual in-field outages, automatically playing catch-up when network elements were restored.

The IEEE 804.15.4 ‘ZigBee’ standard was the obvious starting place to develop such technology because of the deep underpinning developed by the standards people and implemented by big IC manufacturers who made radio systems-on-chip, including the internal software ‘stacks’ that operate the various layers of networked radios. This created an immediate problem for the development team, as each node on the Plexus on-farm network needed to be a ‘router’ under the design brief, forwarding data across a self-healing mesh network with the minimum of set up fuss. However, ZigBee routers are typically ‘always on’, and the solar-powered energy budget simply did not allow for this. The eventual compromise was to re-fashion the whole network for a solid minute every fifteen minutes, then go into complete power-down mode for the remaining 14 minutes to conserve energy.

Plexus systems guarantee a maximum 1000 m spacing between any field station in flat country. Given a 5-deep parent-child router arrangement, this allows coverage of most on-farm applications up to 1000 hectares. Radios, solar panels and batteries have to be light-weight and streamlined to live safely about two metres above the top of the crop for clean solar and radio access. Over-row machinery in permanent row crops such as grapes means that the whole Plexus field station pod needs to be ‘knock-down-spring-back’ so that on-farm operations are unaffected by the presence of the radio system. All this geometrical confinement forces a limit on the energy budget that is physical; it only becomes possible if the solar panel is small and light enough to fit inside a tough polycarbonate streamlined enclosure. 5V 400mW solar panels measuring 50m x 50mm fitted the bill but limit field station average operating current to a maximum of 8 mA, distributed between radio, sensor and system elements.

Plexus product development took over three years of intensive effort, including seemingly endless returns to the field to be beaten up and humiliated yet again as we tried to understand what was going on – or was not. All this before we even let customers near the data that was being produced. The usual engineering compromises were reached in an effort to meet the deadlines imposed on us by the need to get to market and get a return on investment. Needless to say, we are still unwinding some of these ‘frozen-in-stone’ decisions in an effort to build a more flexible system capable of handling sensors and systems we’ve not even heard of yet. Yet the original concepts proved robust, and more than two years of field data from hundreds of sites across a broad range of crops and climates has vindicated the design decisions made.

Like all new game-changing technologies, the Internet of Things is in danger of being over-hyped. Yet it can be made to work by a highly disciplined and experienced engineering team, given sufficient focus and across-company support. But it’s not a game for the faint-hearted or the weak-of-purse.

 

 

[Jon Eggins]

On 20 June 2016 at 6:55 PM, Andrew at MEA said:

I agree with IoT’s promise, but see few of its practitioners.

Much of the IoT hype talks about connecting the fridge to the stove, although why, I can’t imagine.

Andrew, I could not agree more. I am writing down my thoughts on this progressively; you may be interested:

 

[Jon Eggins]

On 5 July 2016 at 4:23 PM, Andrew at MEA said:

“IoT is like teenage sex:   

Everyone talks about it, nobody really knows how to do it.

Everyone thinks everyone else is doing it, so everyone claims they are doing it too.”

Gold!!!

In all seriousness, it's true - most people really don't know or understand what IoT is meant to be. They thing its about inserting a sensor into the Internet, and then seeing what happens.

 

[Cesar A Gonzalez]

@Andrew at MEA great post, amazing effort from you and your team. it is a true entrepreurship endevour from engineering. 

I would like to ask about this bit: "All this before we even let customers near the data that was being produced" Is this means that you were designing a product without knowing the data you needed ? 

What design approach did your team used? 

A more technical one, what software was used for RF coverage, LoS/nLoS and QoS? 

Thanks again for sharing this. 

Cesar. 

  

[Andrew at MEA]

Smart sensors and piped data

Hi Cesar

Well, MEA is short for ‘Measurement Engineering Australia’, so we certainly knew which sensors farmers wanted to use.

But they had to be ‘smart sensors’, with digital outputs on the standard environmental SDI-12 bus.

Why is that?

Because our Plexus radio network is just a pipe, blindly moving data from smart sensors up the chain to the web application in the cloud.

We purposely did not put any ‘self-knowledge’ into the Plexus system –as we have always done with data loggers - as that would require all sorts of ‘programmability’ at each node in the IoT, explaining how to convert  ‘dumb’ sensor data (voltages, frequencies, counts, currents) into ‘real’ values of soil moisture content and tension, temperatures, rainfall rates and so forth.

Nor did we want to bog our server down doing these computations for thousands of sites every fifteen minutes, converting raw data into processed data.

So what exactly is a ‘smart sensor’?

Smart sensors make the analog measurement in the real world then convert the data internally to real units, correcting for temperature, applying non-linear algorithms and using sensor-specific calibration coefficients. The output is human-readable ASCII values.

Data packets are in CSV format, travelling by radio in 82-byte data packets by various routes back to the network hub and thence to the cloud via a cellular phone modem. Each packet includes a unique node-identifying MAC number, date, time, battery voltage, and all the readings returned from the smart sensors. Also the packet number, because packets need to be re-assembled into orderly data at the Hub.

Sorry, no idea what LoS/nLoS and QoS are… I’m off to look them up.

Andrew

[Geoff Sizer]

Question from 5-Jul Webinar:

 I have graduate as a civil engineer last year and started working at Accenture with the technology consulting segment. I have seen a great rise in digital innovation and rise in IoT. I have started reading on this and have seen some project such as IBM and Yarra Valley Water in Water Asset Management using IBM Blue mix or Accenture and National Farmers Federation in Agriculture.

As a Civil Engineer in IT and on behalf of many others in similar situation, how could I participate in projects within IoT and how could I marry up my knowledge in Civil Engineering with IoT applications. Are there any training or reading materials available that could bring people like me up to speed? 

Answer:

There is so much information about IoT on the Internet so as to become overwhelming - and a lot of hype. 

Solution adopters can approaching the issue form the application perspective, and seek out case studies and papers relating the use of IoT in the application in question.  From that base, build knowledge of what others are doing and follow the threads from there.

This community aims to build a knowledge base, and over time will accumulate an increasing amount of information on IoT applications and technologies.

A useful approach to gain information is to start forum threads on topics of interest - and suggesting topics for future webinars.

 

[Geoff Sizer]

Question from 5-Jul Webinar: 

Do you feel it's more likely that enterprise will look to develop IoT development capabilities in house or rely on external consultancy?

Answer:

The technologies and engineering skills require to implement IoT system  top-to-bottom are extensive, and it is unlikely that typical engineering teams using IoT in their systems or developing IoT-capable products will have the full range of required capabilities. 

Additionally, these skills are different from the core skills required to design and develop the primary functions of the system or product.

It is likely that most organisations will require the services of external consultancies, or full service providers such as the large industrial automation and building management system providers.

 

[Geoff Sizer]

Questions  from 5-Jul Webinar:

1. How can recent graduates get involved considering it is not get in our main curriculum. this is from an environmental engineering point of view

2. I am an electrical engineer working in the EPCM sector. If i want to make a career change to IoT what training path do i need to take? i already have an Computer Science degree and don't particularly want to study another whole degree again

3. In a reference to an IoT skills set. Do we have any industry standards for Universities/Colleges (in Australia) to follow in providing a training to support a wide range of the Internet of Things skills set.

Answer:

The IoT brings together a range of electronics engineering, communications, software engineering and system elements.  These are not unique to the IoT – although the IoT does embody leading-edge technologies and capabilities.

For the IoT technology developer, most if not all of the skills required to participate in IoT systems development and application are covered by existing undergraduate or post-graduate courses, and by career development paths in appropriate industries.  The skills required to participate in IoT systems development and application can be acquired by a combination of undergraduate study, early stage career development and ongoing professional development activities.

In the case of engineers from non-electronics and software backgrounds who wish to incorporate IoT into their systems and projects, there is a need to have awareness of what can be achieved, and the benefits to be gained.

With the growth of IoT, it would make sense for universities to review their course offerings to ensure that appropriate technologies are adequately addressed, for both technology developers and solution adopters.  Course units which bring these elements together under the IoT banner from a systems engineering perspective also make sense.  Undergraduate projects addressing IoT would also be beneficial

 

[Andrew at MEA]

Keeping the IoT Working

There are all sorts of jobs in IoT that are not technical (or very technical)

Successful products have to be marketed, installed and supported. 

Here's a photo of Justin from MEA's Queensland office; he's all over the state talking to growers, giving advise, installing and supporting Plexus on-farm IoT systems.

No engineering degree needed, but an absolutely valuable guy; pleasant, hard-working, prepared to travel long distances, on the customer's side adn always ready to get his hand's dirty and on-ground problems solved.

[Andrew at MEA]

And where's the IoT device in the photo?

The green stick-like thing he is holding is a buriable 'capacitive probe' capable of making soil moisture and temperature measurements every 10 cms down through the soil profile. The Plexus field station is the 'redbird' in the background. There can be dozens of these scattered across a farm, all networked together by radio and moving data to the Plexus hub and thence via cellular modem to our Green Brain web application. The farmer or irrigator can log on to Green Brain to see his data from anywhere and at any time, only providing Internet access is available to him.

So my message is that you don't need to be the technology creator to be in the IoT business; you can use existing gear to provide a monitoring and advice service, such as dam level monitoring if you are a civil engineer.

Think 'applications'...

Edited July 15, 2016 by Andrew at MEA
typos

[Cesar A Gonzalez]

On 11 July 2016 at 0:22 PM, Andrew at MEA said:

Smart sensors and piped data

Hi Cesar

Well, MEA is short for ‘Measurement Engineering Australia’, so we certainly knew which sensors farmers wanted to use.

But they had to be ‘smart sensors’, with digital outputs on the standard environmental SDI-12 bus.

Why is that?

Because our Plexus radio network is just a pipe, blindly moving data from smart sensors up the chain to the web application in the cloud.

We purposely did not put any ‘self-knowledge’ into the Plexus system –as we have always done with data loggers - as that would require all sorts of ‘programmability’ at each node in the IoT, explaining how to convert  ‘dumb’ sensor data (voltages, frequencies, counts, currents) into ‘real’ values of soil moisture content and tension, temperatures, rainfall rates and so forth.

Nor did we want to bog our server down doing these computations for thousands of sites every fifteen minutes, converting raw data into processed data.

So what exactly is a ‘smart sensor’?

Smart sensors make the analog measurement in the real world then convert the data internally to real units, correcting for temperature, applying non-linear algorithms and using sensor-specific calibration coefficients. The output is human-readable ASCII values.

Data packets are in CSV format, travelling by radio in 82-byte data packets by various routes back to the network hub and thence to the cloud via a cellular phone modem. Each packet includes a unique node-identifying MAC number, date, time, battery voltage, and all the readings returned from the smart sensors. Also the packet number, because packets need to be re-assembled into orderly data at the Hub.

Sorry, no idea what LoS/nLoS and QoS are… I’m off to look them up.

Andrew

@Andrew at MEA thanks for replying. 

So basally, Plexus is a turn-key solution. I though there was some RF Design/Planning prior the deployment, so was trust the radio coverage of 1km with LoS (Line of Sight) and assumed a 2 metres height to have access to the radio signals. Always good to have some desktop analysis prior deployment to ensure good quality signals/coverage. 

LoS/nLoS: Line of Sight or Non Line of sight, this are some characteristics to be taken into account when designing RF solutions. 

Thanks

Cesar.

 

[Andrew at MEA]

The Chasm between Australian Industry and Science

Much public hand-wringing has occurred in the past few years about Australia’s poor international rating when it comes to collaboration between our industry and our scientific bodies.

During our IoT webinars, this curious snake-in-the-grass has reared its head in the same old way, suggesting that there remains a fundamental misunderstanding between the two camps.

What really gets my goat are steamy statements from academia about how the growth of the IoT is dependent upon industry driving the cost of sensors and hardware down to just a few dollars each.

I’ve watched in dismay over the last decade as CSIRO, NICTA and Sense-T have all promulgated a message that their clever research will make this happen, bypassing the clunky technology of existing industrialists and heading straight for grateful farmers. This inanity reached a peak some years back with statements that these new ultra-cheap IoT devices would be ‘scattered like confetti from helicopters, link up automatically and feed data back’ to the Big Data folks, seemingly forever.

That the helicopters never took off is just a self-evident footnote to my grumblings.

The reality on the ground is that the deployment of technology and the building of profitable markets that can feed further development is a long hard grind. That’s why technology doesn’t just skip merrily ahead like a spring lamb once the research funding is used up.

It will cost money to sell service and support IoT gear – just like everything else.

So my gut feeling is that the disconnect between Australian industry and academia is somehow fuelled by this hype and a general failing to understand each other’s very different currencies.

More on that later…

Perhaps this webinar series will tentatively open some doors between us all and lift our collaboration ratings?

[Andrew at MEA]

The Chasm between Australian Industry and Science: Part 2

In Part 1 of these musings on the different perspectives of Australian scientists and engineers, I suggested that our differences arise because of our different ‘currencies’.

I explored this idea in a conference paper back in 2013:

Skinner, A.J. (2013) ‘Engineering a Sap Flow Sensor for Irrigators’.  ISHS - IX International Workshop on Sap Flow, Gent, Belgium June 2013 (Conference Paper)

Back then, I was talking as an engineer to a bunch of international scientists about a sensor that I’ve been developing now for over 27 years. This ‘crop water stress’ sensor was aimed at getting plants themselves to advise farmers on ‘when to irrigate’. The idea was to replace more expensive surrogate soil moisture and climate sensors, delivering the data over the IoT via MEA’s Plexus platform, designed to provide the back-channel for this new sensor.

[…from the Introduction]

“Despite the publication of over 1500 scientific papers since the pioneering work of Huber and Schmidt in 1937, sap flow sensors are still not sufficiently simple or robust to have become an everyday tool in use by growers wanting to know ‘when to water’.

And despite an ever-deepening understanding of the physiology of plant transpiration mechanisms, no simple method has been described that relates sap flow to crop water stress in a way that farmers can easily apply to more profitably grow their crops.

That this is so is no fault of scientists; what has been missing has been an essential layer of specialized engineering.

Unlike scientists – employed largely by universities and public research institutions - engineers are most often employed by private companies.

Unlike scientists – subject to the scepticism of their peers to qualify their research – engineers face sceptical farmers when promoting newly-invented irrigation scheduling tools.

Unlike scientists - whose publication output determines their career advancement – engineers are dependent upon the development of workable and profitable sensors for job promotion by their employers.

Unlike scientists – who must build their work upon the published literature – engineers develop instruments based on a considerable store of personal experience and unpublished intellectual property jealously withheld from the public domain by those who pay engineers to acquire it.

Unlike scientists – able to access the scientific literature through their institutional libraries – engineers in commercial environments must pay prohibitively expensive prices to access journal articles describing fundamental principles about sap flow and its measurement.

Unlike scientists – who seek an understanding of those same fundamental principles – engineers require very long and intensive training in additional technical disciplines to be able to bridge the gap between scientists and growers.

Unlike the suppliers of the small numbers of custom-built sap flow sensors in use by the scientific community, designers of instruments for irrigators are bounded by the constraints of low price and high reliability. High development costs must be offset by the expectation of a mass market with lower profit margins.

Finally, a ‘new-to-world’ sensor for plant-based irrigation scheduling carries with it the considerable commercial risk of having to educate agents and irrigators alike in the benefits and usage of new technology.

For these reasons and more, it is a fragile bridge indeed across the deep chasm between scientists and irrigators; a bridge that can be crossed only by measurement engineers adequately trained in both the academic and commercial worlds and with an unlikely focus on building sensors for use in irrigating horticultural crops.

This paper describes a sensor engineered in the forge betwixt science and irrigator”

[Andrew at MEA]

Small is Beautiful: the GBug Story

Back in the year 2000, when mobile phones still had buttons, 2G connectivity and text-only screens, and way before we’d even heard of the Internet of Things, MEA built a very simple on-farm sensor network that pre-empted a useful IoT technology of the modern era.

We called this gadget the GBug, because it could continuously record moisture down through the soil profile using gypsum blocks, very simple yet effective sensors dating back to 1940 and sold since then in their hundreds of thousands. Consisting in its most basic form of a cylinder of porous gypsum (calcium sulphate) with two electrodes built in, gypsum blocks are electrical resistance sensors that have three great advantages for on-farm use; they work, they are robust and they’re cheap.

The GBug ticks some of the modern IoT boxes, although in a very clunky old way: it made measurements, stored data while awaiting collection, ran on an ordinary 9V transistor battery for about a year and used radio to upload weeks of data to a Retriever – a small box with simple LCD display and only four buttons. The irrigator simply carried the Retriever from site-to-site, tapped each GBug on its front lid with his knuckle to wake it up and have it transmit its data to the Retriever for portable storage. Then back to the office to download the data via RS232 (later USB) to a computer which displayed graphs and tables. No Internet, no Cloud, no fancy peripherals, no local graphics, but it worked fine.

The GBug and its brethren (the ABug, EBug, TBug and GTBug) sold by the thousands into Australian horticulture and viticulture. It won the Best New Product Prize at the Irrigation 2002 Conference and Exhibition.

So why was the GBug so popular, and what are the lessons for the IoT of today?

Firstly, the GBug married a seriously simple data logger to radio comms and a low-cost reliable sensor, the gypsum block. In itself, it was the first affordable data logger to roll out onto Australian farms. Being simple, farmers had no fear of it.

More importantly though, the real innovation was to make data collection simple. The Retriever killed off the need to carry laptop computers around the farm, and the tiny inbuilt radio killed off the need to have cables and weatherproof connectors. Operating on the unlicensed ‘garage door opener’ ISM frequency of 433 MHz, the GBug talked to the Retriever from a metre away, directly through the plastic enclosures.

Last week MEA tested a prototype GBug Mark II, solidly founded in today’s IoT.

We ditched the Retriever; modern growers have all that portable computing power in their pockets in the shape of their mobile phones. These are blessed with Bluetooth Low Energy (BTLE) for the short-haul radio link from the sensors, so we could ditch the 433 MHz radio. And the long-distance backhaul to the Cloud and MEA’s web application Green Brain via the omnipotent cellular network replaced that old RS232 cable, the computer and that PC-based software package.

Sure, this GBug2 is not as sexy an IoT solution as MEA’s always-on Plexus radio mesh networks, but small growers can trade their time and travel against high initial capital costs, and that appeal has already been proven by the classic GBug.

[Andrew at MEA]

What’s old is new

There’s a sense that the Internet of Things is something new that has suddenly sprung out of a vacuum to take centre stage in our technical world. But like many another ‘overnight sensation’, the IoT too is rooted in the history of early invention.

Let me take one small example - the development of the Sigfox network.

Sigfox arose in Europe to offer a much better platform for all those many IoT applications that need to shift small data payloads with a minuscule energy budget. The Sigfox network is tailor-made for the IoT, especially in comparison to the cellular networks designed for broadband applications such as streaming video, Internet access and all the accoutrements of our modern connected life.

In Australia, Sigfox operates on the sub-GHz band at 920 MHz. Sigfox is an ideal technology for small packets of data (12 bytes) hopping directly to a base station over a distance of up to 20 kms (+27 dBm power output is allowed). Data is essentially ‘transmit only’ at rates that can vary between 1 and 140 times per day. There is a back-channel allowed, but at an even smaller rate of 8 bytes 4 times per day. Data surety is helped along by the same data packet being transmitted on three separate frequencies, ensuring good data throughput even in electrically noisy environments.

For many IoT applications, Sigfox is a good match between cost, data payload and the power available to transmit it.

I first heard of Sigfox on this EA IoT forum, and have since learnt more about it with a sense of fascination, but also a sense of puzzlement. Why did it seem so familiar?

Sixteen years ago MEA built a very similar technology called simply ‘MEA Radio’. It moved 20 byte soil moisture data packets across farms to a central data logger, using the 433 MHz ISM band. Allowable rf power output was +14 dBm, limiting range to about 5 kms at most. Instead of transmitting on three separate frequencies, MEA Radio transmitted the same data packet three times, randomly and redundantly, to get the data through. There was no back channel, no data hopping between network nodes, no way to beat hills that came between sensor locations and the always-listening base station, and no way to catch up if data was lost due to farm operations. Yet it was all surprisingly robust. Many of these simple battery-powered systems are still in operation a decade after they were installed.

So did I invent the Sigfox protocol sixteen years ago?

Heck no!

I got the idea for MEA Radio from the Argos satellite system that went into operation in 1978, developed nearly 40-years ago to move environmental data from remote locations having small power budgets and low data payloads, just like today.

And what was the killer application back then driving this development? – sea surface temperature monitoring. A vast network of sea-going buoys still drift across the world’s oceans, pinging up small one-way packets of location, temperature and salinity data to orbiting satellites that are always listening far above, and which relay data collected to ground stations at a handful of locations when they pass overhead.

[Andrew at MEA]

Human eyeballs and the IoT

A few weeks back I received an email in from Dr Brent Clothier, one of New Zealand’s most progressive and respected plant research scientists, working for Plant and Food Research over there.

Brent had sent along some photos of MEA’s GDot soil moisture display in use in avocados in the Central Highlands of Kenya, with a neat twist; the GDot was connected via the human eyeball and the ubiquitous cellular phone to a web site in far-off New Zealand.

Brent’s comment was: -

“They’re great, as the growers text in the number of dots, so across 6 regions we know the state of the soil’s water”

Brent’s elegant solution to the IoT in Africa was to get growers to text the number of dots to him every day, thus marrying a simple display device via a simple cellular phone to a simple NZ web-site feeding regional soil moisture data back to the scientists working with the growers.

So what is a GDot?

As you can see from the photograph, the GDot is a very simple display device connected to a single gypsum block soil moisture tension sensor buried beneath it.

 That’s Brent digging the hole and showing folk how to identify the active root zone where most of the soil moisture is taken up by the tree’s root system. That’s the depth at which the gypsum block is located.

I developed the GDot for my own large vegetable garden because any irrigation scheduling tool more complex than walking about was just too hard and too expensive for me.

Being both a vegetable grower and an engineer allowed me to solve one problem at home while generating income at work.

Well, that’s the official story, but I suspect that I was really just trying to find a way to design something with those elegantly simple ‘flip-dots’ - wonderful display devices seen on the destination displays of buses. These magnetically-latched bi-colour discs are activated by a simple pulse through push-pull coils on a soft-iron frame, latching either their black or their yellow face outwards. So it’s like a seven-dot thermometer scale, and dead easy to read from a distance of over 10 meters away, allowing ‘drive-by’ soil moisture measurement.

GDots run on a pair of AA alkaline batteries for years, and can be installed and maintained by the grower without recourse to the manufacturer.

GDots have become so popular with Australian irrigators - across dozens of crop types - that MEA manufactures them by the thousand and ships them into Adelaide via the container-load from China.

That’s Australian IP meshed with overseas manufacturing and now connected as an IoT device by African eyeballs.

[Geoff Sizer]

Eyeball Networking reminds me of a wide area networking solution we used last century - "SneakerNet", aka a junior employee with a box of floppy disks ....

On the topic of conveying data from A to B and the independence of payload from the underlying data transport mechanism, any IoT system we develop at Genesys must pass the "Carrier Pidgeon Test" (with Carrier Goose allowed for larger payloads).

 

 

 

 

 

 

[Andrew at MEA]

The IoT Race against Obsolescence

I hold little fear that my competitors will overtake me, but what keeps me awake at night is the fear of being over-run by technological change and parts obsolescence.

Let’s look at some specifics.

In the past two years, we have had two modems declared obsolete by the manufacturer, Sierra Wireless (the Q26 Extreme and the Q2698). These modems operate the gateway between our Plexus sensor mesh networks and the Cloud. They represented something like three man-years of firmware development, all of which is now useless.

There is no plug-in replacement. The whole code-base has to be redeveloped in a completely different operating environment (Linux rather than Open-AT) on a different modem platform.

Similarly, other models of modems used in our weather station sensor networks – also linked to the Cloud – were simply discontinued by the same manufacturer. A ‘piggy-back’ board had to be developed to allow a plug-in replacement, though control lines were different and difficult to carry across, delaying product release.

As for the ZigBee chip sets in our Plexus IoT product, these were marked ‘not for new design’ some years back. Again, there is no plug-in replacement available, though the parts are still available.

Worse still, the original ZigBee standard itself has become dated in just a handful of years, to be replaced by ZigBee Pro, 6LowPAN and Threads.

Again, a major rewrite needed and failure of backward compatibility in product streams expected (by the farmers who use them) to have a working life of at least a decade.

Strategies for coping with such obsolescence include holding large stocks of obsolete parts, or  continuous re-work of firmware and PCBs. This is a significant impost on a business’s product development team, amounting to unproductive wheel-spinning with no benefits to the end-customer or the business beyond continued existence.

Useful product development falls behind, with priorities skewed to keeping the production line rolling. These senseless activities are outside our control, thrust upon us by decisions made in far-off board-rooms.

These hidden costs are just one more risk element to be accounted for in working in the IoT product development business.

On the up-side, newer chip-sets are often smarter, less 'buggy'  and operate at lower power levels.

Spot the obsolete components in the photo below!