Around the world in 80 Microamps - ESP32 and LoRa for low-power IoT
You could be forgiven for thinking (as I did) that the proliferation of wireless IoT solutions means that implementing environmental monitoring is a simple process. Typically, everything goes swimmingly for the first two hours until your battery runs flat. Many wireless development boards (even the ones with built in battery chargers) are actually not well suited to ultra-low-power applications.
Being truly wireless means (shock) no wires, not even for power. So we rely on battery, and perhaps solar. This brings a host of challenges: selecting the right battery, avoiding power-hungry components, coping with the limitations of a low-power radio platform like LoRa, learning the intricacies of deep-sleep modes, and choosing and using solar cells.
This is a case-study and lessons-learned from a real project for IoT utility metering. What seemed like a simple problem led to a deep dive into ultra-low-power subsystems of modern IoT processors, and the practicalities of the LoRa radio platform.
Outline/Structure of the Case Study
Introduction: the problem space (battery powered wireless sensors for utility metering). The "obvious" solution (off the shelf battery powered uC with LoRa radio).
Experiences: why the off the shelf solution failed.
Hardware Solution: how we developed a device that solved the drawbacks of the off-the-shelf approach, achieving projected battery life of 4 years. A primer on solar charging. Choosing a LoRa gateway.
Software Solution: how we programmed the ultra-low-power coprocessor of the ESP32 system-on-chip to achieve micro-ampere power consumption.
Cloud connection: A brief explanation of the path from chip to cloud, involving LoRa gateways, MQTT message brokers and a data lake.
* You will be able to practically deploy LoRa infrastructure
* You will understand the hardware tactics needed to maximise battery life
* You will be able to utilise the ultra-low-power coprocessor in the ESP32 System-on-chip
Developers and hardware designers
Prerequisites for Attendees
Attendees will be well served by familiarity with the usual IoT development board format (eg arduino, esp8266, esp32) consisting of a microcontroller, USB-bridge and battery management. You should be aware of low-power radio technologies such as LoRa, Sigfox and nbIoT.
schedule Submitted 7 months ago
People who liked this proposal, also liked:
Zhu Chen - Agile IoT InnovationZhu ChenIoT DirectorThoughtWorks
schedule 7 months agoSold Out!
Applying IoT to business successfully is much harder than ordinary Internet projects. Comparing with Internet, we don't have too much experience nowadays about how we should use IoT to create value for consumer and business.
We have challenges on technology sides too. Hardware are hard to change once they are manufactured. The cost will be extreme high if we made some mistake on hardware design. And we need to integrate much more system and hardwares, comparing with just integrate mobile phone / computer to backend server in an Internet project.
In this session, I would like to introduce some experience how to apply Agile methodology to an IoT project. I will use two project, smart cane for Guide Dogs Victoria and a remote healthcare for elderly people, to demonstrate how we work.
Pavi De Alwis - The software of building an IoT pipes: Connecting dumb devices to IoTPavi De AlwisSOfwtareDiUS
schedule 7 months agoSold Out!
IntermediateThis talk discusses a considerations and techniques for IoT enabling typical LAN connected device using a portable gateway, unreliable communication and cloud IoT services. I’ll be looking the different design decisions, technologies and comms protocols involved in enabling an iot-native approach to connecting portable medical devices.We will also be discussing the slower process of getting a hardware enabled IoT solution to production through the different stages of deployment and validation.
Simon Kaplan - A Smart Regional Management Platform for Sunshine Coast CouncilSimon KaplanCEO[ui!] the urban institute
schedule 7 months agoSold Out!
[ui!] the urban institute has been working with Sunshine Coast Council to deliver a smart regional management platform for the city. This exercise raises several interesting questions:
- What kinds of goals is the city trying to achieve by deploying a smart regional management platform?
- What existing data does the city have (eg in their ERP systems) that aligns with these goals?
- What new data does the city need (eg from deployed sensor arrays) to achieve the goals?
- How should a smart city platform bring all this data together?
- What are the organisational hurdles that need to be overcome to achieve a smart city vision?
This case study is a typical instance of the journey that a technology team need to go on to deliver a smart city solution, where just about everything is still alpha or beta quality, and the goalposts continually move as the stakeholders learn what's possible. Some stand-out challenges included:
- Issues with different IoT sensor hardware and data integration (how to get data out consistently, security issues, API issues, etc)
- Compliance/conformance issues around rapidly-emerging hardware, and conflicts with local Australian/New Zealand standards
- Platform flexibility and configurability
The project combines data from twelve different data sources:
- Solar farm
- Environmental sensors (three different types)
- Smart street lighting system
- Irrigation system including data from the city's flood monitoring network and the bureau of meteorology
- Public Wifi
- Customer order/requests CRM
- Public transport
- Smart parking
- Pedestrian counting
- Cyclist counting
The talk will walk through the history of the project, from first trials to current implementation status, and explain challenges confronted and overcome.
Christopher Biggs - The Awful Design of Everyday Things - Rethinking our workplaces and homes in the IoT AgeChristopher BiggsDirectorAccelerando Consulting
schedule 7 months agoSold Out!
Thirty years after its publication, Donald Norman's seminal book "The Design of Everyday Things", which examined how the tiny usability touches in everyday items matter so much, remains relevant and important. In fact, Don just this year wrote that the technology industry badly needs to re-focus on the true meaning of Human Centered Design, observing that despite his decades of advocacy, the same kinds of design flaws continually recur.
We are just a handful of years short of the centenary of the publication of Modern Architecture pioneer Le Corbusier's maxim "A house is a machine to live in", yet our architecture remains stubbornly steam powered.
My position is that we ought step back and critically reexamine the shape and detail of our workplaces and homes. The great labour saving devices of the 20th century freed us from much physical drudgery, but significant cognitive burden remains. I will examine, in the abstract and concrete, how much cognitive load is imposed on us by our environment. It has been written that a modern human makes 30,000 choices every day.
For example, why are our light switches placed for the convenience of builders, not inhabitants. Why do so many of our labour-saving appliances require us to spend so much time monitoring and pampering them. How often do you stumble about in the dark fumbling for a light switch. Wouldn't you prefer to discover the failed refrigerator or flooded storeroom before the contents are ruined?
Join me for an imagination of how Living In The Future could truly be better.
James Zaki - Leveraging blockchain technology for IoT applicationsJames ZakiCTOEther Games
schedule 10 months agoSold Out!
Although there is a lot of hype around blockchain and it's largest currencies, Bitcoin and Ethereum, the technological applications are often lost in the noise. Previously impossible tasks in digital domains are being achieved thanks to some core attributes of blockchain:
- censorship resistant
But what does it mean for individuals/companies in the physical world? Agriculture, Health, Insurance, Smart-Cities...? M2M payments via smart contracts?
James covers the practical elements of blockchain, and explores real-world applications with respect to connected devices (aka the Internet-of-Things).
Simon Kaplan - Standards for Smart City Technologies: What do we need and why would it be a good idea?Simon KaplanCEO[ui!] the urban institute
schedule 7 months agoSold Out!
There is an astonishing dearth of standards around smart cities, from hardware to platforms. Some of the consequences of this are:
- Every sensor family is weird in some way, which means that much energy is wasted building lots of unnecessary custom code for connections to sensors
- Backends provided by sensor companies are often not as good as they should be (after all, the sensor companies are hardware folks who often seem to underestimate the complexities of the software side of their business)
- Security is inconsistent or often just missing completely
- The breadth of capability of sensors is highly variable. They all, of course, do their basic job of sensing and transmitting data, but after that there is enormous variability in the ability to control, monitor and report on sensor status.
- There is no accepted standard for platform interoperability, which makes mix-and-match of platform capabilities, or integration of platforms, more complex than it should be.
Why does this matter? We regularly deploy smart city solutions that consist of:
- A platform (usually our UrbanPulse platform)
- Sensors that we supply, sometimes pre-integrated into packages such as smart street poles or smart furniture
- Sensors that come from other parties or are already deployed.
- Sensor supplier backends
- Comms networks (eg LTE, NB-IoT, LoRa, SIGFOX), always from a third party comms provider.
For any sensor, its exceptionally unusual that the sensor sends data directly to the platform. Usually, the sensor manufacturer supplies a backend, and data flows from sensor to backend, and then must be pushed to the platform or pulled from the sensor backend. There are usually API eccentricities and security issues here that must be mastered for data to flow smoothly.
Now, consider the case where we have a working smart city solution that includes a smart city platform, some smart street poles, and some environmental sensors on the poles. Data from one of the environmental sensors stops.
Why has this happened? It could be:
- There is something wrong with the platform (eg, bug, database crash, etc).
- There is something wrong with the underlying cloud system the platform is running on (eg security configuration, network configuration, etc)
- There is something wrong with the network/internet connection between the supplier backend and the platform
- There is something wrong with the comms network from sensor to supplier backend
- There is something wrong with the sensor itself.
The challenge for the platform provider is to quickly work out which of these scenarios (and sometimes it's several at once) is the cause of the problem. There is literally no way to do this at present other than getting on phone or email and calling all the players (at least 6) in the chain of debugging above - no standard protocols, seldom access to supplier backends, etc.
We need to do better, otherwise the entire smart city movement will strangle in the Gordian knot these problems cause. One way is to simply buy an entire smart city vertical - sensors, comms, platform - from a single provider; but we know cities are wary of being caught in the single-supplier trap. Another is to come up with a family of protocols that allow a platform to do 'out-of-band' things like query comms networks, sensors and 'integration points' like poles and furniture to ask: do you have power? Do you have working comms? What is the state of sensor X?
In this talk I'll explain this problem more completely and suggest some directions towards creating the standards we need to make building out smart city infrastructure at scale a more achievable task.