Building a Proof-of-Concept Device

Before creating a fully-functional "final" device, it is a great idea to begin with a proof-of-concept device. This enables the designer of the device to get a feel for how it works, what can go wrong, what needs to be rethought, etc. Today, using the only set of LEDs I've found that produce reliable and consistent results, I decided to make for myself a "basic" design. By "basic", I mean that the device is cobbled together using only materials in the lab.

Snapshot_20110725_1.JPGYou'd be surprised how difficult it is to come across hemispheres - so the basis for this device was a simple box (which originally contained a few sets of testing LEDs). In this simplified design, I cut out some holes in the top of the box that the LEDs could mount into. From there, I wired up the LEDs to a breadboard and then to an Arduino Duemilanove (the Mega is still wired for testing updated versions of the sensing/emitting sequence code for the hemisphere).

I ran my first set of tests using just one sensor LED and one emitter LED. I ran the tests with two different sample materials - a piece of white lined notebook paper, and a piece of fairly diffuse black cloth. The results? Poor. Both samples showed very high variability. In both tests, the standard deviation was about half of the average value, something which is unacceptable for a scientific device.

In my second setup (seen to the left), I used three LED sensors and one LED as an emitter. Initially, the results from these sensors were confusing, with very high variability, negative readings (!), and jumps of more than 200 counts between consecutive readings on the same sensor. Results are listed below:


Trial
LED1
LED2
LED3
1
122
239
156
2
-7
135
208
3
192
394
214
4
-162
11
149
5
231
399
290
6
-169
9
107
7
228
402
312
8
-163
22
90
9
226
401
312
10
-154
39
88
Perhaps that will explain some of my confusion. Especially when the same LEDs using the same voltage-based sensing approach previously output data that had extremely low standard deviation (often less than 10 counts) at any given light level. However, there is more to this story. Looking closely at the above table, we notice a few trends with the results. If we omit the first four rows (where the LEDs are still "settling down" a little), and then use every other reading, we find that the data starts to look pretty good:

Trial
LED1
LED2
LED3
5
231
399
290
7
228
402
312
9
226
401
312
If you compare this to the data on the Voltage-based Sensing page, you will find that this compares very favorably in terms of precision. Since nothing has changed between these two tests except for the emitter source, I believe that the emitter is somehow introducing some sort of interference into the sensing system. I can't determine what exactly is causing the interference right now, but the disparities between these two tests proves that it is there. Hopefully by the end of the day today I'll be able to provide the cause of this interference, and more importantly, determine a solution to reduce this interference.

If at First You Don't Succeed...

... build another device. After getting some rather mixed results from the first device, my advisor and I decided that there were a lot of possible causes of interference in the system. One of the bigger concerns was electrical interference in the wiring, which admittedly was not my best work (I'm an Imaging Scientist, not an electrical engineer!). I decided to rebuild using some sheets of non-reflective cork board, and the same breadboard/LED/microcontroller combination as before. The new device not only looks "cleaner" but also should take away any further causes of interference.

Unfortunately I'm still working on completing the sensing code for the new device; further testing will happen tomorrow. We'll also try to track down the source of the interference that we've been experiencing with the sensor/emitter pairs tomorrow.

Snapshot_20110725_2.JPG
We had originally discussed the concept of the proposed system as a "black box" system. I took this literally.