Jump to content

What does it take to be an IoT engineer?

Andrew at MEA

Recommended Posts

To Mesh or Not Mesh – that’s the question!

The burgeoning technology base beneath the Internet-of-Things (IoT) offers a plethora of possible technologies for shifting data (in MEA’s case) from on-farm monitoring systems to users.

One of the central questions facing product developers in this field is whether or not to operate using ‘meshing’ technology.

Within a meshed radio network, you get all these smart IoT-enabled devices to help each other out by passing data along a self-healing mesh network to get better coverage and more reliable data delivery.

According to a rough look at our competitors’ products, the choice made has largely been ‘not’ to form IoT sensor mesh networks. They have chosen instead to force each measurement node to find its way directly to the Cloud or a local PC.

So what are the arguments either way?

Sensor Mesh-Networks have a number of solid advantages for on-farm monitoring. They work well in complex terrain with multiple sites, especially if cellular coverage is poor and line-of-site radio doesn't work. Mesh networks can solve connectivity problems through the use of repeaters, and can fill in data gaps if farm operations require field stations to be down for any reason. Measurement siting can be optimised to the crop, rather than to the availability of radio connectivity. Mesh-network field stations can run at lower power levels than single-point cellular field stations, allowing more frequent data updates, useful if farmers are tracking irrigation or frost activity. Mesh networks allow optimal siting of a single hub on the property for cellular gateways, which is advantageous at the periphery of the cellular coverage areas. Only a single SIM card per farm is necessary, reducing on-going costs. Potential use of ZigBee end-point technology would allow wireless sensors from below canopy within crops, reducing mounting costs while simplifying obstruction issues.

Plexus test site at Oxford Landing.JPG

The disadvantages of mesh networks are the expense of the base station for small systems and the more complex installation procedures needed to bind stations to networks (‘installation mode’). Typically, these devices need to be above the crop for solar and radio access, necessitating more expensive mounting hardware in comparison to below-canopy systems such as cellular, and potentially hindering farm operations. Such networks are mostly based on 2.4 GHz technology – rather than the longer-range sub-GHz technologies - limiting the distance between ‘hops’ to about 1 km over flat country.

Single-point monitoring sites – by comparison – are typically better suited to small systems of a few stations, or widely distributed systems. Because they have largely been based on cellular phone technology (prior to the arrival of Sigfox and similar technologies), they are allowed to transmit at higher radio-frequency power levels, allowing long distances between field stations and cell towers. These high power transmissions and cellular towers located on tall structures allow them to be located below the crop canopy out of harm’s way, while simultaneously reducing the cost of mounting hardware. Higher bandwidths associated with normal cell phones makes possible such heavy data payloads as images or high-density data.

The disadvantage of single-point monitoring sites is that they typically operate from long-life non-rechargeable batteries because of poor solar access below crop canopies. This limits data upload and viewing rates to once per day. They cannot be contacted for most of the day, because they are powered down, so system testing is problematic (they need to pick up messages and then act on them when they wake and contact the remote server). They need a clear line between measurement sites and cellular towers, and are poor performers where cellular coverage is patchy or in hilly country. Power consumption is higher for cellular modems than for other radio technologies, reducing energy efficiencies. Radios located at ground level have reduced range.

In summary

The technology dilemma facing IoT product developers is being recognised by the silicon manufacturers who are responding by creating ‘dual technology’ systems for field stations, such as Bluetooth and more advanced versions of ‘ZigBee’-style technologies that can form mesh networks. Narrow-band cellular networks will also arrive within the next two years, allowing lower data rates over the far-reaching Telco networks, pushing cellular modems aside in single-point applications. Single-point networks such as Sigfox will continue to operate effectively in areas with a high-density of users and good base-station coverage, but will struggle in far-flung highly dispersed environments.

A satellite system such as Myriota is the ‘disruptive technology’ in the mix if the engineers at Myriota can pull off. These are small low power low cost data points can be located anywhere. They require no base stations – those are already orbiting the earth.

  • Like 1
Link to comment
Share on other sites

The approach we are following at Genesys is to have a multiple way bet.

For Wireless LANs, we are focussing on 6LoWPAN (similar to Zigbee but open-source) in both 2.4 GHz and 915 MHz bands.  Networks can be configured as star topology, or meshed/repeaterized simply by turning on meshing in some or all nodes.  To be most effective, the meshing nodes require a continually available power source - eg mains derived, or solar+battery.

For PANs, we are using BLE - and WiFi for mobile device access.

WANs are presently stuck with 3G/4G, plus a number of intiialives using Sigfox where it is suitable.  We anxiously await NB-IOT and if they get their act together with a national rollout, LoRa/Taggle/Ingenu/Myriota LPWANs.

And, of course, boring old wired networks (NBN, ADSL, Ethernet, RS-485, CAN bus) also feature.  (Why use wireless when a perfectly good piece of wire will do?)

We are designing highly modular connectivity solutions as plug-on modules, to avoid hitching our wagon to the wrong star.  This also facilitates multi-network solutions for redundancy.



Link to comment
Share on other sites

On 26/11/2016 at 3:38 PM, Geoff Sizer said:

 "To be most effective, the meshing nodes require a continually available power source - eg mains derived, or solar+battery."

Thanks Geoff

Couldn't agree more – with 6LowPAN, multiple technologies, NB-IoT and modularity.

The problem with mesh-networks is the need to keep the repeater nodes (‘routers’) always powered on. This is simply not practicable on a solar-battery budget, unless you don’t mind a big chunky solar panel and fat awkward battery in the mix.

Plexus resolved that issue by re-synchronising clocks at every node at every 15 minute measurement interval, then powering down the network for 14 minutes in every 15. The whole network wakes up simultaneously and the mesh is refashioned for that one minute, during which all traffic and housekeeping activity happens.




  • Like 1
Link to comment
Share on other sites

3 hours ago, Andrew at MEA said:

The problem with mesh-networks is the need to keep the repeater nodes (‘routers’) always powered on. This is simply not practicable on a solar-battery budget, unless you don’t mind a big chunky solar panel and fat awkward battery in the mix.


That's the kicker for me - I worked for a long time on applications for mesh networks, and it was this gotcha that killed it. ZigBee (and the 6LoWPAN family) promised so much and battery-powered (periodic sleeping) mesh repeaters is actually part of the ZigBee spec. Turns out no manufacturer supports it because the practicalities of synchronising sleeping nodes in a reliable way to perform mesh networking without compromising energy consumption is just not feasible.

