Transcript.

Erik: Welcome to the Industrial IoT Spotlight, your number one spot for insight from industrial IoT thought leaders who are transforming businesses today with your host, Erik Walenza.

Welcome back to the Industrial IoT Spotlight podcast. I'm your host, Erik Walenza, CEO of IoT ONE, the consultancy that helps companies create value from data to achieve growth. Our guest today is Richard Landsdowne, Senior Director of Business Development at Semtech. Semtech’s LoRa is a leading long range, low power wireless platform for Internet of Things devices.

In this talk, we discussed a smart city initiative by the town of Cary, SaaS and Semtech to improve community services and environmental monitoring for the town. We also explored the process of evaluating the use case and defining the right tech stack to balance cost, capability and convenience.

If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend a speaker, please email us at team@IoTone.com. Finally, if you have an IoT research strategy or training initiative that you'd like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you. Rich, thank you so much for joining us today.

Richard: Great to be here.

Erik: Before we get into the details of this Smart City project, I'd really be interested in understanding a bit more of your background and your history at Semtech and your history with the technology in general. Can you just walk us through a few of the highlights and then share kind of how you got into this particular technology domain?

Richard: Yeah. I've been with some tech for 25 years, started out with a carrier grade synchronization business, which that business sort of matured out in the early 2010s. And so by around 2015, I moved into the LoRa Group, which we picked up the law of technology in 2012. And I started to get involved with the teams that built the gateway reference designs. And a couple of years later, we came up with the idea of device to cloud, that is where we embed features and functions inside silicon that are managed, enabled and controlled through cloud services, which led me to need to set up the cloud services business for Semtech.

And around about a year ago, I moved away from that and into more of a business development strategic partnerships role, whereas somewhat uniquely for a silicon company, we're trying to reach much deeper into the ecosystem to understand what's holding back solution providers from being more successful with LoRa technology, working with partners that go way beyond the silicon and really to have things actually make a real difference in real life.

Erik: And actually, I'm interested in your perspective on the technology life cycles here. Because often I'm talking to people who are really firmly rooted in the application side. And so of course, they're very much affected by the underlying core technology in terms of the capabilities that they have at hand. But let's say the technology shifts are not so abrupt for them. What does it look like for a company like Semtech? Are there very abrupt technology shifts? But you've been with Semtech, I suppose, for long enough now to have gone through a couple of these cycles, what does it look like internally?

Richard: For sure, you spend some years in developing a new technology and new see the adoption. And one of the key things there is it an industrial technology or consumer technology because they are completely different? Consumer technology, being bash-bosh, you're in, you're out. Industrial, you're looking at much longer design cycles, sometimes you're looking at three years to revenue, and then those products can last for 10 years, 12 years.

So, we certainly within Semtech get involved in both, and LoRa Thorpe bridges both as well. We see mostly this is an industrial kind of technology. But we're starting to see the burgeoning of some more consumer-oriented things out there with some of the LoRa technology. So for sure we see both sides of that story.

You’ve mentioned talking to people who are really firmly rooted in applications and that actually is something that I bring up in a lot of my webinars and stories where I divide the IoT world into two types of people. There's what I call technologists and then there's what we call the application innovators. The technologists typically live in a world where they use technology to answer a question, i.e. I can use this sensor to tell you how full, how empty, how long, how far, how loud. And whereas a solution, an application innovator says I need lots of technologies to build a recipe that gives me a real solution. And that's some of the complexity of IoT that we're trying to solve here is to bridge technologists and application innovators to really understand at the end of the day how multiple technologies go together in a recipe to make a solution for the application.

Erik: And I think this is going to be a great case study this story of the town of Cary because this is really a situation where you could look at it as an industrial use case, to some extent, and that it is enterprise where there is an entity that's driving the initiative. And on the other hand, you have people, you have children, you have grandparents, you have your citizens who are going to be interacting with the application. So there's very much also an individual component of this, so I suppose you're going to have to grapple with the challenges on both sides of that. So this should be an interesting case study to walk through. Can you give us a little bit of a foundation of No, before we get into the specific technologies, and the look of the deployment? How did this conversation with the town of Cary arise?

