Earlier this year I was working with David, W1HKJ, the primary developer of FLDIGI, to create a FLDIGI software widget (named flio) that would allow data that appeared in the RX and TX windows of FLDIGI to be sent as ASCII to a USB serial port. I then had an Arduino like device that would take the output of the USB-Serial bridge chip and send it to a TTY as 5 unit Baudot code, so that a TTY could print content decoded by FLDIGI (so QSOs in modes with significant processing gain, such as Olivia and Domino, could be copied on a mechanical TTY). And it worked great, except that flow control didn't work. Although the serial link was operating at 9600 bps, the actual character rate was the same rate that data appeared in the FLDIGI window. So for Olivia, the character rate was less than the 6-ish chars per second of 60 WPM, so no overflows. But I also wanted it to work with some of the higher speed modes (mostly to test the flow control). In some cases flow control would work, in other cases it would not.
In case it's of interest to some of those following this thread, I've pasted below some of my test results.
Paul, ad7i
======================================================
Results of testing USB to serial converters on Debian and Windows
Converters tested:
CH340G - This is the native USB to serial converter on most all clone Arduino Uno boards (and others).
CP2102
- produced by Silicon Labs. I have several of these as "modules" where
the CP2102 is mounted on a PCB purchased from Ebay for an average of $2
each.
FTDI - The gold standard in USB to serial conversion,
except the ones I'm using are most likely counterfeit, knock offs.
Purchased as "modules" where the FTDI chip is mounted on a PCB purchased
from Ebay for an average $3 each.
Applications software used:
fldigi with flio (debian linux and Windows 10)
Realterm (windows 10)
Picocom (debian linux)
Receiving Hardware
Arduino
Uno with software to function as an ASCII to Baudot converter. Serial
input link speed 9600 8N1 with input flow control of either RTS/CTS
or Xon/Xoff. Serial output is 5 unit Baudot code, TTL and AFSK,
operating at 45.45 baud (60 WPM, approximately one output character
every 163 ms)
Test Text
The text message consisted of
four lines of "quick brown fox...", approximately 52 characters per
line. Normally this would take approximately 45 seconds to output from
the Arduino as 60 WPM Baudot code if there was no over-run on the
Arduino serial input (i.e., flow control working normally).
Arduino SW Fifo
The Arduino SW fifo is 50 bytes deep. When 25 characters are in the fifo the XOFF is transmitted OR CTS is de-asserted (NOT clear to send). When there are less than 5 characters on the fifo, the XON is transmitted OR CTS is asserted (clear to send).
TESTING UNDER DEBIAN
General
Comments: Operation of flidi and flio under Linux were stable and well
behaved. No issues with either of these programs.
Test cases and results
OS: Debian Linux
Conv: CH340G
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control *FAIL*
OS: Debian Linux
Conv: CH340G
Flow: RTS/CTS
App: picocom
Results: Flow Control *FAIL*
OS: Debian Linux
Conv: CH340G
Flow: Xon-Xoff
App: fldigi flio
Results: Flow Control *FAIL*
OS: Debian Linux
Conv: CH340G
Flow: Xon-Xoff
App: picocom
Results: Flow Control *FAIL*
------
OS: Debian Linux
Conv: CP2102
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control Works
OS: Debian Linux
Conv: CP2102
Flow: RTS/CTS
App: picocom
Results: Flow Control Works
OS: Debian Linux
Conv: CP2102
Flow: Xon-Xoff
App: fldigi flio
Results: Flow Control *FAIL*
OS: Debian Linux
Conv: CP2102
Flow: Xon-Xoff
App: picocom
Results: Flow Control *FAIL*
------
OS: Debian Linux
Conv: FTDI-KO
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control Works
OS: Debian Linux
Conv: FTDI-KO
Flow: RTS/CTS
App: picocom
Results: did not test this case because worked OK with flio
OS: Debian Linux
Conv: FTDI-KO
Flow: Xon-Xoff
App: fldigi flio
Results: Flow Control Works
OS: Debian Linux
Conv: FTDI-KO
Flow: Xon-Xoff
App: picocom
Results: did not test this case because worked OK with flio
TESTING UNDER WINDOWs 10
General
Comments: Operation of flidi was stable and well behaved. Operation
of flio was inconsistent and gave odd results, without regard to the
issue of flow control. In some cases text characters in the flio data
window made no sense, as though there was a synchronization problem in
the data transfer between fldigi and flio, or characters were dropped.
Also, in some cases flio would not "see" the Arduino (no green diamond)
after changing the port parameters in flio. Only when flio was closed
and reopened would flio then see the Arduino board.
Test cases and results
OS: Windows 10
Conv: CH340G
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control *FAIL*
OS: Windows 10
Conv: CH340G
Flow: RTS/CTS
App: RealTerm
Results: Flow Control Works
OS: Windows 10
Conv: CH340G
Flow: Xon-Xoff
App: fldigi flio
Results: Flow Control *FAIL*
OS: Windows 10
Conv: CH340G
Flow: Xon-Xoff
App: RealTerm
Results: Flow Control *FAIL*
------
OS: Windows 10
Conv: CP2102
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control *FAIL*
OS: Windows 10
Conv: CP2102
Flow: RTS/CTS
App: RealTerm
Results: Flow Control Works
OS: Windows 10
Conv: CP2102
Flow: Xon-Xoff
App: fldigi flio
Results: Flow Control Works
OS: Windows 10
Conv: CP2102
Flow: Xon-Xoff
App: RealTerm
Results: Flow Control Works
------
OS: Windows 10
Conv: FTDI-KO
Flow: RTS/CTS
App: fldigi flio
Results: Flow Control *FAIL*
OS: Windows 10
Conv: FTDI-KO
Flow: RTS/CTS
App: RealTerm
Results: Flow Control Works
OS: Windows 10
Conv: FTDI-KO
Flow: Xon-Xoff
App: fldigi flio
Results: Flow indeterminate, bad data in flio window
OS: Windows 10
Conv: FTDI-KO
Flow: Xon-Xoff
App: RealTerm
Results: Flow Control Works
---ooOoo-