Ok, that is how I understood it. But to do that, won't you need 20 additional lines in the cable? One for each GPIO pin to sensor power?

Yes. Assuming you daisy chained GND, SCL and SDA across 20 sensors, you would need a total of 23 lines. A very similar situation as has been mentioned with 20 enable lines (for sensors with that option). It's just an extension of what @bertus initially proposed, the difference would allow using I2C sensors.

 

Do you need to create a spectrum graph for each LED under test or to you just need to check that the correct colour LED is fitted in each position and it's brightness is within limits ? (Also is this a student exercise as there seems to be more constaints on the design than if it was just to get the job done.)

Les.

 

Do you need to create a spectrum graph for each LED under test or to you just need to check that the correct colour LED is fitted in each position and it's brightness is within limits ?

Les.

I would like to thank you all for your intercation , I'm noting all the solution to make some research .
LesJones Yes I need to plot a graph for each led under test that contains rgb values and light intensity and i need to save those values in a data base

 

What I would envision would be three lines coming from each sensor board with Vcc (connected to a mega GPIO), SCL and SDA (going to the mega I2C lines. The mega turns on the sensor it wants, reads it and turns it off - repeat 19 more times to read all of the sensors using the I2C interface. Not considering and transmission line length problems for the moment, I think that it might work, at least I don't know why it would not.

I want to work with this method since the beginning , but it's impossible with sensors that have the same adresses because i need to know which responce is coming from which sensor so i need sensor with a programmable adress

 

I want to work with this method since the beginning , but it's impossible with sensors that have the same adresses because i need to know which responce is coming from which sensor so i need sensor with a programmable adress

But if you only have one sensor powered on, then you do know which sensor the response is coming from.

Let's look at an example of two sensors. You have all the sensor's output lines connected together and to a pin on the Mega. You have each sensor's power pin connected to a unique pin on the Mega. Your code turns on the pin for sensor 1. Then you read the data. You know it's coming from sensor 1. Next, you shut off that pin and turns on the pin for sensor 2. Then you read the data. You know it's coming from sensor 2. Just expand this to twenty pins!

The Mega has 54 GPIO pins, so you should have enough...

 

But if you only have one sensor powered on, then you do know which sensor the response is coming from.

Let's look at an example of two sensors. You have all the sensor's output lines connected together and to a pin on the Mega. You have each sensor's power pin connected to a unique pin on the Mega. Your code turns on the pin for sensor 1. Then you read the data. You know it's coming from sensor 1. Next, you shut off that pin and turns on the pin for sensor 2. Then you read the data. You know it's coming from sensor 2. Just expand this to twenty pins!

The Mega has 54 GPIO pins, so you should have enough...

I'm sorryy for my stupidity but how could i know which is sensor 1 and which is sensor2? ....etc

 

theoretically its possible but Practically i dont think so

 

I'm sorryy for my stupidity but how could i know which is sensor 1 and which is sensor2? ....etc

You wired it, so you know which pin on the Mega belongs to which sensor.

 

hi,
As we are powering on/off the sensor elements I wonder what effect, if any, the warm/cooling effect may have on the colour/intensity response of the sensor.?
Anyone got any info on this query.?
E
Clip from d/s.

 

You wired it, so you know which pin on the Mega belongs to which sensor.

and if its I2C sensor? , which is the case
its wired to SCL and SDA

 

hi,
As we are powering on/off the sensor elements I wonder what effect, if any, the warm/cooling effect may have on the colour/intensity response of the sensor.?
Anyone got any info on this query.?
E
Clip from d/s.
View attachment 121853

I have no idea about that

 

and if its I2C sensor , which is the case ?
its wired to SCL and SDA

As Raymond Genovese described, those signals would be shared. You only need one pair of wires, because only one sensor would be active.

The only concern I'd hav

 

why you people are suggesting other solutions while i mentionned that i'm going to use arduino mega wiith 20 sensors which is mentioned in the project's specification: I have to use oone microcontroller to read all the informations

the project consist on reading leds on a pcb to detect the intensity of the light and rgb of the leds (its a functional test for the pcb)

the main problem here is finding the right sensor

Ok, so sounds like a student placement project.

there are multiple sensors, multiple ways of doing things.

so,

lets talk this through a little.

how many boards per hour you looking at checking,
A system that checks one board per week is very different to one that tests on board per second.

are the boards held in a fixed position , such that the leds are in exact known positions ?

As you can imagine , these sort of questions make a big difference to the expected answer,

for instance, at one end one could have a hand held sensor that is put onto each led in turn,
you could have a bank of sensors , held in a jig, that sample all leds.

or may be one sensor that is moved between the leds 'automatically'.

As ever in this sort of project, the system design is the first bit, but the first bit is knowing what is available,
Yes a contradiction ! thats whats engineering is all about, ..

what are your thoughts and suggestions.

what does your supervisor suggest ?

 

Ok, so sounds like a student placement project.

there are multiple sensors, multiple ways of doing things.

so,

lets talk this through a little.

how many boards per hour you looking at checking,
A system that checks one board per week is very different to one that tests on board per second.

are the boards held in a fixed position , such that the leds are in exact known positions ?

As you can imagine , these sort of questions make a big difference to the expected answer,

for instance, at one end one could have a hand held sensor that is put onto each led in turn,
you could have a bank of sensors , held in a jig, that sample all leds.

or may be one sensor that is moved between the leds 'automatically'.

As ever in this sort of project, the system design is the first bit, but the first bit is knowing what is available,
Yes a contradiction ! thats whats engineering is all about, ..

what are your thoughts and suggestions.

what does your supervisor suggest ?

the light of leds id trasmitted in optic fiber, if you change the pcb , you change the position of fibers
as for me i suggested multiplexing but my supervisor refused, please check this photo

 

ther is multiple pcbs with multiple sizes in the company where I work now they are using a tester called "feasa led analyser" to test them.
and unfortunately i can't use a camera to test the pcb

Have you seen these
.
https://www.proto-pic.co.uk/tca9548a-i2c-multiplexer.html?gclid=CNSmvvqnxdICFQ6eGwodToMCoA

ok this is a board, but the chipon it allows one I2C bus to talk to 8 individual I2C buss's.

You can cascade them to address uniquely any number of I2C sensors,

 

Good find @andrewmm

 

Here is a board that was designed for just such a purpose, to validate the function and brightness of 16 RGB LED's on a product. (48 LED's total)
The board was designed to sit right on top of the UUT.

Ignore the circuitry connected to the electrodes, it's irrelevant here.

It uses Taos semiconductor TCS3200 light-to-frequency converters, all of the outputs are logically "OR'd" together.
A shift register multiplexer enables each sensor, one at a time.
The multiplexer also sets up the mode control for the sensors.

The pulse frequency is then measured by a single capture-compare on a PIC MCU.