Richard: We're a silicon company. Silicon companies talk to people who put little black pieces of plastic down on PCBs and build them into modules or devices. Essentially, building IoT solutions is more complex than a lot of people bargain on because they start off with this simple technology, which is the answer to a singular question. And actually, their application solution is rooted in a whole set of interdependent questions which are answered by multiple technologies or multiple sensors.

So in Cary, the company's SaaS is the world's leading data analytics company. And they're a good resident of the town of Cary and had been working with Cary for some time. And Cary came around to thinking, hang on a minute, every time we get some smart idea that maybe it's a waste management idea, maybe it's a building management idea, we get another tool, we get another stack, we get another login, and we've got another bunch of users to administrate and decide who can do what.

And they ended up with well over 200 siloed solutions. And they were finding this frustrating, and they talked to SaaS about that and about how SaaS could say, can we take some of the data that exists in different silos, bring them together to tell a story which is much more powerful than the sum of the parts? And SaaS says, sure we can. And they've been working with them for some time. This came about in 2005-2007, something like that.

So at some point, 10 years down the line, they say, we really need to get more data to feed the analytical engines that SaaS have to drive the insights that Cary we're looking for. So they say we need a much more sophisticated sensing platform. And then they came across LoRaWAN as a really interesting looking technology because of its ability to deploy sensors in the wild that live in the wild untouched for potentially 10-20 years.

So they came to the conclusion over the next year or two that they definitely need LoRaWAN. But LoRaWAN is a large ecosystem. There's more than 500 companies. And every time they try to find a sensing solution, they came across many questions. Why would I choose this one over this one? There was a lot of partners offering their services. So they fell into what we've started to call the maze of complexity, which is, I ask a question, and I get too many answers. And it just blows my mind. And so SaaS started talking to Semtech because they found that Semtech was the center of the LoRa universe. Then we talked for about a year before we decided, okay, we need to do something much more strategic here. And we put together an agreement with SaaS, and then SaaS said, we really need to put together a three way with town of Cary because we think bringing the technology owner to play in the discussions we have with town of Cary was enabling. And so it was really SaaS that brought us to the table with town of Cary.

Erik: And Cary seems like a perfect municipality to be working with, right. It's what brought a couple 100,000 people. So it's big enough to have a lot of complexity, but it's not too big to work with. And I suppose it's a probably a pretty technically savvy city management team. I mean, it's right in the triangle, so there's a lot of tech talent there.

Richard: Yeah. They can leverage the whole of the whole RTP area. There's an awful lot of, in my words, the technologists out there. And Cary as somewhat the owner of the application, they need someone to be this application innovator to pull together all of the technologies together to make them a solution. And Cary also is they’re not afraid to take risks, they’re not afraid to lead the pack to somewhat live on the bleeding edge that a lot of us technologists have become very familiar with over decades of living on that bleeding edge. So Cary is not afraid

Erik: Who are we talking about in terms of the key stakeholders here? Because we always we always end up talking about Carrie and SaaS and Semtech, but the reality is that there's people that are doing this. And a lot of companies, it's hard for the right people to figure out how to talk to each other. You guys seem to figure that out. Who are the key stakeholders or functions that the different partners?

Richard: When SaaS came to us, they were like, okay, analytics without data doesn't exist. And data without analytics has very little value compared with something that has the analytics. So they came to us saying, we just need help to feed the analytics machines with data. So can you help us build the sensing networks that makes sense for us? And we were like, sure, we know an awful lot of foking in the ecosystem. We also have quite a good reach through our contacts. And we can ask questions of the ecosystem. There's a lot of subscribers to our email lists and things.

So, SaaS simply just wanted to stay in their swim lane and us to help them build sensing solutions. One of the key things that that is not obvious is that Semtech not in this relationship to sell these guys anything. We are in this relationship to bring all of the partners from the ecosystem to have conversations with them that makes sense. We're looking for something that does this, here are the choices that really would be good for you, we should bring in Company A, B, and C, for them to talk to see who makes it for them. So it's really just leveraging us as a matchmaker but without being a decision maker. They need to make their own decisions as to who finally gets involved.

Erik: So, Semtech is to some extent, technology expert and also you have the ecosystem to provide the solutions. On the Cary side, is there a CIO office that's running this? Or are there specific departments of the city that are spearheading and driving particular initiatives here?

