Picking and sourcing sensors has been one of the major challenges we've faced with the Scintilla project. Back when our device was just a simple proof of concept, we could rely on some pretty cheap sensors to do the job. Once we got access to the SupplyFrame DesignLab, however, we devoted our time to converting our really basic NASA SpaceApps hack into a full-blown commercial grade air quality sensing IoT device that can generate some bang-on data.
This quest for quality led us through about a month of research before we could mill a single breakout board. In the past few weeks, however, we finally started crawling away from of our digital pile of schematics and datasheets and started wring up our components into working sensors.
Today I'm here to talk to you about one of our sensors in particular: the SDS-021 laser dust sensor made by the Chinese manufacturer Inovafitness. Without going too deep into the muck, the SDS-021 is an actively driven laser dust sensor designed to give accurate readings of PM 2.5 and PM 10 sized particles. It features a long use life, a power saving sleep mode, a query-based reporting system and a few other bells and whistles, all available through a simple-to-user UART protocol.
Or so they say...
Sure, you can say the SDS-021 has a "datasheet", but it's a real case study on the limitations of sourcing things from China. Aside from some poorly translated English paragraphs advertising what the device can do, there is very little in the way of how to get the device to do it. The limited instruction it does give is sometimes wrong -- like the checksum calculation, for example. Finally, the specification ends on something of a cliffhanger when it lists a bunch of "extended features" in a friendly bullet list and doesn't follow up with anything else.
I tried contacting somebody over at Inovafitness for better docs, but I don't speak Chinese and something told me the email address "firstname.lastname@example.org" doesn't get checked very often. After two days of waiting for some kind of reply, I finally decided to roll up my sleeve and take a shot at some good old fashioned reverse engineering.
My hope was that we could find some kind of program or diagnostic utility that can communicate with the SDS-021. Luckily, If you crawl around the Inovafitness site (like I did), you will eventually stumble across a desktop utility for working with their sensors. This was a gold mine, but it didn't list the SDS-021 as an available sensor and it's not designed to work with Windows 10 -- which meant it didn't find any of COM ports I had plugged in.
To work around these problems I had to run the application in compatibility mode for Windows 8 and take a guess that the protocol for the SDS-011 or the SDS-018 (the previous two versions) were the same as the SDS-021. Well, it turns out the SDS-018 didn't work, but the SDS-011 started up without a problem, so the next step was to get some data and play around with the sensor.
Playing around is an important step. First off, it's playing. Secondly, it allows us to answer important questions. For example, what happens if you query the state of the sensor while it's sleeping? Turns out the sensor wakes up all of a sudden and sends some bytes that basically mean, "I'm up! I'm up!" while it wipes the drool off its face. Below you can see a screenshot of the sensor in its default mode, spamming the COM port with data every second.
The next step was a little more boring and tedious: I had to sniff the COM port, click a bunch of buttons and work through every conceivable device state I could think of and keep track of the changes. Eventually I managed to figure out all of the different commands, what they do and how to make sense of the replies the device sends back.
Once I had all of these instructions in the bag, I hacked out a library to drive the sensor with an ESP8266 micro-controller and gave it a whirl. Once I was convinced everything was working right, I changed the status from "In Progress" to "Completed" on the sprint planning chart and pat myself on the back.
Ten minutes later I got an email from our supplier with a (mostly) completed spec for the UART protocol.