[WT-support] Win-Test vs. WinKeyer USB

[Peter Stuge]

Bob Wilson, N6TV wrote:
> On Sun, Oct 10, 2010 at 10:35 PM, Peter Stuge <peter at stuge.se> wrote:
> > I know USB fairly well and I'm really sad to see FTDI chips being
> > used so widely, especially in applications where other chips could
> > offer great benefits, admittedly also requiring more USB knowledge
> > and development, but it's very unfortunate that it's so rare to take
> > advantage of all USB has to offer.
> 
> First, Peter, what is your callsign?

I'm afraid I don't have one yet. I started getting interested in
electronics at age 10 and would buy components at the local radio
repair shop, of course longingly staring at all the nice equipment
on display there. :)

I had an enthousiastic teacher SM7DQW in high school a few years
later, who managed to get some of us through the required training
and pass the license test. At the time I believe CW at 60wpm was a
requirement for the interesting license, and while I really wanted
to learn more about radio I just knew that I wouldn't be able to
learn CW at the time. So no license for me that time.

I continued with my electronics and computer interests outside the
radio field, but about a year ago I really wanted to get going with
radio communication and I signed up to the local club SSRS (SK7OA).
This is also the reason for my interest in Win-Test; it's the
software used at our club station.

I'm good with digital so want to help out with better station
integration, and I'm learning more analog. It's a little annoying
that we don't know exactly how far field magnetics work, because I
enjoy really going into detail when I do something, but OK, it works,
I'll settle with that.

I would like to take time to study some more before I try my luck at
the test, but the other club members are encouraging me to go for it
even if I don't yet know every answer on the practise tests. I hope
to pass a test before winter.


> Consensus in the ham community is that the FTDI chipset is the BEST
> that you can get, and that the Prologic chipset is to be avoided at
> all costs.  I suspect this is probably the result of bad Prologic
> driver software, not bad chip hardware.  Now I know why.

FTDI have had some ugly silicon bugs which made the chip lock up at
power-of-two baud rates. I also find the FTDI chips to be overpriced.

Prolific chips are "dumber" than FTDI chips, thus they require the
driver to do more work. Writing drivers is not the core business of
chip manufacturers, maybe something done in a hurry and maybe not by
the most skilled developers. This of course leads to a horrible user
experience and I completely understand why people dislike USB as a
result. (As I experienced at SK7OA this weekend when testing my
GS-232 emulation the FTDI drivers aren't so different, requiring a
reboot before the emulated COM ports would actually work.)

I've been using Linux for a long time and fairly often Prolific
USB-to-UART chips, without any problems whatsoever. I am convinced
that you are correct about the drivers being at fault for any
problems observed.

If USB-to-UART is absolutely neccessary then I strongly prefer the
Silicon Image CP2102-CP2103 chips over anything else. They cost a few
cents more than the cheapest FTDI chips but they also have larger
buffers.

My chief point however, and what makes me sad, is that any USB-to-UART
chip is neglecting most features offered by the USB protocol.

While it is simple for applications to program a serial port, it's
rarely a very good fit for the actual protocol used on top of the
serial stream, which means extra work both in firmware and in the
host application, to reliably deal with the serial stream.

Although USB is serial communication on the wire the USB protocol is
very much packet based, and it offers many features that are lost
with any USB-to-UART chip.

For applications which do not actually require a stream transport,
programming would become easier if USB was used as the packet
transport it is, and if the four different transfer types could be
taken advantage of as appropriate for each application:

* Request/reply (control)
* Guaranteed latency, low bandwidth with retries (interrupt)
* Guaranteed latency and (high) bandwidth without retries (isochronous)
* Whatever bandwidth is left without guaranteed latency with retries (bulk)

The USB-to-UART chips all use bulk transfers and USB packet semantics
are lost because the only exposed interface is a stream.

USB is so much more than a serial port with power.

I've given a few presentations about USB details at a couple of
conferences, including how to use the open source libusb project
(which I co-maintain) to get a platform-independent and quite
straightforward API for programming USB on the host side without
needing to write a kernel driver. The next release has Windows
support with the new libusb-1.0 API, Windows support was previously
only available from a separate libusb-win32 project which implemented
the old 0.1 API. I've also held some workshops where we developed a
USB device using a microcontroller which includes a generic USB
hardware, allowing us to pick and choose from all the features of
USB, and getting immediate access to USB protocol properties and
behavior within the microcontroller firmware. My favorite at the
moment is the NXP LPC1343, a small ARM Cortex-M3, $5-$6 at Digi-Key.
FTDI chips start at $2. I think that the value of the generic USB
hardware in the ARM micro makes it an easy choice every time.


> But the bottom line is that N6XI's issue was not a USB problem,

Completely agreed! And also what I expected. I suggested to go into
USB traffic only as a way to learn more about how the different
applications were talking to the microcontroller in the device. It
would have shown the difference, but also required significant
effort. Good work finding the solution!


Kind regards

//Peter