0%
0%

# Incandescent RAM

Use lightbulbs to store data!

Similar projects worth following
1.2k views
Herein I propose a plausibly-new old-school method for storing data. Not at all dissimilar to present-day DRAM, which stores data in the form of slowly-decaying electric fields requiring periodic "refresh." Other memories (such as core-memory) use magnetic-fields. Incandescent-RAM, then, is similar, while making use of light-bulbs' *heat*-"fields"!

Dig it!

Attempting to find a high-wattage low-value resistance for current-limiting, I pondered the use of a light-bulb... and came across something even weirder:

Light-bulbs increase in resistance, somewhat dramatically, as they heat up.

My 100W bulb measures 10ohms 'cold', but 100W->144ohms! I later found mention of 15/1 as pretty common (amongst all incandescent bulbs, of all voltages/wattages?! Hmmmm!)

15/1 is *well* within the measurement-ability of even crude instrumentation; even a large enough resistance-change to drive a relay, or not, through a simple voltage-divider using the ol' "10-to-one rule."

So, herein I propose a plausibly-new old-school method for storing data: heat.

Not at all dissimilar to present-day DRAM, which stores data in the form of [slowly-decaying] electric fields requiring periodic "refresh." Other memories (such as core-memory) use magnetic-fields. Incandescent-RAM, then, is similar, while making use of *heat*-"fields".

Why not, eh?

A grid of "holiday festive lights" could make for both a display *and* its frame-buffer.

A blank grid could make for a thermal imager/mirror. Maybe even watch as the heat from your hand gradually causes the bits to toggle.

Or, an inherently-visual display of data in RAM.

----

In this *very* early design stage, it seems a simple "refresh" circuit should be achievable with niothing more than relays and a voltage-divider.

Say the 100W bulb, mentioned earlier, is used, and some quick estimates. A zero-bit results in a resistance of 10 ohms. A one-bit is 100. The bulb is periodically isolated via relay contacts from the 120V source, and switched into the measurement circuit, consisting of a 10V source, a 10ohm resistor, and a 5V relay with a 1k winding is used to measure the 'bit'.

The bulb and resistor make up a voltage-divider whose output is either 5V (powering the relay) when the bulb is cool [zero], or, 1V (not enough to engage the relay) when the bulb is hot [one].

Similar should be accomplishable with smaller/lower-voltage bulbs, plausibly even "grain-of-wheat" bulbs running at logic-levels rather than mains [still 15/1?].

And, of course, why limit to relays for readback/refresh? A comparator could easily do the job.

### AllRR.txt

Falstad Circuit Sim comparing three different Refresh-Circuits (UPDATED WITH THRESHOLD VALUES)

text/plain - 4.42 kB - 12/05/2018 at 04:00

### qUICKoFF.txt

Falstad Circuit Simulation of a Simple Quick-Off Refresh Circuit

plain - 1.32 kB - 12/04/2018 at 23:38

### circuit-20181125-1656.circuitjs-WriteHysteresisGO.txt

plain - 6.62 kB - 11/26/2018 at 03:20

• ### Sense "Amplifier" Circuit...

Eric Hertz09/26/2023 at 13:51 5 comments

Ken Shirriff did a writeup on DRAM...

check this baby out... looks a heck of a lot like what I came up with!

In my case I'm essentially measuring a small *resistance* difference, rather than voltage. But, of course, the voltage-divider created by those resistances is what's responsible for which relay "wins." The 50 ohm (calibratable) resistor is essentially our reference resistance. If the bulb resistance is higher than 50 ohms, it's considered "on" and the lower relay turns on faster than the upper relay, cuting it out of the circuit. (The bulbs measure roughly 10ohms cold, 100 hot).

[The 10ohm resistor is an addition for the refresh circuit to self-reset when it advances from one bulb to the next.]

Simulations, long ago, showed that a bulb could be determined as having been "on" when its resistance had dropped *dramatically*. Real-world tests were not expected to go as well, yet really did far better than I expected, "bits" retaining their value for upwards of a second [of course, that also means that *clearing* a bit to zero also takes upwards of a second], while only being refreshed for a fraction of that. This, too, was a bit of a surprise; I kinda figured I might have to use higher voltages than the bulb's rating to get it to heat fast enough. But, instead, I was able to get a functional system running at less than the bulbs' rated voltages. Increasing the voltage, then, might allow for longer durations between shorter refreshes, which would mean more bits could be handled by the same sense/refresh circuit. [This "sense" circuit also "refreshes" the bulb.]

• ### Overboard

Eric Hertz06/09/2022 at 04:08 3 comments

