ADEM
Wieers, Dag
The aim of this project is to collect air quality information (fine dustparticles) by means of a device that collects fine dust (PM1.0 and PM2.5)metrics. The device is mounted on bicycles to crowdsource factual airpollution information in and around the city of Ghent, Belgium and centralizethat information for further processing. During this presentation we will look at the hardware and firmware design. Newideas and future extensions. But we also touch on the problems related toparticulate matter and air pollution. The device uses an ESP8266 with various sensors and output devices. Thefirmware is written in C++ using the Arduino framework.
 Welcome everybody. This talk is going to be about Adam. Adam is Dutch for breed and this project has something to do with air quality and breeding. My name is Dach Wies, but we only have 23 minutes, so I'm not going to talk about myself today. I'm not going to talk about time-lapse, but time-lapse is a faplap in Ghent where I live. So that's the only thing you need to know. It looks like this. We have lots of stuff to play with. We have a nice logo. And the logo is special in the sense that you know what this means. It's like electronic schemes, but it also includes a bird. Like in the coal mines, they used to have birds with them to monitor air quality. And if a bird died, then there was something wrong with the air quality. And that's what we want to present as well. So the Adam project, what we would like to do is collect raw data, in the first instance, raw data of air quality information. And we are focusing on fine dust because fine dust is something where we don't have a lot of information. In the sense that we do have some information, but usually it's on specific places where they have the expensive equipment to monitor. And in Ghent, for instance, there are only two places in the whole city of Ghent where they are measuring quality of the air. And then the location of these measurement devices is very strange where they are put in a park and stuff like that, which doesn't represent necessarily the real quality of what you would like to know. We think that air quality only makes sense. It's like in nuclear reactors, you have this personal device that actually measures what you're exposed to. So what we would like to do is have something similar in the sense that we can make something that tells you where you are, what the air quality is. And usually it will not be exactly because it's very dependent on lots of things. But if we can collect a lot of information, and we're going to do it by having a device that you can mount on your bike, if we can collect a lot of information during the day, and we can use that information together, we can enhance that information because we get a lot of that information. We can maybe collect information that while the components we use may not give you exact information, because we get so much information, we can get better results from it. That's what we want. And we want to get raw information in the first place because then maybe data scientists can use that information to put it on a map and do things with it that we didn't envision. So the most important thing today is the device itself. So I'm not going to talk about the health, obviously. FindUs is only one of the things you can measure about air quality. But it's one of the things that, like I said, there's not that much information of it. And the quality of that information is debatable. Also for FindUs, the World Health Organization and the European Union, they have also debatable levels that are acceptable. For instance, in Europe, the first 35 days that are measured that exceed a certain level are not taken into account. So that's a really strange way of measuring things because it makes no sense. So you can have very high levels of FindUs, for instance, and those are not counted for the 35 days. Only the 36 days taken into account. Very strange. But it's because obviously FindUs is a problem. Okay, so the different kinds of FindUs. You have PM10, which is 10 micrometrics. You have PM2.5 and PM1. And all of these have a different kind of, how do you say that? It's a sense of how it's dangerous. The PM10 is, you can breathe it in, but it doesn't go as deep as, for instance, PM2.5. Those can get into your bloodstream even if it's getting worse, ultra-fine particles. They go directly into your bloodstream, even not directly to the lungs, but even by other means. FindUs may not be caused by human activity alone. You also have FindUs, obviously, that the nature produces. So FindUs is not necessarily always related to us, to cars, to central heating systems and stuff like that. But it's one of the indicators that air quality is not that good. So, yeah, Ghent, the nice city of Ghent. We have lots of students, lots of bikes. A lot of people use bikes. I think in Belgium, Ghent is probably the city where people use the bike the most. But we also, unfortunately, have a highway going almost directly into the city. I'm living up there at the end of the highway, so I have a personal reason for doing this project. So not that important. Probably you all have these concerns where you're living, especially in cities or near highways. Like I said, yearly averages or daily averages don't mean a thing. It's the exposure you get for yourself that makes a lot of sense. One of the things that we would like to get is that we have a good indication when, for instance, it's good to open the windows to clean the air in your house. Sometimes you know from the weather announcements that the air quality is bad, but sometimes it's related to something closer to you. So it would be nice to be able on a map to tell when it's best to open your windows. Usually later in the evening, but in the winter that's worse because the central heating system, everybody's burning gas or whatever, wood. And then the air quality is even worse than during the day when there's just traffic. So it really depends on, you have to measure in-house and out-of-the-house to be able to know if it's better or not. The device, this is one of the first designs where all the components were put together. It changed a bit. We're going to see what we had to change, but this is how it looked, how it would be put together in the first version. Our idea is to have an open device, open hardware, open firmware, and also how the device is put together. That also will be open. We already have played with that as well because it's a track next to the technical part. We're using as much as possible open source libraries. I don't have to tell you that here because everybody's doing it here at this place. We tried to make it as cheap as possible. And if we have time, I will show you the bill of material. I hope we can make a device like this for 40 euros. Real devices that measure it in a scientific way, they easily cost 1,000 euros on board. So this would make a difference for us. This is also an earlier design. I didn't make a picture of the latest one, but this is basically how it works. We use the SparkFirm ESP8266. The sensor at the top is the Find Us sensor. It can measure 2.5 micrometrics and 1 micrometrics. Particles matter that is in between those in that range. I will show you how that works later on. There is a GPS in there because we obviously have to locate where we are. We have a browser, we have a light to give some indication to the user itself because we think that we get more users if the users have feedback themselves as well, if they have a personal interest. And then we have a humidity sensor. Temperature is also in all of these accelerometers to see when we are moving. That's important for the device as well. And barometer, it's the air pressure sensor as well. And while we're collecting that information as well, it's because that might influence the information you get from the Air Quality Well, the Find Us sensor. We don't know yet what the relations are. We do a bit on scientific papers that are written about the sensor we're using, but we want to be able to verify ourselves based on well data as well. And obviously based on calibrated material. So like I said, we have a microcontroller which is a Sparkfen ESP8266. The reason why we took that one is because it has Wi-Fi. That's the most important thing in this case. Because in the earlier designs we were thinking about using Bluetooth, but that's a lot more of a hassle. Like I said, the Find Us meter, we did try a lot of sensors. I think we bought five or six sensors. Also, there is a better one in the PPD42NS, which is more expensive obviously, but we didn't see that it was much better in the results that we wanted to have. So what is important to say in the latest design, we have started to use a second microcontroller to be able to convert from the GPS to I2C. I'm going to come back to this while we're doing this like this. I'm not fond of the idea, but that's the only affordable way to do it at the moment. The Find Us sensor is very important because it's the basis of everything. One of the things I have to mention as well, we're now doing Find Us in future designs, when this is all working and we have spare time. We're going to probably add other sensors as well because the design allows it. It's a modular design. You can add more sensors to the I2C bus, so that we can do as well. But we first want to focus on this and get something working. What's important about the sensor? The sensor works by sending out, emitting infrared light. We have a lens and a sensor where the light is being reflected to. It gets pulses based on what the sensor receives. The sensor itself already has some fine tuning. You see that here. It has two potential meters to be able to tweak it, but it's normally tweaked at the factory, so we don't have to use that. The air goes in here. There is a resistor to heat up the air, so you have an airflow for standalone devices. In our case, we're probably not going to use the resistor. We're going to use some effect to have an intake of air automatically, so that we don't need the resistor, which will save the battery. What do I have to tell about this as well? The PPD60NS does have two sensors, if I'm correct. So it gets better results. This does not measure black matter. That's the only problem with this sensor. The other problem with this sensor, because it doesn't reflect light, obviously, the second problem with this sensor is the fact that... Oh, I forgot what I wanted to say. Normally, in scientific and in the world health organizations, standards of acceptable levels, they measure fine dust by measuring the weight. Obviously, this doesn't measure weight, it only measures the size of particles. That's one of the problems if we do it this way. It's less scientific, but obviously, if you want to measure weight, you have to collect the dust and you have to weigh it, and that's impossible to do in real time, and that's the reason why these real devices are so expensive. There are better devices than this one using lasers and better techniques and stuff like that, but those are also very expensive. This one is not calibrated, so the calibration is one of the things we have to do ourselves by buying calibrated devices and maybe based on statistics and where you are, and if you pass a calibrated device, we can take that into account. If a bicycle or if cyclists cross each other, we can take that into account if some of them have just passed a calibrated device. Things like this are possible, but we're not counting, in this case, the weight of the fine dust, but we're only counting particles and the sizes of particles. Then, what we have to tell as well, it's an Arduino-based framework. I don't like Arduino myself, the IDE, I don't like the framework. Maybe it's better because there was a new release, I didn't test it yet, but we're also using Platform I.O., and that's a lot easier to work with. We do the CI testing automatically on GitHub with Platform I.O. Components can be swapped, so that's the nice thing about the I2C bus. We also plan to have a driver selection, so if you have different kinds of devices, you can just plug them in, and if we support them, they will be scanned automatically in this as good as possible with the IDs. We accept contributions, go through the brouhards, this is all not. We have a state machine, obviously, this is already implemented, and everything is actually implemented now, but the integration, we didn't do a lot of testing yet, because we want to get rid of the breadboard, we have two PCB designs yet, but none have been produced yet, unless we have everything working on the breadboard first. But we're very close to that now. Let me quickly do this, because this is nice, because you have an idea what it does. When you start it, obviously it has to do some initialization, and it directly goes into sleep mode, in the sense that it's not doing anything and everything is disabled, except the accelerometer, which is always on. As soon as we're moving, we go into some sort of GPS test mode where we try to get a fix for the GPS, because that's not certain, and once we get a GPS fix, then we start to collect, because it doesn't make sense to collect information if you don't know where we are. Obviously, if one of those two are gone, we go back, or we go back if we're not moving. If you shake it, we go into config mode, that opens a Wi-Fi access point where you can configure what are the Wi-Fi credentials, and what are the SSIDs that you're going to use for connecting to Wi-Fi. We plan to have multiple, so that if you cycle to work, then at work, things are being uploaded. If you go back home, they are being uploaded, we expect that if the device is not moving, though, not moving, it's always moving a bit, but not moving a lot, we go into Wi-Fi test mode. If we have data collected, so only if we have data collected, we will see if we have Wi-Fi. If we have Wi-Fi, and we test only every 30 minutes or something like that, we have to see what's acceptable. Then we upload, and as soon as it's uploaded, we go back into sleep. So that's very simple. There are certain cases where we probably want to do things differently. If you go into a tunnel, maybe we want to only go into sleep a little bit longer. We'll wait some time before we do that. Okay, the current device, like I said, the hardware design was done before I even joined the project, but things changed a bit. The components were already evaluated before I joined, so that was needed, obviously, for making the right choices. I still have seven minutes, that's fine. We now are on our second prototype, which is still breadboard based, which also has its own problems, because you have these cables that are not always making the right connections, or there is lots of information, things like that. I'm not that technical, I'm not into electronics as much as I probably should be at this point, but we're working on a team. I'm not doing this alone, so yeah, I'd like to learn more. So we have a second piece of B-design already created, which also includes the second microcontroller. We also have redesigned the casing because of the connections. You only learn those things by making something and see how this would look. We also made it a bit smaller. The idea is to use a standard tube size that is transparent, but not too transparent, so the lights are reflected towards, so that we don't need to make it's going to be mounted on a bicycle, it could be raining, weather conditions, so we have to make sure that it's properly sealed. So if you take a tube which doesn't have any openings on the side, then you only have to care about the front and the back, and that's going to be 3D-printed at first. We already have a design where everything fits into it. At the back we have access points for cables, and at this moment for testing stuff, and in the front there will only be something where air gets in. And that's also a worry in the sense that how will this survive extreme weather conditions or long usage? We still have to see. We have ideas about that as well, but it's too many to go into. We had a lot of issues, as usual, by these kinds of things. We had too few eye-opens, and that was one of the reasons to go to a second microcontroller. You could solve that in other ways, but by having a second microcontroller that only does the GPS, at the moment it only does the GPS, but in the future it could do other things as well, we can offload the GPS handling on that second microcontroller. That's one of the advantages. But the less interesting part is the fact that we have to write two firmware works. One for that microcontroller, obviously, and they have to work together. And that was one of the other problems that we had. We also had problems with imperfect signals. One of the things is that, for instance, our sensor expects 5V, and at the moment we have a battery that can go up to 4 or 2V, I think. So we probably have to use a better battery in the future. We still don't know because we haven't looked at the data the sensor is collecting yet. We first want to finish it, and then we want to do real testing. We did obviously do some things with it, but we don't know what the effect is of only giving 3.3V or more, a bit more, to the device, because obviously if the light is too weak, the results will be influenced. So we have to see how that adds up in the global picture. What can I tell as well? We had some issues with the ESP stability, but also the fact that because it has to give time to the integrated WiFi stuff, that for I2C communications we had a lot of problems that we didn't understand. We found lots of people that were having the same problems, and then we found what the issue was, and we could fix it. We had to change the I2C library a bit to make it work in a stable way. Some other stuff, I still have 3.5 minutes, so let's see. There are lots of things we would like to do. We have lots of organisations that are very interested in this, the possibilities that we have with this device. Collecting road quality information by if you have bumps, and a lot of bicycles have the same bumps at the same location, we could probably do something with it. More air quality sensors, like I said. Obviously when you have a moving device, we could also make a stationary device. It's a little bit different because we may not include the GPS, but we still want to know where we are, so we still have to see how we would do that. It would be nice to have this as well. Obviously if it's outside of the house, we do want to have that information. If it's inside of the house, obviously we don't want that information. But we may still collect it and show it to the user, because the raw data is not usable by normal people. Because you have to see that in the global picture of all the data that we measure, both the calibrated stuff and the non-calibrated stuff. But the stationary devices, if they are spread out through the city, it would be nice to calibrate those maybe ourselves from time to time, so that those are also giving a better indication of the air quality, and those can be used when cyclists pass by. We also want to correlate air quality with weather conditions, so that in the future we can also predict, based on the predictions of what the weather is going to be, what also the air quality will be based on, obviously, if it's a normal day, a weekend, and whatever. Because air quality, like I said, it's important to do that close to where you are, because it doesn't matter if there are only two collectors where the information is guarded. It's of no use, it depends what you are breeding in. The reason why I'm saying that is that... Yeah, I lost that track as well. The reason why I was going into that as well, I forgot. Bill Burchts showed in real time, there's also some interest for using an advertisement space that is unused to give that sort of information as well, which would be nice in a train station, that we could also display that information in between. Because one of the things that's important is that you can get people... that people are interested in these matters as well, only if one minute left, so the demo will be... I can give a demo later on if you're interested, and we'll go somewhere else. If you're interested to help, you're looking for more people to join as well, but now that the device is almost finished, we need obviously people that also want to test, drive around, help with integrating and stuff like that. Like myself, no prior knowledge is required, and you learn a lot. Okay, this is the information if you're interested. Take a picture now, the slides will be up somewhere, the video will be up somewhere. Let me quickly see if there is something... A lot of other projects are going on as well, we learn from that as well, because it may seem that I'm a little bit superficial over all the stuff, but it's based on other projects as well, and it's just that we don't have a lot of time. Yes, questions, quickly. I've looked up online the data interface, and it's said that it should be powered by five volts. Correct. So it's my repeated question. Yeah, we know. Can you repeat the question? Yeah, yeah, yeah, yeah, yeah, correct. Do you want any kind of accuracy on the measurement? Indeed, we know. So the question was that the datasheets say that five volts is needed, there can be 10% difference, and we know that there is an issue, but it's possible that the information we collect when it's lower also relates to the output we get, but we want to have five volts for this, definitely. That's why we're looking for different batteries and stuff like that. Maybe, I'm sorry to interrupt you, we can take other questions outside so that we don't shift the schedule too much. Obviously, obviously. Well, that's all for the presentation.
 Welcome everybody. This talk is going to be about Adam. Adam is Dutch for breed and this project has something to do with air quality and breeding.  My name is Dach Wies, but we only have 23 minutes, so I'm not going to talk about myself today. I'm not going to talk about time-lapse, but time-lapse is a faplap in Ghent where I live.  So that's the only thing you need to know. It looks like this. We have lots of stuff to play with. We have a nice logo.  And the logo is special in the sense that you know what this means. It's like electronic schemes, but it also includes a bird.  Like in the coal mines, they used to have birds with them to monitor air quality.  And if a bird died, then there was something wrong with the air quality. And that's what we want to present as well.  So the Adam project, what we would like to do is collect raw data, in the first instance, raw data of air quality information.  And we are focusing on fine dust because fine dust is something where we don't have a lot of information.  In the sense that we do have some information, but usually it's on specific places where they have the expensive equipment to monitor.  And in Ghent, for instance, there are only two places in the whole city of Ghent where they are measuring quality of the air.  And then the location of these measurement devices is very strange where they are put in a park and stuff like that,  which doesn't represent necessarily the real quality of what you would like to know.  We think that air quality only makes sense. It's like in nuclear reactors, you have this personal device that actually measures what you're exposed to.  So what we would like to do is have something similar in the sense that we can make something that tells you where you are, what the air quality is.  And usually it will not be exactly because it's very dependent on lots of things.  But if we can collect a lot of information, and we're going to do it by having a device that you can mount on your bike,  if we can collect a lot of information during the day, and we can use that information together, we can enhance that information because we get a lot of that information.  We can maybe collect information that while the components we use may not give you exact information, because we get so much information, we can get better results from it.  That's what we want. And we want to get raw information in the first place because then maybe data scientists can use that information to put it on a map and do things with it that we didn't envision.  So the most important thing today is the device itself. So I'm not going to talk about the health, obviously.  FindUs is only one of the things you can measure about air quality. But it's one of the things that, like I said, there's not that much information of it.  And the quality of that information is debatable.  Also for FindUs, the World Health Organization and the European Union, they have also debatable levels that are acceptable.  For instance, in Europe, the first 35 days that are measured that exceed a certain level are not taken into account.  So that's a really strange way of measuring things because it makes no sense. So you can have very high levels of FindUs, for instance, and those are not counted for the 35 days.  Only the 36 days taken into account. Very strange. But it's because obviously FindUs is a problem.  Okay, so the different kinds of FindUs. You have PM10, which is 10 micrometrics. You have PM2.5 and PM1.  And all of these have a different kind of, how do you say that?  It's a sense of how it's dangerous. The PM10 is, you can breathe it in, but it doesn't go as deep as, for instance, PM2.5.  Those can get into your bloodstream even if it's getting worse, ultra-fine particles.  They go directly into your bloodstream, even not directly to the lungs, but even by other means.  FindUs may not be caused by human activity alone. You also have FindUs, obviously, that the nature produces.  So FindUs is not necessarily always related to us, to cars, to central heating systems and stuff like that.  But it's one of the indicators that air quality is not that good.  So, yeah, Ghent, the nice city of Ghent. We have lots of students, lots of bikes.  A lot of people use bikes. I think in Belgium, Ghent is probably the city where people use the bike the most.  But we also, unfortunately, have a highway going almost directly into the city.  I'm living up there at the end of the highway, so I have a personal reason for doing this project.  So not that important. Probably you all have these concerns where you're living, especially in cities or near highways.  Like I said, yearly averages or daily averages don't mean a thing. It's the exposure you get for yourself that makes a lot of sense.  One of the things that we would like to get is that we have a good indication when, for instance, it's good to open the windows to clean the air in your house.  Sometimes you know from the weather announcements that the air quality is bad, but sometimes it's related to something closer to you.  So it would be nice to be able on a map to tell when it's best to open your windows.  Usually later in the evening, but in the winter that's worse because the central heating system, everybody's burning gas or whatever, wood.  And then the air quality is even worse than during the day when there's just traffic.  So it really depends on, you have to measure in-house and out-of-the-house to be able to know if it's better or not.  The device, this is one of the first designs where all the components were put together.  It changed a bit. We're going to see what we had to change, but this is how it looked, how it would be put together in the first version.  Our idea is to have an open device, open hardware, open firmware, and also how the device is put together.  That also will be open. We already have played with that as well because it's a track next to the technical part.  We're using as much as possible open source libraries. I don't have to tell you that here because everybody's doing it here at this place.  We tried to make it as cheap as possible. And if we have time, I will show you the bill of material.  I hope we can make a device like this for 40 euros.  Real devices that measure it in a scientific way, they easily cost 1,000 euros on board.  So this would make a difference for us. This is also an earlier design. I didn't make a picture of the latest one, but this is basically how it works.  We use the SparkFirm ESP8266.  The sensor at the top is the Find Us sensor. It can measure 2.5 micrometrics and 1 micrometrics.  Particles matter that is in between those in that range. I will show you how that works later on.  There is a GPS in there because we obviously have to locate where we are.  We have a browser, we have a light to give some indication to the user itself because we think that we get more users if the users have feedback themselves as well, if they have a personal interest.  And then we have a humidity sensor. Temperature is also in all of these accelerometers to see when we are moving.  That's important for the device as well. And barometer, it's the air pressure sensor as well.  And while we're collecting that information as well, it's because that might influence the information you get from the Air Quality Well, the Find Us sensor.  We don't know yet what the relations are. We do a bit on scientific papers that are written about the sensor we're using, but we want to be able to verify ourselves based on well data as well.  And obviously based on calibrated material.  So like I said, we have a microcontroller which is a Sparkfen ESP8266.  The reason why we took that one is because it has Wi-Fi. That's the most important thing in this case.  Because in the earlier designs we were thinking about using Bluetooth, but that's a lot more of a hassle.  Like I said, the Find Us meter, we did try a lot of sensors. I think we bought five or six sensors.  Also, there is a better one in the PPD42NS, which is more expensive obviously, but we didn't see that it was much better in the results that we wanted to have.  So what is important to say in the latest design, we have started to use a second microcontroller to be able to convert from the GPS to I2C.  I'm going to come back to this while we're doing this like this. I'm not fond of the idea, but that's the only affordable way to do it at the moment.  The Find Us sensor is very important because it's the basis of everything.  One of the things I have to mention as well, we're now doing Find Us in future designs, when this is all working and we have spare time.  We're going to probably add other sensors as well because the design allows it.  It's a modular design. You can add more sensors to the I2C bus, so that we can do as well.  But we first want to focus on this and get something working.  What's important about the sensor? The sensor works by sending out, emitting infrared light.  We have a lens and a sensor where the light is being reflected to.  It gets pulses based on what the sensor receives.  The sensor itself already has some fine tuning. You see that here.  It has two potential meters to be able to tweak it, but it's normally tweaked at the factory, so we don't have to use that.  The air goes in here. There is a resistor to heat up the air, so you have an airflow for standalone devices.  In our case, we're probably not going to use the resistor.  We're going to use some effect to have an intake of air automatically, so that we don't need the resistor, which will save the battery.  What do I have to tell about this as well?  The PPD60NS does have two sensors, if I'm correct.  So it gets better results. This does not measure black matter.  That's the only problem with this sensor. The other problem with this sensor, because it doesn't reflect light, obviously,  the second problem with this sensor is the fact that...  Oh, I forgot what I wanted to say.  Normally, in scientific and in the world health organizations, standards of acceptable levels,  they measure fine dust by measuring the weight. Obviously, this doesn't measure weight, it only measures the size of particles.  That's one of the problems if we do it this way. It's less scientific, but obviously, if you want to measure weight,  you have to collect the dust and you have to weigh it, and that's impossible to do in real time,  and that's the reason why these real devices are so expensive.  There are better devices than this one using lasers and better techniques and stuff like that, but those are also very expensive.  This one is not calibrated, so the calibration is one of the things we have to do ourselves by buying calibrated devices  and maybe based on statistics and where you are, and if you pass a calibrated device, we can take that into account.  If a bicycle or if cyclists cross each other, we can take that into account if some of them have just passed a calibrated device.  Things like this are possible, but we're not counting, in this case, the weight of the fine dust, but we're only counting particles and the sizes of particles.  Then, what we have to tell as well, it's an Arduino-based framework. I don't like Arduino myself, the IDE, I don't like the framework.  Maybe it's better because there was a new release, I didn't test it yet, but we're also using Platform I.O., and that's a lot easier to work with.  We do the CI testing automatically on GitHub with Platform I.O.  Components can be swapped, so that's the nice thing about the I2C bus.  We also plan to have a driver selection, so if you have different kinds of devices, you can just plug them in, and if we support them, they will be scanned automatically in this as good as possible with the IDs.  We accept contributions, go through the brouhards, this is all not.  We have a state machine, obviously, this is already implemented, and everything is actually implemented now, but the integration, we didn't do a lot of testing yet,  because we want to get rid of the breadboard, we have two PCB designs yet, but none have been produced yet, unless we have everything working on the breadboard first.  But we're very close to that now.  Let me quickly do this, because this is nice, because you have an idea what it does.  When you start it, obviously it has to do some initialization, and it directly goes into sleep mode, in the sense that it's not doing anything and everything is disabled, except the accelerometer, which is always on.  As soon as we're moving, we go into some sort of GPS test mode where we try to get a fix for the GPS, because that's not certain, and once we get a GPS fix, then we start to collect, because it doesn't make sense to collect information if you don't know where we are.  Obviously, if one of those two are gone, we go back, or we go back if we're not moving.  If you shake it, we go into config mode, that opens a Wi-Fi access point where you can configure what are the Wi-Fi credentials, and what are the SSIDs that you're going to use for connecting to Wi-Fi.  We plan to have multiple, so that if you cycle to work, then at work, things are being uploaded.  If you go back home, they are being uploaded, we expect that if the device is not moving, though, not moving, it's always moving a bit, but not moving a lot, we go into Wi-Fi test mode.  If we have data collected, so only if we have data collected, we will see if we have Wi-Fi.  If we have Wi-Fi, and we test only every 30 minutes or something like that, we have to see what's acceptable.  Then we upload, and as soon as it's uploaded, we go back into sleep. So that's very simple.  There are certain cases where we probably want to do things differently.  If you go into a tunnel, maybe we want to only go into sleep a little bit longer.  We'll wait some time before we do that.  Okay, the current device, like I said, the hardware design was done before I even joined the project, but things changed a bit.  The components were already evaluated before I joined, so that was needed, obviously, for making the right choices.  I still have seven minutes, that's fine.  We now are on our second prototype, which is still breadboard based, which also has its own problems,  because you have these cables that are not always making the right connections, or there is lots of information, things like that.  I'm not that technical, I'm not into electronics as much as I probably should be at this point, but we're working on a team.  I'm not doing this alone, so yeah, I'd like to learn more.  So we have a second piece of B-design already created, which also includes the second microcontroller.  We also have redesigned the casing because of the connections. You only learn those things by making something and see how this would look.  We also made it a bit smaller. The idea is to use a standard tube size that is transparent, but not too transparent, so the lights are reflected towards,  so that we don't need to make it's going to be mounted on a bicycle, it could be raining, weather conditions, so we have to make sure that it's properly sealed.  So if you take a tube which doesn't have any openings on the side, then you only have to care about the front and the back,  and that's going to be 3D-printed at first. We already have a design where everything fits into it.  At the back we have access points for cables, and at this moment for testing stuff, and in the front there will only be something where air gets in.  And that's also a worry in the sense that how will this survive extreme weather conditions or long usage? We still have to see.  We have ideas about that as well, but it's too many to go into. We had a lot of issues, as usual, by these kinds of things.  We had too few eye-opens, and that was one of the reasons to go to a second microcontroller.  You could solve that in other ways, but by having a second microcontroller that only does the GPS, at the moment it only does the GPS,  but in the future it could do other things as well, we can offload the GPS handling on that second microcontroller.  That's one of the advantages. But the less interesting part is the fact that we have to write two firmware works.  One for that microcontroller, obviously, and they have to work together. And that was one of the other problems that we had.  We also had problems with imperfect signals. One of the things is that, for instance, our sensor expects 5V,  and at the moment we have a battery that can go up to 4 or 2V, I think.  So we probably have to use a better battery in the future.  We still don't know because we haven't looked at the data the sensor is collecting yet.  We first want to finish it, and then we want to do real testing. We did obviously do some things with it,  but we don't know what the effect is of only giving 3.3V or more, a bit more, to the device,  because obviously if the light is too weak, the results will be influenced.  So we have to see how that adds up in the global picture.  What can I tell as well? We had some issues with the ESP stability,  but also the fact that because it has to give time to the integrated WiFi stuff,  that for I2C communications we had a lot of problems that we didn't understand.  We found lots of people that were having the same problems, and then we found what the issue was,  and we could fix it. We had to change the I2C library a bit to make it work in a stable way.  Some other stuff, I still have 3.5 minutes, so let's see.  There are lots of things we would like to do. We have lots of organisations that are very interested in this,  the possibilities that we have with this device.  Collecting road quality information by if you have bumps, and a lot of bicycles have the same bumps  at the same location, we could probably do something with it.  More air quality sensors, like I said.  Obviously when you have a moving device, we could also make a stationary device.  It's a little bit different because we may not include the GPS, but we still want to know where we are,  so we still have to see how we would do that.  It would be nice to have this as well. Obviously if it's outside of the house, we do want to have that information.  If it's inside of the house, obviously we don't want that information.  But we may still collect it and show it to the user, because the raw data is not usable by normal people.  Because you have to see that in the global picture of all the data that we measure,  both the calibrated stuff and the non-calibrated stuff.  But the stationary devices, if they are spread out through the city,  it would be nice to calibrate those maybe ourselves from time to time,  so that those are also giving a better indication of the air quality,  and those can be used when cyclists pass by.  We also want to correlate air quality with weather conditions, so that in the future we can also predict,  based on the predictions of what the weather is going to be,  what also the air quality will be based on, obviously, if it's a normal day, a weekend, and whatever.  Because air quality, like I said, it's important to do that close to where you are,  because it doesn't matter if there are only two collectors where the information is guarded.  It's of no use, it depends what you are breeding in.  The reason why I'm saying that is that...  Yeah, I lost that track as well.  The reason why I was going into that as well, I forgot.  Bill Burchts showed in real time,  there's also some interest for using an advertisement space that is unused to give that sort of information as well,  which would be nice in a train station,  that we could also display that information in between.  Because one of the things that's important is that you can get people...  that people are interested in these matters as well,  only if one minute left, so the demo will be...  I can give a demo later on if you're interested, and we'll go somewhere else.  If you're interested to help, you're looking for more people to join as well,  but now that the device is almost finished, we need obviously people that also want to test,  drive around, help with integrating and stuff like that.  Like myself, no prior knowledge is required, and you learn a lot.  Okay, this is the information if you're interested.  Take a picture now, the slides will be up somewhere, the video will be up somewhere.  Let me quickly see if there is something... A lot of other projects are going on as well,  we learn from that as well, because it may seem that I'm a little bit superficial over all the stuff,  but it's based on other projects as well, and it's just that we don't have a lot of time.  Yes, questions, quickly.  I've looked up online the data interface, and it's said that it should be powered by five volts.  Correct. So it's my repeated question.  Yeah, we know.  Can you repeat the question?  Yeah, yeah, yeah, yeah, yeah, correct.  Do you want any kind of accuracy on the measurement?  Indeed, we know.  So the question was that the datasheets say that five volts is needed,  there can be 10% difference, and we know that there is an issue,  but it's possible that the information we collect when it's lower also relates to the output we get,  but we want to have five volts for this, definitely.  That's why we're looking for different batteries and stuff like that.  Maybe, I'm sorry to interrupt you, we can take other questions outside so that we don't shift the schedule too much.  Obviously, obviously.  Well, that's all for the presentation.
