Alt-BEAM Archive

Message #09759



To: "'beam@sgiblab.sgi.com'" beam@sgiblab.sgi.com
From: Wilf Rigter Wilf.Rigter@powertech.bc.ca
Date: Thu, 3 Feb 2000 23:58:04 -0800
Subject: [alt-beam] Re: wilf


Yes. Blue LEDs like the Panasonic LNG992 need something like 4V to light up
but you may only have 2.5V or 3V on the cap. So the LEDPUMP driver "pumps"
the charge on the small (47-100uf) cap through the LED which produces a blue
flash.

wilf

> -----Original Message-----
> From: Bumper314@aol.com [SMTP:Bumper314@aol.com]
> Sent: Thursday, February 03, 2000 11:34 PM
> To: beam@sgiblab.sgi.com
> Subject: Re: wilf
>
> In a message dated 2/4/00 12:27:26 AM Mountain Standard Time,
> Wilf.Rigter@powertech.bc.ca writes:
>
> > The LEDPUMP is just a method of driving a LED when the power supply is
> lower
> > than the minimum forward voltage of the LED. Say you want to power a
> > circuit from a single 1.5V battery and you want to turn on some LEDs to
>
> show
> > it's doing something. Too bad, because the LED needs 1.6V to light up,
> so
> > what you gonna do? Use the LED pump, cause that way the LED will light
> up
> > even if the battery is right down at 1V. Running a bicore off solar and
>
> need
> > some LEDs to light up all the way down to 1V? Use the LEDPUMP. So the
> > LEDPUMP is really a general purpose solution for driving LEDs from low
> > volts. That's all folks!
>
> Right, so I want to make a blue LED run off a 1F cap that I let charge up
> all
> day. So would I put the inputs of this LED pump in place of the LED on the
>
> SIMD1 to get same power saving features of having a regular LED in there,
> but
> just being able to drive a much more thirsty load?
>
> Steve



9760 Fri, 4 Feb 2000 03:08:23 EST [alt-beam] Re: wilf beam@sgiblab.sgi.com Bumper314@aol.com In a message dated 2/4/00 12:58:13 AM Mountain Standard Time,=20
Wilf.Rigter@powertech.bc.ca writes:

> Yes. Blue LEDs like the Panasonic LNG992 need something like 4V to light u=
p
> but you may only have 2.5V or 3V on the cap. So the LEDPUMP driver "pumps=
"
> the charge on the small (47-100uf) cap through the LED which produces a=20
blue
> flash.=20

So I'm going to need two ICs just to run one blue LED, I guess thats not bad=
,=20
but should I remove the 47=B5f cap that would come before the LED on the SIM=
D1=20
since the full range LED pump produces a blink of its own?

Steve



9761 Fri, 4 Feb 2000 00:47:08 -0800 [alt-beam] Re: The 240 microcore - was Bicore question "'beam@sgiblab.sgi.com'" Wilf Rigter Sorry bout the rollercoaster. Can't stuff pulses? We are talking
about open ended chains or branches mind. Me thinks that as long as the time
between processes is longer than the longest process, they cannot collide
destructively. That means that the maximum number of processes in a chain of
is equal to the sum of all Nv pulsewidths divided by the longest Nv
pulsewidth, divided by 2. Of course, we were just talking about simple
nervous Nv neurons which are "resettable" when active ( regardless of the
output state, the input state will change the output) but those could be
easily modified (one diode) to become super Nv neurons which can be
retriggered but cannot be reset (bulk up with incoming pulses) or Nvs that
once triggered, don't give a hoot about the input (non retriggerable, non-
resettable) until they time out (black hole for colliding pulses).

regards

wilf

