Skip to content

acerion/cwdaemon

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

cwdaemon-0.13.0
===============

cwdaemon is a small daemon which uses an USB-to-UART converter or PC parallel or
serial port to output Morse code to a transmitter from a text message sent to
it via UDP port 6789.

The program uses the soundcard or PC speaker (console buzzer) to generate a
sidetone.

It is called as root, with "cwdaemon -p <portnumber> -d <device>". If no
portnumber is given, the default portnumber 6789 is used. Device can be one of
the serial (ttyS0, ttyS1, etc) or parallel (parport0, parport1, etc) ports.
Default is parport0.

For FreeBSD, use ttyd0, ttyd1, etc. for the serial ports and ppi0, ppi1, etc.
for the parallel ports. Default is the first parallel port.

You can also use dummy device "null" instead of parallel or serial port.
This device does exactly nothing (no rig keying, no ssb keying, etc.).

cwdaemon also handles PTT, and band index output for automatic switching of
antennas, filters etc. Pinout is compatible with the standard (CT, TRlog).

cwdaemon is available on github: https://github.com/acerion/cwdaemon
cwdaemon's older webpage is http://cwdaemon.sourceforge.net/


Please note
-----------
BSD and/or Linux are not real-time operating systems. e.g. the timer resolution
of the kernel is 10 milliseconds. You may especially notice this when using PTT
and setting the PTT delay value. If you experience timing problems, you might
try using the -P flag. This will set cwdaemon's priority. The default is zero,
any negative value will be a higher priority, the maximum being -20.


Quickstart
----------
On linux run the cwsetup.sh script and next run cwdaemon with the -n flag.
If this does not work, read the next paragraphs....


Setting up parallel port(s) on linux for cwdaemon
-------------------------------------------------
You need the parport devices to use cwdaemon. Check if you have them:

  ls -al /dev/parport*

If you don't see any files, create the with MAKEDEV (as root user):

  cd /dev; ./MAKEDEV parport

Next, check whether the parport and parport_pc kernel modules are loaded: when
you type 'lsmod', you should (on the i386 architecture) see something like:

  parport_pc             23304   0 (autoclean)
  parport                25992   0 (autoclean) [parport_pc]

The lp module should not be loaded, it is only needed if you want to use a
printer and it will block the parallel port if you use cwdaemon. You can unload
it with the command 'rmmod lp' as root.

If you don't see any parport modules please check whether you have the line:

  alias parport_lowlevel parport_pc

in your /etc/modules.conf file and load the modules with:

  modprobe parport
  modprobe parport_pc

Be sure that parallel port support is enabled in your BIOS! If you use odd
ioports or interrupts, you can do things like:

  modprobe parport_pc io=0x3bc,0x378,0x278 irq=none,7,auto

which configures 3 parallel ports with the second port using irq 7 and the
third port some auto-detected irq.

When cwdaemon is run, the ppdev kernel module should be loaded automatically.
In case it doesn't, just type:

  modprobe ppdev

PLEASE NOTE: you should probably run a 2.4 kernel to use the ppdev device with
cwdaemon.

Setting up serial port(s) on linux for cwdaemon
-----------------------------------------------
Setting up your serial ports is straightforward. Here are some commands to get
you started:

  setserial -g /dev/ttyS*

will tell you what serial lines are configured. If you see a line with
"UART: unknown", this probably means there is no serial port for the device.

  setserial /dev/ttyS0 -v autoconfig

will try to autoconfigure your first serial port. You need to run this command
as root.

Other valid commands are:

  setserial /dev/ttyS1 auto_irq skip_test autoconfig
  setserial /dev/ttyS3 irq 5 uart 16550A skip_test

Newer distributions use a file called '/etc/serial.conf' where the information
for your serial ports are stored.


Setting up parallel port(s) on FreeBSD for cwdaemon
---------------------------------------------------
You will need ppbus and ppi either defined in the kernel or loaded at boot time
as kernel modules. ppbus and ppi are defined in the GENERIC kernel hence should
work as is unless you have removed them from your kernel. If not, you can add
the following in the kernel config, recompiling and reloading a kernel as
outlined in the FreeBSD handbook.

# Parallel port
device          ppbus           # Parallel port bus (required)
device          ppi             # Parallel port interface device

You can also load ppbus.ko and ppi.ko at boot time instead of rebuilding your
kernel. This is also outlined in the FreeBSD handbook.

