Thread: Developments in Dust Sensor tech

Got 3 new PMS7003 counters today (3 matchbox size blue boxes) and started setting one up with SD card and Real time clock (RTC) data logging.

Below is a mock up of the type I will be loaning to mens sheds to assess dust levels.
Picture doesn't show much but thought you might like to see what I'm dabbling with.
IMG_2350p.jpg

These units will use simple single numerical value LED display of PM10 Concentrations but they will log all particle sizes and concentrations onto an SD card.
The red SD card/RTC modules plug in on top of the arduino boards.
I was keen to use the smaller and Uno board (one is under the topmost Red board) and although there are enough of the right connection pins (just) as the program developed I rapidly ran out of dynamic RAM and had to switch to the bigger MEGA board.
The program for this setup is already up to over 800 lines of code and it could get to 1000 by the time I finish.

Really nice work Bob, I have one of these on the way and I've been reading your test results here, and your latest thoughts in the FAQ thread.

I've decided to use one of these sensors to "occasionally" check the levels in the workshop, the idea being to verify that the levels are staying below the (revised) low end of the allowable values as outlined in your current FAQ thread, and likely to be revised as you carry out more tests.

For my needs I'll be mounting a tiny Transceiver module and a 4ah li-ion battery with the sensor, so relatively small and can be positioned anywhere. The receiver / controller will be a touch screen display micro controller unit that I use for various projects in my other hobby workshop.

So to use the sensor, I select the touch screen menu and load the module (I have yet to write) for the Air quality monitor, then plug in a companion transceiver adaptor in the back of the display box to talk to the sensor and it's ready to go.

I'll have the advantage of a 7" touch screen display, so anything is selectable on screen for any kind of graphical display, meter, graph, logging and averaging code that needs to written for this device.

It's only been a week since I ordered one, so it's still a few weeks away, by then I hope to have the time to have a much closer look at your findings, and perhaps pick you brain for thoughts on how best to use, and importantly, formulate the various data from these sensors to give the most meaningful information display.

Mike.

Originally Posted by MandJ

Really nice work Bob, I have one of these on the way and I've been reading your test results here, and your latest thoughts in the FAQ thread.

I've decided to use one of these sensors to "occasionally" check the levels in the workshop, the idea being to verify that the levels are staying below the (revised) low end of the allowable values as outlined in your current FAQ thread, and likely to be revised as you carry out more tests. .

Good to see someone else setting one of these up.
What sort of micro controller are you going to use?

The sensors seem to ship very quickly, the first I ordered arrived within seven days of ordering and the second lot only took 5 days to get to Perth.

I would encourage users to leave their sensor running at least while they are in the shed and not just look at it when they think there is a lot of dust around.
A running graph of data would be very useful.

The more I think about it the more I think we need to be monitoring PM2.5 concentrations because this is where the greatest general risks seem to be. PM5 and PM10 are relevant to woodworkers because it is known that they cause nose and throat cancers but the number that contract this is low. PM2.5 is what is more likely to trigger allergies and other more general health issues like cardiovascular problems which are much wider problems.

This then a good guide as to what you should display/monitor.

I would look at least to monitoring PM10 and PM2.5 concentrations - the sensor provides these directly about once every 3 seconds.
The particle profile is to some extent captured by the monitoring PM10 and PM2.5 concentration levels and is an issue to discuss for another time

The sensor provides the same set of data about once a second three times so a new set of data is only available every ~3 seconds which is plenty of time to do other things like log, process and plot data.

The data jumps around a lot so I'm using a simple 10 point average (30 seconds) which is short enough to measure rapid and significant dust level changes.

As I have said before (maybe?) I don't believe what the sensor says at low or at high concentrations but around the 500 ppb range which is sort of the cross over range for woodworkers, it is at least +/- 20% for PM10, and for PM 2.5 it might be as good as +/-10%. This pretty good for dust measurement at these prices and to do any better you need to spend 100X more.

I think these sensors will rapidly get better in the next few years.

Thanks, on the subject of running them when ever in the shop, I was thinking of running it continuously during all the normal work we do, then having determined that the Dust collection and room venting are working as hoped (providing filters are keep reasonably clean) and that any shed clean up practices are not creating a problem, it would then be used to check weekly or run whenever we do something different. I'm concerned about how long the sensor will last if running continually, perhaps you can shed some light on this? Obviously the more polluted the air the shorter the life of the sensor, so assuming that levels are low, I wonder what the expected life time of one of these sensors would be in a wood working environment with "reasonably" effective dust extraction?


The Microcontroller is Microchip PIC32MX470 - my soon be upgraded to PIC32MZ2048EFM100.

Originally Posted by MandJ

