Searching \ for '[EE:] Analog signaling. TDM, PWM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/atod.htm?key=analog
Search entire site for: 'Analog signaling. TDM, PWM'.

Exact match. Not showing close matches.
PICList Thread
'[EE:] Analog signaling. TDM, PWM'
2004\06\24@172505 by Robert Rolf

picon face
"Robert B." wrote:
>
> Sounds like a way better idea than mine... cheaper too.  And avoids the
> analog circuitry.  Probably less subject to interference, too.  And its easy
> to implement.  One thing though, is how to handle errors? Have you thought
> about it any?  Maybe a checksum at the end could do some error checking...
>
> {Original Message removed}

2004\06\24@181107 by Robert B.

flavicon
face
TDM sounds like it would also work way better, but it sort of kills the main
idea of the analog system, in that the data is always there at all times, so
the uC could sample at will, as rarely or frequently as needed.  The idea
behind it is to transfer the actuator control to the uC's at the end of the
analog line.  Think about it as "modular" programming.  The "module"
actuator controller just gets a rough indication of what to do from the
analog line, so it distributes the processing power among many individual
units as opposed to a more powerful processor passing commands to each uC in
turn.  Forget firm "rules", what I've got in mind for the main analog
backbone is more like a guideline for the end actuator.  The machine's
current status could be described in several frequencies on the backbone as
well, which would help the end actuators interpret the received guidelines.
An example would be have an "urgency" state, which when elevated causes the
end actuator controllers to act faster or slower to match the situation.
The beauty of this system as I see it is that all the machine state
information would be available to every controller module, and it could just
pick and choose which bits it wanted to use.  Especially with digital
filtering this would become more realistic.

I'm probably way off the deep end again! :-D  Does anybody understand what
I'm getting at?


{Original Message removed}

2004\06\25@012637 by Robert Rolf

picon face
"Robert B." wrote:
{Quote hidden}

Yeah.
You're trying to make things WAY more complicated than they need to
be. K.I.S.S Keep It Simple Stupid.

Send a digital stream with your 'guideline' state commands and let
the uCs use whichever channel(s) they need to listen to get the
motion/position you want.
Send your 'state info' fast enough that latency and
the number of channels isn't an issue. e.g. 400k baud (I2C).

I work in neuroscience so I think I know where you're -trying- to go
with this.

When the brain makes a limb move, it doesn't concern itself with
the individual firing rates of thousands of individual nerve fibres.
It just issues a general 'contract this much' command down the
spinal cord and that firing rate appears on the main nerve for
a particular muscle, and a large group of fibers contract.
There is a parallel descending command to the golgi tendon organs,
and if a muscle doesn't contract as much as expected, the
golgi capsule gets stretched internally (internal muscle) and
generates additional pulses that get 'OR'd' in the spinal column
to supplement the descending command and make the muscle contract more.
This 'stretch reflex' is what doctors test when they tap your
knee tendon with the rubber mallet (various disease processes
affect this control loop).

There are also neurons in the spinal cord that divide up the
descending command based on limb position, and some which
generate the basic locomotion pattern.

And yes, this is a gross simplification, but it should be enough
to make my analogy.

Robert

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...