e.g. In /boot add

ppbus_load="YES"
ppi_load="YES"


Setting up serial port(s) on FreeBSD for cwdaemon
-------------------------------------------------
The serial port driver is loaded by default in the GENERIC kernel. If not
configured in the kernel, you can add to the kernel config and rebuild the
kernel as outlined in the FreeBSD handbook.

# Serial (COM) ports
device          sio             # 8250, 16[45]50 based serial ports


How cwdaemon works
------------------

After starting, the program detaches from its controlling terminal,
after that the program can be controlled via its network udp input
port.

You can control cwdaemon by sending requests to it. Recognized
requests are listed below. Skip the quotes around codes when sending
actual requests. <ESC> is ASCII escape character (decimal 27, hex 1B).
Most of the requests are so called "escape requests", because they
start with Escape character.

<ESC>0                   Reset to default values
<ESC>2<speed value>      Set keying speed (5 ... 60 wpm)
<ESC>3<tone value>       Set sidetone (300 ... 1000 Hz)
<ESC>3<0>                Sound off
<ESC>4                   Abort message
<ESC>5                   Stop (Exit) the daemon
<ESC>6                   Set uninterruptable (word- ) mode for simulator
<ESC>7<weight value>     Set weighting (-50 ... 50)
<ESC>8<device>           Set device for keying (same as -d)
<ESC>9<port number>      Obsolete
<ESC>a<0|1>              PTT keying off or on
<ESC>b<0|1>              SSB signal from microphone or soundcard
<ESC>c<x>                Tune x seconds long (limit = 10 seconds)
<ESC>d<delay>            PTT on delay 0..50 (0 .. 50ms)
<ESC>e<bandindex>        Band info output on pins 2, 7, 8, 9 of the parport
                         (pin 2 = lsb, 9 = msb, e.g. 1000 = 160m, 1001 = 10m)
<ESC>f<sound system>     Set sound system, same as '-x' command line option.
                         Recognized values are:
                         c - console buzzer (PC speaker) - default system,
                         o - OSS,
                         a - ALSA,
                         p - PulseAudio,
                         n - none - no audio,
                         s - soundcard - autoselect from OSS/ALSA/PulseAudio.
                         You may experience few seconds of delay (~4 s) when
                         switching from ALSA or PulseAudio to OSS audio
                         system. This is because OSS waits until audio device
                         stops being blocked by ALSA or PulseAudio.
<ESC>g<volume>           Set soundcard volume (0 .. 100).

<ESC>h<text>             This request must be followed by a second request
                         containing only text to be played by cwdaemon. Once
			 the cwdaemon finishes playing the text from second
			 request, it replies to the client with "h"+<text>+"\r\n",
			 where <text> is a text from first request.

			 "text" is optional.

			 The reply defined in first request is used by
			 cwdaemon only once, i.e. only for a single
			 text request that follows the escape
			 request. If you want to receive a reply from
			 the cwdaemon after playing each text request,
			 you need to send the "<ESC>h" escape request
			 first, for every text request.

			 Example:
			 client sends: "<ESC>hcat"
			 client sends: "purring"
			 server plays: "purring"
			 server sends back: "hcat"

			 client sends: "<ESC>hdog"
			 client sends: "barking"
			 server plays: "barking"
			 server sends back: "hdog"

			 client sends: "<ESC>h"
			 client sends: "whispering"
			 server plays: "whispering"
			 server sends back: "h"

			 client sends: "<ESC>hdog"
			 client sends: "barking"
			 server plays: "barking"
			 server sends back: "hdog"

			 client sends: "purring"
			 server plays: "purring"
			 server does not send a reply - none was specified this time for "purring"


Any message              Send Morse code message  (max 1 packet!)
qrz de pa0rct ++test--   In- and decrease speed on the fly in 2 wpm steps.
                         Repeated '+' and '-' characters are allowed,
                         in such cases increase and decrease of speed is
                         multiple of 2 wpm.
de ~d~l~2~w~rj pse k     Add half-space delay after characters
                         NOTE: the delay is added after the character
                         _following_ the tilde (~). E.g. AB~CD results in
                         a delay between C and D.


Default startup values
----------------------
Speed = 24 wpm
Tone = 800 Hz
Sound = on
Wordmode = off
Weight = 0
UDP port = 6789
PTT delay = 0 (off)
Device = parport0
Sound device = console buzzer


tty driver tuning
-----------------