Richard: So it's led by CIO and anyone who's worked on smart city projects will tell you one of the biggest problems with selling a whole big smart city concept is the bridge too many departments. There's too many decision makers and no one wants to take the final decision. You've got to really work top down. And so the CIO at Cary is very innovative, supportive and driving of this initiative. It wasn't our initiative. It was their initiative. It's coming from them. So we're not pushing them. We're helping them on their journey. But it's their journey.

Erik: And in the press release that I have read through, looks like there's a few areas that are being highlighted. So there's a quality of life which is kind of a fairly big bucket that touches a number of departments, and then there's, let's say environmental impact and issues related to flooding and so forth and then lastly, waste management. So would these be the big clusters of use cases that you're dealing with or how would you frame the priorities?

Richard: For sure, that's the starting point. And as I mentioned, this is a journey they've already embarked on for some time. They've had a bunch of maybe not necessarily blind alleys, but maybe just roads that didn't all meet up. And so this journey starts with some of their biggest problems. And some of their biggest problems is stormwater. So that's definitely priority number one, is to instrument more of their bodies of water, more of the creeks with more devices so that SaaS will create more of their hydrographical models which give them a predictive element.

So the name of the game here is to predict and respond to predictions rather than to events. So if you can get ahead of the game, then some events can be avoided. But every event can be better managed if you predict it. If you know that the parking lot in the shopping mall is going to flood in two hours, you can reduce A, the risk and B, the financial impact considerably by knowing that. That's really the first biggest hit that we're looking to help with.

Erik: So maybe we can use that to deep dive a bit. What does this then look like you defining the architecture, defining the partners for this particular use case?

Richard: So again, this comes back to SaaS. So, SaaS have the technical architecture because SaaS have this long standing relationship with Cary where they've built an architecture in Microsoft Azure for them, which makes sense as a repeatable architecture. So you can take it from flood and you can reapply the architecture to all of the other use cases. So there's multiple inputs that require to go into something like the flood prediction and prevention model. Some of those come from the internet. They come from the Azure maps service. They come from rainfall detection. They'll come from river level and flow rate sensors.

So essentially, they build that picture of what's already there, what's on the ground. They then look at other feeds, which is going to tell them what's potentially coming. And from that, suggest in two hours, four hours, six hours, whatever it is, there's going to be problems in areas A, B and C. So that software architecture has been built and tested and is robust. And essentially, with Semtech has come along to say, okay, they need a data feed from a bunch of sensors, they've already got data feeds from Azure maps, from various other things. But the LoRa staff can come from any different direction.

And so we will help them build the story that makes sense for whatever the application is. And in most cases, you can deploy a whole town of Cary by, let's say about, five tower mounted gateways. So for a very low cost, you can cover the whole entire town. Alternatively, you can deploy a very low cost gateway that's relatively close to where you want to use it. And they don't actually change the architecture of the system. They're just an implementation, So the architecture is set and SaaS has really been driving that.

Erik: And maybe we can take a bit of a deviation because we haven't actually talked much about LoRa yet. I think some of our listeners are going to be quite familiar with the protocol, some less so. You just mentioned that the town of Cary maybe five or six gateways is going to be sufficient to have coverage, you could also have a cellular network. So that could be another option. So what would be the benefits of using the LoRa network, as opposed to, for example, a cellular network for this type of situation?

Richard: We start maybe right at the edge of the sensor. The sensor on LoRa is going to use less power than it will do on a cellular, or on WiFi, for example, or even Bluetooth. And the reason for that is that those technologies were designed to connect and ship quite a lot of data. LoRa has developed from the ground up for bits and bytes, not megabytes and gigabytes.

So a sense of on LoRa, number one, it spends most of its life completely asleep, not listening, not doing anything, it's literally in deep sleep. So if you had a water level sensor, it might wake up every 10 minutes, take a measurement of the water level, and that measurement might be three or four bytes and it's going to uplink it to the network. And that's where the second major difference comes.

LoRa devices, because again, they're designed to be super power efficient, they just wake up and spit out a packet. When they spit it out, they go back to sleep. There's a rule that says when you spit out a packet, you have to listen just in case the network wants to talk back to you. But in most cases, it doesn't and then you go back to sleep. So in contrast with something like WiFi, where as your phone, it scans for WiFi, it then talks to one WiFi access point, it creates a little contract with that WiFi access point and constantly, there's a communication in between the two, they may go to sleep. But when you wake up, there's a back and forth communication that goes on to set up a session and those kinds of things.

