Alt-BEAM Archive
Message #12701
To: "'beam@sgiblab.sgi.com'" beam@sgiblab.sgi.com
From: Wilf Rigter Wilf.Rigter@powertech.bc.ca
Date: Wed, 29 Mar 2000 07:35:13 -0800
Subject: [alt-beam] Re: SIMD1/LEDPump Problems
The problem is the way you combined the LEDpump and the SIMD1. First, the
SIMD1 is different from the D1 in a fundamental way. The D1 turns off
everything connected to it while charging but the SIMD1 simply provides a
logic output that must be used to disable other parts of the circuit ie the
LEDpump during charging. I assume that you use a 2 stage Nv loop driving the
voltage doubler so you can use a diode from the output of the detector stage
to kill the oscillator just like the PNC circuit.
The LEDpump is designed to operate LEDs from supplies below their normal
turn-on voltage, so the blue LED is fine since it needs 5V to operate but
you should put 2 or 3 red LEDs in series to avoid them turning on
continuously.
Lett me know if that helps
wilf
> -----Original Message-----
> From: Dye, Roy [SMTP:rdye@logicaldimensions.com]
> Sent: Wednesday, March 29, 2000 5:45 AM
> To: beam@sgiblab.sgi.com
> Subject: SIMD1/LEDPump Problems
>
> I am working with Wilf's SIMD1/LEDPump circuit and having a few problems.
> I
> was under the impression that this circuit charges all day and blinks a
> LED
> all night. However, my breadboarded circuit flashes the LED while it
> charges and only lasts about a half hour in the dark (with about an hour
> charge). I don't think it would make it all night.
>
> To get the LED to flash longer in the dark, I decided to replace the blue
> LED with a high efficiency red LED. Now, the LED stays on steady when the
> cap voltage is above 2.4v.
>
> I am using a high output solar cell 3766 (5.5V&30ma), a coin type 1F super
> cap, and 1N4148 diodes for the SIMD1.
>
> I am not sure if these problems are due to my substitutions, or, I have
> some
> type of a wiring problem.
>
> Has anyone else built this circuit?
>
> Roy
12702 Wed, 29 Mar 2000 10:33:01 EST [alt-beam] Re: SIMD1/LEDPump Problems beam@sgiblab.sgi.com JVernonM@aol.com In a message dated 3/29/00 8:55:35 AM Eastern Standard Time,
rdye@logicaldimensions.com writes:
> I am not sure if these problems are due to my substitutions, or, I have some
> type of a wiring problem.
You definitely have a wiring problem. What you have now has been termed a
pochmark. The LED is simply working directly off of the solar cell with the
cap acting as a delay buffer. Recheck your connections.
See ya,
Jim
http://www.geocities.com/SoHo/Exhibit/8281/beamart.html
ICQ# 55657870
12703 Thu, 30 Mar 2000 04:25:44 +1200 [alt-beam] "Electric nerve" designs beam@corp.sgi.com Justin
--Boundary_(ID_kYLrmqzUN1XvbDylcqB5LA)
content-transfer-encoding: quoted-printable
x-mime-autoconverted: from 8bit to quoted-printable by pneumatic-tube.sgi.com id IAA04629
Unlike insect feelers (or your arm), which is sensitive to touch along
the entire length, BEAM feelers tend to use the universal switch, thus
require large amounts of force and movement to activate, even
interfering with the robot motion, or else are more sensitive but can be
triggered by momentum from the bot=92s own motion. I=92ve been playing with
simple ways to enable a feeler to react to the faintest touch anywhere
along the length - to act as a nerve, rather than as a switch activated
by mechanical force, and while I suspect what I=92ve come up with may
quite possibly be "old hat", I haven=92t seen them used elsewhere and they
work well on the breadboard, so I thought I=92d share them. (And at least
one of these is at the heart of a device I hope to enter in the
Innovative Machines section of the Robot Games :-)
As you can see, I=92ve provided a basic circuit for two "electric nerve"
systems, but you=92ll really want to customise them to the application -
the circuits here are more of a demonstration of principle and lacking
some of the refinements I=92ve yet to finish developing :-)
For a low-tech solution, I was quite surprised at how effective the
ground trigger is - set it up right and the slightest contact with any
object will trigger it, and leave a nice delay before the charge wears
off. It seems to have the potential to be a genuinely universal nerve. I
haven=92t tried it in a bot yet, but I suspect that construction and
grounding issues will be very important if it=92s going to be reliable! =
Another idea I haven=92t played with is detecting a minute change in
capacitance of a feeler or section of the robot. As I don=92t know how you
sense a change in capacitance, and can=92t be bothered finding out, I=92ll
leave that one to you guys. I don=92t know what other people think, but I
really don=92t like problems caused by the universal switch feelers, and
would think an "electric nerve" solution is well worth pursuing.
--Boundary_(ID_kYLrmqzUN1XvbDylcqB5LA)
Attachment: nerves.gif
--Boundary_(ID_kYLrmqzUN1XvbDylcqB5LA)--
12704 Thu, 30 Mar 2000 04:49:27 +1200 [alt-beam] Re: "Electric nerve" designs beam@corp.sgi.com Justin Forgot to mention - before adding the "Ground trigger" to an actual
robot, with the exposed pin some order of static ZAP protection would
probably be a good idea (or perhaps an IC socket so you just
quick-change the 240 after an "accident"=85 :-))
Any suggestions?
12705 Wed, 29 Mar 2000 12:32:44 -0800 [alt-beam] Re: "Electric nerve" designs "Dennison Bertram" That looks like a pretty nice design, on your circuit where it say's, "to
robot" how exactly does it connect to your control circuitry? What sort o=
f
output does it produce also? I'm looking at it, and I'm supposing that
changes in the 'ground trigger' will alter the resistance across the
transistor, anyway Looks nice! It does remind me of something called the
"captiflector" which has been 'big news' or something like that. It
basically detects objects and their proximity by measuring the changes in
the capacitence of the air around it. Pretty cool, I really like your
contact sensor though, that's a really neat implementation of a touch
sensor.
dennison
Forgot to mention - before adding the "Ground trigger" to an actual
robot, with the exposed pin some order of static ZAP protection would
probably be a good idea (or perhaps an IC socket so you just
quick-change the 240 after an "accident"=85 :-))
Any suggestions?
Home