Thanks, on the subject of running them when ever in the shop, I was thinking of running it continuously during all the normal work we do, then having determined that the Dust collection and room venting are working as hoped (providing filters are keep reasonably clean) and that any shed clean up practices are not creating a problem, it would then be used to check weekly or run whenever we do something different. I'm concerned about how long the sensor will last if running continually, perhaps you can shed some light on this? Obviously the more polluted the air the shorter the life of the sensor, so assuming that levels are low, I wonder what the expected life time of one of these sensors would be in a wood working environment with "reasonably" effective dust extraction?

The manufacturers are reporting a MTBF of >3 years continuous in a moderately dusty environment whatever that means.
For a 40 hour week that equates to ~12 years and if they die then whats another $34 to keep going - I expect that they will improve rapidly so you will be wanting a new model in a few years time anyway.
If your DC is working properly you should have the same as outside air so for Australia I would expect that in most cases to be much cleaner than average Chinese air.
If they get a unexpected burst of dust they supposedly can be cleaned although I cannot see a way to easily open them up.
If it was not too great a flood of dust they can self clean to some extent by placing them in clean air. Its a good idea to check they can read zero from time to time.

The Microcontroller is Microchip PIC32MX470 - my soon be upgraded to PIC32MZ2048EFM100.

Thanks

Thanks for that clarity Bob, that makes my concern over running it full time in the workshop irrelevant, so full time it is.

BTW on the subject of Micro controllers - The unit I'm using is based around a development board from Microchip - If anyone is interested I could post a small bit of info and a link to an Australian designed and available kit for this kind of thing - you program this in a specially written version of Basic, so very short learning curve for new users, especially things like touch screens and screen graphic controls all built into the language and the AU kit.

I would be interested.

Same here.

I'll try and keep this short then. I mentioned before that I usually program mostly in assembler, it's just something I'm very at home with. However on larger micros with plenty of speed, code space and memory (relative to the programming task) I used to use C.

Quite a few years ago Geoff Graham, here in AU, designed the first of his Micromite range - sure you have heard of it, he also wrote a Basic programming language especially for these 32 bit microprocessors called MMBasic, it's a Microsoft BASIC compatible implementation of the BASIC language with floating point, integer and string variables, arrays, long variable names, a built in program editor and many other features. He constantly updates MMBasic for his smaller (and lower cost) embedded micro boards and the newer "Explore 100" designs based around the PIC32MX470. I used it years ago and started using once again when I found that his MMBasic worked with the development board I'm using.

So why would you want to program in Basic? Because his implementation is great, it allows someone new to micro controllers, a simple easy path to get even a very advanced project going with relative ease - If you know of the small Picaxe chips, then think of something like that on steroids.

His latest board is set up for almost any display type, including touch screen up to 8". BTW a 7" touch display is around $39. The 5" and 7" screen just plug straight into his board. The thing is, the learning curve is really simple and the power and ease of this is seriously impressive for this type of process control, especially with the simple touch screen and graphic controls available and the extensive (and ever growing) built in hardware control functions. If you program these things occasionally then it's easy to come back after months and pick up where you left off. And there is a big free library of control code available for download.

The only down side is the cost of the Explore 100 Kit, from silicon chip it's around $69 (without LCD screen) AND you have to solder a 100 pin SMD - seriously?.

However there is a kit available with all SMD devices mounted, it's available from over the Pond in NZ - costs $75 USD including standard Airmail -
https://www.rictech.nz/products/13/M...L-KIT-OF-PARTS. He works closely with Geoff on the board design and kits.

The idea is that you reuse the same controller and screen, you simply plug a different hardware interface into the I/O connector for the control task at hand, you can have a huge number of control code modules on the SD card, just a matter of selecting the one from the Touch screen for the current control device.

You can make changes to the code you are writing or testing on the unit itself, and instantly run it with the changes - Obviously you can also write code for it on the PC and send it to the device, or test and run code on the PC itself before sending to the controller.

Geoffs site for the Explore-100 and the various smaller units that share this code language. Geoff's Projects - Micromite Explore 100.

As daunting as it my seem - this is seriously a simple device to use, there is a lot of on line forum help available in AU, GB and US. If you want to know more I could start a thread in the Electronics forum - there may already be one? or just PM me.

I'll be writing the program to interface and display the Sensor data in various ways, so code of course will be given to anyone who wants it.

Mike.

BTW I know everyone has their own favourite low cost board, programming language and this is not about which is the best, fastest or easiest. If we start down that road then it just gets silly. So as to not go far off topic in this important thread - please start another thread to debate this if it's a life and death subject for you.

Thanks for posting this.
I just realised this should probably go in the electronics forum under its own thread.

