Using the jt9 executable to receive FST4W signals

Note: 

Since originally posted, WSJT-X v2.3.0-rc2 was released, adding a feature to the "JT9" executable that simplifies this process (the "-F" parameter) as described below.  Note that most of this post was originally written soon after "rc1" had become available.

* * *

As a heavy user of K1JT's WSPR and operating on the 2200 and 630 meter bands, I have noted with interest the introduction of the "FST4W" mode in the recent (v2.3.0-rc1) wsjt-x release.  Operating using the same detection bandwidth as WSPR (when FST4W is operated in the 120 second mode) it offers a theoretical 1.4dB improvement in detection sensitivity.

Being involved with wsprdaemon (link to that project here ) - an open-source project that automates and optimizes reception of WSPR signals on all bands, particularly if multiple receivers/antennas are used - we have been watching this development with interest, particularly since FST4W has the likelihood of supplanting conventional WSPR operation, especially on the lowest amateur bands (2200, 630 and possibly 160 meters) where minimal of Doppler shift is expected.

Internally, WSJT-X  uses the subordinate wsprd program as the decoding (and encoding) engine.  As a stand-alone program, the wsprd executable code may be invoked with a command line to decode signals contained within a .wav file that was captured during the standard two minute interval - aligned with even UTC minutes - and produce a text file containing the decoded signals.

Why use the executable rather than the entire wsjt-x suite?  The fact is that the use of the wsjt-x suite does not lend itself easily to script-driven, bare-minimum, lightweight implementations where further processing of the decoded data (to remove duplicate decodes from multiple receivers, antennas and to use this same data for further analysis of signal/noise) is desired.

The "jt9" executable:

After a bit of digging about, it was "discovered" that FST4W - being an offshoot of the JT9 protocol - was handled not by the wsprd executable, but the jt9 executable.  Simply executing this program with no arguments will yield a list of command-line arguments which, on the face of it, made it appear that updating the wsprdaemon to include the decoding of FST4W signals would be a relatively simple matter.

Except that it didn't work.

Initial testing with strong, off-air FST4W signals that was known to be decodable (because farther-flung stations were able to decode the very same transmissions) yielded no results when the .wav file was applied to the jt9 program - but automatic execution over many hours yielded the occasional off-air decode.  Confused by this, I sought help on the WSJT-X groups.io forum.  Fortunately, Joe Taylor and several of the developers offered a clue:  The "-f" parameter of the jt9 executable, described minimally as "Receive Frequency Offset".

Apparently, the default center frequency of the jt9 executable - at least when in FST4W mode (and maybe others) is 1500 Hz - a fact implied when one gets the display of command-line arguments.  What is not so clear - and only alluded to in the available documentation - is that the apparent bandwidth of the decoding, at least in the 120 second mode, is on the order of 40 Hz (+/- 20 Hz).  Addendum:  This issue was fixed with the "-F" parameter - see below.

At a quick glance through the source code (file "jt9.f90"), this bandwidth setting appears to be hard-coded into a shared variable (apparently accessible by other programs in the WSJT-X suite) called "ntol" (likely a number referring to the "frequency tolerance" setting in the GUI) that is not available via the jt9 command line - at least, not without modification of the source code.  (The possibility of directly accessing these shared variables exists - but this would be platform-specific, a bit messy and somewhat dangerous!)

Unfortunately, this fixed +/-20Hz bandwidth does not appear to be compatible with the way that the FST4W mode has (already!) found use on 2200 and 630 meters where it is used along-side the WSPR mode in the 200 Hz subbands.

A hell of a kludge:

Update - kludge no longer needed:

As of version 2.3.0-rc2 it appears that a new parameter "-F" was added to allow something other than a +/-20Hz bandwidth (referred to as "tolerance") to be used, likely eliminating the need for multiple decodes, below.  A possible command-line for this would be:

jt9 -W -p 120 -f 1500 -F 200 <wav file to be processed> 

With the center frequency (-f) being the center of the passband (1500 Hz) and the "-F" parameter referred to as"tolerance" (e.g. detection bandwidth) being 200 Hz. 

Initial testing indicates that the -F parameter does what it's supposed to do and the kludge below is now longer required.

This fact implies that in order to use something other than the GUI version of the wsjt-x software, a work-around must be invoked.  The following is a bare-minimum example of how one might do this via the command line:

jt9 -W -p 120 -f 1420 <wav file to be processed> 

jt9 -W -p 120 -f 1460 <wav file to be processed>

