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 ----- From: "Hopkins" To: Sent: Thursday, June 24, 2004 3:17 PM Subject: Re: [EE:] Analog signaling > 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 > respond to a broadcast address - all return to neutral. > > ************************************************* > Roy Hopkins :-) > > Tauranga > New Zealand > ************************************************* > > ----- Original Message ----- > From: "Robert B." > To: > Sent: Friday, June 25, 2004 6:48 AM > Subject: [EE:] Analog signaling > > > > 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 > > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.710 / Virus Database: 466 - Release Date: 23/06/2004 > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu