>>> 3. Scrambled: many high-bit characters >> is a given character either always corrupted or never corrupted? > I appreciate the help, Mouse. Unfortunately, the answer is No. :-(
Oh well, it was a nice theory while it lasted. :/ >> s\000\332ow\000LX\000\000\264\233\000\000n\000\000\262 = 9600\015 > ConLock = Enabled\015 > ConMute = Disabled\015 > [...rest of output looks good...] > \015 > Note that the first letters of the output from the "show" command -- > "Speed", I think -- are garbled. After that it's clear. The "h" in > "show" is ruined, but OK in "ShowPCI". This looks to me as though output is corrupted in the presence of input occurring at the same time. Does the speed with which you type "show" matter? For example, if you do it manually versus pasting it, does it affect the syndrome? Looking at the bit patterns from what you quote, there are some tantalizing similarities between what you got and what should be there, but I haven't formed a coherent theory for them. While it's a very vague feeling, this feels to me like a ground bounce issue or some such. If you have a 'scope, I'd be inclined to put it across power and see what you get. Another thing that might be worth scoping out is the difference between shield ground and signal ground. It also might be worth trying shorting the Soekris's ground to the other computer's ground with a separate wire - the Soekris's power supply probably provides reasonably good isolation from mains ground, whereas most desktops deliberately earth the case and many power supplies also earth the 0V line as well. I'm thinking the difference between desktop<->desktop and desktop<->Soekris could be that the desktops have a fairly low-impedance path between their grounds because they're both connected to mains earth. Of course, it could also be that something's fried in the serial port circuitry, too, though I have trouble thinking of a plausible fault that would produce perfectly clear output when no input is occurring. Perhaps one of the power rails isn't reaching the serial chip, and, provided the input pin is at mark, it powers the chip through the protection diodes? I actually had something similar occur in a circuit I'd built; it could lead to corruption of output only when input is also occurring - and, because it's affecting the output driver and nothing else, explains the "input characters work" part. Looking at "show"'s bits, I note... s 01110011 h 01101000 o 01101111 w 01110111 ...that the three characters that worked have a lot of 1 bits (the same voltage level as an idle line), and that the characters that got corrupted occurred when characters with relatively long periods of 0s (h, \n, and/or \r) were being sent, or had recently been sent. (I'm assuming the "show" was manually typed, so there's substantial delay between the h and the o.) If you have some way to generate output over a significant time, do you get clear output with nothing but signal ground and the Soekris->desktop data line connected (in particular, no desktop-driven lines connected)? Do you have any other desktop-driven lines which are driven to the same level as an idle data line connected? (I realize that some/all of these may not be easy for you to test....) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ Soekris-tech mailing list [email protected] http://lists.soekris.com/mailman/listinfo/soekris-tech