jt9 -W -p 120 -f 1500 <wav file to be processed>

jt9 -W -p 120 -f 1540 <wav file to be processed>

jt9 -W -p 120 -f 1580 <wav file to be processed>

(One might include the -H, -L and -d parameters in actual practice.)

In other words, in order to cover the entire 200 Hz WSPR subband, the JT9 executable (v2.3.0-rc1) must be executed - processing the same .wav file - at least five times:  The results of the decoding will, in each case, be found in the file "decoded.txt".  If one wishes to implement an equivalent of the -w parameter of the wsprd executable (e.g. +/- 150 Hz "wideband" mode), you will need even more invocations than above.

The result from the above mess will be five different decoding results, each of which must be saved (e.g. renamed) between subsequent executions to prevent overwriting by the previous instance.  After this, the five results would be concatenated to yield a single file - but there is a catch:  It is likely - particularly if the signal is strong - that the same signal will be decoded more than once.  Apparently, the "+/- 20Hz" limit isn't the result of a "brick-wall" filter:  Signals beyond this frequency range may be decoded, but the reported S/N values will likely be reduced as distance of the received signal from the specified center frequency increases.  In short, this means that the results of the concatenated version of the "decoded" file(s) must be sorted and all but the single, "strongest" decode (e.g. best SNR) for each station must be discarded.

Comment:

It would appear that just five iterations to cover the 200 Hz bandwidth is not enough:  I received correspondence from a reader of this blog that observed that a frequency variation of less than 10 Hz from that defined by the "-f" parameter can affect the S/N reading by about 1 dB.  Make of that what you will!

* * * * * * * * *

If one wishes to integrate the FST4W decodes into the existing WSPR captures for processing, yet another step must be undertaken:  "Fixing" the formatting.  Not surprisingly, the output in the "decoded.txt" is not formatted the same as the results of the decoding from the wsprd executable meaning that one will need to do a few things, after the fact, to "fix" them - particularly if you wish to forward them to wsprnet.org, including:

• Supply the date.  The "decoded.txt" includes the time - but not the date.  Because date of the .wav file may not be the same as the system date (e.g. later processing of the .wav files - or the interval being processed occurred just before the new day) - one must use the actual date of the recording.  The obvious place to obtain this is from the name of the .wav file being processed.
  

• Frequency offset.  The information that one might send to wsprnet.org must include the carrier frequency of the received signal, but the output in the "decoded" file has only the audio frequency:  One must obtain the LO frequency of the receiver being used from "somewhere else" and calculate this on the fly.
  

• Supply missing information.  The "decoded.txt" file does not have all of the same information fields that one might supply when uploading WSPR spots, so this information must be added as necessary.
  

• Arrange the fields in the proper order.  Once the needed information is applied, one will probably want to use "awk" or similar to produce the same order as the wsprd data - assuming this wasn't already done in the process.
  

* * *

There are two outputs from the jt9 executable - one directly from the program itself to the standard console and that output to the file "decoded.txt" - and the latter is the most useful. 

Console output:

0416 -24  0.7 1515 `  KA7OEI DN40 17                                 
<DecodeFinished>   0   1

The fields are:  <time UTC> <SNR in dB> <DT?> <Audio frequency in Hz> <always "`"> <Callsign received> <Grid of received station> <Reported TX power in dBm>

From the "decoded.txt" file:

0416   0  -24   0.7   1515.   0   KA7OEI DN40 17                        FST4

 The fields are:  <time UTC> <unknown - possibly drift in Hz> <SNR in dB> <DT?> <Audio frequency in Hz> <unknown> <Callsign received> <Grid of received station> <Reported TX power in dBm> <Always "FST4">

* * *

There you have it:  The germ of what would be needed if one wishes to supplement the existing WSPR decodes with the newer FST4W mode using just the bare executables.  If one wishes to decode other than the 120 second FST4W mode, things get even more complicated!

Sample audio file:

An audio file containing both FST4W-120 and WSPR transmissions may be found HERE - right-click to download.  This file contains an FST4W-120 transmission by KA7OEI from about 116km distant and (at least) two WSPR transmissions.

* * * 

 

Note:  It appears that the "-F" parameter, above, modifies the default ntol setting as described above.

P.S.:  While it would be pretty trivial tweak the code to allow modification of the ntol variable via command line, this would complicate the ongoing maintenance of the wsprdaemon code.  We can only hope that the current authors see fit to include a means by which the entire wspr subband can be monitored with a single invocation of the jt9 executable.

 