Today I worked out most of how to interface with a Z80... Hah!

It's about 11 relays per data-bit.

Seeing as how I think I might be able to handle 8 bulbs per refresh-circuit (one refresh circuit per data bit), we're coming out a bit behind.

So... Hmmm...

The idea was to have read and write be random-access; completely independent of refresh. There are a couple cases where the refresh and read/write circuits might glitch when run simultaneously... Nothing a couple more relays couldn't fix!

The next idea was a write-circuit which automatically tests whether the bit is fully-written, before releasing the Z80's "Wait" line. Only a couple/few more relays!

...

Scaling back, well... An earlier thought was to use the refresh circuit to also handle reading. That might save a couple/few relays at the cost of an additional pole on the rotary-switch/drum. It also means the data will only be available when the drum gets around to it.

Which, actually, I kinda dig... The idea of hooking this to a Z80 is so utterly ridiculous, but yet, also a *great* demonstration of the Wait signal, which for some reason I'm rather fascinated by.

Writing... Well... I could save a few, maybe several, relays by just using an RC circuit timed a bit longer than it should actually take to write a bit. Heh, why not?

I guess, realistically, since writing a *byte* will almost always contain both ones and zeroes, it'll seldom if ever write all the bits faster than it takes for a bulb to cool.

OTOH, this use of Wait, I'm not as fond of... I'd almost rather write each bit in sequence, as fast as possible, (even if just using separate RC circuits for writing highs and lows), even though it'd be *significantly* slower, because, I guess, I'm fascinated by Wait. This'd demonstrate it better, taking varying amounts of time, depending on the data being written.

Then, of course, there's the question of where do I draw the line between semiconductors and relays? Wait, itself, will almost certainly have to be driven by a bit of automatic logic; a relay can't switch fast enough! But, Even though that'll likely involve a flip-flop (and some glue logic) I'm not sure I want to use e.g. a 7400-series shift-register to load the bits in/out.

I dunno, we'll see if this actually goes anywhere. It didn't *start* with thinking to interface with a Z80... it got there when I realized my Write/Verify circuit would take differing amounts of time, and would go well into that Wait pin.

That inkling was already there, though, when I realized the Read circuit has two separate outputs, two separate relays, for high vs low. Thus, its data output is guaranteed valid when one of those relays is switched-on. It inherently tells you (or the next circuit) when its data is valid, when the operation is complete.

I kinda dig that. Especially since its speed may vary depending on things like ambient temperature, or even the shapes of the contacts in the rotary-switch/"drum." Which, actually, are not all identical. Some are skinnier due to the trace connecting the pole to its solder-tab. Those skinnier contacts will likely result in bulbs that average just a slight bit cooler-when-hot than the others. Thus their resistances will be slightly lower, which would make for lower voltages on the output of the voltage divider, making for more slowly-transitioning relays... And, then, leaving even less time, while sliding across the already skinny drum contact, to do the actual reheating. Thus, some bits will inherently take longer to read than others, which, again, I kinda dig the idea of a system that gets it out there as fast as it can, and inherently "clocks" the next process when it's ready (deactivating Wait).

I'm not certain, by any means, but I think 16 bulbs per refresh circuit is probably pretty close to the limit, based on how much time they'd need to reheat. I was thinking maybe 8, for this project. Then 8 of those in parallel for 8 bytes...

• ### Refreshing 4 bits

Eric Hertz06/07/2022 at 03:48 0 comments

We now have Incandescent DRAM and a refresh controller!

