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 ----- From: "Robert Rolf" To: Sent: Thursday, June 24, 2004 5:17 PM Subject: Re: [EE:] Analog signaling. TDM, PWM > "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 ----- > > From: "Bob Ammerman" > > To: > > Sent: Thursday, June 24, 2004 3:48 PM > > Subject: Re: [EE:] Analog signaling > > > > > 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: > > > > > > > > > 0 <--- pointer value > > > data for PIC1 (0 or more bytes) > > > data for PIC2 > > > data for PIC3 > > > . > > > . > > > data for PICn > > > > > > > > > > > > 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. > > And because of the way the data gets passed around, you have > 100 bytes in the pipe at a time (rxbuf & txbuf). > > If you really want to be 'analog' why not do TDM (time division > multiplex) using analog multiplexers? With a 1 ms sample time > you can do 1000 channels/second. If you need more channels, > raise the mux rate to 10k or 100k or as high as your wire > will allow. Reserve an 'illegal' voltage (minus full scale) as > the 'trigger' for resetting the counter to zero, and phase lock > your demux clock to the voltage changes (differentiate the signal > to get spikes between channels). > This 'sync' pulse could also be used to compensate for bus > loading (AGC) as it's amplitude changed. > > Each slave could be 'analog' with a sample and hold driven > by a varying monostable delay after sync. > > You could even send back sensor info in time slices allocated > for that purpose. > > Or you could just do what the R/C guys do. PWM (easy to convert > to analog with an integrator & S&H) with each channel given > a time slice after the previous channel's falling edge. > e.g. a finite dead time followed by a variable width pulse > that encodes the signal. > > Robert > > -- > 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