Searching \ for '[EE:] Analog signaling' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/io/atod.htm?key=analog
Search entire site for: 'Analog signaling'.

Exact match. Not showing close matches.
'[EE:] Analog signaling'
2004\06\24@144838 by

I recently had an idea (probably ages old) for the transmission of data on a
continual basis using analog voltages, and would like to get some criticisms
on it before I get too deep into trying to make it work.  The basic idea is
to use frequency-dependent filters to determine the amplitude of some analog
signal at a given frequency.  Perhaps the best way to explain the idea is
with an example:

Example:  Take a robot with 40 separate actuator "muscles".  For now just
consider the actuation control and disregard the feedback mechanisms. To
establish real-time control of 40 actuators on a digital link would not be
impossible, but would perhaps restrict expandability, etc.  So we assign
each "muscle" a control frequency based around a signal amplitude.  Muscle 1
gets 20khz, 10vpp centered on 0v.  To move it from neutral, the amplitude of
the 20khz signal drops to say 5vpp or rises to 15vpp.  The actuators are
tuned to listen on a specific frequency, which is then smoothed to a
relatively DC voltage.  All 40 actuators are installed as said, at perhaps
22khz, 24khz, ... and so on (no calcs yet, but assume there is enough
bandwidth), each with an independent filter to see what component of its
tuned control frequency is present.  So now to control all 40 actuators at
once it would (only?) be necessary to sum 40 separate control signals into
one analog signal, and inject that to the backbone where each actuator will
single out its respective command.

The apparent advantage of this method (to me) would be the increased amount
of data transfer on a single wire, with the primary disadvantage being
somewhat imprecise control all around.

The way I would envision it working is having a powerful processor to
generate the analog stream, and multiple PICS spread around the network to
read the filtered frequency and do the actuator control, then perhaps
eventually "capturing" analog streams to memory for replaying, for example,
a walking routine for a humanoid robot.

Is there any major problem I'm overlooking in a network like this?  It seems
pretty sound to me, but I'd really like to get some expert opinions, or
maybe advice from someone experienced with a similar network.  If it looks
feasible I very well may be turning it into an "open hardware" project for
robotic control, but I'd hate to take it that far and have a miserable
failure!

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

In my opinion there would be allot of problems with cross modulation,
filters tend to be bulky and hard to get accurate filtering with expense.

At the end of the day what is wrong with a single wire protocol as discussed
in another thread were each device has individual address and all devises

*************************************************
Roy Hopkins   :-)

Tauranga
New Zealand
*************************************************

{Original Message removed}
The point is not that it would be better, but if could it be made to work.
I know a serial interface would work, but for some reason the idea of doing
it semi-analog seems like it would be super-expandable and possibly very
effective.  Imagine scaling it to hundreds of actuator / filter combos and a
serial protocol becomes very complicated.  Summing analog signals is no big
deal though, so it would just be a matter of adding a new sum-point for the
main control signal.  Also it could be used perhaps more effectively in
controlling time-domain type movements.  All speculation so far, but I'm
pretty excited thinking about how it could work.  Plus I absolutely despise
multi-device serial comms :-)

{Original Message removed}
Robert,

Some of the obvious issues that I see are:

1.  Intermodulation causing false signals.  Channel 1 and channel 6 mix
to create a false signal on channel 31.  Touch tone phone frequencies
were VERY carefully selected to avoid this problem.

