0%
0%

# Incandescent RAM

Use lightbulbs to store data!

Similar projects worth following
662 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

• ### Status - backburner

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!

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

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...

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,...

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.(?)

• ### SIMS!

(simulation file in this project's files section, or click here and save-as... Then go to the falstad circuit simulator and select File-Open...)

The bottom two decade-counters merely simulate a rotating drum with magnets and reed switches spinning at 10 rotations/sec. Seems realizable. The left one just creates a slight delay between certain states, essentially a larger magnet. Similarly, the relays connecting the bulbs are also part of the drum-simulator.

For each bulb there are three states: Read/refresh-start, refresh, and stop-refreshing.

The third (upper) decade counter is a delay and loop for periodic write-testing. It could be little more than an RC circuit, but here it tests the bit being written periodically until the read-back value matches the value we're writing. This circuit's been optimized for writing that bit as fast as possible, and still allowing refresh of all bulbs as-usual.

I've also added write-hysteresis, by plopping a resistor in series with the bulb or the read-back resistor, depending if writing 0 or 1. Thus the bulb will be written until it's either 10ohms below or above the threshold.

Note that after reaching steady-state Ron is roughly 116ohms, and Roff roughly 44. The readback-threshold seems to be roughly 60ohms. I haven't checked the write-hysteresis thresholds very carefully. That was a late-addition upon finding an unusual case. But, I think it should be quite handy to assure reliability e.g. when the ambient temperature varies dramatically.

It's a lot of circuitry for three bits, but the numbers suggest it could be extended a bit. And... without write-automation the circuit's actually pretty small. Another possibility, maybe, is to use one write-circuit for multiple rows. And, obviously, multiple rows can use the same rotating-drum refresh-sequencer.

Actually, I should clean this up a bit... it looks way more complicated than it is.

Ran some sims... seems to work.

They're on the computer, kinda too beat to start it up.

Got a bit of feature-creep.

Reading, writing, and refreshing a single bulb requires a single relay, a resistor, pushbuttons, and eyeballs, or hands...

Adding multiplexing for three bulbs adds a rotary-switch for refreshing and another for selecting which to write. This topology allows refreshing in the background without interfering with write... so, throw a motor on the refresh-selector and have at it.

Presently the full refresh-cycle runs at 10Hz. Bulbs rated for Roff=10ohms and Ron=150ohms are asymptoing to around 45ohms off and 116ohms on.

....

Now I get a bit carried away...

wouldn't it be nice to automate the write process? Have it automatically stop writing once the bulb cools/warms enough? Bam: a couple additional relays and some boolean logic (XNOR!).

Ah, let's speed up the process, no need to write a zero when it already is! Sample-first-then-write. Uh-oh, bug. If you start a write of 1 to a 0 at just the right time after its previous 1->0, and at just the right time during refresh, it *just barely* crosses the 0->1 threshold, stops writing, and cools back to 0.

Part of the point of automated-write-testing/completion was to assure such things *wouldn't* happen, e.g. in extremely cold weather. And, ironically, maybe, attempting to avoid that scenario *caused* it.

So, now a further feature-creep... Hysteresis... Let's set a lower threshold for Roff and a higher one for Ron, but only when *writing*. No prob, we already have the relays... two more resistors and add another pole (3PDT, now!)

Or... yahknow, it worked before because it wrote for a while before testing... could just have an arbitrarily-long write-process with a single R/C circuit....

I think I've forgotten some intermediate feature-creeps... But, the point is, it's automated and simulated functional...

A rotary-switch, another on a motor (or a drum with magnets and reed switches), a few relays, and there yah have it, heh!

..

Oh, interesting observation: I used a decade-counter (4017?) to simulate our drum-switch... And using the reset terminal causes the first bulb's refresh-timing to be slightly shortened.

This is actually quite telling, as it reaches asymptotes of something like 10ohms lower than the others... Yet it remains stable and still far from the threshold (currently ~60ohms).

Thus, this seems way more resilliant than I expected, and once that timing glitch is fixed and write hysteresis is functioning (heh!) it should be able to handle at least a few more bulbs. 5x7 may be realistic.

....

Oh, a few feature-creeps actually resulted in a simpler system... That was cool.

I should throw up screenshots and simulation files (TODO).

...

Actually, it seems resiliant-enough that I've pondered multiple values per bulb...

Presently the sims are for a 5V-only system... 5V bulbs (160mW seems reasonable), 5V relays (600ohm coils, similarly reasonable)... But what about going back to an earlier idea...? 120V bulbs, 5V measurement-system... And various DC voltage-sources (rather'n resistors/current sources) for refreshing various values... they can't get nearly as hot at, say, 60V as 120V... Pretty sure bulbs aren't a perfect thermos, and photon-ejection must require some power, otherwise 5V in a 120V bulb would eventually glow white-hot...

Relay-measurement, still? Also, 'spose similar could be done with 5V bulbs and a lot more precision.

• ### Relay Refresh 2

Another unpublished draft. sheesh!

-----

Got simpler, then went all-out... We're talking multiplexing and Write-Complete testing.

Pardon the Digital logic, Dunno how to make a rotating drum-ROM with magnets and reed-switches in this simulator. And... well... I got lazy with the gates.

The key, of course, is the refresh/read circuitry, at the upper-right which consist of a single relay and a few resistors.

Herein, I think I've chosen somewhat realistic components, etc... 5V 160mW bulbs, a 5V relay with 600ohm coil, 10Hz refresh.

A few last-minute changes, can't say they've been fully-pondered, but... oh snap... oscillation again? No.

Another key, of course, is finding timings/values that cause the off bulbs' heat/resistance to asymptote, rather'n keep climbing, due to periodic measurement current. I think it's doable with enough slack to not require a lot of precision.

Really, this is a mess, the concept is pretty simple, just need some old cylindrical container, a motor, magnets, and reed-switches for all them counters, diodes, and associated relays.

The write-complete circuitry, though... That's something else. That's a lotta relays and gates. And may be completely unnecessary, depending on the goal. E.G. was thinking of a 5x7 grid where pixels are set by hand. In which case the "set" and "clear" switches could be used manually with a keen eye, and all that testing circuitry removed.

But also have a "big idea" to make my millions from this... so that'd need automation for writing (which, really, could just use a R-C delay circuit...)

• ### Relay-based Refresh Circuit

Heh, thought about drawing it again [again again] cleaner, but there's a lotta info here.

It may be hard to tell, but the idea is to use just one read/write/refresh circuit for numerous bulbs (maybe a row). The Refresh-Select switch is likely to be a motorized-drum with magnets and reed switches. This might also handle timing for the Refresh and Refresh-Inhibit/Stop pulses, as well as another pulse during Data-Valid.

Write-select is on a different switch [rotary, likely motorized]. Note that writing safely overrides refresh on the selected bulb, and presently does so as fast as possible... Not requiring the multiplexed refresh circuit to do-so, nor interfering with refresh timing of other bulbs.

(oh snap, 'safely' was before the refresh-reset ... gotta look into that. TODO)

Relays, then, can also be used in the write circuitry, for automation...

Oh, snap... I just came up with another possible change.

Anyhow, was-thinking a 5x7 display might be manageable...

This, of course, all relies on whether bulbs can be found near these specs...

100ohms 5V -> 50mA? Sure... and 1K relay-windings? Seems doable. Induction, heating/cooling-time, thermocouples(?!)... I guess we'll see.

But I've obviously gotten carried-away, already thinking of 5x7, write-complete feedback, counters, and even ISA cards...

How about *one*, hand-controlled light-bit, first.

Might be a while. Might be repurposing a relay or two from under the hood!

Oh, and resistors... these values aren't in my collection, and I'm a ways away from the part-store... I might just scrap some pencils.

(Which, dangit, woulda been *the* solution for the friggin' battery charger!)

Oh yeah, hey... the read-process inherently refreshes and vice-versa... kinda handy.

Share

## Discussions

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

esot.eric 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

esot.eric 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

esot.eric 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

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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

esot.eric 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

# Does this project spark your interest?

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