I did some more on the software yesterday.
Broke up some the code into functions and this reduced the code length a bit, but then decided to add a rotary switch so that users can see a bit more data on the one line LED display.
SO now the display can be switched to show, PM10, PM2.5 and PM1 concentrations, and total numbers of particles be 100 mL of air.

The larger brighter LED display is definitely easier to see, especially from a distance, but programming it is a right PITA. There are a few libraries, but you can't just say, display "1234.5" - the number has to be broken down into single digits and all you can say is display a single digit in a specific LED location. If you want to print something using letters you have direct access asking it to display these two digit (hex) numbers "10, 11, 12, 13, 14, 15" which it converts to "A, b, c, d, and E", but any other letters have to be built up by disconcerting.

Displaying "no DISP" for rotary switch position which did not display any data required the individual LED pixels to be manipulated for the letters "n, o, and P"
for the "D, I and S", I used the numbers 0, 1 and 5.
This looked easy but it just took quiet a while to sort out making sure previous data is erased is the worst part.

All this took most of the morning and then I programmed which days of the week and times it collected data. This can be adjusted in the program just before the counter is installed to suit specific shed operating times.

This reduces the size of the files significantly, not because storage is a problem - the total file size for a week is about 14Mb which easily fits on a 4Gb SD card - I just don't want to be dealing with too large a file later when analysing the data. The time-date programming sounded easy but I got totally tangle up in logic and sting statements and had to break it down into manageable for an older bloke brain into smaller bits and pieces. I solved it just before tea time.

Still have to add the Temp Humidity module and the code is already now up to 950 lines - it could be substantially reduced in size but all I want to do is get it in place collecting data.

From the quick reading I've had time to do, I think that Temp and Humidity can affect the readings, are you going to just display the two values or are you planning on doing some maths to allow for these factors - perhaps I'm over thinking this and the effect may be unimportant for WoodW testing?

Originally Posted by MandJ

From the quick reading I've had time to do, I think that Temp and Humidity can affect the readings, are you going to just display the two values or are you planning on doing some maths to allow for these factors - perhaps I'm over thinking this and the effect may be unimportant for WoodW testing?

Sorry I meant to include the following in my previous post.

Yesterday while programming the sensor in my study, amongst other things I was watching the PM10 numbers come out all through the day. The morning started out with the the PM10 concentration in my study at around about 3 ppb. This very low but that is typical of what happens overnight - still air inside a reasonably well sealed room with only light cool dry winds outside. This also reduces air exchange between inside and outside air and allows for the fine particles to settle. Over the next couple of hours with me going in and out of the study the PM10 slowly rose to about 5 ppb.

At around 11 am the SWMBO released the robot vacuum cleaner into the adjacent room and it came into the study and the dust levels went up to about 10 ppb. It probably would have gone higher but I took it outside one it had cleaner up most of the floor.

Over the next few hours the levels slowly dropped to around 5ppb and then at around 4:30 pm the levels rose quickly to ~ 30 ppb - I looked at the local weather stations website and sure enough the humidity rose from 68 to 86 % just before a short sharp 1.5 mm - during the shower the PM10 concentration rose to nearly 40 ppb and then it came backdown again to 3ppb even though the humidity stayed over 87% for the next 3+ hours. The more very very fine dust (i.e. sub 3 micron) there is in the air, the more this will affect readings. For example testing after a long dry windy period (high atmospheric dust) struck by a rapid change in humidity (e.g. thunderstorm) could lead to difficulties in making meaningful measurements.

What this shows is how complex it all is - it's not just the absolute Relatively humidity that changes the numbers of particles, but a complex interaction in the change in the relative humidity/temp with the dust. Corrections are hard to make because one thing needed for correction is the composition of the particles and while in a workshop, wood should be the obvious component it could well be that external dust drawn by a DC into the shed of unknown origin is affecting the results. Ultimately it will be these changes that limit the extent to which changes to DC systems to improve things based on particle counters could even make things worse.

The usual thing to do is record temperature and humidity so if one sees an abnormal changes in dust levels possibly linked to changes in H/T then those levels are questioned. This is why constant logging of your own shed is useful so in time you will gain some understanding of how it is all linked for your situation.

Thanks Bob, this is really time saving information to have for those of us who set one of these up in the shed. Especially air intake from outside when running the DC, almost need two sensors with one as an outside shed reference. It would be simple to log and graph the time, temperature and humidity along with the air quality readings, as you say, over time it should help indicate when inside shed readings are going to be skewed. Like everything else we try to measure with dust collection and air flow, the devil is in the detail of taking and interpreting those readings correctly.

One thing you mentioned with storms, rain and the readings, reminded me about the research showing a big spike in spore readings as rain drops hit the ground, trees etc. It being a cause of sinus / hay fever conditions for a lot of people.