Hi Bruce, > I wish to take 8 digital channels and multiplex them > down one fiber optic cable, and demux them back into > 8 channels. The fastest changing signal is around > 0.1 milliseconds. > > My first response to this is to use a PIC to convert > the digital inputs into some sort of serial bit stream, > and do the reverse on the other end. > > Is this a viable method, or are there chips on the market > which do the above? Should I use something like an UART? > If a PIC is a good way, any data formatting ideas? I have a ready PIC design and code that could be licenced to do what you want. It can multiplex 8 RS232 signals over a single pair of fibres, each signal at 19k2 (4 times over sampled at 76800 times per second) and also sends 8 slower handshake signals so one can do hardware handshaking on printers and other devices. The design has been in use and is very cost effective in terms of components and complexity. An added advantage is a fibre fault indication to show when the quality of the fibre connection is compromised. I call or mail me if you are interested. What sort of volumes was your run projected at. Todd, > You might take a look at our EDE300 IC. You would use two; they will talk > to each other and get the 8 digital lines from one place to another > serially. The only problem I forsee is that the (stock) EDE300's run at > 9600 BAUD; we could however make a higher speed version for you if need be. > > An Acrobat PDF datasheet can be downloaded from our web site at > http://www.netins.net/showcase/elab in the 'Integrated Circuits' section, > or contact me for a printed copy. I had a look at your Web page, interesting stuff, I think I will send you some Email to discuss some stuff. Perhaps you would like to add some High speed repeater ICs to your range.... Bob, > I think it is time for a sanity check here. First of all, does > the last sentence above imply that you expect to update each channel > every 100 microseconds? Let's see .. 8 bits every 100 microcseconds > is 12.5 microseconds/bit or 80kb/s. And this is just for one channel > and assumes only 8 bit resolution. Add in some identification bits > (three minimum) and the other channels and you are near > 1 microsecond/bit. With a 20mHz PIC this is only 5 instructions. > It would seem that at a minimum a UART will be needed. The UART will > have to run at 1mb/s. Will your communications channel handle this? My design updates each high speed channel every 13 us. It did take a bit of thought to get it to work reasonably but the beauty is that it required no external ICs (excluding the RS-232 line drivers) to implement the mux functioning. I won't pretend that there is any spare CPU bandwidth to do anything else but that was not required. Your calculations are pretty good. The need was for a digital link so one only needs to send only one bit per channel for each sampling period. The PIC works well as a UART (or any other single function) but getting it to do many things is much harder. Speeds beyond what my design does are not possible without external Hardware and the new wider (32 channel) mux designs have been implemented with FPGAs, the cost does go up and the FPGAs cannot drive the fibre devices directly and the pin input protection is weak compared to what the PIC has to offer so there is more added cost. As far as the communications channel coping with the speed, 1 Mb/s is no great shakes for fibre drivers. Once you get past the sensitive (typically plastic fibre) devices that cope upto about 10 .. 200 kb/s the next range of devices work about 5 .. 30 Mb/s and you can even go further to 100 .. 155 Mb/s in devices suitable for FDDI use and then over 600Mb/s but these are already hard to develope at home so 20 MHz over fibre is a comfotable limit. Bruce, > No sanity check needed here - updates only need occur when other end > has changed. It is no need to constantly re-send the same channel > configuration if nothing has changed. You are correct here but it makes for a somewhat non-deterministic sampling interval which does add jitter to the recovered data. If you know the form of the data and you know the changes to be sparse and that there will be a limited number of simultaneous changes then this method works well. For asynchronous serial data that you want to recreate faithfully you do not gain a lot as the update packet size is still large in proportion to the bandwidth available unless you use variable packet sizes for multi updates and such. For sparse data or if you have a lot of channes to update over a link that could not support continuous multiplexing or even if you wanted to do other stuff at the same time then it does make sense. > I do agree that the data rates are very high, however, this > should be achieveable. It is, works a treat. Cheers -- Kalle Pihlajasaari kalle@ip.co.za http://www.ip.co.za/ip Interface Products P O Box 15775, DOORNFONTEIN, 2028, South Africa + 27 (11) 402-7750 Fax: 402-7751 http://www.ip.co.za/people/kalle DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer