In The Air – Week 11

As you’ll notice, week 9 and 10 have gone missing. I wasn’t able to put enough time in the project during the holiday period to justify a blog post (or two).
With the family visits all over Belgium done, I’m gradually able to put more time back in my projects. Here goes week 11 …

During week 7, I experimented with my dust sensor using an Arduino. This made it easier to understand the sensor using a microcontroller I’m familiar with.
For this post, I thought I’d hook up the dust sensor to the CC3200. Shouldn’t be too hard, right ? Well … just a little bit harder than expected!


It would seem that the ADC on the CC3200 only supports input levels up to 1.46V and not the 5V I had on the Arduino!
For testing purposes I used a voltage divider, with a ratio of 1/3. Because the maximum analog output voltage of the dust sensor is approximately 3.5V, that should do.

Another thing to be aware of, is that the analog value read using the analogRead() function results in a value between 0 and 4095 (as opposed to 0 and 1023 on Arduino).

I adapted my measuring function to the new conditions as follows:

void readDustSensor() {
  digitalWrite(ledPin, LOW); // turn LED on
  delayMicroseconds(delaySampling); // wait before sampling

  sensorValue = analogRead(sensorPin); // sample
  delayMicroseconds(delayLed); // wait before turning LED off

  digitalWrite(ledPin, HIGH); // turn LED off
  delayMicroseconds(delayCycle); // wait for end of cycle

  // max voltage of 1.46V, represented by values from 0 to 4095, times 3 to compensate for the voltage divider
  voltage = sensorValue * (1.46 / 4095.0) * 3;

I was expecting this to return the same value (or at least close to it) as during my tests with the Arduino. Somewhere around 0.74V.

Unfortunately, I’m getting values reported around 2.0V! Why ?!

Screen Shot 2015-01-09 at 22.56.40

Using the TBS 1052B oscilloscope from the previous challenge, I tried to understand what was going on. With both probes, I tried to visualise the (divided) output of the dust sensor and the trigger of the IR LED.

This was the resulting snapshot:

Using the cursors, I measured 0.280ms between the IR LED being turned on (Cursor 1 – falling edge on Ch2) and the dust sensor’s (divided) analog output (Cursor 2 – Ch1).

As you can see, the snapshot matches the expected behaviour as documented in the sensor’s datasheet rather well:

Screen Shot 2014-12-11 at 20.11.39
Cursor 2 on Ch1 reports an amplitude of 220mV, times 3 to compensate for the divider, that results in 660mv. So why is the analogRead() reporting 2.0V ??

With the scope reporting a plausible value, I’m thinking the issue lies in the analogRead() itself. So I started searching for similar issues online.
I came across following issue where multiple analogRead() attempts must be made before a correct value is obtained (what’s the deal with that?).
Not having better options at this stage, I decided to give it a try. But adding multiple analogRead() calls would surely affect the sampling timing.

To assess the impact, I report the microseconds using micros() right before and after the four dummy analogRead(), measuring how long it takes to execute.
This delay is then subtracted from the 0.280ms sampling delay.

Screen Shot 2015-01-09 at 22.42.19
The four dummy analogRead() introduce a delay of 0.040ms, so that’s what I’ll subtract from the 0.280ms delay.

The good news is that the readings after those changes are much closer to what I had measured with the Arduino, and are in line with what is measured with the scope.
The bad news is that the results fluctuate a lot more, losing the ability for proper monitoring of dust levels.

Screen Shot 2015-01-09 at 22.55.06

Smoke however, is still properly identifiable at 3.6V, as it results in the maximum output value of the sensor.

Screen Shot 2015-01-09 at 22.54.30


Well, that wasn’t as easy as I had expected … at all.

Unfortunately, it looks like this approach won’t give me reliable and stable readings. I’ll have to find another solution and make it work in the remaining seven weeks of the challenge.
That will be a challenge on its own. On the bright side, I now know about these limitations/issues with the CC3200/Energia and am able to take it into account for future projects. Oh well.

(Unless I did something very wrong in all of this and someone will point out the obvious …)

© Frederick Vandenbosch, 2014-2021. Unauthorised use and/or duplication of this material without express and written permission from this blog’s author and owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Frederick Vandenbosch with appropriate and specific direction to the original content.