For now, mesh is relegated to academic projects. If each node contributing to the mesh has to be powered/always on anyway, then you may as well go with a more traditional star network.

Which is one reason I find LPWANs so exciting - finally there is a low power, low complexity, wireless comms solution for relatively dumb and sleepy nodes. While we wait for national rollouts, we're installing our own LoRaWAN networks to get the job done. I literally just commissioned one last week, so while it is seriously bleeding edge, with all the inherent cuts and bruises, it's into the realm of here and now.

Link to comment
Share on other sites

32 minutes ago, Heath said:


"That's the kicker for me - I worked for a long time on applications for mesh networks, and it was this gotcha that killed it. ZigBee (and the 6LoWPAN family) promised so much and battery-powered (periodic sleeping) mesh repeaters is actually part of the ZigBee spec. Turns out no manufacturer supports it because the practicalities of synchronising sleeping nodes in a reliable way to perform mesh networking without compromising energy consumption is just not feasible.

For now, mesh is relegated to academic projects."

Hi Heath

Thanks for your reply; you've nailed the 'gotcha' with mesh-networks precisely.

The Plexus development team at MEA solved the problem (as per my recent response to Geoff) by creating the synchronization in the 'applications layer', simply because the chip manufactures didn't have that in their ZigBee stack. [They also never got the very low power ZigBee 'end-point' to work, but that's another story]

What's not apparent in my reply is where the real architectural design effort comes in; during non-standard binding of nodes to a working system that is already synchronised.

How do you pass the network time to a node that's been out-of-range, off getting serviced or newly-joined during a system expansion?

The answer lies in implementing a 'search mode' that keeps the joining node awake for four hours, then off for two. [The slowest netwrok refresh rate is two hours, so you span any activity with this pattern]. When the new joining station is taken out of its box and powered on, it's always listening for its caller id, responding asynchronously when it hears it, gets told what everyone else is doing and how to conform, then stepping into line while returning to low power mode.

The same is true if the Hub (or 'co-ordinator' in ZigBee language) falls off for any reason; all the field stations get busy looking for their lost mother, using up the finite amount of energy stored in their batteries.

This is the central reason that mesh networks need a source of ambient energy harvesting; battery capacity has to carry them through network outages into a calm place where they can recharge. This 'search mode' would knock primary cells about pretty badly.

Do all this, and mesh-networking under field conditions is entirely feasible.

MEA's Plexus mesh networks are deployed all across Australia, at over 400 sites and with more than a thousand nodes. Data entries to the Green Brain database recently passed 356 million, with 100 new entries every second.

So it's possible to make it work with sufficient effort at the application level; the chip manufacturers have - as you say - spat the dummy on the really useful things needed by such mesh networks.

Maybe the newer chip sets do better?


Link to comment
Share on other sites

Some ZigBee things that didn't work

After four decades of studying datasheets, I've learnt that you’ll never actually discover in there what’s wrong with the current product - that enlightenment only happens when its successor or competitor arrives.

This proved to be true for our CC2480 ZigBee chips in our MEA Plexus mesh networking radios; there were things that all of our struggles and forum posts just couldn’t make happen. The ZigBee standard suggests that they should.

Here’s the story behind two of them…

1) Deep networks

The ZigBee specification and some basic mathematics suggest that there’s room for at least a 1000 nodes in a ZigBee network, but we were just unable to make this work in practice.

In fact, the parent-child relationship between ZigBee ‘routers’ means that any field station more than five steps away from the Hub just won’t get a ticket to join the network, no matter how lightly spaced other nodes are in between.

What this means is that Plexus struggles to deliver data from one end of a long thin property to the other. It hasn’t yet caused us a problem, but it would limit us in very large systems.

This ‘five-hop limit’ seems to have been arbitrarily imposed over the original ZigBee standard to suit the whims of the software engineers implementing that particular CC2480 version of the ZigBee stack.

Maybe it’s been fixed in more modern chips sets that arrived in the past three years?

2) ‘End-point’ devices are still way off into the future

The ZigBee standard was developed for radio-linking sensor networks, with particular attention given to those devices running off batteries and therefore unable to route traffic from nearby devices along the mesh.

These so-called ‘end-point’ devices should be able to cluster around ‘routers’, solving sensor-to-radio cabling issues by creating a short radio link between ground-based sensors and above-canopy routers just tens of meters away.

We spent months using our best engineers in an attempt to crack this one.

It would have allowed us to get damage-probe cables out of vineyards and orchards. How sweet would that be?

We couldn’t make it work, so eventually concluded that it was never implemented in that version of ZigBee.

We contacted the manufacturer about it (the giant Texas Instruments), only to be told that we shouldn’t be using that old product (which they were still selling) and should move on to something more modern.

In summary

One has to design with the current IoT technology, even while knowing that it will likely be obsolete or superseded by a better ‘less buggy’ product by the time one gets to product launch.

So you will likely spend much fruitless efforts creating ‘work-arounds’ for today’s bugs in the knowledge that you will be handed a whole new set in the next round of product release.

That’s just how it is.

Link to comment
Share on other sites

On 01/12/2016 at 1:43 PM, Andrew at MEA said:

That’s just how it is.

So very true. But your willingness to share makes a huge difference.

Many times we have developed a product to meet the expectations set by OEM marketing, using the information provided by the datasheets, with hard won expertise from decades of training, only to discover that we're the guinea pigs finding that the practical limitations fall short of the potential.

As much as I love to jump on board the next great thing and develop on the latest technology, I've learnt to stay wary of anything that doesn't have a "community" around it. The power of the community is extraordinary, and it explains (in a self-fulfilling kind of way) the success of the Arduino over the STM32 Discovery, the Raspberry Pi over the VoCore, Linux over BSD. It's natural to dismiss these projects as "hobbyist" (and I do, sometimes) but the fact is it is just too time consuming and risky to discover the limitations on your lonesome, no matter how clever and professional you are. You either become the pioneer, investing months and significant dollars to find you've designed your way into a dead-end and the competition is about to leap-frog you, or you navigate the community forums and figure out the capabilities and gotchas from the collective power of the "hobbyists".

Fortunately by the time I began my ZigBee journey, the community had caught up, and I was able to do my research and set my expectations without much investment.

On the LPWAN front, of great interest to many IoT practitioners, I've had a foot in both camps. I started by waiting and watching for the community to form, to learn from the scouts at the coalface, suffering the early blows. But I've also discovered that given the focus on European and US markets, and the fact that the Australian market actually has unique technical challenges, that there's value in taking some lead in developing that community. I recently learnt I'm only one of 4 people in Australia with a functioning, Australian regulation compliant, LoRaWAN network made up of components from more than one vendor. Those painful steps into the unknown command a valuable, if fleeting, position in the marketplace.

