On Wed, 2008-07-02 at 15:45 -0400, Bill Davidsen wrote: > Gene Heskett wrote: > > On Wednesday 02 July 2008, Mikkel L. Ellertson wrote: > >> Gene Heskett wrote: > >>> My old Garmin 12 (yeah, it has gray hair) has a very dumb serial > >>> interface, so I have to use an adapter to make it usb. > >>> > >>> And there are no intermittent connection problems? > >>> > >>> Maybe Prolific has quietly fixed that bug in later issues. Mine are 5 or > >>> 6 years old, one I got from the shack, and another I got from Wallies a > >>> year or so later. Both of them have been problems. I tried to use one to > >>> connect to a ups, but every time it dropped the connection, the ups > >>> monitor initiated a shut down about a second later. Several times a day. > >>> That, and glancing over at the roadnav screen while in western Iowa, and > >>> noted it showing me in downtown Indianapolis IN for 30 seconds just got to > >>> be too much. I moved one of them to the heyu circuit, that gave heyu a > >>> tummy ache & it would segfault & die. I asked Charles on the heyu list & > >>> he said I wasn't the only one having trouble with pl2303's, and he was > >>> telling folks to go get the FTDI devices as they seemed to Just Work(TM), > >>> and they have, very well, as have the Atmel silicon in a pair of extension > >>> cables I use. > >> By intermittent connection problems, do you mean that it would drop > >> characters? One problem I have run into is where the flow control > >> lines are not implemented. If the hardware and/or application are > >> set up to use hardware flow control, this can cause data loss. I > >> don't know if this is the case here. > >> > >> Mikkel > > > > In the case of roadnav, the serial speed is about 1/100th the usb speed, so > > there should not even be a need for flow controls. AFAT pl2303 is concerned, > > in my tests, trying to run a minicom terminal here, to a serial port on a > > TRS-80 Color Computer 3, (aka a coco3) running nitros9, using a 9600 baud > > connection rate, and Chuck Foresberg's rzsz to move files. With a pl2303 doing > > that adaptation, I could type by hand from either end and see it perfectly. > > Fire up a zmodem transfer, and the data got so scrambled that zmodem eventually > > gave up on a 12 byte file! The rz implementation on the coco3 actually > > checksums each character as rx'd into the total for a 128 byte packet, but this > > restricts the coco3 to about 700cps. > > > > I tried every flow control method, but with the coco3 acia chip only having a 1 > > byte buffer, and the coco3 was exerting the 7 wire protocol (with xon/xoff, > > control is too slow) that I could see on an rs232 sniffer was working, but the > > pl2303 was apparently ignoring. Conversely, a transfer from the coco3 to here > > got scrambled even though this box takes naps between bytes received. I could > > only come to the conclusion that the pl2303 was a $40 POS. Add in its poor > > showing with heyu, roadnav and 2 different UPS's and any reasoning person will > > reach the same conclusion. > > > > Now I've moved an FTDI adapter to that circuit, and while there are errors that > > make rz do resets & restarts on the larger files, it will eventually get the > > file moved with no errors in the file. I think those are because I don't have > > the 7 wire properly configured on the coco3, I believe it is here on this box > > although stty's nemonics nomenclature is a bit foreign to me & the manpage > > quite frankly, is all but worthless. A manpage should have demo cli examples > > for eol translations and for the two 'std' flow mechanisms in common use. No, > > instead it explains each option in excrutiating detail, taking up 4 or 5 pages, > > which is info overload IMO to me. > > > > Experts at rs232 protocols are, like me at 73, a dying breed, so there are few > > to ask about it in this world, and I might get 1 or 2 fingers used counting > > them in the coco3 world, very scarce and memories are fading. Since the coco3 > > & os9 (a mini unix) precede google by over a decade, googling is not the help > > it could be. > > > Shades of the old Telebit Trailblazer running the serial at 230400 bps > to keep compressed data flowing and using RTS when the data you were > sending didn't compress enough. > Check your grounding and isolation. Typically that is what causes the error. A well designed interface uses the supply wire to controll the voltage on the interface logic. If you are getting scrambled data, one or the other of the ports is probably not supplying the voltage for the interface. Or alternatively the ground may be broken at either end or in the cable. Losing the voltage will make one interface not pass valid data, losing the ground loses the reference to the receiver comparators, which will make them decode junk depending upon the transitions on the cable. Regards, Les H ANother OLD RS232 and other serial buss Factually Accurate but often Retarded Technician. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
