Optical Delay Dynamic RAM (ODDRAM!)

[jpanhalt]

Won't 4 hours, or even 30 minutes, be a bit long to show the bytes changing?  The BB's were much shorter.  So far as I know, there is no way to reversibly quench phosphorescence.

John

[jamesglanville]

I think you could skip the hall sensor:

You just need to center on a glowy spot, so turn the light on for a second, then off then rotate back and forward to find the maximum brightness

[wobbly]

Won't 4 hours, or even 30 minutes, be a bit long to show the bytes changing?

Don't get the wrong end of the stick, mate.  The half-life is only (I'd estimate off the top of my head) 1 minute (the dynamic range of the human eye is HUGE).  Ignore the fact that the eye can detect a state retained for 4-hours in a little bit of plastic.
My sensor can do a MUCH better job on a MUCH SHORTER time scale (tens or hundreds of milliseconds).  I know this for a fact, I can see the frequency of the PWM output change smoothly and rather quickly in real time on my scope.

Consider the size of the wheel... 40 bits.  AND it takes time to charge up each bit as well!  We have time to burn!

People are apparently neglecting the other variables we have under our control:

*Charge time -- arbitrary down to the microsecond.
*Charge intensity -- a UV LED running at 30 mA.

By definition, the brightness change will be most easily detectable when the brightness gradient is (falling) steepest.  That is immediately after charging!

If my eye can see a state held for 4 hours, then a closely-coupled sensor should be able to do the same after 1 minute or however long the wheel takes to turn (less than that)!

Maybe I can read a bit, advance the wheel and charge a bit and advance the wheel again in less than 1 second.  That's 40-ish seconds per revolution, without data loss.  In a fairly dark room I suppose.

[wobbly]

I think you could skip the hall sensor:

You just need to center on a glowy spot, so turn the light on for a second, then off then rotate back and forward to find the maximum brightness

Where does the glowy spot come from?  The LED might be between bits at startup (e.g. no glowy spot at all, or perhaps two half-glowy spots).   Hence needing calibration.

[PCB.Wiz]

I think you could skip the hall sensor:

You just need to center on a glowy spot, so turn the light on for a second, then off then rotate back and forward to find the maximum brightness

Where does the glowy spot come from?  The LED might be between bits at startup (e.g. no glowy spot at all, or perhaps two half-glowy spots).   Hence needing calibration.

True, but a smarter calibrate could work.
If you drive the led and wobble over 2-3 bits, you always have one bit full bright plus 2 bits of possible fractional bright.
You then sweep across the 3 bits and calibrate to the brightest plateau.

An advantage is this would not need a full turn to seek the Hall trip.

 You could extend this angle calibrate to sensor calibrate too, by drive the wheel the 'wrong way', you can vary the LED energy and choose an operating point of brightness, by reading a few dots as they go past. This locks angle and gain.
 
This could self adjust for daylight/nighttime.

[jpanhalt]

I am familiar with half-life.  An optical filter with an OD of 1.0 (10% transmission, about 3.3 half-lives) appears quite dark.  5 half-lives is 1/(2^5) or about only 3% as bright.  Six half-lives is 1.5% as bright.  The BBs were only a few seconds.  In a dim, not dark room, I suspect you will need about 5 to 6 half-lives for an observer to preserve O's instead of 1's.

[wobbly]

@PCB.wiz,
Yeah that's true.  But I could also build a rocketship to explore Neptune.  In the interests of actually finishing the project I think I will just use a Hall sensor 😊

[wobbly]

I am familiar with half-life.  An optical filter with an OD of 1.0 (10% transmission, about 3.3 half-lives) appears quite dark.  5 half-lives is 1/(2^5) or about only 3% as bright.  Six half-lives is 1.5% as bright.  The BBs were only a few seconds.  In a dim, not dark room, I suspect you will need about 5 to 6 half-lives for an observer to preserve O's instead of 1's.

You are talking about the "observer?
 Do you mean a human?  There is no human in my electronics.  Observation might be done either in person or with a digital camera perhaps.

People, please give me a chance to build this thing before finding obstacles for it.  I'm learning too!

[Kleinstein]

Changing the time for charging or LED intensity should not have much effect on the speed. The problem is reliably seeing the difference between a dot charges 1 turn and 2+3+4 turns ago. This wants enough (e.g. 1 half life, as 1/2+1/4+1/8 is already quite close to 1) of a decay for one turn. So it gets tricky with less than 1 half life. If really needed one could gain a little from using less power for refreshing a bit than writing a new bright dot, but this compicates things.

One the other hand one wants enough light left, like no more than some 6 half lifes to get enough light left even with relatively short charging time.

The intesity may not follow a strict exponential law, but could be a bit stretched from a mix of lifetimes.

[Phil1977]

Yes. The time constant of the decay (or the half-life-time) definitely need to be in the same order of magnitude than the period time of the wheel.