2.  No real immunity to network (call it resistive but, it doesn't have
of the signals will probably drop a little causing all actuators to skew
in one direction.  Difficult to sense this loading at the controller or
to compensate for its effect at various points along the network.

3.  As described, the system is open loop with no mechanism for sensors
to feedback information to the controller.

4.  Limited control bandwidth.  Spacing between control frequencies
limits the rate at which you can change signal amplitude without

5.  All channels consume signalling power (and bandwidth) continuously
(whether it's needed or not).

6.  Difficult (not impossible) to manufacture a system with say, 40
independent, nearly brickwall bandpass filters at very specific
frequencies.  You'll probably start using digital filtering techniques
long before you get to 40 channels.

7.  All systems drive through the stops in one direction if transmit
power is lost at the controller.

There are appropriate places for such a signalling scheme.  One that I
know of uses two different audio tones, transmitted on the same carrier
frequency, by two different high gain antennas pointed in slightly
different directions.  A device which wants to follow a path between the
two transmission lobes just servos to maintain the same amplitude
between the two audio tones.  The pilots on the list will know what I'm

Before I started looking at actually building a signalling system like
you've described, I'd take a good hard look at CAN bus or, for one way
communication, look at some of the PCM systems that are used in model
aircraft control.

Best regards,

Dave

Robert B. wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Yeah, all that complicated analog signaling is bound to cause trouble.

Here is an idea I just had (based on the serial 'Token Ring' stuff that was
on the list in the last few days).

The hardware:

Each unit contains a PIC controller. The UARTs are wired in a ring with the
master controller:

TX of the master goes to RX of PIC1
TX of PIC1 goes to RX of PIC2
TX of PIC2 goes to RX of PIC3
......
TX of PICn goes to RX of the master

The master sends packets of the format:

<start marker>
0 <--- pointer value
data for PIC1 (0 or more bytes)
data for PIC2
data for PIC3
.
.
data for PICn
<end marker>
<crc>

The 'data for PICn' is an area reserved in the packet for a specific PIC. On
receipt, this area contains the incoming data to the PIC, on transmission it
contains information to be reported back to the host. The area needs to be
max(incomingsize,outgoingsize) bytes long.

Each PIC, as it receives the packet, does the following things to it:

1: Increments the pointer value by the number of bytes it needs
2: Extracts its data from the packet as it flies by.
3: Replaces its data received from the host with its response to the host
4: Checks the CRC. If it is valid then it accepts the input bytes, otherwise
it ignores them.
5: If the incoming CRC is valid then output a new valid CRC, otherwise
deliberately 'smudge' the CRC to force it to be bad.

Note that the PIC sends the packet out as quickly as it receives it. It does
not buffer the entire packet in RAM.

When the packet gets back to the host, all the responses are there and ready
to process.

Now, to check performance:

Assume 50 pics, with an average of 2 bytes of data each. This gives a packet
size of about 110 bytes, counting overhead. At 19,200 baud that packet can
be sent about 17 times per second.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Thanks for the thought-provoking response, but I see that perhaps I didn't
explain my intentions as well as I thought I did.

(inlined below)

{Original Message removed}
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}
What you are describing sounds like the frequency division multiplexing
amplitude on the designated frequency it was an actual communications
channel.  This system was a hold-over from the early 70's (I served in the
90's) and it took up a full sized rack to fit all 25 or so modules in
because it used entirely analog components.  It was always in need of tuning
and all of us techs were happy when it was replaced with newer digital
modems.  Of course, it did work reasonably well despite everything.

If you want to try and implement a new version of this I would recommend
spending a lot of time getting the frequency management digitally controlled
and use digital filtering for each receiver unit.  This would make it much
easier to control and maintain without all the drift the analog approach
inherently adds.  Maybe using a digital pot to run a vcxo?  I know the Navy
has a lot of its technical documents online and they would be a good source
for this.  You will have to search for it because I dont remember where I
have seen them.

This may not be too many answers but it may point you in the right direction
at least.  Having said all this I tend to use rs-485 systems myself.

Regards,
Andy

_________________________________________________________________
MSN Toolbar provides one-click access to Hotmail from any Web page   FREE

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Robert B. wrote:

>>1.  Intermodulation causing false signals.  Channel 1 and channel 6 mix
>>to create a false signal on channel 31.  Touch tone phone frequencies
>>were VERY carefully selected to avoid this problem.
>>
>>
>This is a very valid concern, but it could probably be worked around with
>some effort.  But hey, they cram 40 channels into a standard CB radio (AM
>modulated, right?), so I'd like to think some of these problems have already
>been solved in the RF fields, and could be worked around.
>
>
Sort of.  While the CB radio uses amplitude modulation, it also uses AGC
which would effectively destroy the type of control that you were trying
to achieve.

{Quote hidden}

I don't know what you have in mind for transmission medium (coax,
twisted pair?).  You can certainly maintain a stiff source.  I don't
know how precise your control would need to be.  Presumably it would
vary with actuator.

>>3.  As described, the system is open loop with no mechanism for sensors
>>to feedback information to the controller.
>>
>>
>I didn't describe any feedback system yet (see note in original post)
>
Agreed.  I was just mentioning it for completeness (and to add a little
weight to my later plug for a CAN bus solution (should  we maybe change
the topic tag to PIC?).

{Quote hidden}

True.

{Quote hidden}

Actually, it was cost that I was trying to address here.

>>7.  All systems drive through the stops in one direction if transmit
>>power is lost at the controller.
>>
>>
>Since the controllers would respond to the RMS signal, 0v would just return
>everything to a neutral state.  In the event of controller failure it would
>probably be catastrophic regardless without some sort of backup signal
>generator.  Essentially the same thing that would happen if your brain
>suddenly quit sending signals. :-)
>
My brain stops sending signals all the time, just ask my wife.  :-)

"Muscle 1 gets 20khz, 10vpp centered on 0v.  To move it from neutral, the amplitude of the 20khz signal drops to say 5vpp or rises to 15vpp."

it sounds like the actuator is centered or neutral at an input signal
amplitude of 10Vp-p (for example), extends or servos to a new position
(again, for example) at an input signal amplitude of 15Vp-p and
contracts with a 5Vp-p signal.  If the input signal at the actuator
drops to 0Vp-p, as would occur if the controller stops sending then the
system servos to a super contracted state (on all channels!).

Most of the digital signalling systems that I'm aware of either hold the
last commanded position or go into some kind of pre-programmed sequence.

>>Before I started looking at actually building a signalling system like
>>you've described, I'd take a good hard look at CAN bus or, for one way
>>communication, look at some of the PCM systems that are used in model
>>aircraft control.
>>
I'll plug again now for a CAN bus solution.  It's relatively (compared
to a 40 channel analog solution) inexpensive, fairly fault tolerant,
allows two way communication, allows lots of channels blah blah blah.
Did I mention that it's a simple effective alternative to analog
signalling systems?  :-)

Best regards,

Dave

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

David Minkler wrote:
<snip>

> My brain stops sending signals all the time, just ask my wife.  :-)
>
>
> "Muscle 1 gets 20khz, 10vpp centered on 0v.  To move it from neutral, the
amplitude of the 20khz signal drops to say 5vpp or rises to 15vpp."
{Quote hidden}

<snip>

Yeah it was an error in the initial description.  Whoops! You are correct, I
guess I'd have to rectify the signal before smoothing, or else it would
always cancel to 0v for a symmetric sine wave centered about 0v.  So then
for a rectified 0v indeed it would swing to one extreme, as you stated.
Hows that for a graceful failure mode? :>

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> 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...

That is what the CRC is about.

Bob Ammerman
RAm Systems

>
> {Original Message removed}

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