Signal Reflections on a Bus with Connectors and Long Cables
JRetSapDoog
Posts: 954
Final Update: 74HC245 bus transceivers appear to have resolved the problem, the problem likely being due to reflections from the long stubs involved. For the final resolution, see post #25 and post #27. I'm considering the problem solved for now and marking the thread as such. Thanks for your helpful comments, suggestions and links.
I'm out of my element here and could use a few clues. And even if the problem can't be solved, perhaps I can understand it better with your input/experience. In the nutshell, I believe I'm experiencing glitches due to reflections caused by connectors and somewhat long cable runs, though maybe other factors are at play. Although I've done a lot of reading on the topic as a result of the problem, it's something I've never dealt with before.
I am using a single-sided circuit board to send data signals (and three control signals) to 4 connectors downstream from a Propeller on the same circuit board, wherein the connectors are progressively further away from the Propeller. That is, the connectors are all on one linear bus, not arranged in a star arrangement (though perhaps the latter would be more consistent or fair). Consequently, the first connector is closest (has the shortest signal path), and the last connector is farthermost (has the longest signal path).
Additionally, from the connectors, 20cm ribbon-like cables extend to separate PCB's (one for each connector), wherein one set of signals from any one cable directly drives inputs of a CMOS chip (no signals are intentionally going back to the Propeller PCB).
One of the control signals is a Chip Select signal; however, at this time, I'm asserting all of the Chip Select lines (active low) at the same time in the same way, as if all the Chip Select lines were tied low. At this point, I just want the SAME data to be received by all of the devices.
Now, if I connect only a SINGLE device (call the devices A, B, C & D, with device A being the nearest), that device will work fine, regardless of which position. If, however, I connect exactly two devices, they sometimes both receive the data correctly but sometimes not (the six possible combinations being AB, AC, AD, BC, BD and CD). With more devices, things get progressively worse for all devices. For example, with three devices attached, all or most of the data might get through to one device at best.
The connector that exhibits the worst performance overall is the one closest to the propeller, which, while closest physically, would have the longest signal path for any reflections coming back. I tried to take a look at the signals on a 160MHz scope, but it was hard for me to tell what was going on. It did seem like the low-time for signals was shorter and more rounded with more devices and/or cables attached.
Do you think the problem I'm experiencing is mostly due to reflections? Could other things be involved? I don't know the impedance of the bus or how to calculate it. I think it would be a bear to calculate due to the signals propagating through the tracks on the single-sided PCB I made, then through the connectors on that PCB, then through the cables, then through connectors on the PCB's for the devices (with very short signal tracks on those boards).
I can't readily change the cable length or the device circuit boards on the far ends. From reading, it doesn't appear to me that a double-sided circuit board would really help and might even hurt (your input is welcome). I did try adding inline 23 Ohm resistors (just a guess based on reading) on the Propeller end before the first connector, but the results didn't seem to change. I haven't tried any resistors in parallel or combinations of series/parallel resistors.
If I had an MCU with more pins (Hello, Prop 2!), I could individually drive each device, which I think should work based on the fact that single-device setups are working. However, I believe this problem is related to frequency and I guess things would only get worse as the frequency went higher. I've used 2 Propellers working together in another project, but this particular project doesn't divide up nicely across a pair of Propellers.
I wonder if I could redesign my PCB to improve matters. Would a star-arrangement for the bus help or hurt? Also, are there any kind of chips that I could place before the connectors on my PCB to condition the signals or reduce reflections? I've ordered some tri-state 74HC244's (octal buffer/line driver) and 74HC245's (octal bus transceivers). I'm not sure if these could help or which would be best. Would it be better to try another chip?
I've searched a lot for similar problems online, but I'm interested in what you folks think, and perhaps your comments could be useful for others. Any comments are welcome/appreciated. I'm not sure if I'll tackle a redesign right away or consider moving to a multi-processor design or chip with more pins. But your comments might help me make that decision. Thanks. --Jim
Update: The following simplified figure shows the overall layout. Sorry for not providing this at the get-go a few days back. The Prop and 4 connectors (CON X) are on a PCB, which has a bus with data lines and some control signals. Then, four 20-cm FPC cables (CAB X) extend from the connectors on the Prop-based board to four device boards (DEV X). Essentially, the arrangement involved four stubs, highly frowned upon in the comments that follow, but that's the situation and it's pretty difficult to change. Moreover, the device boards and the FPC cables are not really subject to change (other than shorter cables could be used if the Prop were physically closer, which it isn't).
I'm out of my element here and could use a few clues. And even if the problem can't be solved, perhaps I can understand it better with your input/experience. In the nutshell, I believe I'm experiencing glitches due to reflections caused by connectors and somewhat long cable runs, though maybe other factors are at play. Although I've done a lot of reading on the topic as a result of the problem, it's something I've never dealt with before.
I am using a single-sided circuit board to send data signals (and three control signals) to 4 connectors downstream from a Propeller on the same circuit board, wherein the connectors are progressively further away from the Propeller. That is, the connectors are all on one linear bus, not arranged in a star arrangement (though perhaps the latter would be more consistent or fair). Consequently, the first connector is closest (has the shortest signal path), and the last connector is farthermost (has the longest signal path).
Additionally, from the connectors, 20cm ribbon-like cables extend to separate PCB's (one for each connector), wherein one set of signals from any one cable directly drives inputs of a CMOS chip (no signals are intentionally going back to the Propeller PCB).
One of the control signals is a Chip Select signal; however, at this time, I'm asserting all of the Chip Select lines (active low) at the same time in the same way, as if all the Chip Select lines were tied low. At this point, I just want the SAME data to be received by all of the devices.
Now, if I connect only a SINGLE device (call the devices A, B, C & D, with device A being the nearest), that device will work fine, regardless of which position. If, however, I connect exactly two devices, they sometimes both receive the data correctly but sometimes not (the six possible combinations being AB, AC, AD, BC, BD and CD). With more devices, things get progressively worse for all devices. For example, with three devices attached, all or most of the data might get through to one device at best.
The connector that exhibits the worst performance overall is the one closest to the propeller, which, while closest physically, would have the longest signal path for any reflections coming back. I tried to take a look at the signals on a 160MHz scope, but it was hard for me to tell what was going on. It did seem like the low-time for signals was shorter and more rounded with more devices and/or cables attached.
Do you think the problem I'm experiencing is mostly due to reflections? Could other things be involved? I don't know the impedance of the bus or how to calculate it. I think it would be a bear to calculate due to the signals propagating through the tracks on the single-sided PCB I made, then through the connectors on that PCB, then through the cables, then through connectors on the PCB's for the devices (with very short signal tracks on those boards).
I can't readily change the cable length or the device circuit boards on the far ends. From reading, it doesn't appear to me that a double-sided circuit board would really help and might even hurt (your input is welcome). I did try adding inline 23 Ohm resistors (just a guess based on reading) on the Propeller end before the first connector, but the results didn't seem to change. I haven't tried any resistors in parallel or combinations of series/parallel resistors.
If I had an MCU with more pins (Hello, Prop 2!), I could individually drive each device, which I think should work based on the fact that single-device setups are working. However, I believe this problem is related to frequency and I guess things would only get worse as the frequency went higher. I've used 2 Propellers working together in another project, but this particular project doesn't divide up nicely across a pair of Propellers.
I wonder if I could redesign my PCB to improve matters. Would a star-arrangement for the bus help or hurt? Also, are there any kind of chips that I could place before the connectors on my PCB to condition the signals or reduce reflections? I've ordered some tri-state 74HC244's (octal buffer/line driver) and 74HC245's (octal bus transceivers). I'm not sure if these could help or which would be best. Would it be better to try another chip?
I've searched a lot for similar problems online, but I'm interested in what you folks think, and perhaps your comments could be useful for others. Any comments are welcome/appreciated. I'm not sure if I'll tackle a redesign right away or consider moving to a multi-processor design or chip with more pins. But your comments might help me make that decision. Thanks. --Jim
Update: The following simplified figure shows the overall layout. Sorry for not providing this at the get-go a few days back. The Prop and 4 connectors (CON X) are on a PCB, which has a bus with data lines and some control signals. Then, four 20-cm FPC cables (CAB X) extend from the connectors on the Prop-based board to four device boards (DEV X). Essentially, the arrangement involved four stubs, highly frowned upon in the comments that follow, but that's the situation and it's pretty difficult to change. Moreover, the device boards and the FPC cables are not really subject to change (other than shorter cables could be used if the Prop were physically closer, which it isn't).
400 x 330 - 10K
Comments
From what I understand, reflections can be more of a problem when a harmonic length is reached. Most of the tutorial material about these problems are written in feeding power to an antenna.
And does your network have any stubs? These add problems.
imo Connectors should be a loss issue, not a reflection issue.
http://www.s100computers.com/My%20System%20Pages/Terminator%20Board/Bus%20Terminator%20Board.htm
It did send me off on a(nother) tangent because I noticed that if the Prop was cold(ish) or if cooled by isopropyl spray, the SD would run.
PS For the expense of that S100 board I would have hoped for pristine pulses !!!
For a pc board bus 220 or 330 ohm resistors were commonly used. Not sure what is needed for ribbon cable but 220 or 330 ohms would be a good starting point. Unfortunately the propeller may not be able to drive such a load so you may have to buffer each cable. Since you do not need a bidirectional bus the '244 would work. If you are using a PASM program to drive the bus the HC chips may not be fast enough. Use HCT or AHC chips instead.
An alternative to running individual ribbon cables to each board would be to use a single cable with a connector for each board and termination resistors at the end.
Reference:
https://en.wikipedia.org/wiki/Transmission_line
...since the P2P uses bi-directional communication over the lines, a derivative of the reference above is implemented.
It is important to note that "Zs" in combination with "ZL" form a voltage divider where the voltage MUST be above the I/O threshold.
In the case of the P2P I decided to use 100 Ohm resistors for "Zs" and 330 Ohm resistors for "ZL". The effective resistor divider is...
100 165 Signal >---/\/\--o--/\/\---> GND | o---------> Vout Note: The value of 165 is two 330 Ohm resistors in Parallel taken from each end of the transmission line. Where Vout is 2.05 Volts when the signal voltage is 3.3VNormally Zs is a value of the internal resistance, in this case however, by forcing it to be at least 100 Ohms, it provides collision protection on the signal line if both ends happen to transmitt at the same time and do not agree with one another.
Jim, you can try Beau's solution of putting in 330 ohm resistor on each cable to ground and see if that solve your problem.
If it does then you have what I call impedance mismatch on your cable between the 2 prop. By force matching your cable
you eliminate your reflection our line.
Hope that helps.
I had a similar problem many years ago serially driving a cmos led chip with 35 led's attached.
It worked great with six inches of cable but would not work with the required seven feet.
Eventually,- more in hope and frustration than anything else, I inserted a 100 ohm resistor into the data line at source. It worked fine ever after.
Also, include a 0 volt with each connector to the remote boards as a signal common, don't rely on the power common alone.
Can you slow down the data stream by inserting nops between data hi's and lo's and chip select, or different combinations.
Dave
Last weel I came across an ancient PCB that had Z80 bits and a whole bunch of 4116 dynamic rams. I was so taken back to my youth that the other guy had to walk over to me and bring me back to the 21 century.
@ tritonium
Which bit of Bristol? I used to be up at Filton.
Sorry about not supplying the data rate (I was in a real hurry when I posted and knew I'd be away awhile). I calculate and estimate (as oppose to measure) that the data rate is on the order of 1 to 2Mbits per second per line, probably closer to 2Mbps. So, I suppose it's really not that high (a lot less than Beau's max). Nevertheless, with connectors introducing line discontinuities and the long cable runs, I appear to have run into trouble. Yes, for this application, I can slow down the data rate, and I may try that to try to learn more about what's going on. The driver is using PASM and, as suggested, I could insert some dummy ops or whatever to slow it down and see if that helps, though I won't be able to change the rise time. But ultimately, I don't want to slow things down and, if possible, would even like to speed things up (though we'll see). And what if I was using a Prop 2 that could signal ~10X faster!
Unfortunately, I can't really shorten the cables (~20cm in length) or get the devices all on the same bus without the long cable "stubs" (?) I am currently using, as the end devices are spread out and there are partitions blocking the way (from "daisy-chaining" them). Although this project is under my control (very loosely speaking), it doesn't lend itself to changing the cabling, at least not without a major redesign (such as using a separate Prop to drive each device). I do appreciate that it's not an ideal situation/design, though.
From your suggestions, it sounds like I should give it another go with resistors to see if I can get lucky matching the impedance or otherwise conditioning things. However, a big problem is that the boards on the other ends of the cables (away from the Prop board) are not my boards and can't really be modified. I'd have to interpose another board between them and the cables to apply resistors on those far ends, which would introduce two more connectors and another PCB (per device!) and I'm afraid that might cause more problems than it solves (just too many discontinuities and also complexity). If I was in dire straits or a mission critical situation, perhaps I'd have no choice, but I'm hoping to find a simpler solution. Nevertheless, I might play with the resistor values or configurations and see if that helps (though limiting myself to doing so on only the source end will limit the effectiveness or flexibility a lot, I guess).
If possible, I'd like to find a robust approach, though such doesn't necessarily lend itself to a simple design. I'll probably draw up another circuit board using line buffers to see if they help. For all I know, they may just pass reflections on through, though I'm hoping they tend to isolate things somewhat on both sides (though, or course, the desired signals must still get through). Although I ordered the 74HC244 and 245 parts, I'm leaning towards trying the 245 ones because they have inputs and outputs on opposite sides, which will likely make things easier to layout. Or maybe I'll add a second prop and dispense with the drivers, I haven't really decided yet.
If I do make any progress using resistors or buffers/drivers, I'll update this thread, as it might be useful for others. Thanks for all the help and for the links (I visited them all, even if some of the details were over my head). Meanwhile, other comments or shared experiences are always welcome, of course. Thanks again!
Kingswood
I spent many hours at Filton house during the Concord days keeping the telex machines running.
Had a 'close encounter' with the Vulcan test-bed when crossing the runway to the met-office in a mini-van...
The first computer club I attended was run at the Bristol Uni- top of St Michaels Hill (eons ago) - that's when I found out what a stepping motor was and acquired my first a/d converter a '427. I drove it using a neat little circuit from 'electronic design' (or something like that - a free industry magazine)
Memory lane.....
Dave
Dropping the clock speed until you get stability would at least confirm the problem. If you can't get stability... well, it could be something else.
I am not sure that this is so much impedance matching as it is absorbing reflections at each end of the line by adding the resistors to load them.
AT the far end, where you cannot modify the target boards, you may insert good termination on a board of your own and have driver chips repeat the signals in both directions. There would be a bit of a delay inserted, but likely not critical. In fact, these chips might actually clean up the signal a bit if you use Schotky devices.
While the S100 backplane was terminated with resistors to knock down reflections, I believe that a lot of the boards that were inserted did go through such driver chips to assure better signal quality. These are 8 bit parallel devices that can be ganged to 32 bit if you need to do so.
return wire next to it (meaning a fairly well behaved transmission line impedance). If every second wire then you reduce
cross-talk substantially too.
For longer runs you want differential signalling over twisted pairs... 20cm isn't super long though.
-- how many conductors?
-- alternating ground and signal/control?
-- power also delivered on the cable?
-- devices at the end, are they edge clocked or level clocked or ...?
-- devices at the end, are they externally powered or otherwise connected (ground loops)?
At 1 or 2 MHz, 20cm is nowhere near 1/4 wavelength. However, a 12.5ns clock pulse would start to feel the reflection delay, estimate 5ns per meter on a ribbon cable. Clocked logic can be picky about multiple clock edges that come from reflections. That's why I asked about how the boards are clocked. On the other hand, clocked logic can be picky about too-slow clock edges that might come from loading down a clock line with multiple devices.
You can get ribbon cable ferrite clamps that attenuate high frequency hash, e.g. this:
http://www.cablesdirect.com/prodimages/SCSIU3S-1T_LR.jpg
The above cable also has an added 'terminator connector' to make inserting of the terminator network easier. That might fill the bill.
Can you tell us the following
A. How many bits of parallel data you are trying to include?
B. Does your ribbon cable already avoid crosstalk by providing alternated ground and data lines?
Due to the short length, it seems like 'passive termination' in the form of resistors may be all that is required.. but at both ends. Of course, it may be worth trying just one end first as no actual harm may be done. And having done so and demonstrated the need to do the other end, you other user may allow it. The modifications can be done cleanly and easily removed... with the right solution.
SCSI cables (with 50 or more wires) have managed to provide both 'passive and active termination' into the connectors at the end of ribbon cables. So it just might be worth exploring using these devices inserted with appropriate adaptors.
With a simple ribbon cable and data buses in 8, 16, 24, or 32 bit width, the Single-in-Line resistor packs that have 9 pins will make construction of the grounded side very easy in byte sized chunks.... not a lot of individual resistors. Sometimes you see these directly attached to where the cable connector pokes out the other side of a circuit board and a jumper wire to ground added.
And there are 8x DIP parallel resistor networks for the in series load (Those would be the 100 ohm resistors).
I made a mistake and mentioned Schottky devices when I meant Schmitt trigger logic. But I really really feel that you might best resolve this with an 'all resistor solution' and not look to adding bus drivers unless they are obviously required.
http://www.thenetworkencyclopedia.com/d2.asp?ref=1948
https://en.wikipedia.org/wiki/Electrical_termination
Schematics of the old S-100 back plane are useful, but the example provided in an above post was active, not passive.
And there is quite a bit of discussion in the context of SCSI that may be helpful.
But all models are pretty much based foremost of what one or two wires require.
Searching for Backplane may provide good information about how to resolve design.
https://en.wikipedia.org/wiki/Backplane
@Loopy, fellow Ex-pat in TWN: dropping the bitrate is on my "to-do" list; as you say, I might learn something from that. At the far end, I'm really hoping to avoid interposing another board (with connectors) per device. I (at least partially) get the need for it, reflection-wise, but there's little room for something like that and, if this case, would be inelegant enough to cause me to pursue a total redesign. I do think I'll try driver chips on the Prop-end, though, to see if it helps. I've made two attempts at redesigning the board using a star-configured bus on the Prop board, but I'm not happy with it so far (my thinking was to keep the signal paths to each connector approximately the same length and that perhaps a star-configuration might isolate things more, which is probably just wishful thinking and it could even hurt. If I can't come up with a good star-based board layout with a manageable number of jumpers, I'll go back to a "linear" bus topology but with the drivers this time. Thanks for your continuing input.
@Mark: I see what you mean about interposing grounds to help with crosstalk (and maybe other things). Unfortunately, as with the device boards on the four ends, the cables are basically out of my control as the cables are designed to match the connectors on those boards (see below for more details about those cables).
@Peter: You're right that it's hard to offer help without pics/schematics and I'll add that it's of dubious judgment to seek such without those. Apologies for that. A day or so prior to posting, I did draw up a block diagram to show the overall board/connector/cable layout, but I wasn't satisfied with it. Then, realizing that I'd be away for a day, I quickly posted thinking I'd check for any responses when I got back. But obviously responders can give more specific comments with clearer information. Perhaps I'll finish a simple drawing, as understanding this particular system layout calls for it more than most, though I must say that I think an earlier comment about this being about the worst possible layout is true (though I don't know of any way around it). I'll spare you the thousand words for the missing pic, but, basically, picture a Prop-based board in the middle, with 4 connectors, then cables extend from those four connectors to 4 device boards with connectors. The Prop board supplies power for those 4 device boards through the cables. If a device board is plugged in, then it's on/running (no on/off switches) providing the Prop-based board is powered up. On the Prop-based board, I routed thick, separate power lines back to a common point to feed each of those device boards.
Now here's an *** important clarification *** (and apologies for any earlier ambiguity), during testing, it was not the case that all device boards were connected (plugged in) at the same time. When I plugged exactly one device board in (the board along with its cable, I mean), that board would work regardless of which connector on the Prop-based board it was plugged into. But as I tried to plug in additional device boards, the data received by them would get progressively more corrupted. Sometimes, I was lucky enough to get two device boards to work well, but not often. I never got three device boards working well, though one or two of them might have been okay. And for four device boards plugged in at the same time, at best, only one of the device board would work well. Again, the device board plugged into the connector on the Prop-based board closest to the Prop suffered the worst, which might make sense as it has the longest total path for any signals reflecting back from OTHER cables (even though it's closest to the Prop). Also, another *** important point *** easily missed in my long first post, I've got all the Chip Select lines connected together to one Prop pin, and so I'm simply trying to send the SAME data to all device boards. I'm not trying to individually target them at this point (as I often do want them to receive the same data and don't want to send it multiple times). The PASM driver will have to be modified to target them individually, anyway, and I haven't done that yet. For now, I'd be happy to reliably send the same data to each of the four device boards at the same time, kind of a step-by-step approach.
@Tracy: Regarding my so-called "ribbon-like cables, yep, you got me! Actually, they are not ribbon cables (though I did use some in the past with a different set-up). They are FPC (flex/flexible PCB cables), with around 3 dozens signal lines (I'm not using them all, nor do I have any control over the signal assignment). If I recall correctly, the conductors (and connector pins) are spaced 0.5mm apart, so they're pretty small. I actually use small adapter boards on the Prop-board to convert to 0.1" (254mm) connectors, and that's another reason why I don't want to interpose any more boards/cables on the far ends as there are enough impedance changes (I guess) already. Ultimately, I might be able to get rid of the 0.1" connectors, though, plugging the cables directly in to the Prop-based board, but that's for future development.
About the signals, around half of them are data signals. Presently, there are many unused signals (due to functionality that I don't require, at least at this time). I'm not using a clock signal, per se. Data is simply latched in "at will/on demand" on the rising edge of a Write line after it has gone low for a short while. Regarding power, there are separate analog and digital power lines in the cable, which I've tried to route separately for each of the four connectors, or mostly so (though I may have compromised the ground a bit), on the Prop-based board. I'm glad that you think I'm well under the 1/4 wavelength length for my cables (and traces). However, even though I don't use a clock, per se, the rising edge of the Write line would seem to be pretty critical, and I'm worried that reflections may be causing havoc there. That concerns me so much that I'm not even sure it's worth trying to compensate for with resistors, and if separate buffers/drivers at each connector on the Prop-based board would work, then that's the route I'd go (unless the Prop had more pins). But, again, I'm not sure how much they will help. Need to try I guess. I am running at 80MHz (12.5ns instructions), but the Write low time spans a few instructions, so it's not that fast. I am worried about the rise-time when the Write line goes high. Your comment about "loading down the clock (or in my case Write) line with multiple devices" is interesting. I guess that's a different problem than reflections and crosstalk, though perhaps I'm experiencing a little of all of them. For this project, data is sent to the device boards at a couple different rates (the throughput for various operations), depending on the situation, and I have noticed that it is the data being sent at the faster of the two rate that tends to get the most corrupted (it's kind of a night-and-day difference, in fact). By the way, the ferrite clamp is interesting and not so expensive (don't know if I have room for it (though maybe I could make room) but good to know about).
Thanks again, everyone, for your useful/interesting comments, including DRAC, Toby, kwinn, Beau, Reyp2000 and tritonium, even though I lumped you all together in my first reply. If/when I learn anything more or try anything different, I'll post an update. And further comments are always welcome.
About the cable, it's actually a FPC, and between every two data lines (I'm using 8 in total) there is another signal (or ground or no-connection line) interposed. The analog and digital power and ground lines are widely separated and are not adjacent to the data/control lines. Incidentally, these cable are basically out of my control, unless I elect to interpose more boards on the far ends prior to the device boards, something that I don't plan on at this point (though never say "never," except for in this saying). You think my cable length is short? Yeah, I suppose 20cm is not super long, but I've got 4 separate 20cm-cables extending from the Prop-based board, and perhaps therein lies the problem. Thanks for the links! I wish my setup was more like the backplane of a PC motherboard where the device PCB's plug directly into the backplane. However, unfortunately, such is not the case, as I have 20-cm cables going from the connectors on the Prop-based PCB to the device boards. I don't know if one would call those "stubs" or what, but they seem pretty undesirable. Anyway, that's the setup.
About the buffer/drivers I'm contemplating using, I guess I wish they had Schmitt triggers in them or similar to possible resist triggering so easily, but I don't think that they do. As I recall, I ordered TI and NXP parts. Anyway, perhaps they'll still help.
Thanks again for your further comments posted late afternoon our time.
If you need to feed a signal into several places, route the signal in and then back out to continue on without splitting it. These inputs should be high-z with only the last connection having the load resistor.
Don't do this... | | | | | | -----+-----+----- Do this... | | +--+--+ +--+--+ | | | | -----+ +-----+ +-----Bean
Check out his other tutorials too. They are good.
Bean
Are you sure the program is meeting the setup and hold times, that is, the data is stable long enough both before and after the rising edge of Write? Give it an extra instruction cycle or two before changing the data. Adding devices can easily skew marginal timing into the no-fly zone. An issue of loading the shared signal/control lines.
Some devices are sensitive to the rise time of the Clock or Write edge. Rise time per se is a separate issue from setup/hold times. It could be tested by adding a ~100pF of capacitance to the Write line and see if it affects the ability of the single device to receive data. Paradoxically, the rise time can be affected at both ends of the speed spectrum. At the low end by capacitive loading, at the high end by ns excitation causing a signal to take a staircase or oscillating time course rather than one clean edge, on a mismatched line.
@Bean, nice find!
But you need to figure out which DOs and DON'Ts apply and commit to the right cabling for the job.
If you have 4 devices that you want on a terminated line, eliminate stubs at all costs.. even if the cable is a bit longer. Stubs can get tricky if not kept extremely short.
So I guess you really need to get the right ribbon cable and a good solid connector selected.
~~~
So you are saying that just one of any boards does work and works well with what you have. It is only when you insert more that communications fall apart. That is an important starting point.
@ Tracy: Thanks for your comments encouraging me to think beyond the obvious possibilities like reflections and so. It is indeed the case here in the forum that the problem turns out to be things other than what the original poster had speculated. Therefore, I double-checked things. I'm pretty sure the timing is okay, as the CMOS chip on the device end has pretty good specs. The minimum total data time (prep and hold) is about 5ns (1/10 of a Prop Op), and the minimum total time for an entire write operation, including the time to "rest" before the next one, is on the order of 100ns (a couple of Prop Ops). I'm writing far slower than that, as many Prop instructions are needed to setup a write operation. Also, in the few cases where there are back-to-back OUTA (or DIRA) instructions, the minimum prep and hold times are observed by several fold. Nevertheless, it was worth double-checking such things and helped solidify my understanding. Thanks for your comments about some chips being sensitive to fluctuations during the rise-time window (around a 1/2ns max in this case). I am worried about that, whether such fluctuations are due to loading or reflections or whatever. Your idea of loading (pardon if that's the wrong word) the Write line as a troubleshooting means is really clever. I might try that, especially since it's only one line. I even have another PCB on hand that just drives one end device, so I could experiment on it as well as the problematic board. Anyway, I would have never considered that, nor have known (or known how to calculate) what value to insert. By the way, I'm not sure what "ns excitation" means (perhaps just (sub) nanosecond variations), but I see what you mean about the desire to have a uni-directional rise transition rather than one that wanders up and down. Anyway, thanks again for your input, and despite the above-mentioned double-checking, I'll try to keep an open mind for other problem sources (even hard-to find loose connections and poor solder joints can masquerade as other things).
@ Loopy: I think you're right about the stubs being problematic, or as you aptly put it "tricky." I'd like to eliminate them, but this particular project doesn't easily allow that, as the devices attached to the stubs are basically out of my control and the required FPC cables add difficulty as well. And, as I've mentioned earlier, there's no straightforward way to put them all on one longer cable or backplane. Currently, my first strategy is to find a way to make a single "centralized" driver board work, either by using buffers/drivers/etc. or by adding a second Prop or switching to an MCU with more pins. If that fails, I could always use separate driver boards (each with its own MCU) to separately drive each device (but then I'd have to coordinate the MCU's). Regarding your last comment about communication falling apart only after connecting a second or third device, yes, that is exactly the current situation.
Thanks again, everyone, for the comments. You've given me several things to test/try or think about, as well as some good links. For now, I think I'll go ahead with drawing up another board with line buffers/drivers. If I build that and learn anything from it, I'll be sure to post. Also, for now, I'm operating under the assumption that the stubs are the main problem (though I'll keep my eyes open for other factors).
It can be done, but it is a lot of maths and you might get better advice from an expert ham radio operator that enjoys impedance matching of complex transmission lines.
Still, I think you would need passive termination at each end.
And it would be far better to have every other wire be grounded to prevent cross talk.
Crosstalk may be killing this as much as reflection. The day of the ribbon cable is nearly gone. Parallel is considired useful for chip interiors and multilayer motherboards that do all the work to deal with standing wavelength reflections including bus termination.
You FPC devices are really just intended for conviienent assembly of short runs and one-to-one links, not as the backbone of a backplane or distributed bus.
~~
Another option is to have each device cable out and convert all these parallel signals into a serial packet system with full duplex. Then have your card receive and breakdown the serial.
You can get extremely high baud rates via RS422 or even direct TTL serial and not have such complex wiring issues.
You may have noticed that SCSI has been overtaken by SATA serial and FireWire, and that old parallel printer cords have evolve in to serial USB cords.
The industry just realized it was far easier to transmit serial for any distance at extreme high speed than it ever would be to network in parallel over any sort of ribbon cable. Even your hard disk only dared to have two devices on a ribbon cable, not 4.
In sum, innovate and adapt to use newer solutions.
If you can't go to serial, have yet another Propeller buffer and distribute on a star network. You have already determined that one-to-one parallel communication is feasible. The junk comes from when you try to build a party line.
You seem to be saying that just one additional card brings the system down. You would at least have to solve that configuration to get to the possiblity of all 4.
~~~~~~~~~~~~~~~~~~~
And if you cannot figure out a star network with a control hub arbitrating communication, just make enough duplicate Propeller boards that communicate 1 to 1 and use the existing serial port on pins 31 and 30 each of those to oversee and pass data back and forth from each individual Propeller board that is in touch with one one device. The serial could go all to individual Windows in a laptop in Linux as you can easily have 4 separate USB to serial ports open in 4 separate Windows simultaneously.
In other words, use your existing board design to feed serial into a laptop PC and have that be your communications hub. It has more speed and versatility.
With reference to a voltage buffer, Wikipedia says, "The interposed buffer amplifier prevents the second circuit from loading the first circuit unacceptably and interfering with its desired operation." I'm guessing buffers also help in my case with reflections, too, because I think that they might prevent reflections on the 20cm-long cables from entering the bus of the Prop-based PCB (maybe). The bus transceivers only work in one direction at a time, as selected by the direction pin (I'm not currently using the tri-state feature). Moreover, I'm just using the transceivers to send signals out onto the cables plugged into the connectors on the Prop-based board (no data is coming back, so the direction control is permanently set). Incidentally, I presently don't have any passive termination of the bus on the Prop-based board (or elsewhere), though I may add that later. However, the total trace length for that bus is "only" about 43cm (17 inches), so, hopefully, it isn't needed at the speed at which the signals are being sent (I'm not counting the cables as part of the bus because, hopefully, the buffers isolate them in terms of reflections/loading, and they are no longer "shared" or directly connected to the bus).
So far, I haven't detected any glitches in the three devices that are working. I'm not sure why the remaining device is not working, but will be looking into it. I'm encouraged, though, because the problem device is basically not working at all, rather than receiving corrupted data (the latter being the problem with the prior board), which hopefully implies that I'm doing something different with it compared to the other three devices. However, the device that is not working is always the device that is plugged into the first connector that is closest to the Prop. So, it is "special" in that way and would see the longest path for any reflected signals on the PCB. But I'm hopeful that such reflections aren't significant and that the reason for the problem is something else, such as a circuit error, bad connection, programming error, bad Prop pin (perish the thought!) or similar (or maybe I damaged a bus transceiver during handling/soldering). Anyway, I've been burning the midnight oil 'til dawn to get this far, so I'll look into that further at another time.
Thanks again for everyone's comments. They really helped me to think more clearly about the problem and gave me more confidence to proceed. I now better understand the difference between a hobbyist and a qualified technician/engineer.
And your comment about FPC cables being intended for short runs is quite valid. That's always been a concern of mine for the boards I'm using. In fact, they come bundled with shorter flex cables, but I ordered longer ones online (I've seen FPC cables in excess of 30cm, for example). But just because longer cables are available, doesn't mean that they are suitable for a particular device. But I tried them and they seem to be okay (when being individually driven). I'm just learning as I go, here. But generally speaking, I think you're totally right about FPC cables (after all, they often connect high-speed, high-functionality devices that might be intolerant of longer cables).
About your suggestion to use separate Props to drive each board, I might go that way when it's all said and done. But, for now, I want(ed) to keep things relatively simple. I also wanted to learn whether buffers could help in the situation I was facing. And unless I've just lucked out with the new board (due to differing routing, signal lengths, capacitance, etc.), they seem to have helped (I'll be more confident of that if I can get the remaining device board working). Anyway, there certainly are many ways to skin a cat and you're right to remind me to not get tunnel-vision and locked in to one solution (I've actually experimented with three totally different solutions in working on this particular project).
Thanks again for the in-depth information and the alternatives that you suggested. I've kind of got some constraints that have taken me down the path I'm on, but it's always good to consider alternative and to realize what trade-offs one is making.
Whether the problem with the prior board was due to reflections or loading or a combination of them (or something else), I can't say for sure. My suspicion is that reflections due to the long stubs were the main culprit (which seems to be the general opinion in the comments). Still, perhaps loading was a factor more than I realize and maybe I can experiment to pin that down. But, for now, I'm just glad that it's working.
I've really never dealt with busses and long cables before; its been interesting. Thanks to everyone who responded and to Parallax for this forum (and for the Propeller, of course)! --Jim