If the decay time is too high, you can't reset bits.

If it´s too low, you have little SNR for readout.

I´d set the threshold for readout in a way that a visibly lighting dot is recognized by the photodiode. Afterwards I would try to find two critical speeds of the wheel:

- V1: The minimum speed when an activated lighting bit just triggers the photodiode with its next revolution
- V2: The maximum speed when an activated lighting bit just not triggers the photodiode after two revolutions

The average (V1+V2)/2 should be a good starting speed for operation...

[3roomlab]

acoustic delay line memory ?

[wobbly]

Not had time to do very much today, but I did get the 8-tooth gear made (see pic), which will make the maths a bit neater in the firmware.

Ordered some matte-black paint too, which should arrive tomorrow.

Maybe I'll have something worth photographing (videoing even?) by the weekend. 

By the way I keep forgetting to mention - the glow powder I'm using is this stuff: https://www.amazon.co.uk/dp/B0788NLQKZ?th=1
It mixes beautifully with optically clear two-part Polyurethane epoxy resin and works best when in thin layers up to about 3mm thickness.

[wobbly]

@Phil1977, did you develop your multi-channel "Drum" memory version any further?

[ebastler]

Great to see this neat memory idea gaining traction! I can't resist a little nitpicking though:

This is not "RAM", as in Random Access Memory. A connected computer will not be able to access any "random" memory address at any time, but will have to wait until the right data word comes along on the drum or disk -- as was the case with all the serial memory architectures based on magnetic or capacitive drums, acoustic delay lines etc.

When I got into computers in 1980, I thought the naming of memory types to be quite unlogical: ROM made sense for "read only memory", but why the heck was the writable version called "RAM"?! I guess it's a carry-over from the days of transitioning from delay lines and magnetic drums used as main memory, to ferrite cores which had the revolutionary capability of "random access"! (Well, the Williams/Kilburn tube could provide random access before, but did not gain traction in any commercial computer to my knowledge.)

In the tradition of "magnetic drum memory", I would probably call this "optical drum (or disk) memory". The "delay" part is inherent in the drum-based design. 

[wobbly]

@ebastler: I am delighted by your nitpick.  I knew someone would notice eventually!

I think it's too late to change the name though.

[Phil1977]

Just as a heads-up:

What you see on the right is a cheap robot wheel with the tire removed and replaced by the phosphorescent tape. On the left is a standard blue 3mm-LED with a slot aperture and an eyepiece of a $2.99 telescope as a focusing lens. The LED is connected to a pulse generator with 3Hz and 10% PWM.

The robot wheel runs at around 15-20rpm. Slower would be better but then its motor stalls. Next step is to replace the robot wheel by a larger 3d-printed wheel on a stepper motor for direct phase control.

For the first run I´ll try a photodiode that´s exactly the same construction as the LED assembly. Probably I´ll set the detector at 180° position to the emitter. I´ll try to use an edge-detector that triggers the emitter LED with a fixed pulse width of around 250ms.

With the 180° detector position I waste half of the storage capacity but I don't have to mess with direct optical feedback from the emitter to the detector.

[wobbly]

@Phil1977, thanks for the PM

I do like the finer pitch that your glow tape allows, rather than the fixed pitch model that I'm using.

I've just had an idea for a new device that might be useful in such projects...  Imagine a very small plastic Hammond case (like this one https://www.newark.com/hammond/1551pbk/enclosure-pcb-box-abs-black/dp/53K7866).  Inside is a UV LED, a suitable light sensor (I'm tending towards my favourite TSL235R) and a small chamber for a TEST SAMPLE!

Put a sample of some random glow material in the chamber and put the lid on the box to make it light-tight.  Then run some code on a microcontroller that energises the sample repeatedly over days/weeks and records the brightness over time.  Basically a curve-tracer for phosphorescent optical materials.

I don't care if this already exists, I'm going to make one, because it sounds fun.  Then we can begin the race to find the best phosphorescent glow material in the universe!

Hmm, I guess my lack of inspiration issue has been solved 

Don't worry, I'll finish the ODDRAM machine first, of course!

[wobbly]

Project progress update:

Paint arrived, later than hoped, so I only had time to do the large gear and not the backboard just yet.  See pic.

Contrast is drastically better, which is great.  In addition to painting it, I also made some repairs to a few of the glow "bits" because a few bubbles had crept in and left holes in the glow/epoxy mixture.  So I poked in a bit of glow powder (as one might fix some busted drywall) and poured some fresh PU resin on top without mixing it in.  And then topped-off all the rest of the bits with more PU.  So now, all 40 bits have a nice "lens" of PU resin to help make the glow more uniform around the entire ring.  Looks good to my eyes; judge for yourself and let me know what you think.

[ebastler]

With the 180° detector position I waste half of the storage capacity but I don't have to mess with direct optical feedback from the emitter to the detector.

