Optical Delay Dynamic RAM (ODDRAM!)

[Phil1977]

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.

A laser would for sure be easy to focus onto the active bit - but regarding it´s power a usual LED should be more than enough.

In my setup I waste probable 90% of the LED power by a slit aperture. And another 90% by the PWM I have used. And I just used a clear 3mm-LED at 10mA. Anyhow, even at usual indoor daylight the activated phosphorescent dye has been clearly visible.

Do you use any lens with your LED? Even if you have no aperture you would strongly increase the irradiance by any focusing lens. Or just use a laser ;-)

[wobbly]

Do you use any lens with your LED?

Nothing other than the LED's own clear package. 

This is a roughly to-scale image of the LED in relation to the bits...


The orange part is a short bit of brass tube which is a snug fit for the LED.  I reckon that at least 75% of the LED's output reaches the phosphor dots, as a conservative estimate.  Might be as much as 90%.

Perhaps I can find a COB LED with a bit more grunt.

[wobbly]

I now have the TSL235R hooked up and Timer1 taking it's external clock from it.  Works great, and I can get usable readings from it.

As a test just now, I configured the sensor to be read for 1 second at each bit position.  And after each reading I'm sending the data out via the USART to my PC.  I then charged up a few of the bits with a flashlight and allowed them to move past the sensor...

Code: [Select]