(Note, I have since moved the 10ohm resistor such that RyC is now connected directly to C1 and C2. This resistor allows writing at any time, regardless of the refresh circuit's being plausibly already latched at the opposite value. In the schematic, as drawn, it allows a little bit of current to flow through the bulb, heating it up, even when Relay2 has latched low. Moving it as I described prevents any current from flowing through the bulb after Relay2 latches. The drawback is that if the relays are already latched when a write comes through, it will not automatically unlatch them, and instead just waste power through the resistor until the refresh circuit moves on to the next bulb. Still, beter than warming a cold bulb!).

Do-Refresh resets the latches in the refresh circuit (shown in the last post) when the "drum" rotates between two bulbs.

The "drum" is a rotary switch removed from an old 6-way Parallel-Printer switchbox, and modified slightly to remove the detents as well as the endstops. Also, it handled 2 poles of six positions each on each "disk", but was easily modified to handle 1 pole of 12 positions, by removing one of the two  sets of brushes, and tying the poles together.

I had four identical bulbs to work with, so each is handled by three of the 12 positions. The Do-Refresh signal is handled on another rotary-switch disk, tying all its positions together to generate a reset pulse when switching to the next position. So each bulb gets refreshed three times before it moves to the next. I did it this way, rather than doing all four in sequence three times, because I was unsure about the timing... e.g. whether Do-Refresh might hold the previous bulb's value onto the next, due to the layout of the switch wipers. Three refreshes in series would help assure that even if it held the previous bulb's value onto the next, it would have two more tries to switch over to the current bulb's value. It also means all the relays are switching three times as often as they need to. Heh! It's really quite amazing how fast these things are!

Do-Refresh is questionable, to say the least; if it occurs *before* the bulb is switched-in, it'll think the bulb is hot, so latch (and write) it high, even if it was low (cold). I tried adjusting the wiper a bit so it'd be later in the rotation, but it wasn't really assurable, and also meant that it might be more prone to holding the previous bulb's value onto the next, so eventually I scrapped the wiper-adjustment and gave it a go with the normal wiper arrangement...

Basically, I'm saying this was thrown together not expecting the timings to be accurate-enough to actually function... but it does, surprisingly well, considering!

So, the circuit allows for writing any bulb asynchronously to the refresh circuit; a Write overrides the refresh.

The only "cheat" in here, as far as to its being implementable in the era of the telegraph, is that I added flyback diodes on the relay coils, which, really, was just a quick test that may not really have been necessary.

Calibration is finicky, but not impossible with a rheostat. And, I think if I had the timings better-aligned (make contact with the bulb first, then Do-Refresh, then maybe even break Do-Refresh before switching out the bulb) it'd be far more reliable.

(Note that since these bulbs retain their heat for so long, it's actually a bit less finicky than I'd expected. Earlier simulations suggested that the appropriate resistor value was highly dependent on the refresh rate and duration, nevermind the coil resistances, and more. But in the video you can see its working despite the slowing of my drum rotation, etc.)

If I was making a drum, maybe with magnets and reed switches, or even bumps and microswitches, assuring proper timings would probably be quite doable.

But, I've come up with a circuit, adding two DPDT relays, that should delay switching-in the Refresh...

• ### Refresh Circuit - Concept Proven

Eric Hertz06/03/2022 at 23:58 0 comments

• ### ToPonders:

Eric Hertz01/17/2019 at 02:03 0 comments
• ### Status - backburner

Eric Hertz01/15/2019 at 05:04 0 comments

From memory, as it's been 'a minute':

Next Time, probably, to start building a prototype... The full write/read and measure/refresh circuit is now simulated with relays, resistors, lightbulbs, switches, and a rotating drum with magnets and reed switches (to sequence through the bulbs, refreshing each). No Silicon, this coulda been built in 1901.

The relay count has gone down *dramatically* since the last sims uploaded (TODO: upload!). Reliability seems surprisingly good.

There's a handy trick could be done to reduce the circuitry-requirements some more: Presently it's necessary to *stop* a refresh of a "1" bulb before switching to the next bulb. Inserting a current-sensing relay in series between the refresh-circuit and the bulb-sequencer/selector switch/drum might do the job. When the selector switch selects the next bulb, it first breaks contact with the previous, current stops flowing, the relay cuts-out, resetting the refresh-circuit for measurement-mode, which as I recall, might work fine if active with no bulb connected. As soon as current flows, the measurement is taken, refreshing begins... all based on the "sequencing" inherent to one relay's actuating causing the next and the next... (no clocking necessary!) Similar to Propagation-Delays in TTL/CMOS, maybe, but since it actually relies on actuation of relays, rather than logic levels which are always "on" in one form or another, there should be near-ziltch as far as intermediate-states during switching/glitching. it's either off or on, and the next stage *cannot* be on until the previous is, and *cannot* remain on when the previous begins to release. It's kinda groovy thinking this way after all the parallel synchronization circuitry necessary for clocked/synchronous systems. Anyhow, an aside.

The current-sensing relay I imagined was surprisingly hard to find. Seems a simple idea: it's not uncommon to find e.g. a 5V reed-relay actuated at 5ma, or thereabouts... 1kohm winding... So, beef up that wire a bit, winding-resistance down to 1ohm... now a 150mA current flows through the winding, dropping a negligible voltage and actuating while 150mA lights my bulb. Somewhere, thereabouts, anyhow. If they can make tiny little solenoids that run off watch batteries, surely a reed switch could be actuated in these, or similar, conditions... And, surely, there are uses for such all around, no? Lots of searching, seriously, lots. It got to the point I was debating whether the winding in earbud-headphones would trigger a reed switch. Eventually *one* result came up... then two, but only two. Allegedly used in land-line phones/faxes/modems to detect when the line is open(?). Well, shit, if that's the use-case, surely at one time they were plentiful! Surely they have a name! Surely if such exists for phone systems, similar must exist for other common systems, in different ratings and specs. Surely they have a name! "current-sensing relay" Exactly as I'd originally thought, returning results *nothing* like I'd originally thought. Still, only two such models found. WTH. Oh well, I know they exist, and they both happen to be spec'd within my needs, I'll continue to ponder its use, here. What else to do but chalk it up to bad search-fu?

Anyhow, another aside was coming up with an edge-triggered D-flip-flop. A few of these, if simple enough, could be used instead of the rotating drum. Maybe more worth it, now, per the last "D'oh!" wherein I realized I'd need switch-contacts for every bulb, as opposed to every *column* as I'd originally thought... 4Pole relays exist, 4 rows handled by each.

So I managed to whittle-down the Master-Slave edge-triggered flip-flop (in the falstad simulator) down from 4 NANDs and 2 inverters down to 2 spst and 2 spdt relays and two resistors... might be feasible. Though 4 per column still seems a bit much, I've other plans for edge-triggered d-ffs, as well. And, still, might be worth pondering, here, when 35 reed switches (and associated magnets/drum-size)...

• ### d'oh!

Eric Hertz12/17/2018 at 00:19 0 comments

And now we need one reed-switch (or rotary-switch contact) for every bulb. 5x7's not sounding nearly as fun, now.

Eric Hertz12/05/2018 at 00:36 0 comments

UPDATE: Circuit Comparisons at the bottom

UPDATE2: Whoops, noted, and thresholds, at the bottom...

UPDATE3: more thoughts at the bottom.

-------

Relay-Logic is *really cool*.

There are *So Many* ways to implement a simple circuit, each having different benefits.

Here I've been working on a "Quick-Off" Read/Refresh-circuit.

In the long-run, this'll help in several ways... Not the least of which is that it won't heat up "Off" bulbs nearly as much (not that it was particularly a problem).

It also removes the "dead-zone" between high and low measurements. At the end of a measurement, the circuit will either output high or low, no weird inbetween/floating-states.

BUT, I got on this redesign-tangent because... one of the design-goals, overall, has been the idea that the Refresh-circuitry could run in the background, periodically refreshing a whole slew of bulbs, and Reads/Writes of a particular bulb will not be interrupted by this process. The previous design of the Refresh-circuit allowed for a tiny glitch-case, wherein a refresh perfectly-timed with the end of a write would cause a bulb's being refreshed-high even though it was *just written* low.

I've gotten so side-tracked, that I honestly don't know whether this new circuit solves that. I'll have to revisit that later. But, here's the quick-off circuit:

OK, first: The diode is only there for shunting the relays' voltage-surges when turning off, which isn't a problem in the circuit, but makes viewing on the 'scope difficult. (I'm trying to do this whole thing sans-silicon).