The same thing happens with cellular. Even if you go to sleep, you've got to wake up and kick off a new session, which means seeing which base stations you're nearby, requesting the network to connect you to the right base station and things like that where the mobile station might ask to be switched to another base station and all those kinds of things. LoRa just doesn't do that, so it doesn't use the battery power of that.

The other thing that is really different with LoRa is it transmits very small amounts of data. So it can transmit those data very, very slowly. And when you do it very slowly, and with the power of spread spectrum, that signal can be well below the noise level of the radio spectrum and still be picked up. So that means that even though you're not using any more battery power than a Bluetooth device, the signal can actually travel for many miles or kilometers in to a high point. It can go tens of miles, tens of kilometers.

So, LoRa device is built to be asleep to use very, very, very little power and wake up and transmit and then it goes back to sleep. Because it doesn't do that communication with the network back and forth, essentially just assumes it's in coverage most of the time. If it has an alert or an alarm that it needs to guarantee reaches the network, it can ask for a confirmation. But most cases, it just sends a measurement and assumes that someone hears it.

So the difference between the LoRa network, when you look at the base stations, the LoRa gateways or base stations that are all identical, they all lesson on the same channels and the same data rates at the same time, all of them. So if you have a dense network, your device may be picked up by a great many of LoRa gateways. And they will all forward that same packet to the server and the server will say, okay, these are all duplicates and throw most of them away. Whereas other technologies, you only talk to one endpoint in one base station at a time.

So there's a resiliency in a neural network because if you have interference at a base station, but you've designed the network such that there's multiple gateways going to receive your signal at any one time, then one that doesn't have a strong interferer or a collision at that point will still receive the network receipt, see the packet and forward it on. So that means that you've got the opportunity because all gateways are identical. You can overlay multiple gateways in the same area. So if you have a problem with coverage or capacity, you can just plug in another gateway, even if it's a small indoor gateway and it can fill in a hole because they can overlap quite happily. They don't enjoy fee with each other, which, you know the WiFi access points interfere with each other and there's a frequency reuse plan in cellular you have to abide by. With LoRa, you just plug in at the gateway and off you go.

Erik: And especially with this type of use case, I suppose the time when the infrastructure might be impacted is exactly at the time when you need it, right. So there's an earthquake, there's a hurricane, that's when you need the infrastructure to be operating. So this redundancy is quite valuable here.

Richard: If you've got short range communication, you may be using the infrastructure of the building to receive the sensors that are trying to protect that very building. And if you have a power outage in that building, your sensors go down. Whereas if you've got sensors, which are long range and transmitting the high points, those high points, they can have resilient power and therefore, your battery power devices carry on working through severe event, be it earthquake, flood, or whatever. So, there's a lot to be said for that resiliency where the devices can reach multiple distant high points from the same device.

Erik: Maybe it sounds a little silly to say, a famous case study. But there's a famous case study that basically somebody invented a light bulb that lasts for 200 years, or whatever and what's the business case? And I think, historically, this actually happened. They had light bulbs that lasted for a long time. And then the light bulb manufacturers made a bit of a cartel and they agreed to sell bulbs with a limited lifespan. But the crux here is that the business cases selling this to municipal governments, because if we're talking here about sensors, instead of light bulbs, the cost is not so much in the sensor, it's in sending out a team to replace the sensor when the battery dies. So the sensor might cost $50, or $100, but sending out a team once a year to go replace a battery is quite expensive.

Can you give us a bit of a look at what would be the range of costs for sensors that would be used in this application?

Richard: Let's just take a river level sensor. There's multiple different ways you can sense the level of a river. You can either put something above it, bounce a sound wave or a light wave off the water. And based on the time, then you can measure the distance from the sensor to the water level. And that can be ultrasonic or it can be LIDAR, it can be radar. There's multiple different ways of doing that. You can also put a pressure sensor at the bottom and measure the height of water bearing on that pressure. Any number of those techniques will yield you a reading.

And one way or another, you've got to get that reading back into the analytics. So the connection technology, some devices that I've seen that sort of $3,000 or so with a solar panel, and a cellular modem going to connect you back to the internet and this thing's going to do a great job. But we have seen where you particularly want to get a creek, it's under dense foliage, it doesn't get so much sun. Then when you have a storm event, quite often, the weather's not great for a day or two beforehand, so the battery starts off pretty low; as the storm event approaches, the thing runs out of juice and goes offline.

