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