The default tty driver pinout uses DTR (pin 4 on DB-9) for keying CW,
and RTS (pin 7 on DB-9) for PTT.  This is the equivalent of

-o key=DTR -o ptt=RTS

To swap both pins, use

-o key=RTS -o ptt=DTR

To turn PTT off (e.g. transceiver in QSK mode) while retaining CW key
at DTR, use

-o ptt=none ["-o key=DTR" can be omitted]


cwdaemon supports the following special characters
--------------------------------------------------
*	AR
=	BT
<	SK
(	KN
!	SN
&	AS
>	BK


cwdaemon parallel and serial port circuitry
-------------------------------------------
See the examples in the schematics directory.


Examples
------------------
Example programs are located in examples/ directory.


Platforms
---------
cwdaemon 0.13.0 has been compiled and tested on following platforms:
 - Debian GNU/Linux 12, x86_64, gcc 12.2.0, libcw 8:0:0 (unixcw 3.6.1)
 - FreeBSD 14.1-RELEASE, x86_64, gcc 13.2.0, libcw 8:0:0 (unixcw 3.6.1)

A subset of tests has been also executed on:
 - Alpine Linux 3.20, x86_64, gcc 13.2.1, libcw 8:0:0 (unixcw 3.6.1)


Quality Assurance
-----------------

- Compile-time flags

    - -std=c99
    - -Wall -Wextra -pedantic
    - a long list of additional warning flags for compiler, enabled during
      development cycles (see configure.ac)
    - -D_FORTIFY_SOURCE=2

    Only a handful of enabled compiler warnings aren't fixed yet.

- Static analysis of code

    - clang-tidy is being run on code of cwdaemon and on code of unit and
      functional tests. Scope of checks is specified by .clang-tidy config
      file found in repo's root dir.

- Unit tests

    - Small parts of daemon are tested with unit tests (see
      tests/unit_tests/README).

      The tests are enabled by default.

      The tests are executed with "make check".

    - Few utility functions used in functional tests are tested with unit
      tests, if the functional tests are enabled.

    - See tests/unit_tests/README for more info.

    - A very basic support for gcov/lcov coverage for unit tests is
      available. Relevant commands:

        - ./configure --enable-gcov
        - make gcov
        - < examine reports found in tests/coverage/unit_tests >
        - make gcov-clean

- Functional tests

    - Automatic (and unattended) tests written in C that cover to some degree
      a small (but growing) set of functionalities.

      The tests are located in tests/functional_tests/unattended/ dir.

      The tests are disabled by default. They can be enabled at compile time
      by passing '--enable-functional-tests' flag to './configure'.

      Some of the functional test take a very long time to complete. Such
      tests are disabled by default, even if functional tests are enabled. To
      enable the long-running functional tests, an additional flag must be
      passed to ./configure: '--enable-long-functional-tests'.

      The functional tests are executed by running "make check" command.

      The tests require presence of USB-to-UART converter, which is visible as
      /dev/ttyUSB0 (on other OSes the default name may be different). The
      name of /dev/ device can be configured at compile time with
      '--with-tests-tty-cwdevice-name=<name>' flag passed to './configure'
      script.

    - A very basic support for gcov/lcov coverage for functional tests
      written in C is available. Relevant commands:

        - ./configure --enable-gcov --enable-functional-tests
        - make gcov
        - < examine reports found in tests/coverage/functional_tests >
        - make gcov-clean

      Don't forget to connect USB-to-UART converter before running the tests,
      otherwise the functional tests fill all fail.

    - An array of tests written in Perl, to be executed manually and observed
      for results.

      The tests are located in tests/ dir.

      The tests are not executed automatically by build system.

      The tests are slowly phased out in favour of unattended tests written
      in C.

- Fuzzing test

      A simple fuzzing test is sending random requests to cwdaemon's network
      socket. The test is located in tests/fuzzing/simple/.




Credits
-------
Conversion to stand-alone utility, basic work, POSIX porting, integration
with unixcw and initial FreeBSD support by PG4I.
Networking, daemon mode and band switching by PA0R.
Rework of the device handling, echo-ing and Debian init.d support by OK1ZIA.
Many contributions by DL2WRJ. Unixcw library by G0FRD. FreeBSD support by
Diane Bruce, VA3DB. OpenBSD and multi-platform support by Jason L. Wright,
AI4JW.

All of this code is distributed under the GNU GPL license.