This page stolen from ka7oei.blogspot.com

[End]

A quick (and probably incomplete) guide to getting kiwirecorder and kiwiwspr (now wsprdaemon) running on Linux

What follows is likely to be quite incomplete - but it contains the major steps in installing the kiwirecorder and kiwiwspr packages on a Linux machine.  I did my installation on Ubuntu, but similar may be done on other distros, such as Debian - including on the Raspberry Pi platform.

I don't claim to be an expert in such things and it is likely that I missed a few steps that may be specific to some distros/platforms - but the phrase "Google is your friend" is applicable if you run into trouble as it's likely that I can't help in your specific case.

What is "kiwirecorder"?

The kiwirecorder package works in conjunction with a "KiwiSDR" (see KiwiSDR.com for more information) - a relatively inexpensive (approx. $300) stand-alone, Linux based HF receiver capable of tuning from a few kHz to over 30 MHz.  Intended to be remotely accessed, it sports a Web-based user interface that provides both audio and a waterfall display along with the capability of demodulating various modes (SSB, CW, AM, FM) and decoding several different types of transmissions, including CW, FAX, FSK and WSPR.  Depending on configuration it is possible to have up to eight "users" connected, via the Internet, to a single KiwiSDR, each using their own frequency and mode settings.

While capable, it may be that this interface isn't quite what you need:  Perhaps you need an audio stream to feed somewhere else - maybe, to another computer that is decoding a mode that is not "built in" to the KiwiSDR or to record the goings-on on a certain frequency:  This is where the "kiwirecorder" comes in.

The kiwirecorder script makes a minimalist connection the the KiwiSDR, not requiring the user interface (display, waterfall, etc.) providing only a streaming audio connection with the frequency and mode specified in the connecting URL.  This stream may then be processed by another computer connected to it (locally and/or via the Internet) to do what it is that you wish to do.

Exactly how this works and its options are beyond the scope of this article, but the source code and documentation may be found here:

https://github.com/hcab14/kiwiclient

What is "kiwiwspr"? 

Note:  The "kiwiwspr" package has been renamed "wsprdaemon" as it is no longer specific only to the kiwirecorder package - see the addendum at the bottom of this posting.

While the KiwiSDR itself is capable of decoding WSPR transmissions, doing so takes a lot of its processing power and if there are many WSPR transmissions to be decoded within a passband - such as 20 or 30 meters during band openings - it may "miss" many opportunities if there isn't enough processing power to go through all of the latent signals.  Additionally, in a multi-user environment, having several WSPR decoders running simultaneously causes the normal user interface to slow noticeably - particularly with respect to the update rate of the waterfall display.

By "piping" audio to another, more capable computer, more effective WSPR decoding may be done by recording about 110 seconds of audio starting at the beginning of an even-numbered minute and then passing that file to the "wsprd" (wspr decoder) program which is part of the WSJT-X suite.  Using an outboard computer for this task minimizes the load on the KiwiSDR itself and with the faster, better hardware of the remote computer, more "in depth" processing may be done to allow the recover of more weak signals than may be possible with the KiwiSDR's built-in decoder - and be able to do so more quickly, with the latest version of the software.

Installing kiwirecorder and kiwiwspr 

The following assumes that you have a running Ubuntu Linux computer running on a network that has access to the KiwiSDR.  Ideally, such a computer would be placed on a local network, but this is not required.

• Be sure that the computer in question is reasonably up-to-date and has installed on it Python.  If Python is not already installed, the steps on doing so are readily found on the web. 

• The computer in question must have access to means of keeping the clock within +/- 2 seconds of UTC.  This is usually done by via NTP or similar.  If the computer's clock is not held to within a couple seconds of UTC, WSPR decoding will fail.

• It is highly recommended that the KiwiSDR's GPS antenna be placed outside in a location with a clear view of the sky and that its GPS lock is verified.  By supplying the KiwiSDR a valid GPS signal both its frequency and time may be held to good accuracy.

The steps:

• Log into the computer as the user that you wish to run the kiwirecorder and related software.  It is generally a good idea not to be logged in as a user with root access when you are running scripts.

• Install "kiwiclient" and change to its directory after install:
• git clone https://github.com/jks-prv/kiwiclient
• cd kiwiclient

•  Install Python dependencies for the scripts:
• sudo apt-get install python-pip
• sudo pip install numpy scipy
• (There are other ways to install "numpy" and "scipy", but the above works fine)

