I am still working on an arduino based IR-Photodiode Matrix, and i have run into a rather bad problem .
-Basically i have one master multiplexer that controls 5 other multiplexers which in turn power 8 photodiodes sequentially , and i then get the data from those photodiodes through a single data line to the Arduino.
-Now the thing is, i am having some huge "interference" from the normally NOT powered multiplexers/photodiodes that i did not notice before : ie out of 1023, i get a value of almost 300 on those elements that are not powered! I even checked with a voltmeter, and the normally unpowered multiplexer actually put out almost 2V on their pins!
-Following the info in the datasheet i grounded the E1 and E2 pins on the 74HC238s
-I can see different possible sources for this problem:
*i "cheated" in my wiring by connecting the VCC pin to the Enable input pin of the slave since i assumed (wrongly it seems) that an unpowered multiplexer should not be active
*similarly i haven't put a pull down resistor on the slave multiplexers
*I have checked each and everyone of my connections and i see no problem, although i might have missed something...
Photo diodes have also can also have a Photovoltaic effect on a circuit. Did you take that into account?
I'm pretty sure TTL chip designers NEVER assumed you would supply POWER to other IC's instead of using the ENABLE pins. Look at the TTL fanout characteristics of the chip. That is what the enable is for... when a chip is not "enabled"... a chip will stay "off the bus". If it doesn't stay off the bus, you have a design flaw that needs more/better glue logic.
Photo diodes are technically "ANALOG" devices and without any kind of biasing or amplification they are pretty much capable of giving you fits and false readings. I also think that an analog multiplexer like the CD4053 would be a better choice here. Well, it's what I would have started with.
So, for a start... I think you need to stop trying to control the Vcc feed to other IC's... and start relying on enable.
Here is a thought:
Get your circuit working "without" the diodes. Tie all of the "digital" multiplexer inputs "high" or "low" in a pattern you can then "verify" to validate the operation of your code to read the inputs. With that done... you can start playing the photo diodes. You can then be pretty sure that the logic and code remain good... so you can focus on why the diodes are giving you problems.
thanks for the fast answer pwillard!
1-yes, i have taken it into account , the photo-voltaic effect in this case is very marginal (minuscule, even at full illumination)
2-you are completely right about this, i took this not so good "shortcut" after checking out the voltage/amperage the multiplexer can source, and in an attempt to minimize power consumption (since in effect i only need one slave multiplexer on at a time...and this is important since the final version of the project will have over 350 photodiodes and over 70 multiplexers)
3-I actually use amplification before going to the arduino analog pin, although it isn't shown in the schematic
I originally used a 4051 but i switched in an attemp to both reduce the complexity and the overall power consumption.
Following you advice i will try and separate the vcc from the the enable on the slave ICs, and see how it turns out !
Thanks a lot!
As an additional note : i looked up the input current in the datasheet for the 74HC238 and it really isn't much , so perhaps just connecting the different multiplexers in parallel (as far as power supply goes) would not be that bad?
Hi Grumpy Mike ! thanks a lot, i will take a look at the article. It seems like for whatever problem i am running into you already have a very good article about it
Yes they work very well, and i didn't know about the pull up tendency of the LC logic input: i am actually using a pull down resistor (20k) before the amp.
I am not sure i am following you pwillard: do you mean isolating the diodes as in keeping their separated, sequential powering but in a better way or isolating as in "blocking" any data coming from them at undesired time ?
Right... I meant to say... you have me thinking about how to do it differently...
In my head... I keep wanting look at it like cross-point array... you know... like a 4x4 scanned keyboard array only on a much grander scale...
select a row, select a column... only 1 diode is in play...
If you control the peripherals with I2C, like with the Microchip MCp23016 to provide SINK source for the diodes, you get 16 I/O per device and you barely use any pins on the arduino. To keep the signal "ANALOG" you could employ analog multiplexers like the CD4053 on the anode side.
Thanks Willard honestly i turned this a lot around both in my head , on paper and earlier prototypes, but heck if you can find something better (although it already works quite well) i would be very thankful!
And i also wanted to thank you for your first reply : i seperated the slave's vcc from the enable, and i am not having the same problem anymore, although mike is right i will probably need to decouple the supplies since i am getting some small but present "weirdnesses" : when a shadow is cast on a part of the matrix it reduces every so slightly the values received at the other sensors.. although this will need to be rechecked at night without background ir...
hmm well thinking more about the latest problem it might be because of this (please correct me if i am completely wrong):
The way the photodiodes work right now, is:
-more light=> less resistance and less light => more resistance
So if there is more resistance, it increases the load on the overall power supply, reducing the supply for the rest of the photodiodes as well, giving slightly lower values...
hello again!
after some more testing i found a very big flaw in my design : you were right PWillard, i need to improve the isolation of the diodes !
Because right now , given the huge speed at which the data transits through the same line, there is massive cross interference / saturation, not visible at first but very present: i get much more "reactivity" and bigger high/low differences when i put a delay between each analogread...
-So before i scrap my whole design (which still works acceptably although not as good as i thought), ANY suggestions on how i can pull down the value between each reading of a photodiode value without needing a delay (which is completely innaceptable right now) is more than welcome !
Thanks in advance!
As a side note : Mike, after reading through your article a few times i have a question : without an oscilloscope to determine the frequency of the variations in the supply it will be hard to find an adapted capacitor, right ? (since most calculation depend on the frequency)
After a whole week end of trial and error i am now certain the problem comes from sending all the sensor data through one line .
Unfortunately i did a simpler test on a breadbord and using a 4051 hooked up to a few photodiodes, and the problem is EXACTLY the same!
The more sensors are hooked up to the same multiplexer , going out through the same line , the more the values get skewed (ie :at the same illumination, i get a value of 150 for one hooked up sensor, 300 for two , 450 for three etc...)!!
The wiring is the standard for a 4051 (example from arduino playground), i just have a 10k pulldown resistor before going to the analog pin....
I really don't understand it anymore : is this normal? is it only possible to send so much data at high speed through one line before it saturates? and mostly how can i solve this ?
Please, really , any help would be appreciated !
without an oscilloscope to determine the frequency of the variations in the supply it will be hard to find an adapted capacitor, right ? (since most calculation depend on the frequency)
The actual frequency of the interference doesn't matter much, just that a small capacitor gets rid of high frequencies and a large one for low frequencies.
As to your circuit I was convinced it wouldn't work as soon as I saw it, it is very unconventional. Each diode when not selected by the multiplexer is effectively connected to ground pulling the data line down. All these diodes are in parallel and so contributing to the collective pulling down of the line. With only one diode powered trying to pull the line up it is fighting a loosing battle.
However, before you pull it apart try this.
At the end of a conversion, instead of having a delay which you say helps turn the analogue input pin into a digital output with a logic zero on it, hold it for a very short time then turn it back into an input before you take the next measurement. In that way you will discharge any leakage capacitance currents building up.
Thanks a lot Mike!
In particular for that trick of using the software to enhance the pulldown, in the end i solved the problem hardware side, but it is likely to come in handy later in the project.
I agree with you completely on the unconventionality of the design and its problems. I had come to the same conclusion as you did regarding all the unpowered photodiodes pulling the line down, but actually after a lot of testing i found the major flaw of the design :
i actually put only ONE pull down resistor at the end of the data line.
i tested putting a pull down at each sensor and it solved most of the problem!
-then i replaced the pull down resistors with "pull down capacitors" (bypass capacitors if i remember right) with a value of around 100 mFarards and it solved both the noise on the line, and the pulldown problem
Now the thing is , i still think i need to change the design, while i am still in the prototyping stage : i really was trying to cut corners too much with the current design : so what i was thinking :
-switch back to analog multiplexers to get the values (which would be a "cleaner" solution: no problem there : i tested it on a breadboard works well
-problem is : i need to be able to power only a few of the photodiodes simultaniously since powering 350 of them constantly is impossible:
so any input on how i could do this is more than welcome (i though of either reusing a modified version of my current system with a few of the sensors in parallel instead of individually powered, or perhaps a led driver? )