Light:9
Light:6
Light:7
Light:10
Light:14
Light:20
Light:14
Light:15
Light:11
Light:10
Light:175
Light:209 <------ :) Brightest Bit passing the sensor!
Light:128
Light:94
Light:47
Light:9
Light:7
Light:7
Light:8
Light:7
Light:6
Light:6
Light:6
I'm quite pleased with this result.  The dynamic range isn't great (it's a 16-bit timer) but I think it is usable.  But this will depend on me finding a more powerful UV LED.  I was charging the bits from the "wrong" side using my flashlight, which does reduce the effectiveness a bit but as a first test I think this is quite encouraging.

[Kleinstein]

The resolution is not very high, but should still be sufficient. One is somewhat limited in the speed to still get at least a little reading for the dark dots.

An interesting test would be so look at the decay. So look at 1 originally bright dot for a longer time and record the decay over something like 1 or 5 minutes. The speed will tell how fast or slow one would have to run the thing. So maybe more time to write and one would also know the time available for the frequency measurement.

Brass is pretty absorbing in the blue / UV range, but this should not be that bad. Ideally the LED would have a relatively small opening angle to get more of the light actually to the target. Simply less distance and a 3 mm LED could also be an idea.

[Phil1977]

Another small step towards the optical memory revolution:

https://youtu.be/LTuTPwY1iZc

A non-collimated photodiode (BPW34) is already creating enough feedback for the 180°-assembly to periodically refresh the memory content.

The circuit between the Photodiode and the LED is currently just a 2-stage OpAmp-Amplifier with AC coupling and small hysteresis.

Next step will be to built a collimator for the photodiode, then - hopefully - the storage density will rise and more complex patterns may be feasible.

[wobbly]

@Phil1977, your setup is looking very promising.  It will be interesting to know what kind of bit-density you can squeeze onto that wheel.

I'm now wondering about how the "charging" light should best be applied.  I think that a high intensity light for a short amount of time, is greatly preferable to a lower intensity light for a longer time.  But there is a latency to the charging process!  When the LED turns on it takes a while for the phosphor to respond and this is actually visible - the LED goes to full brightness instantly, but the glow from the phosphor takes a little time to increase.  And then the same happens in reverse, when the LED goes off, the phosphor's natural decay is very obvious.

Following is a graph of my light sensor's output frequency (y-axis) over time (seconds, x-axis).  The phosphor was charged up for 1 second from a 30 mA 395 nm LED basically at point blank, and aimed at the same side of the phosphor that faces the sensor...


This tells me a few things:

• My LED sucks.  So I've ordered some hopefully more capable COB LEDs (3 Watts allegedly)
• The TSL235R is an awesome sensor.  Apart from it being unobtainable these days.
• I'm going to have to complete a full ring revolution in something like 15 seconds.  Including sensing and refreshing the bits.
• The half-life isn't constant!  It increases as it gets dimmer.  Hmm.

[Phil1977]

Thanks for naming your sensor - I needed quite some tries to find something appropriate.

But then the BPW34 together with a rather bad opamp proofed as more than sensitive enough.

The shown circuitry is only the very first try. AC-coupling is not optimized in any way yet, it was just the first breadboard setup and I was quite glad it did something.

 

D1 is the photodiode, D3 is the "writing" LED. LM324 was just used because it was laying around and fast opamps sometimes do stupid things on breadboards. The feedback loop of U1A is a little strange (filter cap outside of the loop) because it significantly reduced mains hum on this stages output.

For the next circuitry I want to superimpose a clock sine with the photodiode so that the memory content gets phase stable.

[Kleinstein]

Getting a non exponential decay and thus a half life that gets longer over time is not that surprising. One can naturally expect areas that are faster and slower, so a mix of different half lifes. After some time less of the fast part and more of the slow part is present.

I would not expect this to be an effect of the intensity, more a time effect. So first fast and later slow.

The time constant looks good. Form that side one should be able to use something like 4 seconds to 30 seconds for a cycle / rotation.

The intensity may not be greate, but looks like it is enough to measure, at least for the time used in the test. Faster writing may want more intensity.

For the charging / writing with the LED there should be little difference between short time with high intensity or longer with less intensity. It should be the energy delivered that matters.


For the TIA circuit the capacitor C1 is odd: one usually tries to keep that capacitance at a minimum. In simulation the capacitance is usually there to include parasitics and the capacity of the photodiode. It is more that one want a little capacitance in parallel to R2 to better tollerate capacitance of the detector.

[wobbly]

The time constant looks good. Form that side one should be able to use something like 4 seconds to 30 seconds for a cycle / rotation.

For my (not ideal) hardware I think that 20 to 30 seconds per revolution would be a good balance between robust operation and being something visually appealing to look at.

If I can really hammer the light into the phosphor quickly by using a high intensity pulse of strong UV, then I can also use a shorter sensor sampling time and thus increase the speed of the ring's rotation.

Another worry is that the phosphor degrades with repeated charge / discharge cycles and has a limited lifetime.  That would be a showstopper.

[Phil1977]

Another worry is that the phosphor degrades with repeated charge / discharge cycles and has a limited lifetime.  That would be a showstopper.

These phosphors are usually meant to be daylight-stable, and 12h of daylight will be many thousand hours of data storage...

For the TIA circuit the capacitor C1 is odd: one usually tries to keep that capacitance at a minimum. In simulation the capacitance is usually there to include parasitics and the capacity of the photodiode. It is more that one want a little capacitance in parallel to R2 to better tollerate capacitance of the detector.

Yep, C1 should get into the feedback loop. I´ll try it the next run. Thanks!

I also have a OPT-101 photodiode with integrated TIA in my box with parts to play with. I once scavenged it because it features an opamp in a very fancy crystal clear housing. Maybe it´s a good opportunity to use it...

[wobbly]

I'm sorry I've not been posting lately.  Shoulder pain problems continue  :'( , and I'm waiting for more powerful LEDs to arrive hopefully in the next day or two.

[jpanhalt]

That's OK.  I love the updates.  Just don't delay more that 7 days as that makes one weak.

[wobbly]

Shoulder works again.  If anyone tells you to look after your "rotator cuffs" and avoid standing up before the bus has come to a halt... LISTEN TO THEM!  Thank me later.  Torn muscle, inflammation and trapped nerve.  Not fun.

Anyway! Back to the matter at hand.

I found some highly dubious UV COB LEDs on the interwebs:

• 395 nm
• 3 Watts total
• Vf = 3.5 V
• 80-110 mW of UV spectral emission power
• 800 mA

Surprisingly enough I think this data checks out.  I'm running it for very short periods (1 second and then 1 minute turned off).

Driving it from the main 12V supply through a very overkill NFET (23A, 30V) and a 10 , 3W resistor (hence the low duty cycle), it does a good job of "charging" up my phosphor material.

I've got some more mechanical things to do now so I can mount the new shaped LEDs into the machine (the LEDs are these annoyingly shaped things mounted on hexagonal aluminium PCBs).  So tiresome.

So, I think I have an emitter strong enough to make this a possibly viable system!

[Kleinstein]

A power full LED can help, but no real need to got that extreme. One should have something like 1/2 the time for a bit (e.g. on the order of 0.5 seconds), and expect a duty cycle of up to 50%.

One may be able so save a bit on the power, if the bit is not overwritten from dark to lit, but is just refeshing a lit bit.

[iMo]

FYI - these guys are discussing the QDots as the memory elements.. In case you would need a ROM as the next step

[wobbly]

Video time!  https://www.youtube.com/shorts/8GnpiZxX6PI

It's only 33 seconds long though so blink and you'll miss it.

This is part of the early debugging process.  I'm still working out the timings needed and light thresholds I can get away with.  Changing one changes all the others, so it's a combinatorics nightmare!

In the video you'll see the ring make 3 full rotations.  Firstly, it does a very fast seek to locate the magnet (ends up at 12 o'clock position).  Second, it does a rotation to write a sequence of date bits to the ring.

