Group Actions
Engagement
  • Author Author: fvan
  • Date Created: Date Created
  • Views 2175 views
  • Likes 4 likes
  • Comments 10 comments
Related
Recommended

[AirCare] InTheAir - Week 11: CC3200, Energia and analogRead()

fvan

Previous posts for this project:

 

 

Introduction

 

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!

 

 

AnalogRead

 

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 ?! image

image

 

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:

image

Using the cursors, I measured 0.280ms between the IR LED being turned on (fCursor 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:

image

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.

image

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.

image

 

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

image

 

Conclusion

 

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 image On the bright side, I now know 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 ...)