Alt-BEAM Archive
Message #05142
To: beam@sgiblab.sgi.com
From: Bob Shannon bshannon@tiac.net
Date: Thu, 08 Jul 1999 18:55:16 -0400
Subject: [alt-beam] Re: Something funny with the 1382 voltage triggers?
Steven Bolt wrote:
> > The idea that the 1381 SE is not good 'in this application' is highly
> > dependant on the specifics of the application.
> ---8<---
>
> As you are finding out, and is causing you considerable
> frustration, judging by your postings. The 1381 is difficult to
> obtain but otherwise great.
Wrong again Steven. My fusteration comes from people who assume
they know whats going on, and dont. They would rather find the circuit
design to be at fault (ignoring the many working versions) and address
anything
but the subject of the thread.
This circuit is proven to operate reliably with (measured) identical
component
values. Something different starts to happen when SMT parts are used
however.
And thats the point of the thread.
We can assume that this is only due to tolerance issues, but the imperical
facts
point in a different direction.
I heard today that SOT23 transistors are not made from the same dies used
for the
TO92 packages, due to bonding wire attachement issues. It seems that they
are not quite the same
parts. I'll be hooking up sets of TO92 and SOT23 transistors to a Fairchild
dual curve
tracer this weekend and seeing exactly what these differences may actually
be.
Please remember that this thread is intended to be about the differences
between SMT
and conventional parts rather than the flaws in the circuit.
BTW, the full sun lockup problem is effected by the total capacitance.
Replace the 6,600
uf cap bank with 4,700 uf, and there seems to be no problem.
Raising the resistor values from 1.8K to 2.7K made the full sun lockup (with
the full 6,600 uf)
less frequent, but it still happens. I'm working up to higher values
carefully while noting any
effects on the emitter to collector voltage drop on the NPN transistor. (I
had though it was
fixed at 2.7K because the failure rate dropped quite a bit)
> The 2-transistor latch/driver is not,
> except when delivered in a package with the right motor and solar
> panel. The motor must suck lots of current at half a volt, the
> panel must supply very little current even in full sunlight. So
> using a better motor or a larger panel gets you in trouble.
No, not at all. I have built several photovores with the very same
component values
without having the full sun lockup problem until I intoduced SMT parts into
the equation.
Other builders have reported this same effect. The closest problem I've
read of is the
problem with the magbot kit from Solarbotics you posted recently. But not
knowing the
circuit parameters in that case, I'm not going to assume anything just yet.
> Even just about `correct' motors tend to help the latch/driver
> oscillate, which it is all too happy doing (and obviously shouldn't).
I've only ever seen the oscillations with one type of motor, and they were
easily eliminated.
> The very large difference between the switch-on and switch-off
> voltages - typically a factor four - just can't fit many
> applications, as motors like their supply a bit more constant or
> they won't be efficient. Even the rapid start/stop needs of most
> photovores aren't served well by more than a factor two.
Perhaps the BEAM community should rethink the 'rapid start/stop needs' of a
photovore.
Rapid starts and stops waste energy, and have no place in an efficient
design.
> Of course there are exceptions, like a SolaRoller which should run
> its entire race on one charge, and certainly shouldn't use its
> motor as a brake. Even there you might want to do something
> different, as 0.7V may be too *high* as switch-off level...
If your motor stops about 0.7 volts, then you sure dont want to leave the
latch on in
a solar roller application, or you will be using the motor as a break!
The motor will free wheel when its open circuited, it will have resistance
proportional to
the cap voltage while the latch is on, and the capacitor voltage is below
the operating point
for the motor.
> > Its not good engineering practice to make that choice without
> > knowing all the design parameters.
>
> So your design is working perfectly? Must have misread your postings.
Well now, that depends on the package types I use. With thru-hole parts,
yes, its
working perfectly. How much clearer can I make this?
> But anything you do with
> that 2-transistor latch/driver can be done better with other
> circuitry, as you seem to be finding out, judging by your previous
> postings.
Hmmm. Well, why does it work perfectly with thru-hole parts then?
I looked at lots of SE circuits, and lots of ways to shuttle energy between
suspension
system components. If you say I can do better with something different,
please point
the way, and I'll test it.
I've tried to introduce this full sun lockup problem by lowing the resistor
value on my
thru-hole version of the circuit. So far, I have not suceeded in doing so
without using
parts values very far removed from those in the problematic SMT SE's.
> Earlier, you had much to say about advancing BEAM, if
> memory serves; so why are you now so wedded to the first and worst
> part of the BEAM circuit book? Very odd, methinks.
Well, simply because I took the time to look for the best combination of
circuits, components
and mechanical design for my application.
Also I've had more luck advancing BEAM by extending the photopopper design
than I have
had trying to measure implex in a microcore.
> > The details of the application can become very important when you
> > design for maximum practical efficiency rather than theorectical
> > efficiency.
>
> If there is a serious discrepancy, then your theory can't be much
> good, can it? Storing energy in suspension springs is clever, but
> surely not beyond theory.
Of your theory is based on incorrect/incomplete assumptions.
> > This we should leave as a matter of opinion. I think more people
> > learn from the more popular SE's than they do from the 'better'
> > ones.
>
> I bow to your superior knowledge, and hope you enjoy that
> `superior' circuitry...
Did you notice I never claimed it was superior? I claimed that its a better
match
for my application than other published SE's. Lets keep this reasonable
please.
> > > Can you do better? Sure. Separate latch and driver. Then make sure
> > > that your latch switches off properly (at well above 0.7V), or use a
> > > monostable instead of a latch; that's more appropriate for most SE
> > > applications.
> >
> > Ok, prove it. Show me the numbers.
>
> It's a matter of reliably working with diverse motors and solar
> panels, as your are finding out.
Wrong again!
We are dealing with the same solar cell, same capacitors, and same motors.
Please re-read the thread and subject line.
> > How many centimeters per minute, under what lighting, and over what
> > obstacles?
>
> A SolaRoller race, or anything like that, will be decided by the
> quality of the motor, the mechanical parts and the solar panel,
> with the electronics coming in as a distant fifth.
Se lets set them as constants, or set competition criteria like sollar
roller matches.
> > Or maybe my photovore can simply drag yours backwards faster than
> > yours can go forwards?
>
> Yeah, right. Photovore Sumo. Could be a good contest idea!
> But the outcome is still decided mostly by the parts you didn't
> design or make - motor and solar panel.
See above.
> > Lets test this directly. I have little interest in arguing the
> > point, but I am very keen to test it emperically, maybe we can
> > all learn something new here.
>
> Like what? I'm arguing in favour of properly designed, described
> and explained circuitry, to make BEAM a better learning experience.
> You're turning it into a "who can find or buy the best motors"
> contest. Can be fun, but it's a different topic.
No, I'm trying to learn what the difference in circuit operation is!
You seem to be trying anything and everything else but this.
------------------------------------------------------------------------
eGroups.com home: http://www.egroups.com/group/alt-beam
http://www.egroups.com
- Simplifying group communications
Home