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

Re: [wsjtgroup] WSJT-X / WSJT Feature Request

Expand Messages
  • Joe Subich, W4TV
    ... An audio notch in the decoder software is of dubious value - it is outside the receiver s AGC loop and occurs after the soundcard ADC (as well as and ADC
    Message 1 of 4 , Apr 8, 2013
    • 0 Attachment
      On 4/8/2013 6:36 PM, ki7mt wrote:
      > I use N1MM Logger for contesting, and one feature I find very useful
      > in digital mode contests (PSK in particular) is the Notch feature
      > within MMVARI. It doesn't fix all the issues in a crowded band, but
      > certainly can make the difference between working a new one, and
      > having to QSY to avoid a strong signal coming from the same direction
      > as the station your trying to work.

      An audio notch in the decoder software is of dubious value - it is
      outside the receiver's AGC loop and occurs after the soundcard ADC
      (as well as and ADC in the transceiver's DSP circuitry). In the
      digital software it can not address issues of sound card, DSP or
      transceiver dynamic range.

      It is far more valuable for the software to function well with a
      audio passband (e.g. 100 or 200 Hz) as WSJT-X does rather than require
      the entire 200-2800 Hz audio passsband as is the case with JT65-HF.
      With the ability to function properly at narrow bandwidth, one can
      narrow filters in the transceiver IF to reject exceptionally strong
      adjacent channel signals - and even prevent them from desensing the
      system.

      73,

      ... Joe, W4TV
    • kc2wuf
      The use I see for it would be to eliminate QRM (i.e. RTTY in all cases, JT65 in the case of WSJT-X and JT9 in the case of WSJT) in the middle of the decode
      Message 2 of 4 , Apr 11, 2013
      • 0 Attachment
        The use I see for it would be to eliminate QRM (i.e. RTTY in all cases, JT65 in the case of WSJT-X and JT9 in the case of WSJT) in the middle of the decode band from attempting to be decoded. In the case of RTTY and JT65 the notch would have to be rather wide, at least 200 Hz, and would only be necessary if the QRM showed up in the middle of the decode band and there were signals of interest both below and above the QRM. I only say this because the decode time when this type of QRM is present greatly increases the number of false potential signals to decode.

        I rarely see this problem as the RTTY QRM is usually at the upper end of the JT9 decode band and can be filtered with the new fMin and fMax parameters. However, I have seen JT65 QRM in the middle of the WSJT-X decode band on occasion. I assume they are being sent by someone using both WSJT-X and JT65-HF at the same time. I often have both programs running at the same time, but QSY when using the other program.

        73 David KC2WUF
      • Joe Taylor
        ... By far the best way to handle QRM from non-JT9 signals is for the decoder to have enough smarts to recognize the interloper and ignore it. For this to be
        Message 3 of 4 , Apr 11, 2013
        • 0 Attachment
          On 4/11/2013 12:42 PM, kc2wuf wrote:
          > The use I see for it would be to eliminate QRM (i.e. RTTY in all cases, JT65 in the case of WSJT-X and JT9 in the case of WSJT) in the middle of the decode band from attempting to be decoded. In the case of RTTY and JT65 the notch would have to be rather wide, at least 200 Hz, and would only be necessary if the QRM showed up in the middle of the decode band and there were signals of interest both below and above the QRM. I only say this because the decode time when this type of QRM is present greatly increases the number of false potential signals to decode.
          >
          > I rarely see this problem as the RTTY QRM is usually at the upper end of the JT9 decode band and can be filtered with the new fMin and fMax parameters. However, I have seen JT65 QRM in the middle of the WSJT-X decode band on occasion. I assume they are being sent by someone using both WSJT-X and JT65-HF at the same time. I often have both programs running at the same time, but QSY when using the other program.

          By far the best way to handle QRM from non-JT9 signals is for the
          decoder to have enough smarts to recognize the interloper and ignore it.
          For this to be useful, it has to be done without much degradation in
          decoding speed.

          If you (or anyone) has recorded an example file in which the present
          "smarts" are inadequate -- too much time is waster on the interloper
          signal -- please send me the file.

          -- Joe, K1JT
        Your message has been successfully submitted and would be delivered to recipients shortly.