Optical Bench REDUX: Digital Switching can have Analog Functions!

[RJSV]

   Going to the bigger value, like '52' for example, allows for pushing the limits on resolution and accuracy (of some very very fast multiplies).
You can see, in diagram, the basic light 'valve' blocking or admitting light elements can be all arranged in a line, like the 10 piece BUS was, but starts to get unwieldy packaged that way...
That's why the emphasis on a more square or round shape, all condensed together.
   You might notice; this particular structure would be for a constant...A constant multiplier, like '52' in this case.

[RJSV]

This third diagram, today, starts to show the type of game to be played:
   Idea is to pre-position as many BUS signal blocking flaps as possible, so that the column of multiply and accumulate actions are as deep as possible...(so that only the fast calculation, of multiple conditional adds takes place).  That part is fine...but only with condition that the 'lateral' summations only include valid columns.  Funny thing is, you can still proceed, down that column, even when not knowing or resolving what you have.  In this case now, you've got a 2-digit multiplier, going against a totally wide-open analog value, as the multiplicand. Some preliminary thoughts there are to use, perhaps, 14 bits worth of analog value, but use a 10 but converter.
That way you've got some extra capacity, in the two numbers to be multiplied.
   Oh, and at the finish, of any progress down the calculation column, you might have something like;
   5, 5, 5 in columns 1,2 and 3, in some other multiply, plus a '149' constant added in, to column #1.
What this means is you will see:
   '5', '5', '154', ...which of course is unbalanced, or not evenly distributed across the analog columns.  The process that I have (attempted) been describing, would lateral sum every valid column, and that ends up as '164', which should be dividwd up into ten element pieces, of approx. 16.4 each.  That way the vertical summations can proceed, down the remaining elements in columns.
   Confused yet ?
Welcome to Rick's world...

[MK14]

Bold and font size change made by me, to highlight the bit, I'm responding to.

Here is a view of one particular 'switch', or Optical 'Gate', I like to call it. Takes time, but making secure fixtures eliminates some of the distraction, placing various light-operated pieces in relation.
This piece has only the IC, battery, and LED / reflector, while another table-mount piece contains the little square solar photo-voltaic cell, also glued for upright operation.  All this takes dedication, over stretches of days, so I try to make sure that's worth (the extra trouble).
   Main problem is, there is some mechanism, not a capacitor, but something is creating a delay time...maybe could be the solar cell itself.
