[sdiy] Reading IR phototransistors in a 8X8 matrix

[Jean-Pierre Desrochers]

Thanks Brian for your neat suggestions.
Yes, my mistake about the 8x8 = 64 reads and...  the 90 PT's I need.. !!!
The suggestion of using 6 columns of 15 rows (16 bits port) is a good one.
Much faster response. A PIC18 will do nicely on that.
And about the IR leds, well They will always be ON, connected on the main VCC.
I don't need any switching on them..
I will need a complete row of around 60 of them to spread over all the 88 + 2 = 90 possible paper holes. 
That's around 12 inches long.
Each IR led will not align correctly to each of the  90 holes
but that's not a problem. The row of IR overall light is what it's needed over the scrolling paper
to get through each scrolling paper holes and get 'caught' by the underneath holes
in the brass reading bar that the paper scrolls on.
Each of the brass bar holes will house 1mm optic fibers (around 1 foot long)
That will be glued in place and pushed flush to the bar's front surface.
The fiber's other end will face a phototransistor. All of this inside black shrinkable tubing.


> -----Message d'origine-----
> De : brianw <brianw at audiobanshee.com>
> Envoyé : 15 août 2022 21:31
> À : Jean-Pierre Desrochers <jpdesroc at oricom.ca>
> Cc : Synth-diy at synth-diy.org
> Objet : Re: [sdiy] Reading IR phototransistors in a 8X8 matrix
> 
> I've not designed any photosensitive circuits, but my first concern is the
> settling time of the phototransistor after the light source disappears (turns
> off). Perhaps photoresistors are the technology that has a long settling time.
> MIDI optoisolators are based on phototransistors, and they switch very
> quickly, so perhaps it's not an issue.
> 
> You'd have to plan for the speed of the piano roll, the spacing between
> notes, and the rate that you'd need to scan in order to catch all transitions.
> Longer settling times will require a slower scan rate, but hopefully the scan
> rate would still be high enough to catch everything.
> 
> I see that you mentioned 90 phototransistors, but only described an 8x8
> matrix. You'd only be able to scan 64 PT elements from an 8x8, so you'll need
> 12 columns of 8-bit rows. I've done 13x8 and 14x8 matrix designs on a
> Microchip USB-capable PIC18, so there should be no problem. One
> suggestion, rather than have more 8-bit rows, resulting in lots of columns,
> and thus long gaps between updates of the same coordinate; I had good luck
> increasing the row beyond 8 bits to read a pair of ports. That allows 16-bit
> rows (although I happened to choose ports where only 14 pins were
> available, but 14 is still a lot more than 8). You could scan 6 columns of 15 (or
> 16) bit rows and reach your 90 PT array. Having only 6 columns means that
> the gap between scans of the same column is much shorter than with 8 or 12
> columns. Once a column is energized, it's fairly quick to read a couple of input
> ports, rather than just one input port, before disabling the column and
> energizing the next.
> 
> Another hint is that you only ever need to energize one column at a time, so
> you do not actually need one output port pin per column. With an external
> decoder chip (discrete logic function), you can use just 3 output pins to select
> 1 of 8 possible column circuits. Even if you only need 6 columns, you can still
> use the 1-of-8 decoder to control 6 columns from 3 output bits.
> 
> Depending upon the current used for the IR LED drivers, you might want a
> 4th output pin to disable all columns, otherwise stopping the firmware might
> overdrive the LED. This is only necessary if you're trying to exceed the 20 mA
> limit of the typical LED, and instead using the 1/6 PWM of the column
> scanning to keep the average current within check. If your 10kΩ resistors are
> enough to keep the LED current below the data sheet DC limits, then you can
> leave the decoder enabled at all times and save an output pin.
> 
> It's not that I think you'll run out of GPIO pins, necessarily, but the fewer pins
> that you need to update per scan step, the faster your code will run. I've had
> good luck writing the LED matrix driver in a PIC assembly language interrupt
> routine, while the rest of the code was in the C Language for ease of
> development. The assembly interrupt uses the least amount of CPU cycles,
> allowing the main code to run at nearly 100% speed, despite the interrupts.
> 
> Brian Willoughby
> 
> 
> On Aug 15, 2022, at 12:00 PM, Jean-Pierre Desrochers <jpdesroc at oricom.ca>
> wrote:
> > I'm designing a piano Roll reader/player (yes antique paper piano
> > rolls !) that will read holes on a scrolling paper and play the actual
> > musical notes using MIDI standards..
> > This has already been done in the past but with very few
> > documentations left for DIYers like me.
> > So.. I'm thinking of using IR (940nm) LEDs, phototransistors and
> > aligned short optical fibers to read the actual scrolling holes. 90
> phototransistors will be used as 'bit' readers.
> > I would use IR because paper is mostly opaque to 940nm wavelength
> > compared to visible light that could get through it.
> > Because of that high quantity of PT’s to be read I was thinking of
> > using rows/columns matrix of switches like keyboards in synths like this:
> >
> > <image004.png>
> > But instead of switches like in this circuit I would use 2 pins phototransistors
> like this one:
> > <image001.png>
> >
> > The resistors could be around 10K and this configuration would use only 2 x
> 8 bits ports.
> > But I was wondering about using PT’s in a matrix like that would bring
> > glitches or noise In the CPU readings..
> > Has anybody used PT’s in such a circuit ?