The potentiometer represents the lightbulb. My christmas-lights are 6V 0.48W, so roughly 5ohms on, 75ohms off. I didn't go to a tremendous effort, here, to optimize for those values (by changing the 50-ohm measurement resistor), this is just a proof-of-concept.

OK,, the circuit:

The key-concept is making use of the intermediate-stage when a relay is switching from one Throw to the other. The upper relay, when Off, allows measurement of the bulb-resistance by creating a voltage-divider. If the upper-relay has even just-barely enough voltage across its coil to just-begin to pull-in the contact, it immediately breaks the Normally-Closed contact, turning off the voltage-divider. Now the upper-relay gets even more current through its winding, as it goes straight through the bulb without the "upper" resistor limiting the voltage. Thus, causing the upper-relay to pull-in even more-quickly.

Also, as the voltage-divider was turned-off, the lower-relay is effectively shut-off, So, imagine a case where, say, the measurement results in exactly 2.5V, both relays would activate (slowly/slightly, but the same speed/amount, initially)... The *breaking* of the NC contact on the upper relay forces the lower-relay off., mid-swing.

Similarly, if the lower relay is "faster", then as soon as it makes-contact, it forces the upper-relay off. This was the case in previous designs, but the key, here, is that for one measurement a *breaking* of the contact causes that measurement to be made (and accelerated), so there's less dead-time waiting for the two relays to race each other.