So the difference with LoRa devices typically is they are built with a battery. You know, the life of the battery is going to be at least X years and depending on the device. And consequently, it's simpler. So without a recharging mechanism and a rechargeable battery, if you go for just a standard primary lithium cell, you can build a device, these ultrasonic devices, they're from about $60 upwards. And there's depending on brand and exactly the kind of life and the robustness you're looking for, you can spend a few $100 on a sensor, but it's typically a lot, lot cheaper than other technologies purely because of the simplicity.

And you did mention there the cost of servicing a device in field. If I went you know and talk to Gary and say, hey, we can reduce your waste management bill by deploying fill level sensors and all your trash cans, the fill level sensors, as you say, like $20-30, great. How long does the battery lasts? Six months. Okay. So now I need to know, I've got 400 trash cans and now I've got to monitor those 400 trash cans has the battery and I've now got to have a new job created, which says, who's going to be doing that? When are they going to do it? What's the cost of doing it? And it's a whole logistical exercise that they didn't have to do. So that becomes a pain point for the implementation.

If, however, you say, this is a trash can, and trash cans, but let's say they last six years in field, and you say this is a trash can with a 10 year battery life, the average lifetime of a trash can is 6 years, you deploy it as a one off cost and it lasts as long as the trash can last. Then that's a very different equation. They don't have to think. It just becomes simpler. And the same thing with the river level sensors. If you build it long enough, that cost of servicing it, which as you say is way more expensive than actually buying the thing in the first place becomes very much easier to bear.

Erik: Often when I look at IoT use cases or technologies, I kind of divide them into two buckets of value one or the, let's say cutting edge in terms of analytics, and so then you're talking about digital twin and these things. And the other are cutting edge in terms of simplicity. And often the simplicity ones are the ones that have the most value because you're basically taking technology where 90% of the tech stack is more or less ready to go. But there's some element that is preventing scale. You're fixing that element and all of a sudden, you have a solution that's just cost effective and not been widely applicable.

Maybe we can get into a few more. So we've focused so far on this tracking storm events or water levels and so forth. What else is on the priority list on the roadmap here?

Richard: There’s a lot to do with just basically saving money. So, optimizing the waste management, etc, and that gives not only improves the finances, but also the street scene. And now I mentioned, fill levels of trash cans, there's plenty of data around the world that says, if I know which trash cans are at what level, I can only empty the ones that are 80%, they never overflow and I never empty one that's less than half full.

So there's plenty of evidence to suggest that you can save 20-30% in your waste management just purely by not doing a program circuit every 2 hours, or two days, whatever it is. So that certainly is going to be one of the things that we extend. There's already some small pilots in play.

We're also looking a lot of safety issues, lone workers and things like that. And one of the things that maybe I can give an example of where we've seen an credibly fast ROI, this wasn't in Cary, but we're certainly going to leverage these kinds of things in the buildings in Cary is we deployed a pilot in a large campus, there was about 8,000 people on campus, and we covered all of the campus. We decided to put three gateways up, although one gateway covered 98% of the campus. If you put two up, then it filled in any blank spots. And a third one for any power outage result redundancy.

So, $2,000 gateways, we had coverage of the campus. Then we took a floor and we instrumented the toilet, the washroom doors for just counters. They will count how many times the door was opened, which to first approximation tells you how much you use that washroom has had. And they found, to their surprise, after just a few days, that the ladies and the gents were getting a fraction of the usage of the disabled handicap one. They wonder why this was and they found that there was no one in the department on that floor that would be classed as a handicap and was using that. And so everyone was just using the closest washroom.

So they completely changed their cleaning schedule around that data and immediately they knocked the cleaning bill them by 30%. And for the sake of three less than $100 sensors, they started saving that much money in a day. Those kind of use cases we’re rolling a lot across SaaS campus, we're rolling them in across town of Cary. Then there's some very, very simple low hanging fruits.

Then, of course, you've got the post-COVID world. Looking at indoor air quality is a key one as well, people counting and while keeping privacy, of course, and indoor air quality. So, some of those are going to be the big hit as to which come under the sort of safety side of things rather than purely about saving money.