Link to comment
Share on other sites

Solar Energy Harvesting for the IoT

For outdoor applications of IoT mesh networks, the easiest source of on-the-spot energy generation is solar.

Energy harvesting is particularly important in long-term pseudo real-time IoT measurement systems that are slated to run for nearly a decade through all seasons and weather conditions.

Non-rechargeable batteries just would not have the energy capacity for these extended periods of operation, particularly when data updates need to be transmitted four times per hour, and extra energy drain kicks in during network disturbances.

Solar panels are cheap and reasonably robust, but have to be operated with care to extract the maximum usable energy and to store it in a Lithium Ion battery. Li-Ion batteries are light-weight, have excellent charge/discharge characteristics and are capable of running for many years if charged with special care.

So today’s quiz question is:

“Years after designing the original Plexus solar-battery power train, MEA was still trying to shake the bugs out of which component?

1.       the solar panel?

2.       the maximum power point tracking (MPPT) charger?

3.       the power monitoring system?

4.       the battery?”

Surprisingly, the answer is that the solar panel itself gave us the most grief.

Let’s see why…

Firstly, these solar panels are cheap – AUD$2.83 in quantities of 1000, which is our standard buy quantity.

Plexus uses 5V monocrystalline solar panels; these are a good match for 3.6V lithium-ion cell having a 2500 mAh capacity, and will deliver 400 mW at peak solar power of 1000 W/m2. Our rule-of-thumb for determining average available energy – tested over three decades and thousands of solar battery systems – is ‘the 10% rule’. This states that you can count on an average year-round current of 10% of peak current (80 mA peak at 5V for a 400 mW panel). So that makes the average available current  8 mA, through long winter nights, cloudy weather, high temperature conditions that restrict charge generation and so forth.

No need to test them, right? – these are trivial two-terminal devices that should simply work?

Plexus in Test Yard_DSC6836.jpg

Once Plexus was in production and rolling out across the Australian landscape, we began to experience mysterious failures in the charging circuit, traced eventually to weak solar panels in every batch.

We built automatic load testers to compare selected panels against our standard pyranometer located on the roof of MEA in full sunshine, but could never be sure of the output because these little chaps are hugely sensitive to temperature.

Furthermore, as we manufacture year-round, we needed an indoor tester, so moved to a purpose-built xenon-flash system that didn't heat the panels and allowed us to compare every incoming panel against a standard ‘weak’ panel.

But despite 100% testing under this new regime, we continued to experience field failures.

Finally, after months of effort, we built a charge accumulation system that tested every panel against a standard panel under forced heating, loading and irradiance conditions in a home-brewed calibrator, rejecting up to 30% of incoming panels.

Well after product release, we’d finally beaten one more tiny bug in the production of a successful IoT device.

And the moral of this story?

Sometimes bugs don’t turn up until you begin to generate product in sufficient numbers to throw up the outliers. You have to catch those by extensive production testing.

Link to comment
Share on other sites

The IoT and the Software Elephant

The modern world is abuzz with the glory and potential of Big Data, Data Analytics, software in the Cloud, phone apps, web apps, algorithm-driven servitization of business and so on and so forth.

It’s a new world, exploding in our face.

With the ‘half-life’ of software engineers shrunk to around 18 months, it’s a wonder we were able to find just the right folk to create all the software elements required.

These needed to power both MEA’s Plexus on-farm IoT system and the Green Brain web app that stores data in the Cloud and delivers it to farmers when needed.

It was a case of creating all these myriad chunks of software or fail to connect the farmer to his sensor data, and fail in business.

Along the journey, we stumbled into one bear trap after another.

If ‘oils ain’t oils’, then neither are software engineers software engineers. They come in different flavours and with different mind-sets, and don’t appear to be interchangeable or all that cross-platform adaptable.

Down at the sensor coalface, one of our home-grown embedded firmware engineers needed to enact the exquisite timing within Plexus field stations to extract data from smart sensors via the digital SDI-12 bus.

Just slightly upstream of him, another firmware engineer out of the University of Melbourne – also writing in C – created the ZigBee applications layer that shaped how data was gathered, stored and moved over the ZigBee mesh network.

Upstream of him was a firmware/PC engineer out of Adelaide university orchestrating the data flow into and out of the central Hub in the Plexus network, connecting data from across the farm up to the Cloud via 3G/4G modem technology, responding to SMS commands, generating reports, sorting fragmented data packets and such-like chores.

Our old PC-based software data platform (called ‘Magpie software’) was adapted during the product development days to programming Hubs and modems and setting up systems, running mesh diagnostics, filing and concatenating data and all the stuff we’d been doing with field measurements for three decades already.

Another home-grown senior technical officer within MEA used 'Auto-IT' software to drive all the test and measurement gear that ran Plexus hardware through its paces on the production line.

Now the going got even tougher, because upstream of all these engineers was a web-app engineer, and this was a new species altogether.

By now, old hardware engineers such as myself were way beyond our comfort zone, adrift in a sea of incomprehensible terms such as Drupal, My SQL, Pythons, Daemons, PHP, web sockets, ftp, http and I can’t remember what else.

Our own software engineers were also at sea, though looking slightly less puzzled than I.

So we tried out various wandering Samaritans who claimed to have the goods in this brave new web-coding world, but who in fact fell short with exhaustion after pointing the way ahead.

Finally – by the usual odd mix of accident, fate and just ‘being there’ - we found just the right guy – a New Zealander this time -  and MEA’s Green Brain was born.

Was this the end of the pain?

When you’re slamming data into the Cloud from a rising tide of sensor networks, while simultaneously being hit up by an equal number of impatient data-hungry farmers from their smart phones, speed becomes an issue. Security becomes an issue. On-line diagnostic tools become an issue. Smart-phone compatibility – such as different screen sizes – becomes an issue.

So that’s the story of being an IoT engineer; you need to grasp a little of just about everything, guiding the young bucks down the product development runway in the hope that they will take off smoothly rather than run off into the grass.

Now for the next generation of technology...

Link to comment
Share on other sites

The IoT and the End of the Machine Age

Long before I could operate an oscilloscope I was working with lathes, mills and drills in Dad’s custom mechanical engineering factory, paying my way through University. Of his six kids, it was only I who inherited his ‘knack’ with all things electrical and mechanical.

When the time came to choose a career I told Dad – in all my youthful arrogance – that the Machine Age was ended and that the new dawn was in the field of electronic engineering.