Do you expect direct crosstalk from the emitter into the detector to be an actual problem? You could run them in a time-multiplexed, alternating scheme -- read the detector in the pauses between emitter pulses. That's as long as you don't saturate the detector to an extent where it needs a very long time to recover, which I would not expect to happen since your detector does not have to be that sensitive.

I would be tempted to share the same lens (eyepiece) between both, detector and emitter. If you place detector and emitter next to each other in the image plane, with the displacement in the direction of drum travel, the emitter can write slightly "downstream" from the detector position, hence hit the same spot on the drum when is lights up a short time after the detector has read a bit.

[Phil1977]

The 180° setup is just the lowest hanging fruit. I expect it to work from the point I have found a sensitive enough photodiode.

The feedback into the detector should theoretically be no problem with the rising edge detector and a fixed pulsewidth. Anyhow I expect I need to give the detector a certain dead time after a pulse was written.

And for some idealogical reason I want to do the logic with discrete electronics. I do not want to control a superslow 32bit memory with a comparatively superfast megabyte mcu.

But when the 180° readout is working then the combined read/write unit would be nice. Just take it slowly, it´s a project without any timeline 

[wobbly]

Hi all.  See pics.

I've painted most of the mechanical bits matte black to minimise reflections that might be problematic or at the least annoying.

The 8-tooth drive cog meshes nicely with the ring gear.  Anyone who wants to make their own plywood gears - go buy a scrollsaw, they are great.

I've re-assembled it all for now minus the Hall sensor, because I'm having a hard time deciding where I want to install it.  I'll deal with that later.
For now I'll just manually turn the driving gear to a sensible start position before powering on the electronics.

The picture called "Sensor view" shows the contrast between a dimly activated bit and a brightly glowing one -- and this photo was taken in broad daylight, which is encouraging.

Next up: extending the wiring between the sensors and the PCB and wiring that into the microcontroller.

[wobbly]

Hardware is done.  I've attached a wiring pinout for reference, and a picture of the magnet, which is a small neodymium axially magnetised one simply pressed into a 5mm hole in the plywood.  The Hall sensor is directly behind the magnet on the backboard and orientated to suit the magnet's poles.

The Hall sensor works very well and has a very narrow "focus" for want of a better word.  I can turn the stepper one step and it'll trigger the sensor, then turn it back one step and it returns to it's previous state.  The distance between the magnet and the Hall sensor is probably 3mm at the most and there's no other ferrous material nearby to interfere.

So now all that remains is firmware!

I'll use an interrupt to respond to the falling edge of the Hall sensor, and set a flag to indicate that the next time the stepper reaches a known bit position, that'll be bit 0 in the ring.

The ATTiny2313 has one 16-bit counter and one 8-bit counter  I'll use the TSL235R light sensor's frequency output to provide the clock signal for the 16-bit counter.  This means I'll need to gate that counter to provide sensible readings.  I can use the 8-bit counter to do that.  When I'm not reading the light sensor (e.g. when I'm moving the stepper motor) I can use the 8-bit counter to provide the stepping waveform for the stepper motor.

I want to use as much of the ATTiny's hardware features as possible because it reduces the amount of software needed.  I like that because I think the software is kind of a distraction from what I'm trying to demonstrate -- that Phosphor can be used as a memory medium.

I like Phil1977's approach of using discrete components in his "drum memory" concept, because it is much more like how the original delay line memories were developed back in the middle of the last century.  I'm just trying to make something that looks cool, so I'm being lazy and using a micro!

[Kleinstein]

A good way to measure the frequency (specially if relatively low, like < 10 kHz) is to use the ICP function of the 16 bit timer. This way one can make a reciprocal counter, measureing the time of the transistions and get good resolution already fast. It may still be overkill. The other PWM channel could still be used as a delay timer. For a higher frequency direct counting may be easier, but it could be tricky for the low frequency for the dark case.

[wobbly]

@Kleinstein, I have no doubt that you are right.  I'm just not very experienced in using AVR Timer/Counters for frequency measurement.

I just like the simplicity of using the output of the TSL235R sensor as a clock source.  The main software loop of this project will be 99.9% idle, so I don't really mind if there's a bit of slack.

[wobbly]

Progress:

Start up process is complete.  The ring turns quickly until the magnet is detected and then stops dead.  Then I advance the motor by a hard-coded number of steps to compensate for the discrepancy between the magnet's alignment with the bit positions.  After that, bit 0 is correctly aligned with the UV LED.

Also I think that the LED I'm using isn't bright enough for this task.  I'm running it at it's maximum safe rating of 30 mA (from 5 V).  So I will have a look around for something a bit more potent.  Perhaps a laser?

Would a laser be any better than a normal LED when shooting point-blank?  I don't know.  At least it's an excuse to buy lasers, so that's fine.