"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