Now – with yet another era dominating the landscape with the IoT and software engineering – I’ve often had reason to be grateful for those formative years on the factory floor, because even the IoT wouldn’t stand up without a strong element of mechanical engineering and industrial design.

And rather than disappearing with the drawing board and the capstan lathe, mechanical engineering has leapt ahead with powerful CAD tools, 3D printing, over-moulding, CNC sheet-metal forming machines, 5-axis milling machines for tool making and prototyping and all the wonders of injection moulding for mass production.

So MEA’s Plexus IoT development team made use of all these modern accouterments of mechanical and industrial design, and I tracked along behind our mechanical engineer and industrial designer with no real difficulty in understanding what was going on, because all this diversity is just more grist for the mill for a measurement engineer such as myself, surely the most general purpose practitioner in the whole field of engineering.

MEA built tall masts for pecan, avocado and almond orchards, springy mounts for low-lying vegetable and strawberry crops, and ‘push-over spring-back’ Plexus field station masts for row crops with over-row machinery involved. We built lower-cost sensors with over-moulded bodies. We 3D-printed parts for our Plexus production jigs. We worked through the processes of getting injection-moulded parts in polycarbonate and silicone and mass-production issues in China sorted out. We created custom connector blocks and hydrophobic vents for Plexus field stations.

As with all aspects of the Plexus project, we also got cut and bruised and humiliated by our failures, only to return again and again with new solutions forged in the desperate need to keep our reputation and company alive.

Some years and several million dollars later, we are only now crawling off the steep up-slope of IoT product development onto one of those intermediate plateaus where one rests and looks ahead to the next round of development.

Now the heavy lifting within MEA is being done by our management and marketing folk, whose job it is to create a systematic structure within the company, to create strategic, marketing and product development direction, find channels to market, appoint agents and solve their problems, and keep the cash flow working.

Despite my longings to be a lone inventor in my home lab – without daily business, management and personnel hassles - I’ve learnt that only a multi-disciplinary team approach can create new products and successfully bring them to market.

I suspect this lesson is as old as business itself, yet especially true for the multi-disciplinary field of the IoT.

Link to comment
Share on other sites

This is a terrific story. I hope you're planning to publish wider (perhaps somewhere on LinkedIn?).

The story stands on its own two feet, but I'm especially drawn having marvelled at the Plexus/Green Brain system when trying to find an opening for my startup business. We went 80% the way towards developing a remote compost pile temperature monitor with many aspects in common with Plexus, but ultimately the project didn't go ahead.

The path we have taken, that of Smart Parking, went live on Friday and your story rings home. We set out with a very simple goal - count cars as they enter and leave a car park facility to determine the total occupancy level. What we ended up with starts with a pneumatic system with road anchors, rubber tension properties and a tuned pressure threshold. It passes through an analog electrical interface to a sleeping PIC microcontroller with very tight operating limits for maximum battery life. Then it's into the RF world of LoRaWAN with carefully mapped RSSI patterns as well as robust packet redundancy and reconstruction. The data starts as bytes from an ADC and gets wrapped into JSON for processing and distribution in the NodeJS environment, Node-RED. It splits and goes via MQTT to an IoT cloud backend where it is further processed in Go to produce the raw data for consumption via a couple of different HTML webapps. The other channel converts to CSV and goes via TCP to logstash to populate the NoSQL database1 Elasticsearch for searching and graphing with Kibana.

Sometimes I stop and wonder if anyone realises what world we've managed to build for ourselves. Perhaps it's inevitable - the customer wants simple and powerful, so behind the scenes an army of engineers from all disciplines build their world ever more powerful and compatible. Before you know it, every little "app" requires the coordination of the latest and greatest from mechanical, industrial, embedded, electrical, telecomms, software and UX engineers. And that's before you even manage to define a product that matches a market, or has great distribution, sales and support.


1. Yes, calling Elasticsearch a NoSQL database is a gross simplification. So be it.

Link to comment
Share on other sites

The IoT and Mr Murphy

One of the hallmarks of intelligence is that you can give directions without taking your hands out of your pockets.

One of the hallmarks of a good service department is that they too can carry out long distance fault diagnosis over the phone; any specious hand-waving is invisible to the person at the other end of the line.

MEA has sent many many thousands of data logging systems into the field since I founded the company back in 1984. In the intervening three decades, I’ve sat within hearing distance of the service department and listened in on our end of conversations between service techs and remote customers.

The sheer diversity of things that can go wrong in the bush would have Mr Murphy re-writing his own laws, particularly rule number 34: “Mother Nature is a bitch!”

When folk start quoting how many billion IoT devices will have been deployed by 2020, my mind leaps directly to the question of who will keep these devices working?

MEA’s Plexus mesh-network is just such an IoT system, feeding data from sensors to farmers via ZigBee, cellular and cloud services.

And yes, those phones in the service department still ring.

And as engineering director, I get to sit through production, service and product development meetings, trying to hose down one issue after another.

I could launch into war stories, but there are too many.

Suffice it to say that Murphy was probably an engineer, and that engineering is the business of trying to control the chaos that is the real world.

There will be no perfect products in the IoT world, because human error, Acts of God and Mother Nature will all conspire in all the usual ways.

If that’s inevitable, service departments will act as a drag on the successful deployment of all those billions of IoT devices.

Link to comment
Share on other sites

At one point I swore myself off any engineering project that involved (1) wireless comms, (2) self-sufficient battery power or (3) sleeping microcontrollers. Some how I chose to launch a business right in the triple point that is IoT sensors. After losing a day today dealing with a maddening signal strength issue that popped up out of nowhere, I remember why I made that declaration!

Link to comment
Share on other sites

The IoT and Electro-Magnetic Compliance (EMC)

The radio spectrum is infinitely more crowded than it was 114 years ago when Guglielmo Marconi launched the first long-distance transatlantic radio signals on the 350 metre band (~850 MHz). Keeping order amidst chaos are the various spectrum management authorities around the world, because the rf spectrum is considered to be a national resource up there with water, land, fossil fuels and minerals.

Different countries make different use of different parts of the radio spectrum, so developing an IoT product that is ‘international’ and ‘free-to-air’ narrowed our options for the Plexus on-farm IoT developments down to the worldwide 2.45 GHz ISM (industrial, scientific and medical) band.

Other worldwide channels exist, but generally at such low frequencies that antenna size and bit-rate become a problem, or at such high frequencies that transmission distances are affected.

