Close

QuickOff Relay-Read/Refresh!

A project log for Incandescent RAM

Use lightbulbs to store data!

eric-hertzEric Hertz 12/05/2018 at 00:360 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:

(Click here for the simulation-file, which can be run in the falstad circuit simulator)

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 contact as low as 0.6V, given enough time. Swap these relays out for a different batch, even from the same manufacturer, and it may be that the High/Low measurement threshold will vary.

This, however, shouldn't be a great concern as the rest of the circuit is designed with a rather large "undefined" region in mind. Previously, that may've resulted in a "floating" output, or the measurement-voltage (through the divider) which is no-good, possibly heating the bulb through later circuitry-stages. Further, because of the write process and periodic-refreshing, the bulb should never actually wind-up anywhere near that undefined-region.

Also, this was once "Refresh/Read", However, in a previous log I noticed that my RAM wasn't Random-Access at all, using the refresh/read circuit, so now "Read" is moved to the Write circuit. So, the refresh circuit's measurement is, really, irrelevant except that it determines whether or not to refresh the bulb and does-so.

Also, this circuit has great potential for daisy-chaining (which is something I've grown pretty fond of, with this relay-logic endeavor)... Such that, e.g., WHEN the measurement is read (which may be slower or faster depending on the value or the relays' characteristics, or the measurement resistor, outside-temperature, etc...) it is immediately-known. Either one relay is fully-active, or the other is. Add a second Pole on those relays, and we have a "Data-Valid" output. Depending on what circuitry may be connected down-the-line, this could potentially speed up a large system, knowing *when* the data is valid, and acting on it immediately, rather than e.g. waiting for a while before assuming it is.

Thus, I may actually use this circuit in the Read/Write portion, as well.

But first, I need to make sure this actually does what I set out to do, which, frankly, I've kinda forgotten.

Oh yeah, a few other things...

There's a lot of potential for calibration, here.... It's possible to drive the lower relay off 5V,, through the upper-relay's NC contact, for instance. Doing-so would make the lower-relay much faster, adjusting our threshold, and making measurements faster, as well.

Or, it could have its own calibration-resistor, allowing more control over the two relays' overlap, and thus threshold-voltage.

And, for sure, I'm throwing a small-value resistor between it (at least) and the "bulb" such that when a Write (or Random-Read-Back) occurs, it overrides (and disables)) the refresh-circuit.

-----------

Here are three iterations of the Refresh/Read circuit, so far...


(Download the sim!)
(WHOOPS! IGNORE THOSE THRESHOLD VALUES, see the next image)

The plots are, from left, top, going down, then right top:

Read/Refresh Switch, Circuit-1's "bulb-voltage", DQ1, DQ2, DQ3, then on the right, "bulb"-current

First on the plots: A "high" "bulb". First-step is the measurement and time it takes to switch the relay, then the next step is the relay's refreshing of the bulb.

Next we have a "low" "bulb". Again, there's a short measurement-period, then the value...

Note that for the first (original) circuit, the bulb stays "charging" through the measurement resistor (30ohm) the entire time Read/Refresh is active. Thus, if left refreshing for too long, the bulb will switch from "low" to "high". The second two circuits don't have this problem. As soon as they measure "low" they switch out the measurement-current (via the resistor). Note, also, that the measurement-duration is *much* shorter (about 1/3rd!) in the third circuit than the second.

Realistically: The measurement itself is significantly faster, it's a matter of relay-switching time. And, note that the third circuit does *not* increase the switching time for *high* measurements... Am debating whether that's possible and/or time-worthy.

And, I think it turns out that this new circuit does *not* satisfy my original goals in revisiting it in the first place, though I still don't quite remember what those were. SIDETRACKED!

-------

And here's the sims with some odd-cases near threshold-values:

Note Circuit1 actually gets stuck between NC and NO! It reads 2.5V because the relay model has 1Mohm contact-resistance. Circuit2 is *really slow* switching to H when the value is near the measurement-resistor (30ohms). Note also that Circuit1 and Circuit2 have different High thresholds of 31 and 30 ohms, despite being exactly the same in that case. Why...? I think the double-pole relay requires more current to pull-in that extra pole. Physics! And Circuit3 doesn't show any oddities, except being much more difficult to "wing-it" a guess at a measurement-resistor value for a certain threshold.

--------

Update 3:

Forgot to note that circuit3 "QuickOff" draws current through the bulb even after measuring Low. Moving the 30ohm measurement-resistor to the N/C contact takes care of this.

But, look again at Circuit1: it draws 130mA through the OFF bulb during 'refresh'. A few logs back I showed sims using Circuit1 for refreshing 3 bulbs sequentially at a rate of 10refresh-cycles/sec. Those sims resulted in a *stable* asymptote toward around 44ohms on the bulb (Rmeas=50ohms, Rbulb-cold=10, Rbulb-hot=144) when the bit is low, 116ohms high. Those values are nowhere near the threshold of ~60ohms, Also, bulbs somewhat-exceeding 44ohms would eventually cool, and those somewhat below 116 would eventually heat. So, really, the system was already quite stable and there's no need to reduce the bulb-current when refreshing-low, as Circuits2 and 3 do, dramatically. But, can't hurt to have an even larger margin. 

And, again, a key concept in the later circuits is that if used for reading (rather'n refreshing) it'll allow for long-duration reads without impinging on that threshold, while also having a clearly-defined moment when the data is valid (one of the two relays has closed the N-O contact).

I have since modified Circuit3 "Quick-Off" for "Quick-On" as well. A simple modification with some interesting results. I'll probably post those later.

But, ultimately, none of these changes/improvements affected what I'd set-out to do in this endeavor... which, as I recall, was to remove the glitch-case where a refresh timed perfectly with Write-Complete would result in a High-refresh regardless of the bulb-state. OTOH, I suppose, if Off-state bulbs are now asymptoting to a much lower value, then a single high refresh-pulse will have significantly less effect. Hmmm.

I did see the glitch again in a slightly different circuit. It caused a stable 4.7ohm bulb to jump to 22ohms in a single refresh-pulse(!)

Removal of the glitch really only seems doable by actually interrupting refresh at that moment, requiring another set of relay contacts. (and adding the opposite glitch, alowing a high-bit to go that refresh-cycle unrefreshed! But, that should have little effect: resistance-change with cooling is much slower than initial-heating).

But the original design required *two* poles on each bulb-selector-switch: one for refresh and another for write, the first on a motorized rotating-drum, the second a rotary-switch... two-poles would be a hassle! Especially if this circuit gets repeated (e.g. for rows?) So, one more relay-contact is much simpler. And an occasional skipped-*high-bit* refresh should be OK.

--------

TL;DR: It's cool to use "break"-time with relays! A third-state which can actually be quite handy.... and rather than considering it like trinary, it instead can be used more like a status-value alongside a data-bit. (handshaking, etc.)

Discussions