In this system/simulation, then, it can be seen that a measurement can occur *extremely* quickly, And get on to refreshing the bulb, or *not* refreshing the bulb, as the case may be. (Note, again, that *measuring* the bulb-state causes current to flow through it, causing it to heat up, which *could* cause it to eventually switch from "Low" to "High."  (Though, realistically, that hasn't been much of a problem, after some calibration).

This system does, however, rely on some calibration depending on the relays, themselves... E.G. even though they were spec'd to turn on at something like 2.8V, it seems they actually begin to break...

• ### Indeed...

Eric Hertz12/02/2018 at 07:08 0 comments

Draft wasn't published, whoops.

-----

Been all gung-ho on this circuit [sims]...

Relays everywhere, no more TTL/CMOS, no diodes.

Actually, in a lot of cases the complexity has *reduced*.

Am discovering that there's a lot to learn with relay-logic that is seldom considered for boolean logic... E.G., there are *three* states with an SPDT relay... NC-open/NO-closed, NO-open/NC-closed, and *both* NO and NC open (while switching). And, similarly, an SPST-relay can be "on" in its coil, but still (briefly) be "off" at the contacts.

This, then, leads one to consider the previous logic operation's output and the next stage's input a little differently than for TTL...

Combined-with: a string of logic may be *significantly* simplified by changing things like "active-high" vs. "active-low" in intermediate stages... even if, intuitively, it seems odd...

But, even still, it's not a simple matter of "here's three ways to implement AND, choose one", since it's really less about the boolean-logic and more about the end-result.

E.G. The write-verification circuit is simple: XNOR the read-back-value with the write-value, if the two are the same, then XNOR is 1, and the write-process is complete. Simple!

This is as simple as throwing a SPDT relay coil across those two signals. If they're equal the relay will remain off. OK!

But, now I need a bunch of logic between that output and the End-Write relay (or before its inputs) because: It should only end-writing if it's writing AND we're verifying. But our X[N]OR signals read/write equality by remaining in its default state... so will always have a "write-complete" output except for the brief moment *when testing* (and the values differ). Thus, additional logic.

OR: note that what I really want is a relay that turns ON when the two signals are equal. Now we can't just throw a winding across them. But we can invert one signal at the input.

Handily, the read-back circuit is already out of the picture except when verifying... its output *floats*. That won't turn on our "inverter" relay until we're in verification-mode. AND, even more-handily than gating with the mode, this relay *can't* be active until the value is actually properly read-back, which takes some time.

So, now, we know that if that relay is on, we are in fact in "verification" mode AND its value is legit. Feeding that sorta signal into an XNOR with an inverted-input, and using the normally-open contact, then, can go directly to our "end-writing" relay...

...which we no longer need, because that relay was normally-closed, to allow the "writing" relay to latch... and now our "values equal" relay is ON when equal, and OFF (normally-closed) at all other times.

Bam.

Major reduction.

But, one problem... our "inverter relay" connected to our read-back circuit remains off both when the read-back circuit output is floating and also when 0. Nope. But our Writing-circuit's value *never* floats under normal conditions, it's value comes from a SPDT switch which is either high or low (except when switching, which shouldn't happen *during* a write). So, placing our inverter-relay there, instead, (or using another pole with opposite wiring) assures that its output is always valid.

Then, swapping back to the read-back circuit, its value always being "valid" or floating, we can wire that directly to the X[N]OR relay-winding, and now that relay will only ever turn on (breaking the NC contact, stopping writing) when the data's valid, we're writing, we're verifying the write, and the read-back value is opposite the inverted write-value.

BAM. A shitton of logic removed, and no need for added delays or synchronizers to wait until the read-back system has valid data.

Tri-state FTW!

I gotta say, There are some impressive relay-projects out there, many here on .io. Some relay-computers, even. I never really considered 'em anything more than just a pile of gates implemented with relays instead of TTL... An impressive feat alone,...

Eric Hertz11/27/2018 at 19:25 3 comments

Bought a string of "holiday festive lights" from the dollar-store. \$1, 20 bulbs, 120V. These may be darn-near perfect.

My original experiments were with a 120V 100W bulb... This was measured to be ~10ohms cold, and calculated to be 144ohms hot.

I ran some other experiments on a couple 12V bulbs in my home... One looked to be ~0.1ohms cold, ~1.5ohms hot... that'd be hard to work with. Though, it heats and cools at a rate measurable with my multimeter, which is handy... about 3sec->cool.

But, those resistance values would be tough to measure with my old-relay-tech idea, nevermind the power per bit, WATTS/bit! Nevermind, also, the \$/bit.

These festive bulbs are actually specified in the manual (!) (\$1!) as 6V 0.48W. Math: 75ohms hot, 5ohms cold. These numbers are darn-near spot-on for the sims I'd been running.

But, of course, they're tiny in comparison, and have a comparatively tiny heat capacity, which makes measurements difficult, and means the refresh-circuit will need to cycle quickly. (No 'scope presently!)

Am-thinking of an AVR circuit to measure the characteristics... Which, then, is just a fancy logging ohm-meter with a synchronized "charger"... Heat the bulb, measure the resistance (inductance? thermocouple voltage?!) as it cools.

And then.., since that's essentially the refresh/read circuit, why not just implement the whole blasted rotating-drum multiplexer, and the write-select rotary-switch (2-pole!) and the write-complete circuitry (relayS, gateS) in the darn uC...

and then, yahknow, the stupid uC already has 512 Bytes of RAM, so who needs incandescent-RAM anyhow?

...

But that's an aside... I don't have relayS (mayyybe one) with me, so if I'mma do this, a uC is a good proof-of-concept, if y'all would believe it's doing what I claim and not just twiddling GPIOs from internal RAM...

...

Next thing:

Turns out this isn't really RAM at all... it's only 1/2RA-Memory; Writing is random, but reading is sequential-access.

This just won't do!

So, debating a new relay-circuit...

AND, I think if I implement Read and Write in the same circuit, separate from Refresh, then things will actually get cleaner/simpler.

Then write-complete-testing is no longer reliant on synchronization with the refresh circuit, which might remove quite a few gates and maybe a few relay/switch poles.

Duh.(?)

Share

## Discussions

Dr. Cockroach wrote 06/07/2022 at 12:26 point

Cool Beans. You have been busy while I was on vacation, I am going to look into this further and have a go at it.

Are you sure? yes | no

Eric Hertz wrote 06/07/2022 at 23:59 point

Cool! No bigger compliment to a scientist than to have another scientist take an in depth look at their work!

I should probably do better at giving such compliments. Your #Light Logic - Diode Resistor Logic out of its cage is one I've been meaning to try

Hope you had a great vacation

Are you sure? yes | no

Ken KD5ZXG wrote 06/04/2022 at 16:08 point

Erasing a single ended heat bit might take some time. Have you considered differential pairs?

Are you sure? yes | no

Eric Hertz wrote 06/04/2022 at 16:51 point

Interesting. I had just been contemplating the idea of using separate *paths/wires* for high and low for each bit in relay-logic. In fact there's a log-entry discussing it in my drafts, from a couple days ago.

But, ironically, I guess, I hadn't taken that line of thought far enough to use for the actual *memory* cells.

Interesting!

Are you sure? yes | no

Ken KD5ZXG wrote 06/05/2022 at 03:38 point

Homopolar motor/generator may be another cheap way to store/readback/observe an angular momentum bit or trit.

Are you sure? yes | no

roelh wrote 11/18/2018 at 20:58 point

I was working with the Falstad simulator (for my new 2 transistor circuit with 4 stable states) and discovered it has light bulbs ( Draw / Outputs and labels / Add lamp ). Resistance of the filament is indeed about 15 times lower when it is cold ! It has adjustable warmup/cooldown time, and can even show the filament temperature. Voltage and Watts are adjustable. So, you can simulate your RAM first !

Are you sure? yes | no

Eric Hertz wrote 11/19/2018 at 00:13 point

Holy shizzle! Yahknow, I actually thought about checking if falstad had a light, but stupidly figured it would just be an indicator rather'n a circuit model. That's pretty durn cool!

Only thing, the stupid bulb I just experimented with actually goes *down* in resistance with heat!

I saw you've commented on that first log, here, about your multi-state transistor idea... looks interesting. heading over to check it out.

Are you sure? yes | no

roelh wrote 11/17/2018 at 22:04 point

Now for another small puzzle. Suppose Eric has an unlimited number of 100W lightbulbs. Each lightbulb measures 10 Ohms if cold. Trying to build a memory, he connects his endless amount of bulbs in an endless 2-dimensional maze like this:

www.enscope.nl/rrca/ideas/bulbs.png

Question is, if he now measures across a bulb, what resistance does he measure ? Warming-up of the bulbs is of no importance.

Are you sure? yes | no

Eric Hertz wrote 11/18/2018 at 00:41 point

Nice!

That math is beyond me, I think I'd default to the diode-ROM method @Ted Yapo describes below, but I'm definitely curious:

Is there an answer? Is it doable to somehow determine whether one bulb in the matrix was warm/lit recently, and which?

Are you sure? yes | no

rubypanther wrote 11/18/2018 at 05:35 point

I'm going to guess 8.09015 Ohms, or half a Fibonacci times ten.

Are you sure? yes | no

Eric Hertz wrote 11/19/2018 at 00:16 point

I'm afraid to post my findings, as it'd be a bit of a spoiler... but I may do-so, so I'll "spoiler-alert" it ;)

Are you sure? yes | no

roelh wrote 11/18/2018 at 07:43 point

The mathematics to get to the answer is very simple once you find the right method of reasoning...

Are you sure? yes | no

Ken KD5ZXG wrote 06/07/2022 at 08:24 point

Dunno, but perhaps fold the problem makes easier to solve. Or at least moves the question from the center of an infinite structure to an edge...

Are you sure? yes | no

ermatruthseeker wrote 11/17/2018 at 07:37 point

so are you thinking of using that with LiFi to store date in different bulb configurations

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:59 point

LOL, I had to look up LiFi. There's an interesting possible use-case. Though data transmission would be *very* slow. Unless, I suppose, data was being transmitted by travelling quickly past several bulbs? Like streetlights on a highway?

Are you sure? yes | no

salec wrote 11/17/2018 at 01:44 point

Intriguing idea, but very uneven bit set vs. bit reset time.

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:37 point

A valid point, indeed. Are you sure if I reverse the polarity it won't reset to zero?

Are you sure? yes | no

salec wrote 11/17/2018 at 21:49 point

If it would, then I misunderstood the description.

However, if you would use a thermo pair in a bulb instead of a filament, then you could heat, cool (with reverse polarity), and sense the temperature (measuring output voltage) of that cell.

Are you sure? yes | no

Eric Hertz wrote 11/18/2018 at 00:25 point

Oh, wow, by "thermo pair" I take it you mean a peltier junction? (being the only thing I know of that can actively remove heat). There's an idea! I was totally joking about electrical-cooling, but you found the solution!

Are you sure? yes | no

salec wrote 11/18/2018 at 08:20 point

But you led me to it. High-five!

Are you sure? yes | no

DeepSOIC wrote 11/17/2018 at 00:33 point

Once upon a time, I thought, that there can be a lightbulb, that, if powered with a constant current source, will have two stable states. In one, resistance is low, and I^2*R is not enough to heat it up. And if it's hot, R is high, it dissipates more power, and sustains hotness.

I have never found a bulb that would do it though. I'm pretty sure, a thing somewhat like that can be achieved with paralleled leds, provided enough heat isolation of each led.

Are you sure? yes | no

roelh wrote 11/17/2018 at 18:54 point

I tried this once (with series resistor instead of current source). Once connected, the brightness of the lamp came up very slowly. It might be used for a time delay ! But indeed, no two stable states.

Are you sure? yes | no

roelh wrote 11/17/2018 at 18:55 point

A lamp has a positive temperature coefficient. But would the two-state effect be possible with an NTC resistor ?

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:28 point

I came to similar thoughts in responding, then Wikipedia answered, kinda, as well. Yer onto something!

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:15 point

Excellent! I've started a log-entry for this, 'cause you really got me thinking. Shall we carry on discussion at: https://hackaday.io/project/162351-incandescent-ram/log/156044-stable-states ?

Are you sure? yes | no

Starhawk wrote 11/16/2018 at 18:13 point

Dude, you're mental... but I'm pretty sure it's in a good way.

Christmas light bulbs are 2.4v, BTW... and don't forget about thermocouples.

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:43 point

Hey hey! Thankyah, I think.

Actually, I think those bulbs come in many voltages... The Dollah Store has 120V strings with 20 bulbs, wassat? 6V. Weird, but possibly very handy for this project!

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:49 point

Oh, how'd I miss the thermocouple bit? Good call. PTC and NTC [positive and negative thermal coefficient, I just learned] resistors are also a thing. Inspired a thought-path, go check that first log-entry.

Are you sure? yes | no

Ted Yapo wrote 11/16/2018 at 17:10 point

So, there's this riddle I was asked at a job interview once:

You are shown three switches on a wall.  These three switches connect to three light bulbs in the basement of the house, and you have to figure out which switch controls which bulb.  You can assume that all three bulbs are in working order.  How many trips up and down the stairs does it take, and how do you do it?

Are you sure? yes | no

davedarko wrote 11/16/2018 at 18:01 point

I think I can make it in one trip :D nice riddle :)

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/17/2018 at 12:12 point

one ? I can only think of solutions with 2 :-/

Are you sure? yes | no

Jan wrote 11/17/2018 at 14:43 point

@Yann Guidon / YGDES You could let one bulb be on a lot longer so you could tell the difference in temperature and tell it in one go. One hot bulb, one warm bulb, one cold bulb :)