But the over-arching decision to choose the 2.4 GHz band is that that is where the IoT technologies abide: ZigBee, 6LowPan, Wi-Fi and Bluetooth, among others.

Restrictions apply, especially to allowable transmission power – limiting transmission distance – and the narrowness of the allowable signal ‘spread’ around the centre frequency.

And here Plexus ran into its first brick wall; our IoT ZigBee transceivers – built in the good old USA – proved to be outside American FCC guidelines when we actually put them up on the spectrum analyser during pre-compliance testing for EMC certification. Good enough for Australia, but failing to meet the specifications in the manufacturer’s own data sheet.

Much hunting around turned up some SMT bandpass filters centred on 2.45 GHZ that fitted Plexus with ‘spectacles’ that would allow it to pass the FCC testing. This unwieldly solution squeaked Plexus through our in-house tests, but we baulked at taking on full radio spectrum compliance testing, with the accompanying price tag in the order of $20 000. Better to wait for more modern ZigBee chips sets perhaps, or a new dawn in the US agricultural market?

Back in our own vast testing ground of Australia, Plexus achieved full EMC compliance, even without his specs on. All we had to do was set up special versions of the system to run the radio continuously – something that never happens under field conditions – so the EMC test house could get a lock on our signals.

So were we out of the woods now?


It seems unlikely that there is a less crowded band than that centred on 2.45 GHz, but there are few interference problems out there among the trees and vines of our natural turf.

But then we took orders for Plexus soil moisture systems below the turf on some of Australia’s most famous race-tracks, only to find that these folks go to elaborate lengths to make Wi-Fi (with its frequencies bands over-lapping Plexus’ ZigBee channels) available to punters even in the car-parks alongside the track, thus providing them with every possible opportunity to place their bets.

Plexus was blinded, deaf and dumb.


On-site rf spectrum sniffer tests showed the truly amazing clutter of activity right across all available channels, rising and falling with race day and office activity.

Only careful siting of Plexus field stations and repeaters solved the agony of measurement blind spots.

So I guess we’ll be sticking to the country rather than the city for this type of technology…

Link to comment
Share on other sites

Sensors and Standards

Sensors sit at the interface between the real world and the parallel IoT universe.

And it is here – at this most messy of junctions – that Mother Nature wreaks maximum havoc upon young unblooded IoT enthusiasts.

Here’s where raw sewage enters IoT systems and - in my view - no amount of artificial intelligence or post-processing of data can rectify the loss of that small piece of history.

I like sensors. I like designing sensors. I like figuring out how to run them forever on the smell of an oily electron. I like deploying sensors and studying the data they produce while grappling with the meaning of what they’ve been reporting over time.

So, it is with some sense of restraint that I refrain here from succumbing to that very personal enthusiasm for sensors themselves, and restrict myself to just talking about that other interface, between the sensor and the IoT transmitter.

In my field of environmental measurements, ‘smart sensors’ talk to data loggers and Plexus field stations over an ageing three-wire serial interface known as SDI-12, short for ‘Serial Data Interface at 1200 baud’. This is an industry standard first released in 1988, following development by a coalition which included the U.S. Geological Survey's Hydrologic Instrumentation Facility and a group of private companies including Campbell Scientific. The SDI-12 Specification is maintained by a non-profit corporation called the SDI-12 Support Group.

So there is an ‘SDI-12 Standard’ and, in principle, all sensors and all data acquisition systems adhere perfectly to that standard and work seamlessly and interchangeably.

If only that were true…

MEA qualifies sensors for operation on our Plexus on-farm IoT systems, and they must pass through a rigorous compliance testing procedure to get a ticket to ride. Any deviations from the SDI-12 standard are reported back to the sensor manufacturer during this process.

But occasionally, other folk choose other on-farm sensors, and expect Plexus to make the measurements and carry the data load. Here’s where full compliance to the standard is critical for interoperability between different manufacturers.

In this case study, mysterious data dropouts stacked up the barricades and ramped up the rhetoric between MEA, the sensor manufacturer and our common field agent. Who’s responsible?

It is here – within these problem jobs – that good companies prove their mettle, despite the agony that goes along with having their brand tarnished in the marketplace by a system that’s simply not delivering critical irrigation data.

This problem was hand-balled back to the engineers in MEA’s product development group, and we made trips to site and set up long-term tests in the lab back in Adelaide. Months passed as we waited for faults to show, and for theories and remedies to be tested.

This is where the Standard is so useful, because he who conforms best holds the moral high ground.

In this case, the Standard is actually embodied in a piece of hardware one purchases from the USA; it runs both SDI-12 sensors and recorders through exhaustive timing and response tests. All sins are revealed. A detailed report is generated.

SDI-12 verifier.jpg

MEA’s Plexus sensor interfaces passed with flying colours, but the sensor’s SDI-12 interface was in serious breach.

But in this IoT business, who’s right and who’s wrong matters little. Fixing the fault and getting data to flow is all.

Link to comment
Share on other sites

Behind the scenes of the IoT

It’s the week between Christmas and New Year, and I’m alone inside MEA, manning the service desk.

It hasn’t helped that a storm ripped through Adelaide on Boxing Day, shutting down power and phones to our factory in Magill and disabling all communications to the outside world, except for my solitary mobile phone.

So I’ve sat here in the dim light coming through my office windows, and taken calls from across Australia from guys still in the field and grappling with installation and service issues. They’ve been directed to my number by a jolly message on the front page of the MEA website, deployed from outside the war zone by one of our own who lives where the power has remained on.

It’s here at the front line that I find myself most grateful for all the diagnostic tools that we built into our Plexus-Green Brain on-farm IoT products. These enable me to dig deep into problems and kick-start systems remotely, or order up a swap-out system as a last resort.

From a ‘big data’ standpoint all these network codes - battery voltages, fuse checks, power flags, measurement status bits, error and timing violations flags – are just so much redundant baggage riding pointlessly along with real data.

But at the service desk, these tools – and those that allow us to look behind the scenes within the Green Brain databases - are an indispensable facet of determining where problems lie and what actions might dig us out of the current fix. All this while the installer is standing in the hot sun waiting for a call back and some lucid and succinct service advice.

But that’s not even the really good stuff!

At the highest level – seen by the customer – Green Brain itself combs through incoming data and ‘colour flags’ sites that show sensor faults or have failed to report in for over 12 hours. Green Brain can also pro-actively generate alarms by SMS and email, triggered by user settings.

At the hardware level on ground, we’d set up our Plexus Hubs to respond to simple text message commands, which they deal with immediately. We can change network logging rates, query firmware versions, check times, kick off network resets, force unloads, generate reports, clear memory and alter network timing parameters – all remotely.