> -----Original Message-----
> From: Dennison Bertram [SMTP:dibst11+@pitt.edu]
> Sent: Thursday, February 03, 2000 11:14 PM
> To: beam@sgiblab.sgi.com
> Subject: RE: The 240 microcore - was RE: Bicore question
>
>
>
> Here is a little thought experiment: [Wilf Rigter] yada,yada
>
> It's far to late for me to read all of this, :-) And I'm delerius from the
> rollercoaster that person-life-problems bring. But anyway, by coincidence,
> in the patent, or living machines, you can't really 'stuff' pulses. They
> would act much like the 'rollercoaster' point in a closed loop. The output
> of a neuron has less importance than the input, and regardless of the
> output
> state, the input state will change the output. So it will simply, eject
> the
> pulse. And if there is a whole string of uneven pulses around, they will
> each just eject each other till they all fall out. Not really stuffing,
> just
> sort of 'hyper-accelerating'. Anyway, that ends my experiment in thought.
>
> :-)
> dennison
>
>
>
> Is each process still independent or do they interact? Like a microcore
> ring,
> I'm sure the Nv chain can be "saturated" when the maximum duration of any
> Nv
> pulse in the chain is dictated by the shortest process. To inject
> processes
> into the chain, the first Nv can be "stimulated" with a beam flip-flop
> triggered with a pushbutton. That way you can manually control the input
> pulse widths to see the effect it has on process generation and
> propagation.
> Longer chains of n Nv should be capable of maximum n/2 processes but no
> more
> before saturating. A bottom up tree-like Nv structure would see a process
> propagate down the trunk before radiating along the branches. Kind of
> interesting stuff if you plan to control a complex sequence of motor
> motions
> for example in a multi-jointed beam worm. What about a top down tree with
> processes propagating down the branches toward the central neural chain
> (trunk). Add some logic such that two processes must be counted or be
> present at a junction where branches meet before processes can propagate
> any
> further. With only one Nv triggered ie by a sound or light "event", the
> process may die at the nearest junction but with many Nvs triggered,
> processes join up at junctions and can reach major branches or the central
> neural chain to activate some action ie fire a motor neuron.. How about
> some
> memory (Nu) at the junctions so that the junction remembers the last
> process
> and "sensitizes" the junction to lower the propagation threshold. How
> about
> bottom-up and top-down Nv trees connected at each end in a branched but
> closed loop structure like the circulatory system.
>
> Well that's the nature of a thought experiment, ideas happen, propagate
> off
> in different directions until one or more hit fertile ground and then you
> gotta built and test it.
>
> regards
>
> wilf
>
>
> > -----Original Message-----
> > From: Senior [SMTP:kyled@cruzers.com]
> > Sent: Wednesday, February 02, 2000 3:36 PM
> > To: beam@sgiblab.sgi.com
> > Subject: Re: The 240 microcore - was RE: Bicore question
> >
> > Hey Wilf... ;)
> > I've got the opposite problem:
> > No '240's,
> > Excess of '14's.
> > How bout a 14 bicore? PSH? :)
> >
> > Laters,
> > kyle
> >
> > SG wrote:
> > >
> > > WOOWW !



9762 Fri, 4 Feb 2000 14:28:28 +0100 [alt-beam] Peculiarity on Ant and PM1 "Beam Mailing List" "Thomas Pilgaard" Hi all,

I've noticed something about the beam ant / PM1 I'm building, I hope someone
can enlighten me on this. I just don't get it.

When connected to a 5V battery my breadboarded ant cirquit is very
respondant to light and changes in the light and both motors whizz away
happily all along. However, and I find this !very! odd, when connected to
the PM1 SE it seems that the ant cirquit is only responding to !changes! in
the light. That is, if the lightsource is constant in both intensity and
location the cirquit remains 'silent'. At the moment I move the lightsource
or turn it off, the ant cirquit responds by whizzing away.

Can anyone tell me why this is the case?

I've tried to cover the solarcell without influencing the IR sensors to see
if that would have any effect, but it didn't seem to.

I am baffled.

Thanks in advance,

Thomas

---
"You haven't had enough coffee until you can thread a moving sewing
machine."

Home