Then lastly, it just runs around the ring again doing nothing, which demonstrates that the phosphor can store a visible amount of light for at least 1 full revolution without being refreshed.  Assuming I can get the threshold right.

This thing is going to be hard to tune for long periods of data retention.

This video wasn't made in a dark room though, so the real contrast and noise will be better in later tests when I've had time to set up a darkened work area.

Encouraging, I think?

Also, there is now a new problem!  Notice how that group of 3 bits is noticeably brighter than the rest?  That's due to light bleeding across between adjacent bits.  Inter-bit noise if you like.  I can mitigate this a bit by pushing the emitter tube further through the hole in the plywood so it almost grazes the back of the ring gear.  That's about all I can do though.

So plenty of limitations to play with!

[Kleinstein]

Looks nice, though not yet with a refresh. The decay also looks slow and the bits may be somewhat visible even after 2 turns. The slow decay can limit the speed as one has to wait long enough for the dots to get dark again. The point to tell apart is a bit just written a bright after a longer dark and a bit that gets dark after beeing bright for multiple turns.

I don't think there is much leakage to neighboring dots. At least the single dots look like there is not much light in the dark ones to both sides.

[robzy]

The decay also looks slow and the bits may be somewhat visible even after 2 turns.

Does that matter? You choose what threshold brightness you want to use.

I've browsed through the thread, but can't find the answer - what's the solution to writing a 0?

It seems like there's no other option than to "wait for it to dim enough", which will skyrocket the latency.

One work around for this is to use two wheels and, essentially, store the bits differentially. Or use one wheel with two circles of BBs.

[edit]: Or a double-sided wheel?! With BBs on both sides. I don't know why, but that gets me excited.

[wobbly]

Robzy, see replies #2 & #3 on page 1, regarding writing zeroes.  You're right.  But I'm not going to make any new hardware for this experiment, it'll either work or it won't.  It's just a bit of fun really.

I think Phil1977's drum-based version has better scope for bit integrity and reliability than my ring gear one.

[Phil1977]

I think Phil1977's drum-based version has better scope for bit integrity and reliability than my ring gear one.

But yours is visually much more attractive!

I´m just hanging at mounting the drum to a stepper motor. So far I used a gear motor that´s running slightly above it´s stall speed. Hence the angular velocity is much to unstable to do use any bitwise modulation.

I´m having high hopes that after switching to a stepper motor with a step-by-step drum motion I can get it stable. But as I said I'll try to avoid the MCU in my case and this also means I can not just take a Trinamic motor controller  I have to build a 2 phase oscillator to control e.g. a L298N H-bridge IC. Has anyone a simple idea for such an oscillator?

[Kleinstein]

An old style 2 phase oscillator could be a phase shift oscillator, with 1 inverter and than likely 2 x 2 RC elements to get around 90 deg. phase shift each.