Simplifying all this is a phone app, built by one of our senior technical officers in his spare time, just for the fun of it.

Through all this, Plexus remains invariably polite, responding with a cheery ‘OK’ when called upon to make changes, large and small.

Yet the future holds even more magic, known in the trade as ‘over-air-programming’ or OAP. This will allow bug-fixes and new features to be disseminated globally across Plexus networks while remaining invisible to the user.


Need I say it?

The data sheets for our current modems exalted their ability to conduct over-air-programming, but we could never make it work. Nor could the company’s own applications engineers; the possibility was eventually abandoned.

Down in the MEA lab, we are working with the very latest generation of new OAP-enabled modems, while secretly harbouring fears that the gap between the promise and the reality of OAP will be filled with hot air.

Link to comment
Share on other sites

The IoT and those tiny radios

Out the back of MEA stands our test yard, a fenced compound accessible from the factory floor via a ramp, and fully accessible to sun, rain and storm.

For the past thirty years, it’s been this MEA test yard that has kept our reputation alive for being a reliable supplier of measurement systems for the bush. It’s our first line of defence against the horrors of system ‘out-of-box’ failures.

Stated simply “the degree of aggravation for the service department rises exponentially with the distance from MEA’s back door.”

Through this test yard have passed countless MEA weather stations, wind and solar monitoring systems, irrigation, hydrographic, stratification, soil moisture and custom measurement systems of all sorts. All destined for far-away places where they would be erected and put directly into action. The two weeks that systems spent in the test yard was our guarantee that we hadn’t missed any basic wiring cock-ups, unseen sensor logging or communications faults or system programming errors. Likely field faults were therefore reduced to those that occurred in transit or due to operator-error at the other end. We had test data to refer back to.

Yet now the MEA test yard stands empty; Plexus and the IoT have changed all that.

Test yards and custom-engineering go hand-in-hand, but how do you test IoT radios when you change lanes from custom measurement engineering to becoming an IoT manufacturer? Stuff is now rolling down a production line rather than receiving the tender devotions of a dedicated technician.

This turns out to be a production measurement issue of high order.

Our first pass at the problem was to assume that the ZigBee radio manufacturer (the mighty Texas Instruments) put all that comprehensive radio testing upfront, and that all we needed to do was to turn the handle on the sausage machine and Plexus radios would roll off into their shipping boxes.

Pretty soon the rule of ‘exponential aggravation’ kicked in and we seemed to be having issues with weak radios under field conditions. Secondary lightning strike during storm activity was implicated in some cases, damaging the radio ‘rf front-ends’. But there seemed to be production issues involved too. This was likely to be the same old numbers game; the more systems that get shipped, the more likely you are to find the faults in that small number of units that aren’t fit for duty.


Plexus radios were being 100% tested on the production line, but only over a through-air radio path of a few meters. Weak radios can make this hop, but not the 1 km expected of them over flat country under field conditions. In a mesh network, a weak radio can take down a segment of a whole network by failing to keep its end up.

But how do you test radios short of the onerous old business of actually physically separating them by a kilometre?

Turns out the old ways are best; conduct a full system test before shipment of a customer’s order, but with a twist. We do this inside MEA, and not outside in the test yard.

It transpires that pushing 2.4 GHz radio traffic through double pre-cast concrete walls – with all their internal steel reinforcing mesh - is a suitably tough attenuation path to weed out under-performing radios.

Link to comment
Share on other sites


The IoT and the 5% Rule

I love old adages and, as I get older, I love saddling younger engineers with them, whether they want to hear them or not.

Yet during 2016 – now deceased – I was painfully reminded of my own favourite: ‘The last 5% of any job consumes 95% of the effort’.

2016 was a year burdened by the most extraordinary efforts, with what seemed to be almost no forward progress. We were busy cleaning up the last 5% of the Plexus project.

The list of tweaks is long and tiresome and I’ve no wish to re-live them here. Suffice it to say that those efforts raised the bulwarks against future in-field failures through product recall, product revamp, hardware and firmware upgrades, re-tooling, re-jigging, re-thinking, re-engineering, re-documenting and re-vamping. It was enough to make a man think about re-tiring!

So we got through all that and the Plexus on-farm IoT system is solid enough for us to keep marketing it until we obsolete it ourselves with new product offerings.

Down in the MEA basement – where all the MEA technical folk live – I once again call in the scouts whose mission is to roam ahead of our main force and understand where technology is going. In the rapidly-changing world of the IoT, this is a critical role and best done by the young bucks. It will be their world.

Mine is the larger role of digesting all this techno-babble and regurgitating it in its simplest and mildest form within MEA’s product development team. This is a very small group of three representing management, marketing and engineering. Our task is to answer the question ‘where to from here?’

One of the other painful lessons of the past few years has been to learn that an engineering perspective has only a limited bearing upon these larger questions. Marketing folk present the customers’ and competitors’ perspectives and management must answer the question of how new product development will be funded, its likely profitability and our chances of affording it.


In a small self-funded company like MEA, there is very little room for misjudgment here, so there’s plenty of round-table discussion going on, sometimes heated and sometimes for months on end. Talking is cheap, so we do all that up-front before we start shelling out our hard-earned dollars in actually creating hardware and software.

I’ve been in a slump these past months, worn down by the inexorable pressures to finish the existing product development while totally fogged in over new product directions. However, I’ve lived with this sense of uncertainty often enough throughout a forty-year engineering career, so it no longer alarms me. It’s a precursor to that ‘Eureka’ moment brewing in my subconscious, where all these disparate pieces of market and technological insight that have been swirling about looking for a place to land, land.

The world of the IoT has changed markedly since I was brooding away in a similar vein back in 2011, prior to giving birth to Plexus Mk I.

Now I’m spoiled for choice with product offerings, multiple radio protocols, mesh- and star-networks on the same platform, 2.4 GHz and sub-GHz radios all on the same silicon, free software development environments and a huge reservoir of code and technology provided free by the big players, just to get us started.

These are exciting times to be an IoT engineer, if such a beast actually exists.

What the Plexus project has taught us is how to be a manufacturer.

And to be one of those, you truly do have to finish off the last 5% of every product development, because you won’t get to play in Round 2 if you don’t.

Link to comment
Share on other sites

  • 2 weeks later...


What will be the fate of the early innovators in the IoT arena?

Are they a doomed species, to be pushed into oblivion when the big money turns its attention to grabbing market share and blowing away or gobbling up all the small fry who have been trying to create differentiated toe-holds as markets mature?

