[GreenKeys] Arduino Code/Speed Converter

[ad7i]

Greetings –



In a prior message thread regarding the ITTY 100 WPM channel, Ralph Mowery
asked about my Arduino project.  It’s not quite ready for public release,
still adding features and testing, but I’d be happy to describe it, in case
it’s of interest to others.  In fact I have two TTY projects underway.  One
is a 36 volt electronic selector magnet driver that, so far, works well
with my 28 at 100 WPM.  I still have a bit of work to do to on that with
optimizing the magnet snubber components.  The other TTY project is the
Arduino code/speed converter, and that’s the project I’ve described below.



My code/speed converter started in 2015 as a simple TTY driver based on the
Arduino Uno.  It’s original function was to take canned ASCII messages that
were stored in the Arduino Flash code space and send them via CMOS/TTL
serial line to a TTY as 60 WPM US baudot (murray) code and also displaying
the data on a 4x20 LCD display.  And it sort of grew from there.



The project lay dormant for years, but when I finally had a chance to get
my M15 and M28 lubed up and returned to service last fall, I started on the
code/speed converter again.



As implemented today, it accepts input in several forms and outputs data in
several forms.  I’ve dropped the LCD display from the project but hope to
add it back in later.  I’ve also migrated the project from the Arduino UNO
($5) to the Arduino Mega ($8) to provide for more I/O pins, but a lot of
the basic TTY functionality can still be implemented with just an UNO.



My main use of it in my radio room has been to take AFSK data from ITTY at
60 WPM and send it as AFSK at 100 WPM to my HAL ST-5000 that drives my 100
WPM 28RO.



The code/speed converter can accept input data in several forms.  Some
inputs can be active at the same time, but it wouldn’t make sense to
operate more than one at a time, as the input data streams would all be
mixed together in a jumble.



Input streams:



Canned message in code memory.  This may be useful for museums,
demonstrations or displays.  Uses a rotary switch to select a particular
canned text message.  Output can be initiated by push button or motion
sensor with delay (i.e., can be configured to print a two line greeting
message {or something long like the Gettysburg Address} XXX seconds after
it senses movement in the room, provided the TTY has been inactive for the
prior YYY seconds).



ASCII serial input via the internal USB port, speeds from 300 to 250,000
bps.  XON/XOFF flow control.  Use this to send data from a computer to the
converter and hence the TTY. (I was surprised it works at such a input high
speed, and had assumed that at 250,000 the Windows 10 serial driver was not
sending data at full speed – but I checked the serial line with a logic
analyzer and did confirm that Windows 10 was sending at 250,000 without any
inter-character gap).



ASCII serial input via RS232, speeds from 300 to 19,200 pbs.  XON/XOFF flow
control.



ASCII serial input via CMOS/TTL logic levels, speeds from 300 to 19,200 pbs.
XON/XOFF flow control.



AFSK Audio input, low or high tones, TTY speeds 60, 66, 75 or 100 WPM.  Code
can be US, ITA2, TELEX, but I’ve only tested US code so far.  Note that
this AFSK detector is just a period counter.  The audio input can be sine,
square or sawtooth, but it can’t have **any** noise on the audio tones or
the decoder will get very confused.  It works well with ITTY because there
is no noise on that circuit.



Output streams are as follows:



TTY on TTL/CMOS serial output, 60, 66, 75 or 100 WPM (does not have to be
same speed as the input).  Code can be US, ITA2, TELEX.  Also includes a
motor control signal with proper on/off timing, and a send-it-first buffer,
so that CR-CR-LF-LTRS will be sent to TTY after motor start delay but
before normal text is sent to TTY.



TTY on AFSK output, same attributes as above, with tone on/off in synch
with motor control.  Note that this AFSK output is a square wave.  Works
fine driving my TUs in-house but I wouldn’t let this square wave AFSK
signal modulate a radio transmitter or send it down a phone line.



ASCII output on a Centronics parallel printer port.  Printer ESC commands
are designed for IBM PC compatible dot matrix printer operating in
Near-Letter-Quality format (but I use an OKI Microline 320 dot matrix
printer which powers-on in IBM emulation mode).  A separate motor control
signal for the parallel printer is provided.  Note that the OKI 320 is
still in production and is often available on ebay as used at a reasonable
price.  The OKI does not do well at printing one character at a time – poor
character alignment (I miss Daisy Wheel printers) so the data going to the
printer are stored/buffered and sent to the printer when either 15 or more
chars are available or every 4 seconds, which ever comes first.



ASCII output (serial TTL/CMOS at 9,600/19,200) to a small 50mm 32 char/line
thermal printer.  The code/speed converter software provides word-wrap (so
words do not break in half on the 32 char line boundary).  These printers
are physically small, inexpensive, use cheap adding machine paper and run
on 9V 2A.  This thing rocks on ITTY.  Yes, agreed, it’s not as suave and
sophisticated as my Model 15 or 28, but for general electronics projects
that require some sort of printer for logging data or events to hard copy,
it’s pretty darn good.  I haven’t (yet) provided a power control output for
this printer because, so far, I don’t think I need one.



Not all features are fully implement in detail yet and answer-back is not
implemented at all yet, but I do hope to add that in a way that makes sense.
In the case of electronic answerback for heavy metal TTYs,I need to make
sure that paper is present, not jammed, and the motor shaft is running as
speed.  I’m hoping that by measuring and windowing the AC motor current I
can use that as an indicator of motor running at correct speed.



So that’s the primary functionality of the code/speed converter.  My code
started on the Atmel Studio 7 IDE and I then moved to the Arduino IDE (the
exact opposite path from what Atmel recommends :-)  I don’t use an RTOS
(real time operating system) but instead simply write the code in a
non-blocking fashion.  No function or subroutine should take more than 20
uS to execute.  If it does take more than 20 us then I’ve coded it wrong.  To
make each function run very briefly, many of the functions that might need
to wait for input from another function or external event are coded as
state machines.  They do a bit of work when invoked, and when they have
finish up or discovered that needed data are not ready, they quit.  I think
the only Arduino systems calls I use are for the serial port, so I get the
benefit of their interrupt processing of RX data without my having to
recreate that.  For most everything else I control the ports and timers
directly, without using the Arduino system calls.  I also repurposed all 3
of the Uno timers.  Timer 0 is used to create an interrupt every 500 uS,
which drives all the bit-bang software TTY UARTS and other closely timed
events.  Timer 1 is used for the AFSK square wave output.  And Timer 2 is
used for the period counter for the AFSK input decoding.



My problem with making progress and finishing the project (and releasing
the source code) is time.  I had hoped to have this finished by the end of
November but things keep coming up that take me elsewhere.  Why is it that
retired people have no time?  My hope is to have this finished and released
by the end of April.



73, Paul, ad7i
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qth.net/pipermail/greenkeys/attachments/20200123/d3536e5f/attachment.html>