• Install wsprd (WSPR decoder for linux):
• sudo add-apt-repository -y ppk:ki7mt/wsjtx-next
• sudo apt-get update
• sudo apt-get install wsjtx
• Important: 
• If the version that you need isn't available via the repository and/or a new version of WSPR has recently released, it may not be available via the repository as an installation package.  To manually install a newer/different version, do the following:
• Download the most current binary that is appropriate for your system.  Binaries for the most common distros are typically found here:  https://physics.princeton.edu/pulsar/k1jt/wsjtx.html
• In the example this package is called "wsjtx_2.0.0-rc3_amd64.deb", but you would choose the appropriate binary for your system.
• As of the time of this writing, only "1.9" is available via an install package and version 2.0 - which offers slightly better performance - has to be manually isntalled.
• Copy the binary to a directory on the target machine where you have access.
• In the location where you copied the file do:  sudo dpkg -i wsjtx_2.0.0-rc3_amd64.deb  (You would substitute the name of the file that you downloaded and copied to the Linux machine)
• You may get an error saying that "libgfortran3" is not installed:  This package may be installed thusly:  sudo apt-get install libgfortran3
• After you install libdfortran3, the wsjtx package may automatically complete installation, but if not (or if in doubt) try reinstalling it using the "sudo dpkg..." step, above

• Install bc:
• sudo apt-get install bc

•  Go into "tools" subdirectory (kiwiclient/tools)
• cd tools

• Find the newest "kiwiwspr" script and copy it to the "tools" director.
• While a version of the "kiwiwspr" script is included with kiwiclient, it may not be the newest.
• Go to this discussion on the ValentFX.com site and look near the end for the newest kiwiwspr script.   This same discussion also provides clues and help for troubleshooting.
• Make sure to CHMOD the new kiwiwspr script (if you updated it) to 774 so that it may be executed.

This should complete the installation.  The directory of interest will always be "kiwiclient/tools".

Let us assume for what follows that the kiwiwspr script is called (or has been renamed to) "kiwiwspr.sh"

• Execute the script once to get the "default" configuration file:
•  ./kiwiwspr.sh
• If all goes right, you will get a message stating that a "default" configuration file has been created.