(Whenever I try Google 'Solar Panel Impulse Delay Time'...I get some results like:
   'Three months lead time, for Solar Installations, in Midwest...'.
(That's useless).
   But in the edge detect optical circuit, it was supposed to trigger on (just) the falling edge, of light beam input.
So I have to figure out, what's going on with the switching action, as it appears there's a delay, before a new surge of light will create a response, from the circuitry. Since it acts in invert fashion, the newly ON light input causes the circuit to flash it's LED ON.
But if that response is delayed, then my circuit will flash on that (rising) edge, of the input.

I'm NOT sure if you already got an answer to your solar cell response delay time querry.

The following seems to say that less light, causes the delays to increase.  It also seems to hint that it can easily take 250ms for a solar cell to respond (acually it seems to mention 4 Hz).

Source:
https://www.nrel.gov/docs/legosti/fy98/23878.pdf

The response time of PV devices to chopped light can
be a problem for electrochemical cells. Similar to results
reported elsewhere, chopping frequencies below 4 Hz are
required to keep the waveform from changing with frequency
[14]. This effect is more pronounced at low light levels and
in the infrared.

Modern solar cells, are somewhat different types, which may or may not, affect the characteristics, that paper seems to mention.

[RJSV]

   Here (please see photo), is some glimpse, of design considerations for a practical optically operated analog BUS.  While doing a wide bus; of 100 signal partitions (I.E. uncoded bits).  It lends itself as a better shaped format, keeping the 10 BUS lines in a centralized or circular - square organization, better to use while diffusing or making signal (cross section) uniform.
I'm not confident, exactly, yet, but making progress on this whole summation column method.
   Notice, I've simply tried methods to obtain 10 signals, for a decimal BUS read, and various size adjustments put each individual element on equal footing, in regards to an even (as possible) diffusion of total light, into a 'portion' for each conditional addition column.
I did the 5 decades, in the number '52', while the 2 'units' value also are included.  Actually I don't like that; as it mixes between the weights, so that format is a little 'shakey', but readers should be able to realize and follow the function...(whew!).

   It can be disorienting, doing inventing / building inventions.  There is no obvious  set pattern, in the novel stuff...(but that's by definition).
I believe that one of the helpful qualities of a technology involved inventor is TOLERANCE, ...tolerance for unpleasant conditions, (hopefully transient!).

[RJSV]

   So, taking that input BUS, the format has to be changed, some, for the column oriented conditional additions.  Diffusing and even spreading, followed by introduction into a 10 portion light conduit would the number, like 52, to be split down into ten pieces, 5.2 each, or as close as practical.
   The end result 'square' might necessarily have uneven looking divisions, in order to deliver same amount to each of the 10 conduits.

[RJSV]

Mk14: Regarding a delay time.
  Thanks for that ref., I believe the switching time, as inverter, was for the (solar cell with switching IC, and battery.). That way, (maybe) the real switching being done is by way of using the solar ev cell voltage, at some comparator level, 0.5 or half-volt, I believe.
   That's why, using a series string of those little, dollar store type lights, can, actually pass MUSIC... Although wildly exaggerated,...but it does work, to some semblance; The sound passed consists of punctuating 'Hiss' sounds, to the 'beat and cadence', of the music.  Plus, some of the mid-range sounds make it through, down a series line-up of those 'gates', that being the inverting action of the solar lamps, each sending light to the next, in a series string, (of 8 separate solar lamps, acting each as a logic inverter).

[RJSV]

Also, wanted to mention, that it is believable that the little round solar cell / battery Garden Light,...that the PV Cell could take some 250 milliSec to toddle it's way up to saturation.  But I'm no expert, don't misunderstand.
That's PV Cell volts ramping up, while under load, charging the AAA battery.  So, you have some kind of ramp up time, to full peak...( ?).

[RJSV]

   I figure to have a thousand multiplying processors in 32 by 32 Array, and here's the numbers outline;
   Using a basic 4 pixel wide LCD square (4 by 3), that could fit into 10 pixels, including border.  So, a 3 char by 3 char array, covering unit weights of 1 through weight '9', (in light intensity), would be 3 X 10, or about 30 pixels across, to implement a light emitting 'square', (or at least a light valve, for whatever light source.)
For that, an array of 32 across would use 1000 basic pixel spaces,...about right for implementing an experimental passive processing structure

   For a signal processing 'session', lasting 100 mSec, an electronic CPU or GPU will pre-arrange the configuration, for a burst of utilization, doing fast bundle-jobs, of multiply-add nature.
Envisioning up to 10 multiplies, each, for example;
   '21 X 56 = ' and being accumulated, into 14 bits equivalent, for example.  That being a total AtoD count of 16 k, and (estimate) using 10 bit Ato d, at high speed.
Excess range is really just an analog accumulation, of light intensity, but rough equiv. voltage estimate range of 1000 counts, representing 0, 1 mV through 1 volt (0 thru 0.999 V).

[RJSV]

   The really interesting part, from here, is that, after multiply and accumulate, of 10 separate numbers, such as an example of direct sensor inputs, that number rapidly accumulated can then simply be continued, as 'summed' appropriately for a multiply of the whole result...in a continuation, at optical speeds, into some more process stuff, meaning in this case that you don't need to use the AtoD process, as a terminus, yet, but rather, it is possible to re-format, as long as non-valid columns have been blocked, by the set-up process, or pre-process.

[RJSV]

   Looking at various BUS formats, the 'Harmonica', or Piano BUS style encodes as binary-looking 'bits', but it's a one and only one, exclusive type of code..., or actually an 'uncoded' signal.
The right-justified variation is just about right, for doing outputs, although zero gets a little strange.  That's when you'd like an active zero form, of the raw signal, for clocking or pulse recognition.
   But, doing weights-only, this system produces 'Stamps', very reminiscent of video or graphics stamp blocks.  Each of those little squares contains an even amount (of light lumens) and thus the multiplication action happens...by way of multiple addition right there in the 9 squares of the 3 by 3 array.
   (Reminds of the Pop-art Warhol photo art, where the face of Marylyn Monroe gets repeated, in little cells, across the art-poster.)

[RJSV]

   It's easy to read the diagram, (incorrectly), by seeing 'bits',...Rather, it helps to view as multiple copies, in video or raster outputs, or as a set or 'sprites' that come into the big addition going on.
   Looking at a 3 digit number, each can be with separate analog channel. That way the 3 channels, being to separately convey 'ones', 'tens', and 'hundreds' as typical decimal, but with some 'extra' help by using better, higher amplitude, in the lower analog level conveyance.  So, the lowest digit is actually 100 times too strong.  That way that individual signal channel has enough to work with, making multiple copies.

[MK14]

Those patterns, remind me of gray code.

https://en.wikipedia.org/wiki/Gray_code

Even though, they are not really related, to what you are discussing.

[RJSV]

(Thanks for replies).
   The method to read all this, is to separate out a 'Digital mode' for the multiplier digit, fairly standard on-off, at least the signals.  For the other half, the multiplicand value; that's the part that's going to be analog.
So seamlessly intertwined that it's very easy to get confused...But the 'weights' of the multiplier are a set that EXCLUDES zero; no weight means no actual conditional additions, but the whole business of a zero weight signal is messy.
Actual, literal meaning, is like a set of windows, where a number like '4' means that an input value, like '7', will get repeated, each place it is enabled, in that 3 by 3 square shown.  So the multiplier is like a mask, in graphical terms, allowing equal portions of light through, being the light from the multiplicand, (split into 10 equal portions).
Like an old stamp and ink set, but the image being repeated is actually blurred or smeared so as to be in a format that can be further used as a multiplicand, very similar to a fully formatted multiplicand might look.  That is, with right-justified 'origins'.  Doesn't matter, (I think, lol), as either way, a conditional multiply will involve mixing EVERYTHING together, then (evenly!) dividing back to 10 separated columns...
   Down a bit, on a fuller computational column, would be set of LCD 'flaps', closed for the transient duration, of a session, like 100 milliSec. and that feature would keep any summation as valid.  So for that case, is an advantage, that the optical-speed computational 'column' could further proceed (down) through more action, such as multiply everything by 4. 
It's when the designer has run out of the fixed / predictible multiplier(s) that the electronics must resolve thru AtoD convert.

[MK14]

would be set of LCD 'flaps', closed for the transient duration, of a session, like 100 milliSec. and that feature would keep any summation as valid.

You might find that LCD 'flaps', have a fair bit of (light) attenuation, when they are supposed to be fully open (off).  Also, you may find that the LCD 'flaps/squares', pass through some light, even when they are supposed to be fully 'Black'/Opaque (on).

Additionally, LCDs tend to be somewhat (relatively) slow, so 100 milliseconds, may not give (especially a low cost, simple, non-optimized version, salvaged from something version), brilliant (ignore the pun), results.  Finally, the LCD screens polarizer, may also worsen your results/success, in various ways.  Such as reduced brightness/contrast (compared to something which is genuinely fully open or fully opaque).

Faster/fast LCD panels, are possible.  But harder to source, and possibly more expensive.  Even then, they tend to be fundamentally, relatively slow, compared to many other things (in electronics).

[RJSV]

   The method, of splitting '10' pieces, equally, and then keeping or blocking each, has a 'circular' feel to it, (as if any progress, from the multiply has been lost), it does have a useful looking quality of sticking near to some moderation.  That way a string of multiplies doesn't grow out of hand, in hugeness.
   In this, suggested OPTICAL analog the form of 3 digits is also adopted; each analog range channel has same value range, actually.  That helps any signal to noise ratio, but more importantly the fact that a signal will be further split up, by X10 factor, makes for the helpful suggestion, to start at 10 times 'too high', in the representation...but that fits the use very well.
Of course, the method(s) require a lot of excess, or unused 'light', and so disapate more power.
   The investigation, of how to do 'carry', after decimal multiply...(in this case, multiply against an analog value)...one way is to always, unconditionally 'carry' over a one tenth portion, which is actually hilarious, because (I've been) search for what to do, with the extra tenth, left over from multiply. !
So, a multiply like '9 X 9' is 81, which would 'carry' enough to function.
Problem there, though, is to always leave the former column with LESS, as you've moved some of that, up to the tens column...gets confusing !
For now, calling the 'next' column over, a
'Macro-Column', to distinguish.
   Tossing 1/10 unconditionally, over to next lower column, gets you (either) a carry-over, or, just an analog value that contributes, at correct value for the setting.
Result works, but is not in a usually expected format.  Some of an analog value, for instance, could be reduced, and then placed into a higher value column. That's because each lower decade column is 'too big' in amplitude.
   Another detail: might need to accommodate more than '81', might be some more overflow-carry, (to need '99' carry-over.)

[RJSV]

   I think you were trying to say, (Mk14, thanks), is that this conversation is reminiscent of 'Grey Code';  mildly suggestive, that serial data experts HATE long stretches, of 'dead' line time... That's instinctive from radio operating days.
   The optical equivalent, involves how to, effectively transmit a 'zero', in an active way, preferably.
In a (hypothetical) weighted word, on a BUS,  the zero case has no analog weight, but is very important, as a digital token.  This means, that, for example a '20' has that zero symbol, but it is as a place holder, which is different from a 'count'. A very subtle point, but ..
   Another fine sticking point has been the appearance of 'nine' squares of light, to represent values, in a decimal system...No end of confusion there !!!
But it must always be back to a X 10 relation, your x1 symbol must be X 10 across each column.
Of course, the '3' is '3/9' ... of that set I've shown, of a 3 by 3 array, but that is, further a block meant to represent ' 9/10' of a decimal number.
So, combining that math, it still works out:
   '3/9 th X 9/10 ths, is = 3/10'
So the point is; that array can represent in terms of tenths, not 'ninths', as long as carefully about use of area.

[RJSV]

   So there the delightful feature, that the digital summation can proceed, but on the next column.  This means that no data is lost, only that the data, or 'lumens' is accounted for, in the next column over.  This is possible because the format, of the lessor column, is with having 10X too big a quantity, relatively, but in a separated BUS system.
View it as an alternate way, to express that 'weight', into the system.... usually we just do it, but this way, you can hold off..., depositing the same amount, (of light), but just into the next, higher column...
If a lateral sum is OK then, then that subsystem can assemble and sum (addition) everything, to one big analog value (12 bits).

[RJSV]

   You can't SUBTRACT the analog light values, but you can take a 'proportion', or split off a ratio proportion.
So, with an amplitude value of '142' as example, that arriving light could be split, into ten paths, each being
'14.2', as evenly as possible, and 1 of those paths diverted, over (laterally, or X10) into the next power of ten column, or 'macro-column'.
This action gives a multi-digit multiply approach resembling regular 'carry-over' as the early school math teaches, to carry a 'tens digit' over, after a partial multiply. Doing, say, 9 X 9 = 81 suggests sending the '8' portion over...; over to the left to be tabulated in that 'tens' column.
   In this case, optical BUS, the carry-over could be 10 %
 and unconditional, but would also do carry-over of a number like '8', where the action is to carry over a '0.8' to the next higher macro-column, while leaving 7.2 n the one's column.
   Did I mention this shii can be confusing
   The expected actions would have been, to keep all of the (light quantity) in the first, lowest column, the 'ones' column.  But the total quantity is not lost, it is just moved over and gets totaled in next column over
   Now, as to magnitudes, the lowest weight column is physically separate, and does not match, physically, being 10X too big, in magnitude.  The consequence of this is that a carry-over, like the '8.1' in '81' can be easily put through a divide-down, by 10.
Actual is 0.9 X 0.9 = 0.81 and so the actual carry-over is 1/10 or 10%, and that's = 0. 081 literally.  That sizing fits perfect into next column ACTUAL amplitude, as a carry, albeit a little different from a purely single digit, it's expected to be, '0. 08'.
   Not really that confusing, just new...The total light quantity is simply done differently, but result or 'summation', across laterally, across the bottom of column, should always be same.
This method is shown, in a few recent posts, where a number like '0. 184' is expressed as '0.1', '0.8', '0.4'.
That's an amusing variation, of course needing to keep the three separate, and need to attenuate the low digit, when doing any full summation.

[RJSV]

...I'm not even sure, if not fooling myself, here; The 3 macro-columns absorb and carry any light downward, each column in simplicity is just a defined 'lane', pointing downwards.
   The attempt being, to operate a fairly normal looking multiply, of multi-digits against each other. Thus the thought, to 'RELIEVE' any overload, of a digit (column), by doing conventional pencil and paper 'carry', to left, thus keeping your current digit limited to 0 through 9.
But in this situation; Who cares ? ...Since any of those 3 decimal columns will carry, who knows how much light quantity...?
But at least that option is possible, and does do some relief or control, on max. light capacity, for converting, etc.
Ultimately, all those summations, down each column, and then laterally (close proximity mixing in downward direction along BUS path), will create a decimal total, like '184' lumens, for Atod convert.
Likely actual numbers more like 0.184 Lumens when all the amplitude numbers are run, with more certainty.

   Viewing picture, a more 'conventional' paper and pencil method, keeps the columns separate, but also only 'carries' the high digit portion (like the '2' in '27').
Interesting, this (equivalent) method brings over enough to avoid overflow,...but who cares as you can't even know what's there...until AtoD converter finishes.

[RJSV]

Here is view of that unconventional carry-over.

[RJSV]

   I've attempted to run some numbers; the propagation delays, down that stack of individual transactions (multiply and accumulate).
   Getting on the order of 500 pico-seconds, ranging up to around 1.6 nano-seconds, which is loose ballpark for apparatus with 50 cm path lengths.
I've estimated, 7 multiplies, with then being blocked from further progress, until (electronics) control CPU can get the proper 'flaps' into place, for blocking unwanted columns.
After that, moving further down the stack, I've put another 3 processing stages, each doing a multiply and accumulate (addition).  When flaps are effectively in place, the lateral or horizontal summation is considered valid.  Keep in mind, optically that process starts right away, or at least very soon, compared to the time it takes to 'close a flap' which just means an LCD pixel cluster.  Suggesting a 4 by 3 pixel block, for a little more light amounts, per element.

[RJSV]

   Picture shows a stack with 2 bursts of the multiply and add series of calculations.  The design goal is to get as many stages included as possible, for the very rapid optical process...in order to exceed that speed conventional electronics ALU is capable of.  So, the more of those, example, multiply by '5' digit multiplier, the more the better, as the LCD liquid crystal takes time to close or open, in preparation for AtoD reading, as the light beams perform the calculating (see also prev. explanation, on the conditionally used columns).
   You can see, I've tried to imagine / illustrate that stack timing performance.  Other folks, apparently (Professor Fan at Stanford Univ.), are examining the technology from an energy use point of view.
   In the picture, the green line, traveling down the page, is to represent how the older method was intended to track the validity, down the columns, but it's simpler to just write directly to the LCD light blocking, as CPU already knows which summation columns are not valid.  The older idea was as a 'live' bus signal...I.E. the Facilitator word, which could be set by misc. processes moving down the whole stack.

[RJSV]

   Apologies, to any of you experienced in
 Opto-Electronics, as I'm somewhat a newbie...so I'm not pretending to be expert, here.

   I've been self-labling some of this as a
'HILL-BILLY SUPERCOMPUTER'; which is about the behavior (of light) in simple gross or bulk 'beams' and usually without much heavy physics.  (Prof. Fan of Stanford Univ. does the heavy physics lifting & math, according to the YouTube videos I've seen.)
I've got limits on capabilities in physics, but lots of experience with various parallel BUS set-ups.  Industry is almost invariably binary logic.

[RJSV]

   I was pleased to realize that it IS possible to get close to 'SUBTRACTION', while doing math with controlled light beam's amplitude.  That is, a ratio like
' 9 to 10 ' or ' 1 to 100 ' can be set up, similar to the preceding example of using unconditional separation, evenly, using light guiding conduit walls.
   The Stanford researcher, Professor Shanhui Fan uses the term of 'Processing using physics, such as diffraction effects'.
I like to use a similar action descriptor, of 'Processing by BUS' which mainly refers to structurally modified bus lines, such as a rightward shift, among BUS columns, to get a value change, of amplitude value.  That's a tantalizing functional advantage, as compared to contemplating subtraction of light intensity.
   By doing ratio-based, and unconditional amplitude reduction, it's possible to 'count' those ratio portions down, while possibly using the set of values as it 'decrements' the number.  Can't conceive any way to detect a zero ending, in typical FOR-NEXT loop style, but existing techniques for coding an 'un-raveled loop', by simple listing each iteration explicitly, can be used, in a stack of optical manipulation elements.
That is, in cases where you'd like to use the iteration count as part of some calculation, on each loop iteration.  The way to do that would be to split off some light for the current processing element, from the 'iteration count stack lane'; use that in the current element, meanwhile the main light conducting lane continues down, to the element, in your unraveled For/Next line of processing element stations.
For example the structure could 'process' each in a series of '9, 8, 7, 6, ' etc and all of it unconditional, where that iteration count is sent over to some other module, as input.
   Doing that requires a simple series of reflectors and partial reflectors, for manipulating your light column.
By analogy, very much resembles the bit-shift instruction enabling complex operations like divide by 4, or multiply by 8.  This applies to whatever BUS type, but here the 'unit weight' BUS is favored (over typical binary weighted).

[RJSV]

   Here is a view of that optical BUS shifter, (although decimal BUS has ten lines), that moves each column over, changing positional coded notation..., as cannot change a simple 'amplitude', by subtracting light from the bundle, in perfect integer form.
   Of course, here the units weight BUS is used, rather than binary weighted columns.