Loading ...
Sorry, an error occurred while loading the content.

WSPR QSO Mode

Expand Messages
  • Joe Taylor
    Dear Friends of WSJT and WSPR, I write to bring you up to date on continuing evolution of the WSPR protocol and related software. As you have already heard, a
    Message 1 of 2 , May 23, 2008
    • 0 Attachment
      Dear Friends of WSJT and WSPR,

      I write to bring you up to date on continuing evolution of
      the WSPR protocol and related software.

      As you have already heard, a "QSO mode" for this weak-signal
      protocol is in the works. In fact, the first WSPR-mode QSO
      was made on May 6: K1JT worked W6CQZ on the 30 m band, using
      simple antennas and power levels of 1 W at each end of a
      4000 km path.

      The WSPR protocol is designed for use with extremely weak
      signals. It is suitable for making basic amateur contacts
      over any propagation path that provides S/N exceeding -30 dB
      in reference bandwidth 2500 Hz, with Doppler spreading less
      than about 1 Hz. Such paths should include most LF, MF, and
      HF paths of interest to amateurs, as well as the EME path at
      VHF.

      WSPR messages are structured to permit the efficient packing
      of callsigns, grid locators, signal reports,
      acknowledgments, and other information commonly exchanged in
      minimal QSOs. The protocol includes strong forward error
      correction (FEC) using a long-constraint convolutional code
      (K=32, rate=1/2). Messages are almost always received
      exactly as transmitted, or else the decoder declares "no
      result" by remaining silent. False decodes are extremely rare.

      WSPR users are already familiar with its beacon-like
      messages formatted according to the template

      call grid dBm

      In QSO mode, WSPR messages have a much richer variety of
      formats, as indicated by the templates and examples in the
      following list:

      Template Example of usage
      ------------------------------------------------
      CQ call grid CQ K1JT FN20
      CQ p/call CQ PJ4/K1JT

      <call1> call2 <K1JT> W6CQZ
      DE call grid DE W6CQZ CM87
      DE p/call DE PJ4/K1JT

      call1 <call2> rpt W6CQZ <K1JT> S4
      QRZ call QRZ K1JT
      p/call rpt PJ4/W6CQZ S4

      call1 <call2> R rpt K1JT <W6CQZ> R S3
      p/call R rpt PJ4/K1JT R S3

      <call1> call2 RRR <W6CQZ> K1JT RRR
      call1 <call2> RRR W6CQZ <K1JT> RRR
      DE p/call RRR DE PJ4/K1JT RRR

      73 DE call grid 73 DE W6CQZ CM87
      73 DE p/call 73 DE PJ4/K1JT
      TNX name 73 GL TNX VICTORIA 73 GL
      OP name 73 GL OP HARRY 73 GL
      pwr W DIPOLE 5 W DIPOLE
      pwr W VERTICAL 10 W VERTICAL
      pwr W gain DBD 1 W 0 DBD
      pwr W gain DBD 73 GL 1500 W 21 DBD 73 GL
      PSE QSY freq KHZ PSE QSY 1811 KHZ
      WX wx temp F/C wind WX SNOW -5 C CALM
      freetext CUL JACK


      Upper-case letters and numerals are conveyed exactly as
      shown in the templates. Lower-case items are replaced by
      appropriate information, for example call=K1JT, grid=FN20,
      rpt=S1 to S9, name=HARRY, freetext="CUL JACK", etc., as
      shown in the examples.

      Messages may contain one full callsign and one "hash-coded"
      callsign. The transmission of hash codes is indicated by
      angle-brackets surrounding the call, as in <K1JT>; the
      brackets appear in displays of both transmitted and received
      messages. Since hashing is a many-to-one mapping, the
      process is not reversible. However, if a full callsign has
      been decoded in a previous transmission, the decoder may
      assume that a matching hash code usually implies matching
      callsigns. With a 15-bit hash code the chances of
      mis-identification are very small, especially within the
      confines of a particular QSO.

      A minimal QSO using WSPR mode might look like the following
      sequence of messages:

      1. CQ K1JT FN20
      2. <K1JT> W6CQZ
      3. W6CQZ <K1JT> S4
      4. K1JT <W6CQZ> R S3
      5. <W6CQZ> K1JT RRR
      6. TNX JOE 73 GL

      A third-party operator listening to this QSO from the
      beginning would copy everything just as the participating
      stations do. Even if only one of the QSO partners can be
      copied at the third station, both callsigns will be received
      in full. If the third-party operator tunes into the middle
      of a QSO, so that his decoder cannot yet identify one of the
      hashed callsigns, it will produce something like

      W6CQZ <...> S4

      instead of the full message. He must then stay tuned to
      determine the identity of the missing callsign. There will
      be no ambiguities at all for the QSO partners themselves.
      Full callsigns are always decoded (or already available, in
      the case of one’s own call) before their hash codes are needed.

      Signal report S1 corresponds to "-30 dB" on the WSJT scale,
      S2=-27 dB, S3=-24 dB, etc., up to S9=-6 dB. On this scale,
      the threshold for signal audibility is around S5 to S6. The
      placeholder "p/" stands for an add-on prefix or suffix in
      compound callsigns like ZB2/DF2ZC or DH7FB/P. Information
      conveying the add-on prefix or suffix replaces the
      information that would otherwise convey a grid locator or
      hashed callsign.

      Items "pwr", "gain", "freq", and "temp" stand for numbers.
      A 2m EME station might send

      1500 W 21 DBD 73 GL

      to inform his QSO partner about his equipment, at the end of
      a QSO. Similarly, a QRP HF station might send

      1 W 0 DBD

      or

      5 W DIPOLE

      If he finishes a QSO on 80 m and wants to try 160 m next, an
      operator might send

      PSE QSY 1811 KHZ

      Names may contain up to 9 letters, and "freetext" may
      contain any combination of 8 or fewer letters, numerals,
      spaces, and the punctuation marks + . / ?.

      Space has been reserved in the WSPR protocol for many more
      "canned" or "partially canned" messages like those in the
      final group of templates. I hereby solicit suggestions for
      messages that might be included in this group. Note that
      the variable information to be inserted in a given message
      type should be no more than one, two, or possibly three
      numbers or words. Please help me to populate the list
      of message types in the most useful way.

      In addition to the QSO-mode messages described above, a new
      format will be provided so that true beacon stations can
      transmit solar/geomagnetic/ionospheric data (K-index, MUF,
      events in progress, events expected) in a compact and useful
      form.

      Although the first WSPR-mode QSO was made with a special
      version of the WSPR program, future evolution will most
      likely follow a different path. It seems best to keep the
      WSPR program relatively simple and intended for automatic,
      quasi-beacon-like transmission and reception of
      propagation-probing signals. The next released version of
      WSPR will be capable of decoding all of the new messages,
      however. For use in making WSPR QSOs, support for the full
      WSPR protocol will be added to a future version of WSJT.
      This seems desirable because WSJT already has all of the
      necessary amenities for setting up messages, controlling the
      Tx/Rx sequences, etc.

      How will WSPR compare in sensitivity with other weak signal
      communication modes? Under the assumption of additive white
      gaussian noise, no QSB, and negligible Doppler spreading,
      the following table applies:

      Mode Threshold Comments
      S/N
      ----------------------------------------------------
      CW -18 dB Best human operators
      JT65B -24 KV decoder
      JT65B -27 Avg of 3 transmissions, KV decoder
      JT65B -28 Deep Search
      WSPR -29
      WSPR -32 Avg of 3 transmissions

      It should be noted that JT65 uses 1-minute T/R sequences
      while WSPR uses 2-minute sequences. The occupied bandwidth
      of a WSPR signal is about 6 Hz, about 60 times smaller than
      the JT65B bandwidth.


      Technical Details
      -----------------------------------------------------------------------
      For those with technical interest in the WSPR protocol, here
      are a few additional details. The WSPR message "payload" is
      50 information bits per transmission. Most of the message
      formats use 28 bits for a standard callsign and 15 bits for
      a hash-coded callsign or grid locator. The remaining 7 bits
      convey signal reports, acknowledgments, power levels, and
      special message types. Special messages may use the first
      43 bits for any dedicated purpose.

      The WSPR protocol uses continuous-phase 4-tone FSK with tone
      spacing and keying rate both equal to 12000/8192 = 1.46 Hz.
      Each transmission contains (50+K-1)*2 = 162 channel
      symbols, and each symbol conveys a data bit (MSB) and a
      time-and-frequency synchronizing bit (LSB). Transmissions
      last for 162*8192/12000 = 110.6 s. The occupied bandwidth
      of a WSPR signal is about 6 Hz.


      Open Source
      ------------------------------------------------------------------------
      You probably already know that WSJT, WSPR, and MAP65 are
      open-source programs licensed under the GNU General Public
      License. Source code is stored in a public repository at
      developer.berlios.de/projects/wsjt/. If you are interested
      in contributing to the development of these programs, please
      send me email. We also solicit your comments and
      suggestions on the plans outlined above!

      With best wishes,

      -- 73, Joe, K1JT
    • Maxwell Jonas
      Hi Joe, Has there been any consideration on driving some signals to a parallel port for outside keying? I have a DDS driven MELF transmitter that I am working
      Message 2 of 2 , May 28, 2008
      • 0 Attachment
        Hi Joe,

        Has there been any consideration on driving some
        signals to a parallel port for outside keying? I have
        a DDS driven MELF transmitter that I am working on,
        and it would be much simpler to take a BCD or binary
        byte/bits from the parallel port and change the
        frequency of the DDS appropriately. This signal could
        also be used in non-DDS VFOs by keying in voltages to
        a varactor to change the oscillator frequency.

        This would also be handy for the other WSJT modes as
        well.

        Otherwise I need to design an SSB exciter or A/D
        converter. Kinda overkill for a small QRPP
        transmitter.

        Thanks and 73,

        Brian - K0IK
      Your message has been successfully submitted and would be delivered to recipients shortly.