• Copy the resulting file ("kiwiwspr.conf") and rename it as something else (e.g. "kiwiwspr.conf.original) so that you can refer to it later.

• Edit the file to include one's own specific KIWI information.  Each of the items below is required!
• At the top under "KIWI_LIST", enter the required information, separated by at least ONE space:
• "OurID" - Name of the KIWI (no spaces).  It is this name that will be used to refer to this particular KiwiSDR in the schedule described below.
• "IP:PORT" IP address (numerical) and the KiwiSDR's web interface port port (typically 8073)
• "Mycall" - the call by which WSPR decodes are reported:  This is the "reporter" callsign on wsprnet.org
• "MyGrid" - the 4 or 6 character Maidenhead grid location.
• "KiwiPassword" - This is the password, if any, to access the Kiwi if it is not public.  You must put the word "NULL" here if there is no password - it cannot be left blank.
• Note:  Several different KiwiSDRs may be defined in this table:  Each KiwiSDR's definition is as above, surrounded by quotes, on its own line.
• As an example, one might have entered, on its own line, the following:
• "my_kiwi 192.168.1.234:8073 w7xyz-1 cn01dc NULL"  This means that a receiver called "my_kiwi" can be reached via the IP address of 192.168.1.234, port 8073 and it will report to wsprnet using the callsign of "w7xyz-1" using the grid square of "cn01dc" and will not require a password.

• There may be a table labeled "CAPTURE_JOBS":  This is no longer used and it may be ignored.  (It's recommended that you leave it as-is for now if it is there.)

• There is a table called "WSPR_SCHEDULE" that defines on what frequencies, with which KiwiSDR instance and when the WSPR decoding "jobs" are to be scheduled in the following format, each on its own line with quotes:
• "time kiwi_name,first_band kiwi_name,second_band kiwi_name, third_band"
• Or, using the example above:
• "15:00 my_kiwi,80 my_kiwi,40 my_kiwi,30 my_kiwi,20"
• This would cause "my_kiwi" to start decoding WSPR on the 80, 40, 30 and 20 meter bands at 15:00 local time.
• You can also set the schedule relative to you sunrise and sunet time, the location of the sunrise/sunset being determined by the grid square that you entered.  This can be useful if you have only a limited number of audio instances available and you wish to favor the bands that are best in the daytime or nighttime.  Example of this are:
• "sunset-01:15 my_kiwi,80 my_kiwi,40"  - This would start WSPR decoding sessions on 80 and 40 meters at 1 hour and 15 minutes (e.g. 01:15) before local sunset as indicated by the "minus" sign after "sunset".
• "sunrise+2:30 my_kiwi,20 my_kiwi,15" - This would start the WSPR decoding sessions on 20 and 15 meters at 2 hours and 30 minutes after local sunset as indicated by the "plus" sign after "sunrise".
• If you wish, you may also specify UTC (GMT) instead of local time, in which case the you would add ",UDT" after the numerical time as in:
• "01:00,UDT my_kiwi,80 my_kiwi,40" - This would start the WSPR sessions on 80 and 40 meters at 0100 UTC.  Times relative to Sunrise/sunset would not apply here.

Options:

As of version 1-1g there is an optional variable that can be specified called "KIWIRECORDER_CLIENT_NAME".  One would include a link in the kiwiwspr.conf" file like this:

declare KIWIRECORDER_CLIENT_NAME=(
    "My_Kiwirecorder"
)

The above will cause the text "My_Kiwirecorder" to show up as the name of the use on the KiwiSDR instead of "kiwirecorder.py".  Do note that this needs to be placed at or near the top of the kiwiwspr.conf file or else it may not have an effect.

Bands/Frequencies:

Valid bands, their base RF frequencies and receive passbands are:

• BAND  DIAL FREQ  RF (carrier) Frequency range
• 2200     136.0kHz         (137.3-137.7 kHz)
• 630       474.2 kHz        (475.5-475.9 kHz)
• 160       1836.6 kHz      (1837.9-1838.3 kHz)
• 80         3568.6 kHz      (3569.9-3670.3 kHz)
• 80eu     3592.6 kHz      (3593.9-3594.3 kHz)  Deprecated - Usage to be discontinued.
• 60         5287.2 kHz      (5288.5-5288.9 kHz)  Not on a U.S. channel.
• 60eu     5364.7 kHz      (5366.0-5366.4 kHz)  Not on a U.S. channel.
• 40         7038.6 kHz      (7039.9-7040.3 kHz)
• 30         10138.7 kHz    (10140.0-10140.4 kHz)
• 20         14095.6 kHz    (14096.9-14097.3 kHz)
• 17         18104.6 kHz    (18105.9-18106.3 kHz)
• 15         21094.6 kHz    (21095.9-21096.3 kHz)
• 12         24924.6 kHz    (24925.9-24926.3 kHz)
• 10         28124.6 kHz    (28125.9-28126.3 kHz)

Notes about the bands/frequencies listed above:

•  The "80eu" band is still used in some parts of Europe and by other amateurs who have yet to change:  Use of this frequency is deprecated and will eventually cease.
• The "60" meter band reflects the available of that in much of the world while the "60eu" band is better-suited for use in many European countries.  Because 60 meter frequencies/channels differ, you should pick the frequency that reflects the geographical area of interest when it comes to receiving WSPR transmissions.  (Note that none of the listed 60 meter frequencies correlate with the channels available to U.S. amateurs.)
• The "Dial Freq" is that to which one would tune using USB while the "RF" frequency range is that which this script will use to "look" for WSPR signals.
• The audio band 1300-1700 Hz is used for decoding and offset should be applied to determine the actual transmitted/received carrier frequencies.  (e.g. for 40 meters, RF frequencies of 7039.9-7040.3 are in the passband.) 
• The detection bandwidth is 400 Hz instead of the nominal 200 Hz to accommodate "out of band" WSPR operation, frequency drift of your receiver and others' transmitters and the effects of the audio filters applied by the Kiwi.

If you get errors:

• If a package didn't install, you'll get errors indicating such.  Because there are many different possible scenarios with your operating system, I will not cover them here.  Remember:  Google is your friend when it comes to helping solve specific errors.
• If, when you run the "kiwiwspr" script, you get errors about missing elements, etc., these are typically due to data that is expected (like band) but is missing.  Re-check to make sure that:
• ALL of the required fields are entered in the "kiwiwspr.conf" file.
• That there are NO spaces within names or times.
• That there are NO spaces after commas
• That the line with the definition starts and ends with a double quote (e.g. " ) - even if the definition itself spans several lines.

Starting the script:

After installation, you should be in the "kiwiclient/tools" directory.

Assuming that the script is called, to start ALL jobs, do:

./kiwiwspr.sh -j a    - Start ALL jobs
./kiwiwspr.sh -j z    - Stop ALL jobs
./kiwiwspr.sh -j s    - Show running jobs

At this point there should be no errors and you should see "users" called "kiwirecorder.py" appearing on the KiwiSDR on the bands you specify for the most recent time before the current time.  For example, if it is 11:00 and you have two jobs - one scheduled for 09:00 and another for 17:00, the 09:00 schedule will be executed.

If all goes well, you should then start the watchdog, which will allow the schedule to be executed.  If you do not start the watchdog, jobs that were running at the time you started them will continue to run and they will not change according to the schedule.

The watchdog is started/checked/stopped with the following commands:

./kiwiwspr.sh -z a      - Start all watchdog jobs
./kiwiwspr.sh -z z      - Kill all watchdog jobs
./kiwiwspr.sh -z s      - Show watchdog jobs

Use "kiwiwspr.sh" with no arguments for more information about the above commands - and for more information.

If all goes well you will, after 5-10 minutes - assuming that your KiwiSDR is connected to a working antenna and there are signals on the (bands) that you have selected and you have Internet connectivity - start seeing WSPR reports on "wsprnet.org" using the callsign specified in the "MyCall" field in the "kiwiwspr.conf" file in the "KIWI_LIST".

Remember:  A WSPR receiving interval starts at the beginning of each even minute and runs for almost 2 minutes.  It will then take another minute or so for wsprd to decode the WSPR transmissions and forward them to wsprnet.org where they may be displayed.

Final comments:


Remember that the above steps are for an up-to-date Ubuntu Linux distro running on a PC platform and there may be differences in how to install it on other distros/hardware platforms.  If you encounter difficulties, I probably won't be able to help:  I'd just do what you could do in that situation, and that is to refer to Google for a solution to the same/similar problem.

I would like to thank Rob Robinett for his hard work in producing the kiwiwspr script along with John Seamons for his very hard work on the KiwiSDR itself and making the "kiwirecorder" package available.

Best of luck!

* * * * * * * * * * *

[8 February, 2019]

Update:  "kiwiwspr" is now "wsprdaemon"

The "kiwiwspr" package has since been renamed the "wsprdaemon" package as its usefulness has been expanded beyond simply using a KiwiSDR.  As of the time of this update (8 February) its "new" capabilities include:

• Elimination of "duplicate" reception reports from "dirty" transmitters or from modulation caused by noise blankers:  Only the strongest report is used.
• Allowing the use of multiple receivers sharing the same frequency.  This is useful if one has several antennas and wish to submit only the report of the "best" signal of the lot.
• Using audio from a receiver via a sound card.

Even more features may have been added since this page was updated.
 
The configuration of the "multi receiver" aspect is documented in the "wsprdaemon.conf" that accompanies the script while the use of an audio input is beyond the scope of this document.

The modification has required some changes to the way the wsprdaemon package is installed as compared to old "kiwiwspr":

• The "~/wsprdaemon" directory is created and the wsprdaemon .sh and .conf files are put into it
• A "/dir/tmp/wspr-captures" directory is created.  If using a Raspberry Pi, this directory should use tmpfs file system or else you will "wear out" the SD card.  If using a computer with an SSD, you may still consider doing this.
• Use CHMOD to make sure that the wsprdaemon.sh file may be executed
• The configuration from the old "kiwiwspr.conf" file may be copied to, "wsprdaemon.conf" but the array "KIWI_LIST" should be renamed "RECEIVER_LIST".
• The newer "wsprdaemon.conf" includes a the ability to define in RECEIVER_LIST a virtual receiver consisting of several receivers.  If more than one receiver decodes the same transmission, only the reception with the best report is used.  (Even if a single receiver is used, this eliminates multiple reports as noted above.)
• For example, if you have defined "RX1" and "RX2" you can define "MERGED_RX1" as using "RX1" and "RX2".  One can use that virtual receiver name (e.g. "MERGED_RX1") in the scheduling and band definition.
• If you have previously been using "kiwirecorder", copy its directory tree into the "~/wsprdaemon" directory.
• If necessary, rename it from "~/wsprdaemon/kiwirecorder" to "~/wsprdaemon/kiwirecorder-jks-v0.1"
• To start wsprdaemon, use "./wsprdaemon -a"
• To stop wsprdaemon, use  "./wsprdaemon -z"

This page stolen from ka7oei.blogspot.com

[End]