This is a question that bites pretty close to home for MEA.

MEA is a 5-year old start-up with 33 years of experience.

Any company with some sort of longevity is by definition one that has re-invented itself again and again over the course of its history - markets and technologies pop in and out of existence like quantum particles, and good companies ride the growth of these waves and slip across to new waves as they collapse.

What is clear – after a five-year effort to invent and stabilise Plexus Mark I as our latest on-farm IoT offering – is the need to do it all over again, simply because technology has moved rapidly onwards and we can drive down costs and increase performance by updating our technology.


So here we are – down at the bottom of the world – and leading many other international agricultural IoT players by a full generation. That’s an edge we will lose if we don’t keep moving and advancing.

To be a market leader, we will have to export Plexus beyond Australia’s shores. That will require a whole new generation of ‘smarts’ to make the technology simple and seamless. The MEA Law of Exponential Aggravation (known to a previous generation as ‘the Tyranny of Distance’) will see to that.

So, stepping up to become an exporter will be a really tough call for our engineering, marketing, management and service folk. We’ll need all of our combined years of experience to carry that off… and a bunch of new investment.

Can we do it?

I’ve no answer to that; the future in a small business always seems perilous, but we’ve survived and gained a solid reputation.

What I haven’t mentioned in this series of IoT essays is the over-arching need for sound company management.

And that’s not me; I’m a starter, not a runner.

Inventive folk such as myself are highly trained to jump sideways, circumventing problems with new off-the-wall solutions. This makes for a chaotic management style; all my moves appear to originate in left-field.

MEA is a partnership, and my business partner is the solid methodical detail guy who runs our management and marketing and financial and strategic departments, while I have been allowed to focus on the engineering I love.

Yet he and I will both reach retirement age in the next few years, and there’s a real need to re-invigorate the company with young people and fresh ideas. We can find those here on our doorstep.

And my own fate?

I’ve pretty-much lost interest in owning a company, but I find my hunger to develop new products burns more strongly with each passing year. I’d like to retire gracefully to the lab, to teach and to mentor young engineers, to learn new skills, and to create all those environmental sensors that fill my notebooks.

I can be the Colonel Sanders on the Kentucky Fried Chicken bucket, but I don’t need to fry all the chicken myself.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

The Dilemma of Data Ownership

For more than three decades, MEA has built weather stations for wind, solar and agriculture applications within Australia.

In the past decade, there has been a shift from private to public ownership, with many hundreds of MEA weather stations being deployed within networks across whole agricultural regions in southern Australia. These stations give farmers up-to-date access to local weather data via websites hosted by various Government or statuary authorities interested in water use efficiency in irrigated areas and among many other applications outside of agriculture.

Here’s an example from Western Australia: - DAFWA weather station network

Other small private weather networks have begun to be rolled out in the last few years by cashed up agricultural companies whose mission is not to build weather stations, but to sell ‘decision support’ to farmers. For this to work, they have to fund the installation and maintenance of these imported automatic weather stations, then sell their agronomic services and seed and fertiliser products to recoup that cost.

This is a very different model to that of a manufacturer such as MEA. We simply sell the hardware and maintenance services.

While MEA may host public websites and data processing for such weather station networks, we have no ethical right to siphon off the data and feed it to others, such as farmers using Plexus on-farm IoT soil moisture systems.

So we find ourselves on the horns of a dilemma; we know that farmers could extract extra benefit from all this wide-area climate data that our own systems are generating.

But we don’t own the data because our business model has always been to simply sell and support the hardware.

Yet another dilemma to be resolved in a world where data has more valuable than engineered products…


  • Like 1
Link to comment
Share on other sites

On 2/20/2017 at 10:56 AM, Andrew at MEA said:

This is a very different model to that of a manufacturer such as MEA. We simply sell the hardware and maintenance services.

While MEA may host public websites and data processing for such weather station networks, we have no ethical right to siphon off the data and feed it to others, such as farmers using Plexus on-farm IoT soil moisture systems.

So we find ourselves on the horns of a dilemma; we know that farmers could extract extra benefit from all this wide-area climate data that our own systems are generating.

But we don’t own the data because our business model has always been to simply sell and support the hardware.


@Andrew at MEA you've made a great point here and it's easy to see how your approach differs from that of other companies. Most of my work relates to using data rather than generating it and I place a value on good data (specifically data with integrity, currency, completeness, correctness, quality). One common classification of the data associated with a task is to consider the data products in three ways: the raw data collected or generated, the analysis and deliverables given to the client, and the knowledge generated from doing the work. It is good practice to describe in the contract how each of these products are treated for ownership. 

It is a reasonable approach for a company to sell data as a service, and this is a different business model to what you describe as the MEA approach to sell hardware that collects data. I disagree that you are facing an ethical dilemma about whether to sell data or not - producing a data set of temperatures does not infer ownership of the weather. 

I do agree that farmers could greatly benefit from wide area sharing of this type of data with their neighbours, and I would like to think there is a viable business model for those companies that could incorporate data sharing. The mutual benefit would outweigh any perceived commercial advantage to exclusion. I'm sure these systems already take advantage of open source data which are often provided under Creative Commons licences (see example at BOM page). This provides a simple solution that goes back to data integrity - it would make an exciting disruptor to this environment if 'hardware' companies such as MEA incorporated data sharing under a CC arrangement as an inherent characteristic.

Link to comment
Share on other sites

Hi Jason

Thanks for your thoughtful advice on this matter.

We have discussed this internally and believe that you have shown us a way forward.

MEA will approach the various parties who own our weather station networks and discuss Creative Commons licences with them, while talking about how the data can be more broadly used for the good of all.

No doubt there will be much discussion about 'fairness' and 'impartial' dealings between commercial competitors and so forth. We're OK with that.

This is very fundamental issue for manufacturers of IoT technology, so your interest is appreciated.

Best Regards

Andrew at MEA

  • Like 1
Link to comment
Share on other sites

The IoT and Fundamental Things

Barrie Gilbert – inventor of the Gilbert cell found at the heart of all these potentially billions of IoT radios – was one of the most prolific electronics engineers of all time.

For all those young engineers just starting out, and wondering how best to gain a toe-hold in this brave new world of the IoT, look no further than Barrie’s simple but powerful advice describing the source of his own inspiration, in an eight-page story entitled ‘Where Do Little Circuits Come From?’*