Are you sure? yes | no

Ted Yapo wrote 11/17/2018 at 15:00 point

Yes, you can store more than one bit per bulb - you can store a trit, at least temporarily (until it decays, as @esot.eric describes above).  A bulb can either be on, dark and warm, or dark and cold.

Are you sure? yes | no

Yann Guidon / YGDES wrote 11/17/2018 at 15:55 point

OK the solution makes me feel dumb now :-D

thanks for the trick ;-)

Are you sure? yes | no

K.C. Lee wrote 11/17/2018 at 19:17 point

Flip one switch and see which bulb get lit.  While you are there, unscrew one bulb.  Flip switch until the basement lights up - assuming that you can see without getting down there.  The remaining switch controls the unscrewed light bulb.

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:40 point

LOL! I didn't get it. Thanks @Jan and @Ted Yapo for explaining! I feel stupid too.

Are you sure? yes | no

Eric Hertz wrote 11/18/2018 at 02:33 point

@K.C. Lee ah hah! Thinkin' outside the box, and lookin' outside it, too. Nicely-done.

On those lines, I'd like to note that @Ted Yapo 's description of the problem doesn't explicitly state that the three switches aren't already in the basement, so the answer could be zero-trips, if there's a hillside and ground-floor entry-way involved ;)

Are you sure? yes | no