ADEM_Collaborative_air_pollution_monitoring_0_131.png ADEM_Collaborative_air_pollution_monitoring_132_599.png ADEM_Collaborative_air_pollution_monitoring_600_671.png ADEM_Collaborative_air_pollution_monitoring_672_4463.png ADEM_Collaborative_air_pollution_monitoring_4464_6107.png ADEM_Collaborative_air_pollution_monitoring_6108_6923.png ADEM_Collaborative_air_pollution_monitoring_6924_7475.png ADEM_Collaborative_air_pollution_monitoring_7476_7547.png ADEM_Collaborative_air_pollution_monitoring_7548_7595.png ADEM_Collaborative_air_pollution_monitoring_7596_7859.png ADEM_Collaborative_air_pollution_monitoring_7860_8171.png ADEM_Collaborative_air_pollution_monitoring_8172_10919.png ADEM_Collaborative_air_pollution_monitoring_10920_13655.png ADEM_Collaborative_air_pollution_monitoring_13656_14723.png ADEM_Collaborative_air_pollution_monitoring_14724_14867.png ADEM_Collaborative_air_pollution_monitoring_14868_15107.png ADEM_Collaborative_air_pollution_monitoring_15108_19703.png ADEM_Collaborative_air_pollution_monitoring_19704_20879.png ADEM_Collaborative_air_pollution_monitoring_20880_21839.png ADEM_Collaborative_air_pollution_monitoring_21840_21995.png ADEM_Collaborative_air_pollution_monitoring_21996_22055.png ADEM_Collaborative_air_pollution_monitoring_22056_22115.png ADEM_Collaborative_air_pollution_monitoring_22116_22163.png ADEM_Collaborative_air_pollution_monitoring_22164_22211.png ADEM_Collaborative_air_pollution_monitoring_22212_36719.png ADEM_Collaborative_air_pollution_monitoring_36720_36863.png ADEM_Collaborative_air_pollution_monitoring_36864_36911.png ADEM_Collaborative_air_pollution_monitoring_36912_36959.png ADEM_Collaborative_air_pollution_monitoring_36960_37019.png ADEM_Collaborative_air_pollution_monitoring_37020_37067.png ADEM_Collaborative_air_pollution_monitoring_37068_37212.png
Welcome everybody. This talk is going to be about Adam. Adam is Dutch for breed and this project has something to do with air quality and breeding. My name is Dach Wies, but we only have 23 minutes, so I'm not going to talk about myself today. I'm not going to talk about time-lapse, but time-lapse is a faplap in Ghent where I live. So that's the only thing you need to know. It looks like this. We have lots of stuff to play with. We have a nice logo. And the logo is special in the sense that you know what this means. It's like electronic schemes, but it also includes a bird. Like in the coal mines, they used to have birds with them to monitor air quality. And if a bird died, then there was something wrong with the air quality. And that's what we want to present as well. So the Adam project, what we would like to do is collect raw data, in the first instance, raw data of air quality information. And we are focusing on fine dust because fine dust is something where we don't have a lot of information. In the sense that we do have some information, but usually it's on specific places where they have the expensive equipment to monitor. And in Ghent, for instance, there are only two places in the whole city of Ghent where they are measuring quality of the air. And then the location of these measurement devices is very strange where they are put in a park and stuff like that, which doesn't represent necessarily the real quality of what you would like to know. We think that air quality only makes sense. It's like in nuclear reactors, you have this personal device that actually measures what you're exposed to. So what we would like to do is have something similar in the sense that we can make something that tells you where you are, what the air quality is. And usually it will not be exactly because it's very dependent on lots of things. But if we can collect a lot of information, and we're going to do it by having a device that you can mount on your bike, if we can collect a lot of information during the day, and we can use that information together, we can enhance that information because we get a lot of that information. We can maybe collect information that while the components we use may not give you exact information, because we get so much information, we can get better results from it. That's what we want. And we want to get raw information in the first place because then maybe data scientists can use that information to put it on a map and do things with it that we didn't envision. So the most important thing today is the device itself. So I'm not going to talk about the health, obviously. FindUs is only one of the things you can measure about air quality. But it's one of the things that, like I said, there's not that much information of it. And the quality of that information is debatable. Also for FindUs, the World Health Organization and the European Union, they have also debatable levels that are acceptable. For instance, in Europe, the first 35 days that are measured that exceed a certain level are not taken into account. So that's a really strange way of measuring things because it makes no sense. So you can have very high levels of FindUs, for instance, and those are not counted for the 35 days. Only the 36 days taken into account. Very strange. But it's because obviously FindUs is a problem. Okay, so the different kinds of FindUs. You have PM10, which is 10 micrometrics. You have PM2.5 and PM1. And all of these have a different kind of, how do you say that? It's a sense of how it's dangerous. The PM10 is, you can breathe it in, but it doesn't go as deep as, for instance, PM2.5. Those can get into your bloodstream even if it's getting worse, ultra-fine particles. They go directly into your bloodstream, even not directly to the lungs, but even by other means. FindUs may not be caused by human activity alone. You also have FindUs, obviously, that the nature produces. So FindUs is not necessarily always related to us, to cars, to central heating systems and stuff like that. But it's one of the indicators that air quality is not that good. So, yeah, Ghent, the nice city of Ghent. We have lots of students, lots of bikes. A lot of people use bikes. I think in Belgium, Ghent is probably the city where people use the bike the most. But we also, unfortunately, have a highway going almost directly into the city. I'm living up there at the end of the highway, so I have a personal reason for doing this project. So not that important. Probably you all have these concerns where you're living, especially in cities or near highways. Like I said, yearly averages or daily averages don't mean a thing. It's the exposure you get for yourself that makes a lot of sense. One of the things that we would like to get is that we have a good indication when, for instance, it's good to open the windows to clean the air in your house. Sometimes you know from the weather announcements that the air quality is bad, but sometimes it's related to something closer to you. So it would be nice to be able on a map to tell when it's best to open your windows. Usually later in the evening, but in the winter that's worse because the central heating system, everybody's burning gas or whatever, wood. And then the air quality is even worse than during the day when there's just traffic. So it really depends on, you have to measure in-house and out-of-the-house to be able to know if it's better or not. The device, this is one of the first designs where all the components were put together. It changed a bit. We're going to see what we had to change, but this is how it looked, how it would be put together in the first version. Our idea is to have an open device, open hardware, open firmware, and also how the device is put together. That also will be open. We already have played with that as well because it's a track next to the technical part. We're using as much as possible open source libraries. I don't have to tell you that here because everybody's doing it here at this place. We tried to make it as cheap as possible. And if we have time, I will show you the bill of material. I hope we can make a device like this for 40 euros. Real devices that measure it in a scientific way, they easily cost 1,000 euros on board. So this would make a difference for us. This is also an earlier design. I didn't make a picture of the latest one, but this is basically how it works. We use the SparkFirm ESP8266. The sensor at the top is the Find Us sensor. It can measure 2.5 micrometrics and 1 micrometrics. Particles matter that is in between those in that range. I will show you how that works later on. There is a GPS in there because we obviously have to locate where we are. We have a browser, we have a light to give some indication to the user itself because we think that we get more users if the users have feedback themselves as well, if they have a personal interest. And then we have a humidity sensor. Temperature is also in all of these accelerometers to see when we are moving. That's important for the device as well. And barometer, it's the air pressure sensor as well. And while we're collecting that information as well, it's because that might influence the information you get from the Air Quality Well, the Find Us sensor. We don't know yet what the relations are. We do a bit on scientific papers that are written about the sensor we're using, but we want to be able to verify ourselves based on well data as well. And obviously based on calibrated material. So like I said, we have a microcontroller which is a Sparkfen ESP8266. The reason why we took that one is because it has Wi-Fi. That's the most important thing in this case. Because in the earlier designs we were thinking about using Bluetooth, but that's a lot more of a hassle. Like I said, the Find Us meter, we did try a lot of sensors. I think we bought five or six sensors. Also, there is a better one in the PPD42NS, which is more expensive obviously, but we didn't see that it was much better in the results that we wanted to have. So what is important to say in the latest design, we have started to use a second microcontroller to be able to convert from the GPS to I2C. I'm going to come back to this while we're doing this like this. I'm not fond of the idea, but that's the only affordable way to do it at the moment. The Find Us sensor is very important because it's the basis of everything. One of the things I have to mention as well, we're now doing Find Us in future designs, when this is all working and we have spare time. We're going to probably add other sensors as well because the design allows it. It's a modular design. You can add more sensors to the I2C bus, so that we can do as well. But we first want to focus on this and get something working. What's important about the sensor? The sensor works by sending out, emitting infrared light. We have a lens and a sensor where the light is being reflected to. It gets pulses based on what the sensor receives. The sensor itself already has some fine tuning. You see that here. It has two potential meters to be able to tweak it, but it's normally tweaked at the factory, so we don't have to use that. The air goes in here. There is a resistor to heat up the air, so you have an airflow for standalone devices. In our case, we're probably not going to use the resistor. We're going to use some effect to have an intake of air automatically, so that we don't need the resistor, which will save the battery. What do I have to tell about this as well? The PPD60NS does have two sensors, if I'm correct. So it gets better results. This does not measure black matter. That's the only problem with this sensor. The other problem with this sensor, because it doesn't reflect light, obviously, the second problem with this sensor is the fact that... Oh, I forgot what I wanted to say. Normally, in scientific and in the world health organizations, standards of acceptable levels, they measure fine dust by measuring the weight. Obviously, this doesn't measure weight, it only measures the size of particles. That's one of the problems if we do it this way. It's less scientific, but obviously, if you want to measure weight, you have to collect the dust and you have to weigh it, and that's impossible to do in real time, and that's the reason why these real devices are so expensive. There are better devices than this one using lasers and better techniques and stuff like that, but those are also very expensive. This one is not calibrated, so the calibration is one of the things we have to do ourselves by buying calibrated devices and maybe based on statistics and where you are, and if you pass a calibrated device, we can take that into account. If a bicycle or if cyclists cross each other, we can take that into account if some of them have just passed a calibrated device. Things like this are possible, but we're not counting, in this case, the weight of the fine dust, but we're only counting particles and the sizes of particles. Then, what we have to tell as well, it's an Arduino-based framework. I don't like Arduino myself, the IDE, I don't like the framework. Maybe it's better because there was a new release, I didn't test it yet, but we're also using Platform I.O., and that's a lot easier to work with. We do the CI testing automatically on GitHub with Platform I.O. Components can be swapped, so that's the nice thing about the I2C bus. We also plan to have a driver selection, so if you have different kinds of devices, you can just plug them in, and if we support them, they will be scanned automatically in this as good as possible with the IDs. We accept contributions, go through the brouhards, this is all not. We have a state machine, obviously, this is already implemented, and everything is actually implemented now, but the integration, we didn't do a lot of testing yet, because we want to get rid of the breadboard, we have two PCB designs yet, but none have been produced yet, unless we have everything working on the breadboard first. But we're very close to that now. Let me quickly do this, because this is nice, because you have an idea what it does. When you start it, obviously it has to do some initialization, and it directly goes into sleep mode, in the sense that it's not doing anything and everything is disabled, except the accelerometer, which is always on. As soon as we're moving, we go into some sort of GPS test mode where we try to get a fix for the GPS, because that's not certain, and once we get a GPS fix, then we start to collect, because it doesn't make sense to collect information if you don't know where we are. Obviously, if one of those two are gone, we go back, or we go back if we're not moving. If you shake it, we go into config mode, that opens a Wi-Fi access point where you can configure what are the Wi-Fi credentials, and what are the SSIDs that you're going to use for connecting to Wi-Fi. We plan to have multiple, so that if you cycle to work, then at work, things are being uploaded. If you go back home, they are being uploaded, we expect that if the device is not moving, though, not moving, it's always moving a bit, but not moving a lot, we go into Wi-Fi test mode. If we have data collected, so only if we have data collected, we will see if we have Wi-Fi. If we have Wi-Fi, and we test only every 30 minutes or something like that, we have to see what's acceptable. Then we upload, and as soon as it's uploaded, we go back into sleep. So that's very simple. There are certain cases where we probably want to do things differently. If you go into a tunnel, maybe we want to only go into sleep a little bit longer. We'll wait some time before we do that. Okay, the current device, like I said, the hardware design was done before I even joined the project, but things changed a bit. The components were already evaluated before I joined, so that was needed, obviously, for making the right choices. I still have seven minutes, that's fine. We now are on our second prototype, which is still breadboard based, which also has its own problems, because you have these cables that are not always making the right connections, or there is lots of information, things like that. I'm not that technical, I'm not into electronics as much as I probably should be at this point, but we're working on a team. I'm not doing this alone, so yeah, I'd like to learn more. So we have a second piece of B-design already created, which also includes the second microcontroller. We also have redesigned the casing because of the connections. You only learn those things by making something and see how this would look. We also made it a bit smaller. The idea is to use a standard tube size that is transparent, but not too transparent, so the lights are reflected towards, so that we don't need to make it's going to be mounted on a bicycle, it could be raining, weather conditions, so we have to make sure that it's properly sealed. So if you take a tube which doesn't have any openings on the side, then you only have to care about the front and the back, and that's going to be 3D-printed at first. We already have a design where everything fits into it. At the back we have access points for cables, and at this moment for testing stuff, and in the front there will only be something where air gets in. And that's also a worry in the sense that how will this survive extreme weather conditions or long usage? We still have to see. We have ideas about that as well, but it's too many to go into. We had a lot of issues, as usual, by these kinds of things. We had too few eye-opens, and that was one of the reasons to go to a second microcontroller. You could solve that in other ways, but by having a second microcontroller that only does the GPS, at the moment it only does the GPS, but in the future it could do other things as well, we can offload the GPS handling on that second microcontroller. That's one of the advantages. But the less interesting part is the fact that we have to write two firmware works. One for that microcontroller, obviously, and they have to work together. And that was one of the other problems that we had. We also had problems with imperfect signals. One of the things is that, for instance, our sensor expects 5V, and at the moment we have a battery that can go up to 4 or 2V, I think. So we probably have to use a better battery in the future. We still don't know because we haven't looked at the data the sensor is collecting yet. We first want to finish it, and then we want to do real testing. We did obviously do some things with it, but we don't know what the effect is of only giving 3.3V or more, a bit more, to the device, because obviously if the light is too weak, the results will be influenced. So we have to see how that adds up in the global picture. What can I tell as well? We had some issues with the ESP stability, but also the fact that because it has to give time to the integrated WiFi stuff, that for I2C communications we had a lot of problems that we didn't understand. We found lots of people that were having the same problems, and then we found what the issue was, and we could fix it. We had to change the I2C library a bit to make it work in a stable way. Some other stuff, I still have 3.5 minutes, so let's see. There are lots of things we would like to do. We have lots of organisations that are very interested in this, the possibilities that we have with this device. Collecting road quality information by if you have bumps, and a lot of bicycles have the same bumps at the same location, we could probably do something with it. More air quality sensors, like I said. Obviously when you have a moving device, we could also make a stationary device. It's a little bit different because we may not include the GPS, but we still want to know where we are, so we still have to see how we would do that. It would be nice to have this as well. Obviously if it's outside of the house, we do want to have that information. If it's inside of the house, obviously we don't want that information. But we may still collect it and show it to the user, because the raw data is not usable by normal people. Because you have to see that in the global picture of all the data that we measure, both the calibrated stuff and the non-calibrated stuff. But the stationary devices, if they are spread out through the city, it would be nice to calibrate those maybe ourselves from time to time, so that those are also giving a better indication of the air quality, and those can be used when cyclists pass by. We also want to correlate air quality with weather conditions, so that in the future we can also predict, based on the predictions of what the weather is going to be, what also the air quality will be based on, obviously, if it's a normal day, a weekend, and whatever. Because air quality, like I said, it's important to do that close to where you are, because it doesn't matter if there are only two collectors where the information is guarded. It's of no use, it depends what you are breeding in. The reason why I'm saying that is that... Yeah, I lost that track as well. The reason why I was going into that as well, I forgot. Bill Burchts showed in real time, there's also some interest for using an advertisement space that is unused to give that sort of information as well, which would be nice in a train station, that we could also display that information in between. Because one of the things that's important is that you can get people... that people are interested in these matters as well, only if one minute left, so the demo will be... I can give a demo later on if you're interested, and we'll go somewhere else. If you're interested to help, you're looking for more people to join as well, but now that the device is almost finished, we need obviously people that also want to test, drive around, help with integrating and stuff like that. Like myself, no prior knowledge is required, and you learn a lot. Okay, this is the information if you're interested. Take a picture now, the slides will be up somewhere, the video will be up somewhere. Let me quickly see if there is something... A lot of other projects are going on as well, we learn from that as well, because it may seem that I'm a little bit superficial over all the stuff, but it's based on other projects as well, and it's just that we don't have a lot of time. Yes, questions, quickly. I've looked up online the data interface, and it's said that it should be powered by five volts. Correct. So it's my repeated question. Yeah, we know. Can you repeat the question? Yeah, yeah, yeah, yeah, yeah, correct. Do you want any kind of accuracy on the measurement? Indeed, we know. So the question was that the datasheets say that five volts is needed, there can be 10% difference, and we know that there is an issue, but it's possible that the information we collect when it's lower also relates to the output we get, but we want to have five volts for this, definitely. That's why we're looking for different batteries and stuff like that. Maybe, I'm sorry to interrupt you, we can take other questions outside so that we don't shift the schedule too much. Obviously, obviously. Well, that's all for the presentation.
Adam. Adam is Dutch for breed and this project quality information. And we are focusing on fine city of Ghent where they are measuring quality of bike the most. But we also, unfortunately, have a have an open device, open hardware, open firmware, and also how the device is put a device like this for 40 euros. Real devices the SparkFirm ESP8266. The sensor at the top is that are written about the sensor we're using, levels, they measure fine dust by measuring the measure weight, you have to collect the dust and something with it. More air quality sensors, like that in the future we can also predict, based on that's all for the presentation.