A more digital solution would use the 2 D flip-flops from a 74HC74 or similar as a 2 step shift register loop to divide a seprate produced clock by 4.
So clock to both flip flops and Q1 to D2 and /Q2 to D1 for the loop.

A differential mode would make it easier to write a 0. With enough waiting time so that the intensity decayed enough within 1 turn, just waiting should be enough. In this case the signal could be improved if the write intensity also depends on the previous state, not just the new written bit. So newly writing a bright bit to a cell that was dark before would want a bit more (e.g. 1.5x) UV light than just a refresh.

From the video it look like there are like 2 components in the decay, a rather fast part and a rather slow one. Chances are the system could also would a bit faster, mainly using the fast part and alowing the slow part as background. One may have to play with the speed to see when the SNR is good enough.
My guess it could be a bit better with something like 2 x the current speed.

[Phil1977]

Thank you! The digital solution sounds good because it´s not so frequency dependent. A NE555 + 74HC74 should be able to clock everything. I can feed the states of the flipflops into an AND-gate to get an enable-signal for the LED to guarantee blanks between the bits. I probably start with 75% blanking and go down to 50% if its stable.

Maybe the drum version allows to use the fast decay component if the drum makes a few rotations per second.

I´ll keep you updated!

[wobbly]

I've been struggling with a very severe ideological and existential dilemma.

The light sensor (e.g. "Data Read Head") is two physical bits BEFORE the "refresh" LED ("Data Write Head"), there is a gap between them that cannot be accounted for in the mechanical apparatus.  Both heads are behind the backboard and right next to each other, and cannot get closer without serious mechanical problems!

Up to now I have figured I would just use the microcontroller to store the two bits of rolling FIFO storage needed to maintain this data between reading the state and refreshing it.  Having a microcontroller at all is bad enough to start with, let alone using it for all the easy stuff!  I now realise that this is morally and ethically abhorrent.

So, I have decided to implement this 2-bit FIFO in hardware.  I'm lazy though so it's going to be a 74HC74 Dual D-FlipFlop chip dangling off the microcontroller.

Nice thing is that I can put a small green LED on each of the two FIFO bits to visualise the two problematic bits that are being handled by the FIFO.

I just want this project to be over now.  Such a pain in the bum!

[wobbly]

I've wired in the D-FlipFlop (SN74HC74) to handle the two philosophically contentious data bits as mentioned in my previous post.

I feel better about that now.  I'm pretty near the end now so I'll post the rough schematic below.  Boring stuff omitted like the 5V regulation and fuses etc.

Also a picture of the board after the latest updates.  It shows the 74HC74, which acts as the 2-bit FIFO and shows it's internal states by way of the two red LEDS.  All that's left is software and faffing around with light intensity thresholds.  Hopefully this project will be finished by the end of Sunday.

[wobbly]

A bit of progress!  I've been playing around with the bit-refreshing method today.  First attempt is a bit janky but it does have some potential to work.

I constructed a light-proof box that fits over the machine and does a pretty good job of cutting out external light sources.
I've used my old camera to take a video through the front of the box (photo of the setup attached).

For this test I'm writing "100010001" to the first 9 bits in the ring.  Then I put the machine into a read and refresh mode, where it endlessly measures each bit and refreshes it's state.  Unfortunately, the difference in brightness between a 1 and a 0 is way down in the 5 - 12 range.  This is a major issue because the difference between any two adjacent 1 bits can be as wide as 30!  This is due to the inconsistencies in the way each bit was created (by hand-mixing each one out of polyurethane resin and phosphor glow-powder).

The video here shows 3 revolutions of the ring, and you can see the migration of the bits clearly.  Near the end of the video we even get an erroneous double-bit!



I think the bits are too close together and the phosphor isn't optimal.  And a dozen other problems.

The FIFO works nicely though, which means that the microcontroller has absolutely no knowledge of what data is on the ODDRAM ring.  This makes me happy for some reason.

I think that there are few ways to improve this project without completely rebuilding it from scratch.  I'm not going to do that.  I think this proves that data CAN be stored on luminous phosphor for many seconds.  It's just hard to do without serious R&D effort.