“Discovering or inventing (- is there a difference?) new uses for a handful of transistors seems to be difficult for many young engineers entering the field of electronics today. Perhaps this is because they are taught that in confronting this Brave New Digital World they would be ill-advised to waste their precious college hours on such bygone and primitive notions as Kirchhoff’s and Ohm’s laws, or be concerned about such rudimentary concepts as the conservation of energy and charge, or bother to become adept in Laplace and Fourier analysis. The enlightened contemporary view is that everything of importance will be done in DSP sooner or later. Sadly, there is evidence to suggest that this message is increasingly being accepted. It is precisely the lack of these foundation skills, or even an awareness of the history of electronics, which makes it so hard for many new graduates to cope with component-level design, analog or digital.”

“I get the feeling that the development of new circuit topologies is viewed by the newcomer to circuit design as something akin to magic. I’m thinking of those happy little tunes that weave just three or four active elements together in some memorable relationship, the themes, rich in harmonic possibilities, from which countless variations unfold. In these deceptively innocent and simple systems, cause and effect are inextricably bound: we are at the quantum level of electronic structure”      [Barrie Gilbert, 1991]

Very little of the hype surrounding the IoT touches on just where the inspiration will come from for the billions of new sensors that will connect our gadgets to the physical world. There is a sense that these are all already out there on silicon, and that nothing remains to be done except to wait for their prices to fall to next-to-nothing to allow the IoT to take off.

In my own long journey through the world of environmental measurements to the IoT gadgetry that we build at MEA today, I’ve done my day job by managing product development and mentoring the young engineers under me, giving them all the interesting and challenging work while I’ve covered the paperwork.


But in my own time – in cafes, planes and at the kitchen table – I’ve worked for decades on the fundamental principles of new IoT sensors based on a single op-amp, working with the very DNA of electronics to fashion new sensors. In a series if papers in the international IEEE Sensors journal, I’ve shown how these simplest of circuits can be made to measure stratification in urban reservoirs, the hydraulic conductivity  and salinity of soils, and the sap flow and water stress within living plants. These days – down the back garden in my home lab – I’m happily entertaining myself finding new ways to create the ultra-pure sine waves needed to make electrical conductivity measurements in old-fashioned Wenner Arrays used to make the simplest of soil resistivity measurements.

So my advice to young engineers wanting to ride the IoT wave is exactly that which Barrie Gilbert would give you; study the fundamentals and the history of your craft.


*‘Analog Circuit Design – Art, Science and Personalities’, Jim Williams, editor. EDN Series for Design Engineers, 1991

Link to comment
Share on other sites

  • 2 weeks later...

The IoT and the Need for Heroes

One of the hardest things to do when giving birth to new technologies – such as the IoT – is simply ‘to keep going’.

In this series of essays on my own decades-long journey to get to the IoT starting blocks, I’ve talked about all the things that can and did go wrong in product development and roll-out.

What I haven’t touched on is where I found the inner fortitude to keep surmounting a seemingly endless series of obstacles.

This is not something normally discussed in the engineering journals.

Yet the history of invention gives plenty of clues as to the vital role of mentorship and ‘heroes’ for those few engineers who actually managed to create working products when so many others fell by the wayside.

Brian Thomin at AMDEL in the 1970’s and later Brian O’Neill at Monitor Sensors in the 1980’s were early role models for me. These senior engineers answered all my dumb questions and never once made fun of my naivete.

I learnt much from these guys, but I learnt most of all from Jim Williams of Linear Technology.

Jim was an engineer’s engineer, and endlessly patient in offering help to younger engineers. (Jim had no computer or email, but you could always ring him up at Linear Tech and ask for advice, if you had the balls. Few of us did…)

But most of all Jim wrote; over 350 publications relating to analog circuit design, including 5 books, 21 application notes for National Semiconductor, 62 application notes for Linear Technology, and over 125 articles for EDN Magazine.

He reached a lot of engineers, even those of us down at the bottom of the world in Australia.

Jim never talked down to his audience or tried to bamboozle them with pages of mathematics. He used humour and simple explanations to teach electronic fundamentals through the real language of working circuits.

I never met the man (he died of a stroke aged 63 in 2011) but I read everything he wrote - sometimes four or five times - as I tried to figure out how deceptively simple circuits worked.

Much of the heavy lifting of the IoT will be done by young engineers skilled in coding and software.

Yet the sheer breadth of engineering experience needed to orchestrate IoT products is likely to be found only in senior engineers who have come the long hard route to a deep understandings of how to make things really work.

And I’ll bet many of them had been lucky enough during their careers to find older engineering heroes whom they could admire and emulate.

Thanks Jim!

Link to comment
Share on other sites

  • 1 month later...


The IoT in the Outback

I’m in sheep country in far northern South Australia, walking the dirt tracks across the saltbush plains through Yalpara, Minburra and Menton stations to the Waukaringa ruins and back.

Out here life is at its most elemental. The IoT seems to exist on a different planet. There is no mobile phone coverage and therefore no Internet, power is generated at the homesteads by solar or diesel generators and all communications happen by UHF radio or satellite.

Yet the measurement problems found out here are, if anything, even more pressing, exacerbated by the tyranny of distance and the difficulties that arise in servicing and maintaining equipment and stock.

I pass windmills and more modern solar systems pumping underground bore water into storage tanks connected to stock watering troughs. Sheep trails vector in on these life-sustaining sources of water, making grazing of these vast areas possible. Knowing that water is available to remote flocks of sheep and cattle is a quintessentially Australian measurement problem.

I carry no backpack out here; I’m travelling with camel-drawn wagons that hold my swag and camping gear and food and water for ten days. The hassle involved in camel-transport has to be experienced to be believed, but it’s what my country cousins like to do, and because the camels plod along fuelled and watered only off the saltbush  and thorny scrub rather than requiring diesel fuel and expensive 4WDs.


I’m invited along because these cameleers differ in one essential way from the early Australian explorers; they have a well-developed thirst for solar power to operate fridges, lights and torches, CPAP machines, and to charge mobile and satellite phones, cameras and GPS systems. And I’m the city cousin who knows how to build such gear and keep it working, as I have done.

On these vast open plains, solar-powered satellite IoT devices will be the perfect solution, given only the prickly problems that need solutions at both ends of the chain. At the front-end, the problem is to provide affordable tank level monitoring at very low power levels and with zero maintenance for a decade or so. At the back-end, how do you effectively get data to folks who have such limited access to the Internet to check their data?

So I entertain myself with these mental puzzles as I plod along for hour after hour while the country slowly unfolds around me. And as always, the solutions involve a multi-disciplinary approach that is the hallmark of so many IoT activities.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...