Alt-BEAM Archive
Message #04221
To: beam@sgiblab.sgi.com
From: Peter Low peterlow@fletcherspaght.com
Date: Thu, 03 Jun 1999 14:12:41 -0400
Subject: [alt-beam] Re: Bicore, wasting energy
Apologies, I sent my last reply too quickly...
The methods I have heard proposed (to my limited understanding) are
suggesting using feedback from the bicore to dictate when the head is on
target. I am suggesting de-coupling the detection of on-target from the
bicore and using the detector as a switch in the power supply to the bicore.
At 07:35 PM 6/3/99 +0200, you wrote:
>Hello Evaristo
>
>Your observation is correct. I've thought about a Nv-neuron at the output
>of the bicore as well, so that the duty-cycle can be compared with this
>fixed delay-pulse. However, as you mentioned, this isn't a solution since
>the frequency isn't constant. The variable reference I didn't think about,
>but as you say this indeed will take quite a lot of components.
>Today I did some more thinking: what we actually want is something that has
>three states: left, stop and right. When the interval of the dutycycle
>around 50% means stop and can be made bigger or smaller we have what we
>want (of course there probably are nicer options around, but I will settle
>for this one).
>How can this be done: if one output of the bicore is averaged (with a
>low-pass rc-filter) this signal can be fed to the V+ input of one opamp and
>to the V- input of another opamp. The other inputs of the opamps can be
>connected to the different parts of a bridge of wheatstone (those inputs
>should be fed with reference voltages to define the interval around Vcc/2 =
>50% dutycycle and this can be done with a couple of resistors in a
>wheatstone-like configuration ... will draw it sometime and send it).
>With the outputs of the inverters connected to an AND-gate (which can be
>made out of majority logic, like introduced by Wilf a couple of months
>back) we have a signal for
>stop.
>The rest of the signals: left, right and PWM we have already with the
>circuit I drew and posted at the beginning of this week.
>
>Part-count: two inverters in the bicore
> two opamps (in a single dual-opamp-chip) for the stop-signal
> one inverter for the majority logic
> one inverter for the left and right-signal
> one inverter for the PWM (like can be seen in the drawing)
>
>So two chips, one dual-opamp and one 240 and of course a handfull of
>diodes, resistors and capacitors.
>
>What do you think?
>
>Anybody any other idea?
>
>Regards,
>
>Wouter Brok.
>
>
>
>>- Reference pulse:
>>
>>When the head is locked, the outputs of the bicore will have a signal with
>>a duty cycle of around 50%. Comparing one of the outputs with a reference
>>signal can show if the duty cycle is 50%. Using an XOR function with a
>>filter can generate a good signal. Problem however is the cycle time of the
>>bicore, it isn't constant all the time. It depends on the light conditions.
>>So a fixed reference signal won't work.
>>
>>- Variable reference:
>>
>>Output 1 of the bicore can be used to generate a reference signal (for
>>instance charge a capacitor). Output 2 can be checked against this
>>reference signal (generated by output 1). The reference signal has to be
>>updated every time output 1 becomes active. This could work but will
>>require a lot of electronics to update the reference.
>>
>>Problem with above approach:
>>
>>Normaly the output signals turn the motor immediately. With the above
>>approach, it isn't real time anymore. First you check the duty cycle and
>>then you decide to power the motor. What will you use to switch the motor
>>on? The outputs from the bicore are gone when you finally know that it is
>>ok to switch the motor on. You could check the pulses once and then run the
>>motor on the bicore for a few cycles, then check the pulse again. It will
>>save some energy but not much (50% maximum if you check the pulses one
>>cycle and let the motor run the next cycle).
>>
>>Conclusion:
>>
>>This problems needs some serious thinking. Can't come up with an answer
>>right now. Maybe other people have an idea.
>>
>>
>>Evaristo
>>
>>Gizmo homepage: http://www.crosswinds.net/~evaristo
>>
>>
>>
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com
- Simplifying group communications
Home