Alt-BEAM Archive

Message #04138



To: beam@sgiblab.sgi.com
From: Peter Low peterlow@fletcherspaght.com
Date: Tue, 01 Jun 1999 22:44:58 -0400
Subject: [alt-beam] Re: Bicore, wasting energy


I think one question I haven't seen is "what do you want the head to do
when it zeros in on its target?"

If there is a task, or tasks, to be performed at that point, is it possible
to construct a circuit which will cycle through several states (for
example, perform the task at hand for nine cycles and then use a tenth
cycle to make sure that the head is still targeted)?

I know I may be treading into dangerous territory here (ucore vs
uprocessor), but it seemed to me that if a circuit could be constructed
which performs Task A then Task B then Task C then Task D then goes back to
Task A, you could limit the consumption of power spent in keeping the head
on target. Ideally, you would want to be able to vary the cycles spent on
various tasks depending on the situation at hand -- if the head is off
target, spend lots of cycles getting on-target; if the head is on-target,
spend few cycles keeping it there.

Is this a 3 (other solution)?

At 06:18 PM 6/1/99 +0200, you wrote:
>Hello List,
>
>A week or so back I posted a question about the fact that a phototropic
>bicore with a small timeconstant, driving a motor, is wasting quite a bit
>of energy: only a small portion of the energy is used to actually turn the
>motor; in fact the system is most efficient when it is not pointing in the
>direction where it wants to point to; once it has arrived at that direction
>is stands still, converting electrical energy to warmth.
>
>Since then I gave the matter some more thought; that didn't result in much,
>I think, but I want to post it to this list anyway since maybe I will get
>people to get some new ideas or they will start thinking about it:
>
>Problem:
>The suspended bicore is a very, very nice little circuit, but using it in a
>typical light-seeking head application results in efficient light-seeking
>behaviour, which is paid for by a large, and in my opinion, redundant
>energy-consumption. This can be done better and I think this would make the
>bicore rise in its value for Beam.
>
>Ways to tackle this Problem:
>1) find another circuit which can do the same thing in a more
>energy-efficient way. This is kind of a cruel thing to do, since I would
>like to keep the bicore.
>2) add some circuitry to somehow filter the information needed to create
>the turning motion of the motor. The original information is contained in a
>the duty-cycle of the oscillation. This information should be converted to
>a signal which, most important, contains directional information for the
>motor and to a signal which, less important, sets the speed of the motor.
>The second is maybe not necessary.
>3) ... (don't know ... maybe you do !!!)
>
>Possible Solution:
>- Only a solutions of the kind of point (2) are considered for now (maybe
>you will find a much better solution in point (3)).
>- What came to mind is somehow averaging one output of the bicore. This
>results in a signal which is greater than Vcc/2 if the motor should turn
>one way and smaller if the motor should turn the other way. In principle,
>with a high-gain-inverter like the 74HC240, this distinction between higher
>or lower than Vcc/2 can be translated to a high or low logic level and this
>is enough to drive a H-bridge with a motor.
>Perhaps the original oscillation of the bicore can be used to switch the
>power of the h-bridge and thus have some sort of pulse-width modulation. To
>make things clearer I have a drawing of a circuit attached.
>- As a variation of the previous option it is possible to avarage both the
>outputs of the bicore connect the resulting signals to an
>(high-gain)-opamp. The output of the opamp serves the same function as the
>output of the inverter did in the previous point. Advantage of this: nicer
>symmetry (which doesn't serve much since all the information coming out of
>a bicore is contained in one output only, but it looks nice). Disadvantage:
>higher part-count. In the previous point an inverter of the same 240, as
>the bicore uses, can be used.
>
>Problems with the proposed solutions:
>- the additional circuit will start oscillating again if the system is
>pointing to the direction it is supposed to point (where there is most
>light), which isn't good for the efficiency for the same reason as the
>whole thing started with (back to nothing).
>
>NB: the circuits attached aren't tested, they just excisted in my head.
>Probably I overlooked something really badly, but the solution isn't ideal
>anyway ... I'm actually hoping somebody will come up with a very nice
>solution now.
>
>Hope this inspired you a bit ...
>
>Regards,
>
>Wouter Brok.
>
>


------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com - Simplifying group communications



Home