Sebastian Eduardo Demelas Miers wrote 11/19/2018 at 19:52 point

It's one of my favorites! So, you have switches 1, 2 and 3. You can know their correlation with the lamps in just one trip: turn on switch 1; leave it on for a while; turn it off; turn on switch 2 and go down the stairs. The lamp that is off and warm is connected to switch 1, the one that is off and cold is number 3 and the one that is on is number 2.

Are you sure? yes | no

RoGeorge wrote 11/16/2018 at 12:28 point

Nice.
:o)

Thought, once we have relays, we can store data in the relays, but in case of relay scarcity while plenty of light bulbs, then yes, it makes sense.

I like the idea!

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:53 point

Indeed, the goal, which I'm currently not quite achieving, is less than one relay per bulb, via multiplexing or matrixing. But, yeah, my single-bulb refresh circuit uses three relays(!), one of which is actually used as a latch... when I came up with that, I felt a bit goofy ;)

Are you sure? yes | no

Ted Yapo wrote 11/17/2018 at 21:31 point

I think if you allowed diodes, you could build a matrix.  Take a fully-populated diode ROM matrix and add a bulb in series with each diode.  Now, you can access each bulb individually via one row and one column.  If you put a relay on each row and column, you can access N^2 bulbs with 2N relays.  Or, maybe transistors, since for a large matrix, you probably have to scan fairly quickly for refresh.