Erik: So, for example, I was just over at Microsoft's AI Lab on Tuesday, and they had a use case for PwC measuring usage of desks in open spaces and just understanding what is the what's the cadence of use, right? When are we at 100% occupancy? When are we at 20% occupancy, it can help to improve service levels, it can help to reduce costs and say, hey, we need to better utilize this space because it's not being used or we need to add more desks. So these are very simple deployment, but they can really radically change how you operate. But you can imagine this basically anywhere where humans are using a space and you just track, is the door open, is the space been occupied, many different ways to do this?

Richard: You mentioned desk occupancy, which is a great one for so going back to the whole kind of idea of the technologist and the application innovators there is so what's actually your problem? If I look from my application elevator, it says, do I actually want to know what desks are used to? I want to know, where people prefer to sit? Do they prefer in a noisy environment, a quieter environment? Do they want one that's near a coffee machine? Do I want to determine behaviors? Do I want to work out densities? And all of those are real deep application questions. And what do I want to use the data for?

And then the technologist comes along and says, hey, this widget here is $30, tear off the sticky thing and stick it under the desk. And it'll tell you if someone's sat at the desk or not. And so depending on when you roll back to what the question is and what you want the day before, that may or may not solve your problem.

Another technology is to come along and say, hey, put one of these widgets on your ceiling tile, it costs five times as much. So this is going to cost you $200. But this one's got a little camera in it. And the camera, because in the same technology that we've got used to on all of our cell phones, they put little markers around all the people in the image, the camera can tell people and it can say how many people are in a certain area. You can ringfence and geofence certain areas and you can then start reporting how many people are gathering in social spaces around a coffee machine, around the printer, how many people are used in meeting rooms, if they're standing people.

So that's one of the things that I'm doing as Semtech is trying to help our partners to understand really, what's their problem, what are they looking to fulfill with the data before we bring the appropriate different partners in the ecosystem to talk to.

Erik: And I think the cases we've been discussing so far are all dealing with anonymous data. You're measuring people, but you don't know who the person is. You just know that there's a person here. There was a case here in China recently that we were looking at, basically, sensors to check posture for individuals just basically to help with EHS just to make sure people have the right posture. But then of course, you know how some of these sittings, so you know also know when they're sitting.

And there was a case where a company had something and they were building it basically as a posture management solution, but then people started getting emails from their HR, hey, you seem to be leaving your desk 30 minutes early and so they were also using this for a second use case, which was tracking, how their employees, they're leaving early on Fridays and so forth. So is this a topic, because this is also a space where you need to bring in some expertise and say, okay, we're collecting data. What data should we be collecting so we can do the job? But we're not collecting too much because we don't want any citizens to feel like their privacy is being infringed upon? Is this part of conversations or how do you handle these topics?

Richard: To be honest, it is top of mind for many of the discussions we have. So okay, if you've got, let's just start measuring desk occupancy, is it a hot desking office or is that someone's desk? If it's someone's desk, then that starts to become personalized data. And we are always going back and forth with the lawyers internal and external about what kind of data is being collected, whether it can be inferred as personal data, for example. I'm not saying who sat at the desk. But that desk, if I would work out trends, normally, these two guys, they car share or something, they come to work together, and I see their desks come and go at the same time, I can work out that it's those two guys.

Those kinds of things that can be inferred from data, we start to think at some point, you've got to work out where to stop being concerned. And the other thing that we are very aware of is that is before you deploy these technologies, you tell everyone that you're doing it and why you're doing it and what to expect. Because the one thing is for sure, if you stick it out there, and then people go, do you know they're monitoring us right now, that can become very unpopular. And so I don't see any evidence of that style happening. I think very much the opposite is like we can't do anything until we've drafted this, we've reviewed this, we've told the people we've got the feedback. And so I think we're in a good place in terms of looking after the privacy of our people at this point.

Erik: So I think we've touched on quite a bit so far, Rich, what have we not covered yet. It's important for people to know?

Richard: Park area, this is a park area which it's got some venues in there and there's entertainment venues and sporting venues, there's park areas and play areas, sensory areas. And the discussions we've had around building this from the ground up to be pretty much the smartest downtown park anywhere, it's actually quite fun. The ideas that people just throw around, should we have a show social network for people's dogs through too, should we have movable furniture park benches, and try them in different places in different weather conditions and detect when people sit on them and try to position our furniture such that it's subliminally more effective for people to use that furniture, not only to track, of course, when it goes walkies when we don't want it to.

