[aprssig] USB-Serial

[Dave Baxter]

Hi..
 
This has all been discussed ad nausium in the recent past (USB<>serial
etc)  Check the list archives, earlier this year....
 
In essence.  Yes some adapters are better than others, but it seems more
like the associated installable drivers are the problem, NOT the
operating system or the actual USB hardware.
 
It has been found as a result of many peoples experience on this list
and others, that sadly the popular Belkin devices are deficient in some
way.  I know from work experience of our software peeps, that they said
some products drivers did not implement all the needed API call's
correctly.  In one case the call to "Flush Buffers" did nothing, but
returned with an OK status.   The result?  Sulking attached devices
(industrial equipment) and befuddled software (the applications to use
said industrial devices)   The fix at the time, was to implement some
dummy reads to flush out the receive buffer, the Transmit buffer was
less of a problem for them, as the attached "Industrial device" was very
"hard" in it's protocol, so just doing multiple initialisation commands
(after flushing the receive buffer) was enough to get communication.
 
But, with our stuff, radios, TNC's and the like that are not so fussy,
random data from a uninitialised buffer can cause mayhem.
 
To be near 100% sure, choose USB<>serial adapters that have a MS
"certified for use with Windows" sticker, their drivers should have been
through MS's qualification process, at some expense, so those products
will not be at the low cost end of the market.
 
Otherwise, chose devices that use either the Prolific or FTDI chipsets.
Both have proven themselves to be good and reliable for many, the
drivers too!..  Not only that, but often if there is any problem with
the OEM drivers, the "Generic" chipset drivers will work just fine, for
free..
 
As to the spurious mouse traffic issue..  I can't lay my fingers on it
right now, but there is a simple way to tell Windows NOT to poll every
known serial device while looking for a mouse, but only examine one COM
port you specify.
 
The USB drivers when loaded, can also be "Fixed" so if you connect one
particular USB adapter device to one particular USB port of your PC, it
will always show up as the same COMx: each time.   You can actually be
quite creative with your port assignments with this....

You need to get to the device manager, find the virtual com port created
by the attached device and it's drivers, look at the properties, then
the Advanced button, and there you should be able to specify a spare COM
port for it to use every time, so it doesn't just pick the next in the
list, way up like COM25: or something silly.  (XP and 2k will support up
to COM255: by the way)
 
The problem is, not all device drivers are well behaved and release
their COM port allocations when they are unplugged from the system.
Many mobile phone utilities for example will "reserve" a huge block of
COM ports, denying all other use of them, even if said phone tools are
not actually loaded and running.  Again, there are ways around that too,
but way to long to go into here.  (Quick fix, is to uninstall the phone
tool software, when you don't need it.)
 
Hope something here helps someone.

73   Dave G0WBX.
 


________________________________

	From: Ben Lindner [mailto:vk5jfk at activ8.net.au] 
	Sent: 02 December 2008 22:03
	To: TAPR APRS Mailing List
	Subject: Re: [aprssig] USB-Serial
	
	
	There is a fix for this issue and I think its on Stephen Smith's
web site, cant remember his call but I'm sure you will see his name on
this list.
	
	Ben
	VK5JFK
	
	Kevin Sherwood wrote: 

		One thing I've noticed with using USB-serial adapters
and NMEA data streams is if data is coming across as Windows detects the
hardware, it often confuses it for a serial mouse, causing all kinds of
issues as the pointer jumps everywhere and clicks at random.  Making
sure Windows recognizes the USB-Serial adapter before plugging it in to
the device seems to be the only way to avoid this.
		
		Kevin KB3PLX