You've also turned a diode ROM into a diode-lightbulb RAM.

There are cheap holiday light strings available this time of year.  It seems like someone has to demonstrate that the thing could work...

Are you sure? yes | no

Eric Hertz wrote 11/18/2018 at 00:15 point

@Ted Yapo

Gah! You're Totally right that this thing needsta be working *soon*. How'd I not make that connection?!

Diodes, of course! I was tryin'a keep this sans-semiconductors, as a means of showing it coulda-been-done ages ago... but... why? No reason, really.

It would be awesome to see it working!

As much as I love building things and proving concepts, there's little chance I'll get something functioning in time for the holidays. Wonder if there's a challenge in here... ala 1kb or 1sq-in. Maybe too-specific. OTOH, I've yet to throw up refresh-circuitry schematics, there may be countless implementations!

Are you sure? yes | no

Dr. Cockroach wrote 11/16/2018 at 10:26 point

Woah, now that's a neat idea to look into :-D

Are you sure? yes | no

Eric Hertz wrote 11/17/2018 at 20:54 point

Thankyah, Sir! Inspired a bit, I'm sure, by your #Light Logic !

Are you sure? yes | no

## Similar Projects

Project Owner Contributor

### YGREC16 - YG's 16bits Relay Electric Computer

Yann Guidon / YGDES

Project Owner Contributor

### AMBAP: A Modest Bitslice Architecture Proposal

Yann Guidon / YGDES

Project Owner Contributor

### Nonvolitile DRAM-like thing with Russian Relays

Dylan Brophy

Project Owner Contributor

### SPDT16: 16-bits arithmetic unit with relays

Yann Guidon / YGDES

# Does this project spark your interest?

Become a member to follow this project and never miss any updates