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

WSJT-X - No decodes after brief TX

Expand Messages
  • k3wyc
    This isn t a new issue and it s been bugging me for ages. Thought is was time to ask about it. WSJT-X will decode a good JT65 or JT9 signal if just over half
    Message 1 of 19 , Mar 20, 2014

      This isn't a new issue and it's been bugging me for ages.  Thought is was time to ask about it.

      WSJT-X will decode a good JT65 or JT9 signal if just over half of the transmission is  received.  However, if a message transmission, or a tune,  is made during the receive cycle, no matter how brief, then no decode is attempted.

      Is there a reason that no decode is attempted or is it an accident of the implementation?

      Would it be possible to modify WSJT-X so that a decode is attempted if the transmission was, for example, less than 5 seconds out of the receive period?


      Thanks and 73,

      Andy k3wyc



    • Alexandre Moleiro
      Hi. I believe some time ago here on this list, Joe K1JT, agreed that it is annoying and there is no theoretical reason for it. Don t know if it s high priority
      Message 2 of 19 , Mar 21, 2014
        Hi.

        I believe some time ago here on this list, Joe K1JT, agreed that it is annoying and there is no theoretical reason for it.
        Don't know if it's high priority or not...

        73 de Alex - CT1GVN



        On Thursday, March 20, 2014 4:52 PM, "a.durbin@..." <a.durbin@...> wrote:
         
        This isn't a new issue and it's been bugging me for ages.  Thought is was time to ask about it.
        WSJT-X will decode a good JT65 or JT9 signal if just over half of the transmission is  received.  However, if a message transmission, or a tune,  is made during the receive cycle, no matter how brief, then no decode is attempted.
        Is there a reason that no decode is attempted or is it an accident of the implementation?
        Would it be possible to modify WSJT-X so that a decode is attempted if the transmission was, for example, less than 5 seconds out of the receive period?

        Thanks and 73,
        Andy k3wyc




      • Joe
        An excerpt from a request I posted on this list on 11/17/2013 02:31 AM 1. I would like the receive process and decode continue even if a transmission was
        Message 3 of 19 , Mar 21, 2014
          An excerpt from a request I posted on this list on 11/17/2013 02:31 AM


          1.  I would like the receive process and decode continue even if a transmission was started at the top of the minute and aborted.  In addition if during a receive period the transmit function was started after the top of the minute and then stopped prior to the end of the receive period.

          I believe that this requested behavior was the norm with some earlier releases.  The advantage in the first scenario is not to experience a "Lost Minute" when you don't see that a station you are calling went back to someone else.  In the second case something simple such as setting the table to call a station by double clicking his call makes you blind as to what is occurring during that minute. 

          The program knows when it is transmitting and when it is receiving and what second/millisecond into the cycle it is at.  Stopping and restarting a transmission during the minute (to force a change of the message content?) seems to work, I'm just saying that a similar capability would be useful for the cases mentioned above.

          end excerpt

          My recollection is that at one time (probably when using JT65-HF) a transmission during the reception period did not stop decodes.

          Joe, K9HDE

          Alexandre wrote:
          
          1b. Re: WSJT-X - No decodes after brief TX
              Posted by: "Alexandre Moleiro" avataranedotas@... avataranedotas
              Date: Fri Mar 21, 2014 5:36 am ((PDT))
          
          Hi.
          
          I believe some time ago here on this list, Joe K1JT, agreed that it is annoying and there is no theoretical reason for it.
          Don't know if it's high priority or not...
          
          73 de Alex - CT1GVN
          
          
          
          On Thursday, March 20, 2014 4:52 PM, "a.durbin@..." <a.durbin@...> wrote: This isn't a new issue and it's been bugging me for ages.  Thought is was time to ask about it. WSJT-X will decode a good JT65 or JT9 signal if just over half of the transmission is  received.  However, if a message transmission, or a tune,  is made during the receive cycle, no matter how brief, then no decode is attempted. Is there a reason that no decode is attempted or is it an accident of the implementation? Would it be possible to modify WSJT-X so that a decode is attempted if the transmission was, for example, less than 5 seconds out of the receive period? Thanks and 73, Andy k3wyc
        • k3wyc
          The failure to decode after a very brief TX during that minute still seems to happen in the latest version r7052. Would someone on the development team please
          Message 4 of 19 , Sep 3, 2016
            The failure to decode after a very brief TX during that minute still seems to happen in the latest version r7052.

            Would someone on the development team please explain whether this is a design choice and , if so, please explain the reasons behind it.

            If it is not a design choice could it perhaps be fixed before 1.7 release.

            Thanks and 73,
            Andy k3wyc


            ---In wsjtgroup@yahoogroups.com, <a.durbin@...> wrote :

            This isn't a new issue and it's been bugging me for ages.  Thought is was time to ask about it.

            WSJT-X will decode a good JT65 or JT9 signal if just over half of the transmission is  received.  However, if a message transmission, or a tune,  is made during the receive cycle, no matter how brief, then no decode is attempted.

            Is there a reason that no decode is attempted or is it an accident of the implementation?

            Would it be possible to modify WSJT-X so that a decode is attempted if the transmission was, for example, less than 5 seconds out of the receive period?


            Thanks and 73,

            Andy k3wyc



          • Carter
            ... I have experienced the same issue using vers 1.6 of WSJT-X and would also be interested in some words of wisdom on this topic. 73, Carter K8VT ... This
            Message 5 of 19 , Sep 4, 2016
              On 9/3/2016 3:15 PM, a.durbin@... [wsjtgroup] wrote:
               
              ---In wsjtgroup@yahoogroups.com, <a.durbin@...> wrote :

              This isn't a new issue and it's been bugging me for ages.  Thought is was time to ask about it.

              WSJT-X will decode a good JT65 or JT9 signal if just over half of the transmission is  received.  However, if a message transmission, or a tune,  is made during the receive cycle, no matter how brief, then no decode is attempted.

              Is there a reason that no decode is attempted or is it an accident of the implementation?

              Would it be possible to modify WSJT-X so that a decode is attempted if the transmission was, for example, less than 5 seconds out of the receive period?


              Thanks and 73,

              Andy k3wyc


              I have experienced the same issue using vers 1.6 of WSJT-X and would also be interested in some words of wisdom on this topic.

              73,
              Carter   K8VT



              Avast logo

              This email has been checked for viruses by Avast antivirus software.
              www.avast.com


            • k3wyc
              I know everyone on the development team is busy but it would be nice if someone would answer this. Why does wsjt-x inhibit decode if any TX, however short, is
              Message 6 of 19 , Sep 12, 2016
                I know everyone on the development team is busy but it would be nice if someone would answer this.

                Why does wsjt-x inhibit decode if any TX, however short,  is made during the RX period?

                Are there any plans to change this?   Even enabling decode attempts only if the TX ended in the first 10 seconds of the minute would be a significant operational advantage.

                Thanks and 73,
                Andy k3wyc
              • Black Michael
                I just did a test by commenting out the suspendAudioInputStream in mainwindow.cpp Test is with a Signalink.I was able to start transmitting for 10 seconds into
                Message 7 of 19 , Sep 12, 2016
                  I just did a test by commenting out the suspendAudioInputStream in mainwindow.cpp

                  Test is with a Signalink.
                  I was able to start transmitting for 10 seconds into the minute, halt it, and decodes were successful for that minute.
                  I then tested transmitting from 20-30 seconds into the minute and it did not decode.

                  I think you'll find some audio devices don't like writing and reading at the same time but it does seem to work for the Signalink

                  Perhaps some logic like > 50% transmit don't try to decode?  Or just let it do it's thing all the time?
                  Would have to be an option you turn on of course and looks like you could just let it try and decode very minute....if your audio loops back to you though you could be decoding yourself.

                  de Mike W9MDB




                  From: "a.durbin@... [wsjtgroup]" <wsjtgroup-noreply@yahoogroups.com>
                  To: wsjtgroup@yahoogroups.com
                  Sent: Monday, September 12, 2016 2:25 PM
                  Subject: Re: [wsjtgroup] Re: WSJT-X - No decodes after brief TX

                   
                  I know everyone on the development team is busy but it would be nice if someone would answer this.

                  Why does wsjt-x inhibit decode if any TX, however short,  is made during the RX period?

                  Are there any plans to change this?   Even enabling decode attempts only if the TX ended in the first 10 seconds of the minute would be a significant operational advantage.

                  Thanks and 73,
                  Andy k3wyc


                • AG0N-3055
                  ... I ve seen that many times in both 10 and X. I run monitor on, which is also fed back to the program with RX audio. Gary -- Web: http://ag0n.net NodeOp
                  Message 8 of 19 , Sep 12, 2016
                    > if your audio loops back to you though you could be decoding yourself.

                    I've seen that many times in both 10 and X. I run monitor on, which is also fed
                    back to the program with RX audio.

                    Gary
                    --
                    Web: http://ag0n.net
                    NodeOp Page: http://ag0n.net/irlp
                    Node 3055: http://ag0n.net/irlp/3055
                  • Robert Nobis
                    Mike, I also tried that with a SignaLink and my KX3, but didn’t get the same results as you. Even a one-second transmission during the first 5 to 10 seconds
                    Message 9 of 19 , Sep 12, 2016
                      Mike, I also tried that with a SignaLink and my KX3, but didn’t get the same results as you.  Even a one-second transmission during the first 5 to 10 seconds of a cycle, results in no decoding for that period.

                      73,


                      Bob Nobis - N7RJN
                      n7rjn@...


                      On Sep 12, 2016, at 14:21, Black Michael mdblack98@... [wsjtgroup] <wsjtgroup-noreply@yahoogroups.com> wrote:


                      I just did a test by commenting out the suspendAudioInputStream in mainwindow.cpp

                      Test is with a Signalink.
                      I was able to start transmitting for 10 seconds into the minute, halt it, and decodes were successful for that minute.
                      I then tested transmitting from 20-30 seconds into the minute and it did not decode.

                      I think you'll find some audio devices don't like writing and reading at the same time but it does seem to work for the Signalink

                      Perhaps some logic like > 50% transmit don't try to decode?  Or just let it do it's thing all the time?
                      Would have to be an option you turn on of course and looks like you could just let it try and decode very minute....if your audio loops back to you though you could be decoding yourself.

                      de Mike W9MDB




                      From: "a.durbin@... [wsjtgroup]" <wsjtgroup-noreply@yahoogroups.com>
                      To: wsjtgroup@yahoogroups.com 
                      Sent: Monday, September 12, 2016 2:25 PM
                      Subject: Re: [wsjtgroup] Re: WSJT-X - No decodes after brief TX

                       
                      I know everyone on the development team is busy but it would be nice if someone would answer this.

                      Why does wsjt-x inhibit decode if any TX, however short,  is made during the RX period?

                      Are there any plans to change this?   Even enabling decode attempts only if the TX ended in the first 10 seconds of the minute would be a significant operational advantage.

                      Thanks and 73,
                      Andy k3wyc




                    • Carter
                      ... Sorry, I did not do any timing tests, but it seems like if I go to transmit, however briefly, any time within the receive cycle, it will not decode. WSJT-X
                      Message 10 of 19 , Sep 12, 2016
                        On 9/12/2016 5:31 PM, Robert Nobis N7RJN@... [wsjtgroup] wrote:
                         

                        Mike, I also tried that with a SignaLink and my KX3, but didn’t get the same results as you.  Even a one-second transmission during the first 5 to 10 seconds of a cycle, results in no decoding for that period.


                        73,


                        Bob Nobis - N7RJN
                        n7rjn@...

                        Sorry, I did not do any timing tests, but it seems like if I go to transmit, however briefly, any time within the receive cycle, it will not decode.

                        WSJT-X 1.6.0, RigBlaster Advantage, JTALert 2.8.1, Win 10, FT-1000MP [see note below]

                        I mention the rig only because this causes the issue described above (why I xmt in a rcv cycle). Very occasionally, when ending the WSJT xmt cycle and then going to receive, there is no receive (or it is down so far that it seems like no rcv). The fix is clicking on the WSJT "tune" button for just a second. The good news is, this restores rcv; the bad news is, no decode for that rcv cycle.

                        At first, I suspected the rig, a bad T/R relay maybe -- but this loss of rcv NEVER occurs in any other mode, PSK 31, CW, etc. I also recall one other person describing the same problem (of rcv going dead) with a 1000MP in the JT mode.

                        73,
                        Carter   K8VT


                        On Sep 12, 2016, at 14:21, Black Michael mdblack98@... [wsjtgroup] <wsjtgroup-noreply@yahoogroups.com> wrote:


                        I just did a test by commenting out the suspendAudioInputStream in mainwindow.cpp

                        Test is with a Signalink.
                        I was able to start transmitting for 10 seconds into the minute, halt it, and decodes were successful for that minute.
                        I then tested transmitting from 20-30 seconds into the minute and it did not decode.

                        I think you'll find some audio devices don't like writing and reading at the same time but it does seem to work for the Signalink

                        Perhaps some logic like > 50% transmit don't try to decode?  Or just let it do it's thing all the time?
                        Would have to be an option you turn on of course and looks like you could just let it try and decode very minute....if your audio loops back to you though you could be decoding yourself.

                        de Mike W9MDB




                        From: "a.durbin@... [wsjtgroup]" <wsjtgroup-noreply@yahoogroups.com>
                        To: wsjtgroup@yahoogroups.com 
                        Sent: Monday, September 12, 2016 2:25 PM
                        Subject: Re: [wsjtgroup] Re: WSJT-X - No decodes after brief TX

                         
                        I know everyone on the development team is busy but it would be nice if someone would answer this.

                        Why does wsjt-x inhibit decode if any TX, however short,  is made during the RX period?

                        Are there any plans to change this?   Even enabling decode attempts only if the TX ended in the first 10 seconds of the minute would be a significant operational advantage.

                        Thanks and 73,
                        Andy k3wyc








                        Avast logo

                        This email has been checked for viruses by Avast antivirus software.
                        www.avast.com


                      • Joe Taylor
                        Hi Andy and all, You have asked this question many times, it seems. The simple answer is that changing this behavior has not seemed important enough to rise
                        Message 11 of 19 , Sep 13, 2016
                          Hi Andy and all,

                          You have asked this question many times, it seems. The simple answer is
                          that changing this behavior has not seemed important enough to rise to
                          the top of anyone's prioritized "ToDo" list. All of us have (in our
                          judgment) had more important tasks to work on.

                          -- Joe, K1JT

                          On 9/12/2016 3:25 PM, a.durbin@... [wsjtgroup] wrote:
                          > I know everyone on the development team is busy but it would be nice if someone would answer this.
                          >
                          > Why does wsjt-x inhibit decode if any TX, however short, is made during the RX period?
                          >
                          >
                          > Are there any plans to change this? Even enabling decode attempts only if the TX ended in the first 10 seconds of the minute would be a significant operational advantage.
                          >
                          >
                          > Thanks and 73,
                          > Andy k3wyc
                        • 'DGB'
                          Is there a way to import the .adi file from my logging program, DXKeeper, into WSJT-X so it accurately reflects the DX colors, instead of just from the date
                          Message 12 of 19 , Sep 13, 2016
                            Is there a way to import the .adi file from my logging program,
                            DXKeeper, into WSJT-X so it accurately reflects the DX colors, instead
                            of just from the date that I started using/installing WSJT-X?

                            tnx 73 Dwight NS9I
                          • Black Michael
                             Have you tried JTAlert?  It does that plus more. de Mike W9MDB From: DGB ns9i2016@bayland.net [wsjtgroup] To: Joe
                            Message 13 of 19 , Sep 13, 2016
                               Have you tried JTAlert?  It does that plus more.

                              de Mike W9MDB




                              From: "'DGB' ns9i2016@... [wsjtgroup]" <wsjtgroup-noreply@yahoogroups.com>
                              To: Joe Taylor <joe@...>; wsjtgroup@yahoogroups.com
                              Sent: Tuesday, September 13, 2016 9:14 AM
                              Subject: [wsjtgroup] WSJT-X v7

                               
                              Is there a way to import the .adi file from my logging program,
                              DXKeeper, into WSJT-X so it accurately reflects the DX colors, instead
                              of just from the date that I started using/installing WSJT-X?

                              tnx 73 Dwight NS9I



                            • k3wyc
                              Hi Joe, I think I have asked 3 times but this is the first time anyone has answered. I assume from your reply that the behavior could be changed if you wished
                              Message 14 of 19 , Sep 13, 2016
                                Hi Joe,

                                I think I have asked 3 times but this is the first time anyone has answered. 

                                I assume from your reply that the behavior could be changed if you wished it to be.  Hopefully if others would like the behavior changed they will speak up.  

                                Would you please consider adding a caution to the user guide that explains that any TX, message or Tune, during the RX period will inhibit any decode for that RX period.

                                Thanks and 73,
                                Andy k3wyc
                              • James Bennett
                                Joe, Andy, et All, I ve been in the background, reading these requests, certain that I m not alone, and hoping that it would be acted on. Guess it s time to
                                Message 15 of 19 , Sep 13, 2016
                                  Joe, Andy, et All,

                                  I've been in the background, reading these requests, certain that I'm not alone, and hoping that it would be acted on. Guess it's time to put in my two centavos worth. I agree - being able to give a very short "tune" burst without having the decode period rendered worthless would be great. The autotuners in my shack respond to a quick sip of RF and set the correct LC for that band segment. The way it is now, changing bands entails pausing WSJT-X, putting the radio into CW mode, going to a non-WSJT frequency close by, keying the rig to tickle the tuner, going back to Data mode, and then re-enabling WSJT-X monitoring.

                                  I have a K3 coupled to a KAT500 and this isn't a problem, as the two exchange band info without having to send an RF burst. So, running WSJT-X with that combo wouldn't need the program change. But, most often I'm using a KX3/KPA500/KAT500 setup to get my power level up to about 20 watts or so. The KX3 does not share band info with the tuner - it has to send a short burst to the tuner to get things set, so I have to go through the sequence noted above.

                                  Anyway, this certainly isn't a make or break change - just something that would be nice to have. 

                                  Jim Bennett / W6JHB
                                  Folsom, CA

                                  On Sep 13, 2016, at 7:46 AM, a.durbin@... [wsjtgroup] <wsjtgroup-noreply@yahoogroups.com> wrote:

                                   

                                  Hi Joe,


                                  I think I have asked 3 times but this is the first time anyone has answered. 

                                  I assume from your reply that the behavior could be changed if you wished it to be.  Hopefully if others would like the behavior changed they will speak up.  

                                  Would you please consider adding a caution to the user guide that explains that any TX, message or Tune, during the RX period will inhibit any decode for that RX period.

                                  Thanks and 73,
                                  Andy k3wyc

                                • 'DGB'
                                  I agree that behavior is annoying. Would like it fixed as well. I don t think that was always there. 73 Dwight NS9I
                                  Message 16 of 19 , Sep 13, 2016

                                    I agree that behavior is annoying. Would like it fixed as well. I don't think that was always there.


                                    73 Dwight NS9I


                                    On 9/13/2016 10:41 AM, James Bennett w6jhb@... [wsjtgroup] wrote:
                                     
                                    Joe, Andy, et All,

                                    I've been in the background, reading these requests, certain that I'm not alone, and hoping that it would be acted on. Guess it's time to put in my two centavos worth. I agree - being able to give a very short "tune" burst without having the decode period rendered worthless would be great. The autotuners in my shack respond to a quick sip of RF and set the correct LC for that band segment. The way it is now, changing bands entails pausing WSJT-X, putting the radio into CW mode, going to a non-WSJT frequency close by, keying the rig to tickle the tuner, going back to Data mode, and then re-enabling WSJT-X monitoring.

                                    I have a K3 coupled to a KAT500 and this isn't a problem, as the two exchange band info without having to send an RF burst. So, running WSJT-X with that combo wouldn't need the program change. Bu t, most often I'm using a KX3/KPA500/KAT500 setup to get my power level up to about 20 watts or so. The KX3 does not share band info with the tuner - it has to send a short burst to the tuner to get things set, so I have to go through the sequence noted above.

                                    Anyway, this certainly isn't a make or break change - just something that would be nice to have. 

                                    Jim Bennett / W6JHB
                                    Folsom, CA

                                    On Sep 13, 2016, at 7:46 AM, a.durbin@... [wsjtgroup] <wsjtgroup-noreply@yahoogroups.com> wrote:

                                     

                                    Hi Joe,


                                    I think I have asked 3 times but this is the first time anyone has answered. 

                                    I assume from your reply that the behavior could be changed if you wished it to be.  Hopefully if others would like the behavior changed they will speak up.  

                                    Would you please consider adding a caution to the user guide that explains that any TX, message or Tune, during the RX period will inhibit any decode for that RX period.

                                    Thanks and 73,
                                    Andy k3wyc

                                  • Joe Taylor
                                    Hi Andy and all, ... One way to maximize the chance that your wish list items might be acted on sooner (rather than later or never) is to contribute your own
                                    Message 17 of 19 , Sep 13, 2016
                                      Hi Andy and all,

                                      K3WYC wrote:
                                      > I think I have asked 3 times but this is the first time anyone has answered.
                                      >
                                      > I assume from your reply that the behavior could be changed if you
                                      > wished it to be. Hopefully if others would like the behavior changed
                                      > they will speak up.
                                      >
                                      > Would you please consider adding a caution to the user guide that explains
                                      > that any TX, message or Tune, during the RX period will inhibit any decode
                                      > for that RX period.

                                      One way to maximize the chance that your "wish list" items might be
                                      acted on sooner (rather than later or never) is to contribute your own
                                      significant effort.

                                      If you have programming skills, become familiar with the WSJT-X code,
                                      make and test a patch to implement your idea, and submit the patch for
                                      possible approval and adoption. Some changes are not as hard as you
                                      might think.

                                      Anyone can have opinions on documentation. If you find ways in which
                                      the documentation might be improved, do your homework thoroughly enough
                                      that you can make an informed (if tentative) decision about where the
                                      change might be made, draft some text that does what you want, and
                                      submit that for possible approval and adoption.

                                      Please remember that it is vastly easier to think of a way in which a
                                      product like WSJT-X might be improved, than to actually make the
                                      improvement. Consider also the "cost" to the development effort of
                                      asking one of us to respond to your email and/or work on an item that
                                      presently interests you most.

                                      Please don't misunderstand: I am NOT trying to dissuade anyone from
                                      making good suggestions about WSJT-X. Rather, I'm trying to guide users
                                      toward thinking more in terms of "giving back" something to the project,
                                      when they can. We're always on the lookout for helpful contributions!

                                      -- 73, Joe, K1JT
                                    • Black Michael
                                      So what s the trick to implementing this?  I guess it s not a simple thing? de Mike W9MDB #yiv5201811864 #yiv5201811864 -- #yiv5201811864ygrp-mkp {border:1px
                                      Message 18 of 19 , Sep 13, 2016
                                        So what's the trick to implementing this?  I guess it's not a simple thing?

                                        de Mike W9MDB



                                      • k3wyc
                                        Joe, My experience is in integrated system specification and test. I have attempted to contribute to the project by reporting perceived anomalies and by
                                        Message 19 of 19 , Sep 13, 2016
                                          Joe,

                                          My experience is in integrated system specification and test.    I have attempted to contribute to the project by reporting perceived anomalies and by following up with test data when required. 

                                          My code skills would likely set the project back years.  Even if I could have patched the code to enable decode after TX I would not have done so without understanding why the inhibit was there in the first place.  i suspect it's an unintended side effect of the way the TX/RX state switching was implement but my understanding of the code structure is far short of the level needed to verify that.

                                          I am half way through a review of the user guide.  I'll let you have my comments when it's completed.

                                          73,
                                          Andy k3wyc


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