In South Africa, fire safety and protection proves to be a problem for many people in underserved communities because of lack of infrastructure and support. To start solving this problem, Lumkani has developed a strong focus on human-centred product design, mass manufacture and scaling a dev team that is able to constantly listen to their clients.
Paul Mesarcik discusses some of the challenges and design considerations involved in growing a hardware focused startup that is determined to create a huge positive social impact in South Africa.
Presentation transcript
Paul Mesarcik:
[00:10] My name is Paul, and I'm a hardware engineer, #WhatIsJavaScript? I'm going to talk a little bit about the company that I work for and how we try to make an impact with the work we do. Cool. What we do at Lumkani is we try to use technology broadly, that's hardware and software in order to create resilience in the most underserved communities in our country, and in doing that we try to create financial inclusion.
[00:43] Basically, what we started off doing is using IoT to address the challenge of shack fires in South Africa. That was the starting point. This is a, I brought some props along. This is one of the detectors we've developed. And how it all started was on the 1st of January, 2013. The day after New Year's, we all woke up to the news that 6,000 people had lost absolutely everything they have in a fire in Khayelitsha.
[01:14] And I think as Africans, this isn't something that I have to really explain too deeply. It's only we feel and we experience, and we hear on the news all the time. And the challenge is obvious. We have extremely densely populated communities that have very dangerous living environments and if a fire spreads, it leaves everyone with absolutely nothing and kind of entrenched in these cycles of poverty.
[01:41] We were really kind of galvanised by that experience and as a team of engineers and friends, we decided that there's most certainly a technology solution that could at least help to improve this. And I'd like to just describe a little bit about how that came about and a bit about the technology as well. So what we've got here is actually an in-home heat detector. This is a rate of rise detector and we've seen a lot of research that shows that just early warning in itself can improve the chances of stopping devastation drastically. 80 to 90% probably in some cases.
[02:19] What we've designed this to do, is be especially relevant to an informal settlement to a shack which has lots of other disturbances. Smoke detectors, for example, wouldn't work very well because they would be false alarming all the time because of the environments. The next level that we built in is we really wanted these sensors, and I'll talk about why we decided to do that a bit later, but we really wanted these sensors to be able to communicate with one another. We actually decided that was really important is to spread a community wide alarm so that people can respond in an organised and communal way.
[02:56] And in order to do this, we had to develop a mesh network that was robust within a tin shack, which some of you might know is a pretty good example of a Faraday cage, which makes it really difficult to send RF signals through. We took that on. And then we realised that we actually are really, really interested to know exactly when the sensors are triggering and why they're triggering. So we decided we'd build a data collection device, a gateway that could listen to all these signals and feed that information back to us, that we could analyze what was causing them to trigger.
[03:30] Actually, in reality we were terrified that we just deploy a system that would be false alarming all the time. So we wanted to also have a kill switch that we could just go like, "Shut it all down man. It's not working." And luckily we haven't had to do that but we built that in and that was enabled through a GSM gateway. This is an example of that gateway. It's a really small device. I should have brought one but it didn't fit in my jacket pocket. It's solar powered, extremely low power. We can literally just deploy this onto a roof of a home and it is able to collect information from up to 10,000 detectives at a time.
[04:07] We use - sorry I'm geeking out a little bit here on the gateway because it's got a lot of stuff in it - but we actually don't use traditional ways of sending data through GPRS. We've used the technology called thing stream to build an MQTT connection over USSD. This means that our messages are much cheaper, they're actually lower power, and we can get signal in places where you basically see emergency calls only, we can get information out of those areas.
[04:36] It also means that it's multi-operator so we can cross to Vodacom, MTN, all the different networks depending on which has the best connection, and it's globally roaming. So we can deploy these devices in any country and we can have connectivity, which was an absolute nightmare when we were still using some cards because, wow. Yeah. Don't try that, it sucks.
[04:59] We also have an LPWAN backups. We have Sigfox as well. If there aren't any GSM networks available, we can send messages through Sigfox as well. The last little piece of the puzzle is that when we actually detect the fire, we're able to send SMSs to any of the users in that community to warn them about the problem. And we are also able to get responses from those community members to essentially help us to classify the fires. Was this a false alarm or was this an actual event? And if we can confirm that there was a fire from feedback, we can deploy emergency services or we can offer assistance and send out sort of higher warning, "We have confirmed that there is a fire. Be sure to protect your possessions."
[05:44] This is a quick summary on the system. We have an in-home heat detector, we have a way of sending that message to all the neighbors. We can collect data through the gateways and we can send SMSs to warn people even if they aren't in their homes.
[06:00] But we realised quite early that we actually wanted to offer a little bit more. This is just the technology solution, but it didn't feel at the time as a holistic enough way of solving this challenge. And what we developed in the meantime is an agent app that allowed us to collect end-users information. So in this case we are using it to collect GPS coordinates to geo locate every single device, and to collect cell phone numbers that we could SMS people in the event of a fire.
[06:29] We then also built a platform that allowed us to visualise this IoT network. This is actually a photo from Kosovo and Khayelitsha. There's about 6,000 sensors installed in one part of the community. Then you're going to see the density of each one of those little blue tags represents a single heat detector.
[06:49] In so doing, in building these tools, we'd realised that we'd addressed some of the critical challenges in creating financial inclusion for these end-users, right? We were now able to collect personal information. We were able to geo locate every single device, which essentially gave us an address to communities that traditionally were completely uninsurable because they weren't actually addressed. We can prove that you lived in this particular home.
[07:14] It led us to launch, to my knowledge, the first of its kind of household protection insurance against fires for people that don't have addresses. What that lets you do is for R60 a month, you can rent a device, we cover you up to R40 000 in damages. If your house does experience a fire, an agent will come and install a device for you. There's sales agents in all the communities that we operate in. You will receive SMSs and Lumkani will maintain that system for you.
[07:48] That is the fastest I could summarise everything that we do. And I'd love to, if there's any questions about the model, about how we distribute things, I'll love to talk to anyone afterwards, so I’ll take some questions. But Offerzen kept saying to me, "Talk about the challenges though. The solution's fine. But how did you get there? What are the things you had to overcome?" And I think that's actually probably more interesting, and is to try and share some of the experiences we had, and to make it relevant to everyone sitting here as well.
[08:17] The first thing is this idea of product-market fit, and having to really consult at every single step of the way with our end users about what solution they would need to have to alleviate the problem. I think the first thing in our team that we had to acknowledge is that we know nothing. We know absolutely nothing, that's the premise. And we have to embed into our company this ability to listen and empathise with end-users. Otherwise we will build things that will be thrown away after a few months.
[08:50] This photo here is a photo that I really love. This is Lumka Kawuta. She is the community leader in UT Gardens in Khayelitsha. That was the first community that we hosted a code design workshop with. So we spent a lot of time in communities in Khayelitsha trying to understand what a solution to this challenge would look like. Lumka is actually holding the first ever Lumkani device. You can see that that's exactly what a product that an electrical engineer would design. It's a black box. They're like, "How do we put it up? Like double sided tape. I don't know."
[09:25] We got a huge amount of feedback there, right? The first thing was like, "Wow, this looks like trash. You've got to make something that looks a lot better." And we're like, "Is that really important to people?" And it turns out it is. The other piece of feedback that we got was that, "You're misunderstanding the challenge. I don't really mind. I need to know about fires not only that happened in my house, but I need to know about fires that happened in my neighbour's house because that is just as much of a risk as a fire in my own home." And that was really the point at which we had to redesign the whole system to incorporate this network, allowing us to send community-wide alerts. And through the insights obviously of the community leadership, we were able to develop a system that is able to actually radically reduce the spread of fires. Not through our own insights, but through listening to others.
[10:13] The other thing is - and I'm sure it's a bit of a trope now in software development - but iteration, after iteration, upon iteration, right? I can't sort of emphasise this enough. This is a timeline of detectors that we had to roll out. And I think what was really important, and I'm glad we made this decision, is that we would never get it right first time. This is inordinately more complex when you're dealing with hardware. I can't just get pushed to all of my senses, unfortunately, which is a problem. So you have to design strategies that allow you to deploy solutions, get feedback, and improve on them, and then redeploy other solutions.
[10:55] The cycles that you iterate and you have to try and optimise to make sure that those are as short as possible, but never think that you can get it right first time basically. There always has to be improvements and space for that. And if you feel like your technology is perfect, you're not looking close enough.
[11:17] Something that we were super conscious of is the cost sensitivity of this product. The market that we were trying to serve and the problems we were trying to address meant that we had to be able to optimise for costs at every single level. And I think that this doesn't necessarily come naturally for engineers, especially for hardware engineers. If you're faced with a problem, I need a sense for fires and send a message, what do you do? You go online, you search what is the best processor out there right now and you try and design an application that utilises all of the newest technology and best features out there.
[11:50] We did exactly the opposite. We went on to Digi-Key, which is the largest sort of hardware sourcing platform and we just filtered microcontroller by price. And we said, "Okay, we're going to design the sensor with that microchip." It happens to be very close to this one here, PIC 16F 18326. I think we've gone two steps up because we realised like we just really can't fit it in. And that difference in price is about $12 cents from the original to the one that we're currently on. But imbuing in our organisation, the sense that frugality and cost saving is actually really important, I think has led to a huge amount of innovation. Basically being able to say, "We want to be able to solve this problem with the constraints that we have in this case cost or any other number of constraints."
[12:40] Another example of this is - that's a transceiver there. That's very similar to the transceiver that we use to communicate to create that mesh network. The problem with doing RF communications is you need a really stable center frequency basically so that two devices are speaking in the same language. They both know what the center is for them to communicate over.
[13:05] Now, that's okay. There are solutions to their problem. One of the problems that you have is that you have drift over time. They can go out of sync. You also have temperature variation. So if they're experiencing a different temperature, then they can be out of sync and they can't hear one another. The traditional way of solving this problem is to use a temperature compensated oscillator, which gives you a lot of benefit and it costs about $40 cents more than a plain crystal, which is the cheapest solution. And we decided that that was too much to spend. We developed a network, a modulation scheme that allowed us to deal with a wide range of deviation. It meant that we didn't have to calibrate our devices as much, which meant that they were lower custom manufacturer, and it meant that we could use much cheaper forms of hardware to achieve the same results.
[13:55] Another thing that we had to optimise for was the manufacturing process. Everyone thinks that a per second billing was invented by the mobile networks. Well, in a factory floor, when you're manufacturing technology, you're actually being charged per second. Which is kind of crazy. We realised from early on that a huge percentage of your cost is actually in manufacturing these devices, and we really wanted to optimise the manufacturing process through the use of technology. I have one more little prop. This here is a Raspberry Pi with a little bit of extra stuff that we've put on top. And this device here has manufactured 30 000 sensors. And all of the automated testing that is done on the factory floor, so our ability to QC every single device is just controlled through this one Raspberry Pi here. And the solutions that were out there when we consulted with the manufacturers, they were like, "Oh, that's like a hundred thousand rand that you guys need to spend on an automated test jig."
[14:57] We built it out of one Raspberry Pi and a few pieces of Mason Knights. So we're pretty stoked about that. They said, "Please don't drop this one on stage." Because they knew that I was going to throw it around to try and show my point like, "It's fine. It doesn't even... " And they were like, "Don't throw it on the ground, please."
[15:14] Another thing that really helped us, this is the logo of a company called [inaudible 00:00:15:20]. In a view into the sort of single board computer space or interested in Raspberry Pis and general, Bellina lets you deploy images, Lynox images to remote devices at the click of a button. It's extremely powerful. That means that we can update our code remotely on the factory floor, which is really, really powerful when you're trying to iterate through new designs. You can make sure that your whole fleet of manufacturers or devices is constantly running master.
[15:48] The other thing that I learned along this journey, and this was from my colleagues in the software team in Lumkani, who have attended conferences and watched live talks and kind of know a little bit about web developments and best practice is that, hardware engineers and firmware development is sadly very much, in my opinion, stuck in the '90s. You have people that are like, "What? You don't use assembler? Come on." And there's this push back like, "Oh no, we have the hard life. We are kind of going to stick in our ways and that's great because we'll come up with solutions." But haven't really put a lot of time into considering how they can incorporate some of the best practices from web development into hardware development.
[16:35] We spent a lot of time trying to optimise the way that we write code. In this case it's C developing really considered interfaces between all of them. And this kind of sounds I'm sure quite boring for software audience, but for hardware developers, they're like, "What objects and C? Are you serious? That's insane." So we had to spend a lot of time trying to build that out so that we could create maintainable and testable code. Which often if you look under the hood, is not the case.
[17:04] We, again, had to put a lot of work into developing good unit tests for all of our hardware. Because in my experience that isn't really normal practice when it comes to firmware. And I don't know how that's possible. And then again, continuous integration through Belina being able to deploy any changes to our manufacturers so that they can program them directly onto the devices as they come off the line.
[17:32] Just to give a little bit about our impact. So far we've installed 35 000 roughly sensors across South Africa, a couple in Bangladesh. We are about to roll out some into Kenya and into Congo. We've paid out more than a million around in claims to our clients. In the last month we have stopped eight fires across South Africa that we've limited the spread to the first home. Across the life of the company, it's in the hundreds. I don't know the exact number, but yeah.
[18:02] In closing, I just can't emphasise enough - and I'd like to echo what you said is that - the potential to create impacts just from the people that are sitting here that know a little bit or quite a lot about software is immense. And I think it would be really important for people to apply those skills into ways that we can uplift and create impact in the most address and underserved communities in this country. Thank you very much.
NOTE: The questions for this presentation were not transcribed, they start at 18:42.