F8 and a GPS -
Bill Davidsen
davidsen at tmr.com
Wed Jul 2 19:45:58 UTC 2008
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.
--
Bill Davidsen <davidsen at tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
More information about the fedora-list
mailing list