But to understand behaviors and drive towards a better experience for people in a much more, subliminal way for those folks, and we've had a lot of fun discussions around the kind of ideas that go around that beyond the straightforward, smart lighting and smart sound and all that kind of thing through to detecting species of wildlife, birds, marine life, those kinds of things that that might see are we encouraging the right butterflies and birds and all those kinds of things? So, yeah, a lot of fun we have actually because they're very open and it's kind of a greenfield we can push things into it from the ground up, which is great.

Erik: Yeah, we build a lot of these things to be static. And in the reality is that the experience in a park in December should be quite different from August. You want furniture in different places, you have quite different requirements and a lot of that understanding is hidden, so I can see how this will give you a lot of insight into how you could evolve the park.

Richard: O course, we're working on all the energy management and just making sure you retrofit older HVAC systems with things which if you just add control on the damper to knowing what the outdoor air temperature is and if you're trying to cool because there's a lot of people in a room, but the outdoor air temperature is cooler than indoors, open the damper to the max and just suck in as much cool air from outside as possible and obviously, the reverse if it's cooler inside, you're trying to heat and it's hotter outside. So the power of being able to deploy battery powered devices very, very easily means that retrofitting to the existing buildings is also a lot of fun in opening their minds to what's available.

Erik: Well, one for you to look into, if you haven't yet, is this carbon dioxide. So apparently, a lot of HVAC systems, they're set to trigger at a particular temperature. But then you might have five people sit in a room for an hour and a half meeting and maybe the temperature is still relatively low because it's autumn. But those five people are basically filling that room with carbon dioxide. And apparently, that can have pretty significant degradation on your work efficiency, and also your health. And so, just triggering it to identify that there's a certain number of people in a room for a certain amount of time, we need to get some airflow in here can actually be a pretty effective use case.

Richard: CO2 can be a way of people counting, depending on how the ventilation goes. But I mentioned this sort of post-COVID world. But the idea of using CO2 levels as a direct correlation to, let's just call it viral risk is pretty well accepted in that you can have a ton of people in a room, but if it's very well ventilated, the CO2 level doesn't rise too much. But the same air that's carrying away the CO2 is carrying away the viral load.

So if you deploy indoor air quality sensors, as we are doing across SaaS campus, and will be soon across Cary, they include simple CO2 along with volatile organic compounds and particulates and things. But CO2 specifically is super useful in measuring essentially COVID risk. So if it rises is significantly, as you say, we need to look at the ventilation. And we've got some very interesting devices, now they use ink displays, so you can put this on the wall. And even though it's battery-powered, and it lasts for some years on a battery, you've got the display showing you a time graph of the CO2 levels along with temperature and humidity and a few other things. So you can see in a meeting rooms like, man, we need to turn the HVAC back up. So even if it's just manual, you can do a lot, but just by putting a sensor on the wall, particularly the ones that got a display.

Erik: Imagine this role you're playing for the city of Cary is quite useful, you're bringing a lot of technical expertise, you're bringing a lot of insight into different use cases and so forth. Is this something that you frequently do for partners? And if so, what if some of our listeners are interested in maybe getting support on projects that they're running or considering? How is this structured typically?

Richard: Just essentially, my job now is to listen to partners problems and to try to help bring together the members of the ecosystem that can help them out. So, yeah, for sure it's what I do day in, day out. So feel free to contact me. There's other guys in the team based in different time zones. But that's a huge focus. Clearly, I spend a good deal of time with SaaS and with Gary, for sure. Absolutely help, anyone you can find me very easily on LinkedIn. You can find me through Semtech.

Erik: Well, Rich, thanks for coming on today. Really appreciate you taking the time to walk us through the project.

Richard: It's been good to talk to you.

Erik: Thanks for tuning into another edition of the IoT spotlight podcast. If you find these conversations valuable, please leave us a comment and a five-star review. And if you'd like to share your company's story or recommend the speaker, please email us at team@IoTONE.com Finally, if you have an IoT research, strategy or training initiative that you would like to discuss, you can email me directly at erik.walenza@IoTone.com. Thank you.