 If you look at these, you know, natural phenomenon of earthquakes, like, you know, there's no way to kind of fight with the nature. We have to learn to coexist with them and early warnings are the best thing to do that. And we have all these technology, IOT is there, machine learning is there, all those things are there, but we still don't know much about these phenomenons itself. So what I do want to understand, if you look at earthquake, you know, we'll see that in some countries, the damage is much more than some other place. What is the reason for that? Right, this is a great question. So what happens is earthquakes disproportionately affect countries that don't have great construction. And so if you look at places like Mexico, the Caribbean, much of Latin America, Nepal, even some parts of India in the north in the Himalayas, you find that earthquakes can cause more damage than, say, in California or in Tokyo. And the reason is it's buildings that ultimately kill people, not the shaking itself. So if you can find a way to get people out of buildings before the shaking, that's really the solution here. There's many things that we don't know about earthquakes. Obviously it's a whole field of study, but we can't tell you, for example, that an earthquake will happen in 10 years or five years. We can give you some probabilities, but not enough for you to act on. What we can say is that an earthquake is happening right now. And these technologies you mentioned, they're all about reducing the latency so that when we know an earthquake is happening, in milliseconds, we can be telling people who will be affected by that event. I mean, I'm just trying to understand from you what kind of work is going on to better understand earthquakes themselves. Right, so I'm very, I have a very narrow focus. I'm not a seismologist, and I have a very narrow focus related to detecting earthquakes and alerting people. I think in the world of seismology, there is a lot of efforts to understand tectonic movement. But I would say there's a few interesting things happening that I know of, for example, undersea cables. People in Chile and other places are looking at undersea telecommunications cables and the effects that any sort of seismic movement have in the signals. And they can actually use that as a detection system. But when you talk about some of the really deep earthquakes, 60, 100 miles beneath the surface, man has not yet created holes deep enough for us to place sensors. So we're very limited as to actually detecting earthquakes at a great depth. We have to wait for them to affect us nearer the surface. So then how do these earthquake early warning systems work? I want to understand from a couple of points, what does the device itself look like? What do those sensors look like? What does the software look like? And how do you kind of share data and interact with each other? So the sensors that we use, we've developed several iterations over the last couple of years. And effectively, they are a small microcontroller, an accelerometer, this is the core component, and some other components. And what the device does is it records accelerations. So it looks on the X, Y and Z axes and just records accelerations from the ground. So we're very fussy about how we install our sensors. And with our new project now, it's a sort of citizen science project. So anybody can install it in their home through this open EEW initiative that we're doing. But the sensors themselves, they record shaking accelerations and we send all of those accelerations in sort of quite large messages using MQTT. We send them every second from every sensor and all of this data is collated in the cloud and in real time, we run algorithms. We want to know that the shaking which the accelerometer is getting is not a passing truck. It's actually an earthquake. So we've developed the algorithms that can tell those things apart. And of course we wait for one or two sensors to confirm the same event so that we don't get any false positives because you can still get some errors. And once we have that confirmation in the cloud and I'm talking about one second or two seconds, it depends on distances. But when we have that shaking confirmation, then we can send a message to all of the client devices. So if you have an app, if you have a little IoT device, then what will happen is you will be receiving a message saying there's an earthquake at this location and your device will then be calculating how long it will take to reach it and therefore how much energy will be lost and therefore what sort of shaking you're going to be expecting very soon. Where are these devices installed in people's homes or in different locations? Yeah, so they are installed at the moment in several countries, Mexico and in Chile and in Costa Rica and in Puerto Rico. We are very fussy about how people install them. And in fact, on the OpenEW website, we have a guide for this. We really require that they're installed on the ground floor because the higher up you go, the frequencies of the building movement which affects the recordings. So it needs to be on the ground floor or even a basement, but we don't get basements in much of Latin America. And then we need it to be fixed to a solid structural element. So this could be a column or a reinforced wall, something which is rigid and it needs to be away from noise. So it wouldn't be great if it's near a door that was constantly opening and closing. But although we can handle that to some extent, so as long as you are within the parameters and ideally we look for good internet connections, although we have a cellular version as well, as long as we're within these parameters, then that's all we need. And the real name of the game here is quantity more than quality. If you can have a lot of sensors, it doesn't matter if one is out, it doesn't matter if the quality is down because we're waiting for confirmation from other ones and redundancy is how you achieve a stable network. Right, so as you were earlier saying, the sooner you get the warning to get out of the building, that can be a big gap between life and death. But here what you're doing, you're collecting the data and then sending it across the cloud and then trying to calculate okay, where the waves are coming from and how far they are. What if you are in the epic center of an earthquake? How much time do you get? What I'm trying to understand is the latency that is there between the sensor detects something, sends the data out and then you send out the alerts. Right, so the time that a user gets in terms of what we call the window of opportunity for them to actually act on the information, it's a variable and it depends on where the earthquake is relative to the user. So I'll give you an example. If you're in, right now I'm in Mexico City, if we are detecting an earthquake in Acapulco, then you might get 60 seconds of advanced warning because they more or less travel, an earthquake travels at more or less a fixed velocity which is unknown. And so the distance and the velocity give you the time that you're going to be getting. Now if that earthquake was in the south of Mexico and Oaxaca, we might get two minutes. Now this is a variable. So of course if you were in Istanbul, you might be very near the fault line or Kathmandu, you might be near the fault line. If the distance is less than what I just described, of course the time goes down. But even if you only have five seconds or 10 seconds, which might happen in the Bay Area for example, five or 10 seconds, that's still okay. You can still ask children in a school to get underneath the furniture. You can still ask surgeons in a hospital to stop doing the surgery. There's many things you can do and there's also automated things. You can shut off elevators or turn off gas pipes. So any time is good, but the actual time itself is a variable. The most interesting thing that you're doing is that you are also open sourcing some of these technologies. Talk about what components you have open sourced and why. Right, so open sourcing was a tough decision for us. It wasn't something we felt comfortable with initially because we spent several years developing these tools and we're obviously very proud. And I think there came a point where we realized, why are we doing this? Are we doing this to develop cool technologies, to make some money or to save lives? All of us live in Mexico. All of us have seen the devastation of these things. And we realized that open source was the only way to really accelerate what we're doing. If we want to reach people in these countries that I've mentioned, if we really want people to work on our technology as well and make it better, which means better alert times, less false positives. If we want to really take this to the next level, then we can't do it on our own. It will take a long time and we may never get there. So that was the idea for the open source. And then we thought, what could we open source? So we identified three of our core technologies. And by that, I mean the sensors, the detection system which lives in the cloud but could live on a Raspberry Pi and then the way we alert people. And the last part is really quite open. It depends on the context. It could be a radio station. It could be a mobile app which we've got on the website, on the GitHub. It could be many things, loudspeakers. So those three core components we now have published in our repo which is called, which is open EEW on GitHub. And from there people can pick and choose. It might be that some people are data scientists. So they might go just for the data because we also published over a terabyte of accelerometer data from our networks. So people might be developing new detection systems using machine learning. And we've got instructions for that and we would very much welcome it. Then we have something for the people who do front end development. So they might be helping us with the applications. And then we also have people, something for the makers and the hardware guys. So they might be interested in working on the sensors and the firmware. There's really a whole suite of technologies that we published. There are other earthquake warning systems. How is open EEW different? Of course, one of the defining factor is that it's open source but how is it different from those other systems? Right, good. So I would divide the other systems into maybe two categories. I would look at the national systems. I would look at say the Japanese or the Californian or the West Coast system called ShakeAlert. Those are systems with significant public funding and have taken decades to develop. I would put those into one category. And another category, I would look at some applications that people have developed, My Shake or SkyAlert or there's many of them. And if you look at the first category, I would say that the main difference is that, well, first of all, we understand the limitations of those systems because an earthquake in Northern Mexico is going to affect California and vice versa. An earthquake in Guatemala is going to affect Mexico and vice versa. An earthquake in Dominican Republic is going to affect Puerto Rico. The point is that earthquakes don't respect geography or political boundaries. And so we think national systems are limited in so far as they are limited by their borders. So that was the first thing. In terms of the technology, actually in many ways the MEMS accelerometers that we use now are streets ahead of where they were a couple of years ago. And it really allows us to detect earthquakes hundreds of kilometers away. And actually we can perform as well as these national systems. We've studied our system versus the Mexican national system called Sazmex and more often than not, we are faster and more accurate. It's on our website. So there's no reason to say that our technology is worse. And in fact, having cheaper sensors means you can have huge networks and these arrays are what make all the difference. In terms of the private ones, the problems with those is that sometimes they don't have the investment to really do wide coverage. So the open sources are strength there because we can rely on many people to sort of add to the project. Right. So yeah, I mean, you're leveraging a lot of commodity hardware, open source technologies. So it's very easy to deploy those. You mentioned earlier that data scientists, they can leverage a lot of machine learning and all those technologies. What kind of roadmap you have for the project that as you see as the project is under open source and the Linux foundation and the community grows and you get more collaboration, you get more users and those users will also bring their own solutions. So how do you see the evolution of the project itself? Right, that's a good question. So this has been a new area for me. I've had to learn and the governance of the project is very separate to the governance of Grillo. The governance of OpenEW as of today, like you mentioned is now under the umbrella of the Linux foundation. So this is now a Linux foundation project and they have certain prerequisites. So we had to form a committee, a technical committee of which it's not just Grillo, there's IBM people on the board and soon others and this committee makes the steering decisions and creates the roadmap you mentioned. So the roadmap is now published on the GitHub and it's a work in progress but effectively we're looking 12 months ahead and we've identified some areas that really need priority. Machine learning as you mentioned is definitely something that will be a huge change in this world because if we can detect earthquakes, potentially with just a single station with a much higher degree of certainty, then we can create networks that are less dense. So you can have something in Northern India in Nepal in Ecuador with just a handful of sensors. So that's our real holy grail for us. Then we also are asking on the roadmap for people to sort of work with us in lots of other areas in terms of the sensors themselves. We want to do more detection on the edge. We feel that edge computing with the sensors is obviously a much better solution than what we do now which is a lot of cloud detection but if we can move a lot of that work to the actual devices, then I think we're gonna have much smarter networks and less telemetry which opens up new connectivity options. So the sensors as well are another area priority in the roadmap. Now, if you look at the community around OpenEW, you know, Alliance Foundation, they do an incredible job at building communities but from your perspective, what kind of people you would like to get involved and how can they get involved? Right, so as of today, we're sort of formally announcing the initiative and I would really invite people to go to openew.com where we've got a site which outlines maybe some areas that people can get involved with, especially the contributing files and there we've sort of tried to sort of, we've tried to consider what type of people would join the project. You know, and so you're gonna get seismologists, we have seismologists from Harvard University and from other areas. So seismologists, they're mostly interested in the data from what we've seen so far. So they're gonna be looking at the data, the data sets that we've offered and some of them are already looking at machine learning. So there's many things that they might be looking at. Of course, anyone involved with Python and machine learning, data scientists in general might also do the similar things. Ultimately, you can be agnostic about the seismology. It shouldn't put you off because we've tried to abstract it away. We've got down to the point where this is really just data. Can you find these patterns? So that's the data. Then we've also identified the engineers and the makers and we've tried to guide them towards the repos like the sensor repo and we're asking them to help us with the firmware and the hardware. And then we've got for your more typical full stack or front end developer, we've got some other repos that deal with the actual applications. How does a user get the data? How does a user get the alerts? And there's a lot of work who can be doing there as well. So different people might have different interests. Someone might just wanna take it all. Maybe someone might want to start a network in the community, but isn't technical and that's fine. We have a Slack channel where people can join and people can say, hey, I'm in this part of the world and I'm looking for people to help me with the sensors. I can do this part. Maybe just an entrepreneur might wanna join and look for the technical people. So we're just open to anybody who's keen on the mission and they're welcome to join. Andres, thank you so much for taking your time out and talking about OpenEW. And this kind of work, we do need more of these, more open source project that can help save more lives. I would love to talk to you again as the project itself progresses. So once again, thank you and I look forward to talk to you again. Thank you, Swapnil. Pleasure to be here. Thank you.