Jump to content

Andrew at MEA

Registered
  • Posts

    105
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by Andrew at MEA

  1. 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? Nope! 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…
  2. 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.
  3. 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.
  4. Heath - I've also been alarmed by the same patterns of thought among the Big Data crowd. The extension of the 'fire hose' mentality is a demand for vanishingly cheap IoT sensors distributed liberally across the countryside under 'the-more-the-merrier' recipe. Once measurement quality bottoms out in the drive for low-cost sensors, we're back to the same old garbage-in garbage-out conundrum. The corollary to this is that the Big Data crowd fervently wish to have nothing to do with the really tough business of keeping IoT systems working in the field. This grubby end of the business is costly and time-consuming and requires enormous engineering effort until mass markets are reached. They seem very prepared to simply write that off as 'someone else's problem' So we need to understand each others dilemmas - hence the value of this forum.
  5. 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...
  6. 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? 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.
  7. 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.
  8. 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?
  9. 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. 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.
  10. ...thus leaving developers with a conundrum. Developing IoT products for the Sigfox network strengthens their business and enables network expansion and greater coverage. Hanging back to see if Sigfox is a viable IoT platform in the long-term increases the risk that it will not be, creating a self-fulfilling prophecy. So I'm thinking about multi-platform developments, such as Sigfox for 'long-haul always-on' remote applications plus a Bluetooth pipe for local unloading via mobile-phone.
  11. 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!
  12. Or maybe they just don't know what they are talking about? This sort of misrepresentation is distressingly common, and rarely the fault of the original researcher. The publicity machines of many large institutions often trumpet early stage inventions way before practical issues are resolved. Such hype is more than simply fatuous, it is dangerous. Public cynicism is its natural by-product.
  13. 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.
  14. Hi Stuart Firstly, well done with your thought experiment on the ABM; it’s just that sort of ‘what if’ questioning that gets things started. I’ve spent forty years building many thousands of measurement systems for the bush, and in that time, measured just about all of the parameters you mentioned except for vehicle tags and wheel loads. Sure, we used data loggers and cellular telemetry to remote servers, but the concept is the same. Now the hard work begins; who would pay for this, who would deploy it and maintain it, what is the value of the data and most importantly, what price tag per bridge would allow a viable business to arise providing ABMs across Tasmania? Doing a back-of-the envelope calculation, the sensors alone on a single bridge would cost many thousands of dollars before we fill in the back end for measurement, local storage, telemetry and web-access, solar power and batteries, enclosures, aerials and all the other accoutrements of a standard environmental measurement system. So that’s current technology. What is it about the IoT that would make this ABM a viable proposition? I’d be looking at some sort of image-processing technology and bringing a whole bunch of imaginative devices to the table to drive the sensor cost down. This is an exciting application that sounds like grand fun to a measurement engineer such as myself - but only if someone foots a significant development bill up-front. That’s the bit where the hard grind starts – getting funding, sustaining development and interest, overcoming hurdles, generating sales, employing staff, making the data flow, fixing all the things Murphy kicks over...
  15. 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.
  16. 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.
  17. Sierra Wireless in the USA are driving hard to create technology platforms for the IoT. The following two links will take you to one of their blog discussions on LPWN (Low Power Wide-Area Networks): https://www.sierrawireless.com/iot-blog/iot-blog/2016/07/what_is_lpwa_for_the_internet_of_things_part-1_the_thre_-cs_of_iot/ https://www.sierrawireless.com/iot-blog/iot-blog/2016/08/lpwa_for_the_iot_part_2_standard_vs_proprietary_technologies/
  18. 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”
  19. 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?
  20. Hi Tim

    I'm working on next week's Agricultural Case Study presentation, and notice that the flyer talks about the 8th August (Monday) while the event calendar suggest the 9th August (Tuesday)

    Probably just a typo, but might be worth fixing to reduce confusion.

    1. Tim Kannegieter

      Tim Kannegieter

      Which flyer are you talking about? Where it it?

    2. Tim Kannegieter

      Tim Kannegieter

      Dont worry, just found it.

  21. 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'...
  22. 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.
  23. Funding the IoT This thread is possibly the single most important one for an IoT débutante to take note of… Why is that? This is because Australian society lacks the venture capital and angel investors available to high-tech businesses in the USA. Folk in Australia will risk their savings in the property market or superannuation stashes, but not in the product development market. Australian banks have even more to be ashamed of; they will not risk investment in product development or other business ventures that are not backed by a lien across all the real estate assets that business owners possess. After 32 years in business, I can count on one hand (without needing my thumb) the number of occasions where we've been visited by the bank manager to ask about how we’re going. Banks don’t understand product development as a legitimate business risk. So who does that leave? Luckily for us Aussies, that leaves the Australian Government, who take the whole business of product innovation seriously. Yes, these grants are competitive, and there’s paper work to be done. But this is free capital. You don’t pay it back, though you have to match it dollar for dollar from your own funds; that’s only fair. MEA’s Thermex and Plexus products were co-funded for many hundreds of thousands of dollars by AusIndustry then the Early Commercialisation folks within Australian Government Departments. These project developments cost somewhere north of $1.5m before product reached the market. The South Australian government have been great too, though admittedly on a smaller scale. Specific grants helped us to develop our Magpie and Green Brain software platforms for moving and presenting data. MEA wouldn't be where it is today without Government support. Their injection of capital made the difference between success and failure. Their tax incentives are often the difference between red and black in our annual profit and loss statements. They will also support you with advisers to sort out your business strategies and your plans. Product development is exorbitantly risky and expensive. If you want to be an innovator and a manufacturer and exporter, look up these folk in Government. Nobody else will be as helpful.
  24. 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
×
×
  • Create New...