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

WSJT-X / WSJT Feature Request

Expand Messages
  • ki7mt
    Hi Joe, All, Before I begin, this has nothing to do with running too much power, using stacked arrays for gain, over driven TX etc etc etc. Using most modern
    Message 1 of 4 , Apr 8, 2013
    • 0 Attachment
      Hi Joe, All,

      Before I begin, this has nothing to do with running too much power, using stacked arrays for gain, over driven TX etc etc etc.

      Using most modern rig controls, EDSP, VRF, Notch, DNR, DNF, Contour, Shift, etc etc etc is a big help on a crowded band, but they cannot deal with each signal individually. I've been using these features allot more on WSJT, WSJT-X & JT65HF recently, and it has helped a great deal. Running a rig wide open, in crowded band segments, is just asking for aggravation :-)

      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.

      I don't know how practical it would be in the wider modes such as JT65 or the wider JT9 modes, but it seems to me, the narrow bandwidth of JT9-1 would benefit from a multi-notch feature that could be activated/deactivated against the waterfall on a given strong signal or even multiple notch filters for several strong stations.

      If we could somehow knock down or tame the strong signals to a manageable level, would certainly make decoding weaker signals in a crowded band allot easier.

      73's Greg, KI7MT
    • 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 2 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 3 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 4 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.