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

Re: V4 GUI improvement proposal

Expand Messages
  • SV1UY
    Hi Rick again, After reading your reply and realising that the changes need quiter a bit of programming and since the conctents of the 3rd window I propose are
    Message 1 of 30 , Sep 5, 2011
    View Source
    • 0 Attachment
      Hi Rick again,

      After reading your reply and realising that the changes need quiter a bit of programming and since the conctents of the 3rd window I propose are printed in the top window with a different font I will not insist. The program is OK as it is. The only problem I see is the change over mechanism, but then again the IRS station will attempt to seize the link after a full sentence has been typed in the buffer and the other guy has nothing else to send. I noticed this in my QSO with OH7TE yesterday. The only drawback in this is that if the other guy is a fast typist, you will never get the chance to become ISS until the other guy eventually stops typing. When I have a PACTOR QSO every word I type is sent and I can see it echoed back in a 3rd window. My station does not send the whole buffer as a big packet when I hit ENTER.

      73 de Demetre SV1UY

      --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
      >
      > Demetre,
      > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
      >
      > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
      > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
      >
      > The basic rule is simply this:
      > The ISS stays the ISS UNTIL:
      > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
      > AND
      > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
      >
      > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
      >
      > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
      >
      > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
      >
      > 73,
      >
      > Rick KN6KB
    • la7um
      Rick. I know a ham friend beeing colour blind seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra
      Message 2 of 30 , Sep 6, 2011
      View Source
      • 0 Attachment
        Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

        73 Finn/LA7UM

        --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
        >
        > Demetre,
        > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
        >
        > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
        > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
        >
        > The basic rule is simply this:
        > The ISS stays the ISS UNTIL:
        > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
        > AND
        > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
        >
        > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
        >
        > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
        >
        > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
        >
        > 73,
        >
        > Rick KN6KB
        >
        > .
        >
      • Rick Westerfield
        I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was
        Message 3 of 30 , Sep 6, 2011
        View Source
        • 0 Attachment
          I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.

           I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.

          Many thanks. It really is good code in all other respects.

          Rick KH2DF

          Sent from my iPhone

          On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:

           

          Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

          73 Finn/LA7UM

          --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
          >
          > Demetre,
          > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
          >
          > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
          > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
          >
          > The basic rule is simply this:
          > The ISS stays the ISS UNTIL:
          > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
          > AND
          > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
          >
          > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
          >
          > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
          >
          > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
          >
          > 73,
          >
          > Rick KN6KB
          >
          > .
          >

        • Ian Wade G3NRW
          ___Original Message_________________________________________ From: Rick Westerfield Date: Tue, 6 Sep 2011 Time: 07:01:25 ...
          Message 4 of 30 , Sep 6, 2011
          View Source
          • 0 Attachment
            ___Original Message_________________________________________
            From: Rick Westerfield <r_lwesterfield@...>
            Date: Tue, 6 Sep 2011 Time: 07:01:25

            >A fast typist that is very chatty can really dominate the link when he
            >is the ISS. Perhaps a timer of two minutes as the ISS can be
            >implemented to keep the bucket mouth / hand guy such as I can be at
            >times from dominating the link.
            >

            Nah, you don't need a timer. If you're on the receiving end of a
            crocodile, all you need to type is
            ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZzzzzzzz. With luck they'll get the
            message.

            Eventually ... :-)

            --
            73
            Ian, G3NRW
          • Owen Mitchell
            I will agree on this one, with Rick.   The latest version  is working VERY good, with the Flex Radio. Installed it yesterday, and tried it to see if it
            Message 5 of 30 , Sep 6, 2011
            View Source
            • 0 Attachment
              I will agree on this one, with Rick.
               
              The latest version  is working VERY good, with the Flex Radio. Installed it yesterday, and tried it to see if it worked okay. I think I woke up the East Coast. Lot of contacts.
               
              It would be nice to know when others have stopped their QSO, and returned it back to you. Mabe a BK at the end, or OVER would help. I find myself typing in the buffer Q, and entering it in the outbound too soon. It never get to the other end. I know they are the ISS, but I thought  it would go when they turned it over. No such luck. I finally kept listening for a string of "naks" to make sure I was the ISS.
               
              Just my thoughts.  Owen  KB5XE  Albuquerque, NM

              --- On Tue, 9/6/11, Rick Westerfield <r_lwesterfield@...> wrote:

              From: Rick Westerfield <r_lwesterfield@...>
              Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal
              To: "V4Protocol@yahoogroups.com" <V4Protocol@yahoogroups.com>
              Date: Tuesday, September 6, 2011, 6:01 AM

               
              I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.

               I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.

              Many thanks. It really is good code in all other respects.

              Rick KH2DF

              Sent from my iPhone

              On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:

               
              Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

              73 Finn/LA7UM

              --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
              >
              > Demetre,
              > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
              >
              > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
              > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
              >
              > The basic rule is simply this:
              > The ISS stays the ISS UNTIL:
              > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
              > AND
              > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
              >
              > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
              >
              > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
              >
              > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
              >
              > 73,
              >
              > Rick KN6KB
              >
              > .
              >

            • Ron Werthman
              Hi Rick, Ideal would be 2 way comms, attach data onto the ack packet for extra efficiency. ________________________________ From: Rick Westerfield
              Message 6 of 30 , Sep 6, 2011
              View Source
              • 0 Attachment
                Hi Rick, Ideal would be 2 way comms, attach data onto the ack packet for extra efficiency.


                From: Rick Westerfield <r_lwesterfield@...>
                To: "V4Protocol@yahoogroups.com" <V4Protocol@yahoogroups.com>
                Sent: Tuesday, September 6, 2011 8:01:25 AM
                Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal

                 
                I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.

                 I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.

                Many thanks. It really is good code in all other respects.

                Rick KH2DF

                Sent from my iPhone

                On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:

                 
                Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

                73 Finn/LA7UM

                --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                >
                > Demetre,
                > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
                >
                > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
                > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
                >
                > The basic rule is simply this:
                > The ISS stays the ISS UNTIL:
                > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
                > AND
                > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
                >
                > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
                >
                > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
                >
                > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
                >
                > 73,
                >
                > Rick KN6KB
                >
                > .
                >



              • la7um
                As maybe is done with the pactor 3 progr Gold, or something...where a 2way chat may go on during a picture transfer?...If I understood told info correctly. 73.
                Message 7 of 30 , Sep 6, 2011
                View Source
                • 0 Attachment
                  As maybe is done with the pactor 3 progr Gold, or something...where a 2way chat may go on during a picture transfer?...If I understood told info correctly. 73. Finn/LA7UM

                  --- In V4Protocol@yahoogroups.com, Ron Werthman <ron_werthman@...> wrote:
                  >
                  > Hi Rick, Ideal would be 2 way comms, attach data onto the ack packet for extra efficiency.
                  >
                  >
                  >
                  > ________________________________
                  > From: Rick Westerfield <r_lwesterfield@...>
                  > To: "V4Protocol@yahoogroups.com" <V4Protocol@yahoogroups.com>
                  > Sent: Tuesday, September 6, 2011 8:01:25 AM
                  > Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal
                  >
                  >
                  >  
                  > I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.
                  >
                  >  I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.
                  >
                  > Many thanks. It really is good code in all other respects.
                  >
                  > Rick KH2DF
                  >
                  > Sent from my iPhone
                  >
                  > On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:
                  >
                  >
                  >  
                  > >Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?
                  > >
                  > >73 Finn/LA7UM
                  > >
                  > >--- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@> wrote:
                  > >>
                  > >> Demetre,
                  > >> Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
                  > >>
                  > >> Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
                  > >> As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
                  > >>
                  > >> The basic rule is simply this:
                  > >> The ISS stays the ISS UNTIL:
                  > >> 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
                  > >> AND
                  > >> 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
                  > >>
                  > >> When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
                  > >>
                  > >> My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
                  > >>
                  > >> One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
                  > >>
                  > >> 73,
                  > >>
                  > >> Rick KN6KB
                  > >>
                  > >> .
                  > >>
                  > >
                  > >
                  >
                • Rick Muething
                  Ron, You’re trying to circumvent the “no free lunch” theorem!....Everything has a cost. If you send data back with the ACK you HALF the throughput (data
                  Message 8 of 30 , Sep 6, 2011
                  View Source
                  • 0 Attachment
                    Ron,
                    You’re trying to circumvent the “no free lunch” theorem!....Everything has a cost.  If you send data back with the ACK you HALF the throughput (data takes time ~3+ seconds, ACK/NAK take very little time ~300 ms).   The ISS has to know how long to wait to repeat so if the IRS can optionally  send data the ISS must wait to see if that is happening or you get “doubles”.
                     
                    Now you CAN send more data in less time by: (the theory for this is well known and proven)
                    1) Increasing the bandwidth (now 200 Hz, and can go into any spot on the band) You would have to increase the power proportionally to keep the same S/N ratio and bit error rate of course. And of course you get fewer QSO’s per KHz. (You can thank Claude Shannon for that channel capacity vs. S/N theory that is so often quoted!)
                     
                    and/or
                     
                    2) Increasing the bits/symbol (now 2 including 1 FEC bit)  e.g. PSK can send more than 2 bits/symbol but requires a stronger signal to keep the bit error rate the same. 4FSK is near optimum in terms of bandwidth and robustness especially in multipath propagation.
                     
                    and/or
                     
                    3) You can decrease the FEC coding (now at 50%) but that increases the bit error rate (and repeats) unless the signals are strong (The current V4 Viterbi encoding probably yields a coding gain of something >  than 3 dB so you would have to more than double the power to keep the same bit error rate)
                     
                    And then there is the real problem....How do you manage two data senders in a half duplex ARQ environment? ...virtually all half duplex HF protocols use an IRS ISS concept...and it is very difficult (under all missed frames, missed data and missed ACKs situations) to insure both stations don’t ever become the ISS or the IRS at the same time.
                     
                    Maybe I have missed something but I don’t know how to make it more straight forward:
                    You can type and enter data at ANY Time.... You don’t have to wait for anything. You never HAVE to send over or break or anything but typed text.
                    When the current sending station ISS runs out of data (all outbound data has been confirmed received) he Automatically sends IDLs
                    If the Current Receiving station has data to send (queued) and sees an IDL from the ISS it automatically starts the IRS>ISS switchover sequence to become the new ISS.
                    Repeat!
                     
                    Rick KN6KB
                     
                  • Rick Muething
                    Finn, Pactor 3 uses 12 x the bandwidth of V4 (2400 Hz vs 200 Hz). You can’t have narrow bandwidth while sending large amounts of data UNLESS you have very
                    Message 9 of 30 , Sep 6, 2011
                    View Source
                    • 0 Attachment
                      Finn,
                       
                      Pactor 3 uses 12 x the bandwidth of V4 (2400 Hz vs 200 Hz).  You can’t have narrow bandwidth while sending large amounts of data UNLESS you have very high S/N.  This goes back to Claude Shannon’s landmark theorem relating theoretical channel capacity (bits/second/Hz) vs. S/N.  We are dealing here with HF where S/N is low,  sometimes negative and multipath fading is common or severe at times. You simply can’t get the same bits/second/Hz as you do on a land line telephone with a stable channel at 40 dB S/N.
                       
                      Rick KN6KB
                    • Ed Woods WD9DVA
                      whats happened to 7 mkz? NADA. Ed WD9DVA ... From: Rick Westerfield To: V4Protocol@yahoogroups.com Sent: Tuesday, September 06, 2011 12:01 Subject: Re:
                      Message 10 of 30 , Sep 6, 2011
                      View Source
                      • 0 Attachment
                        
                        whats happened to 7 mkz? NADA. Ed WD9DVA
                        ----- Original Message -----
                        Sent: Tuesday, September 06, 2011 12:01
                        Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal

                         

                        I had several very nice chats yesterday with the new version of V4 in the worst crowded conditions on 20 meters imaginable. And the text kept flowing. It was awesome.

                         I do not comment often here but I have to agree with others. A fast typist that is very chatty can really dominate the link when he is the ISS. Perhaps a timer of two minutes as the ISS can be implemented to keep the bucket mouth / hand guy such as I can be at times from dominating the link.

                        Many thanks. It really is good code in all other respects.

                        Rick KH2DF

                        Sent from my iPhone

                        On Sep 6, 2011, at 5:21 AM, "la7um" <la7um@...> wrote:

                         

                        Rick. I know a ham friend beeing "colour blind" seeing only grey scales. Maybe text one direction could be bold or underlined or something? if not in an extra window like "split screen"?

                        73 Finn/LA7UM

                        --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                        >
                        > Demetre,
                        > Thanks for the feedback. We have talked about a mechanism for showing the text confirmed received by the other side. While a third text window is possible it really gets to be messy. A better and more elegant mechanism is to use change the type font of the sent text (in the session window...now as blue italic) to something like blue-green italic and that would show which text is received. Note too that you already have a running indication of the confirmed delivered text by the outbound queue size. This shows in bytes how much is left for the other side to receive/confirm by ACK. When it goes to 0 everything has been confirmed delivered.
                        >
                        > Maybe I don’t understand but the program is already set up for chat and that is just the way I use it for testing. There is no over or BTU command needed.
                        > As the receiving station you can go ahead and type ahead and put data in your outbound buffer. It won’t send until you are the ISS and that won’t happen until the ISS has finished sending all queued data. The if you have data it will switch from IRS to ISS automatically.
                        >
                        > The basic rule is simply this:
                        > The ISS stays the ISS UNTIL:
                        > 1) He has completed all data (confirmed received by the IRS) and the ISS outbound queue is 0
                        > AND
                        > 2) The IRS has typed data and has outbound data to send. The IRS outbound queue is > 0
                        >
                        > When those two conditions are met the switchover occurs and should always be safe. There is an interlock mechanism to prevent a failed IRS<>ISS turnover if both IRS and ISS tried to enter data at the same (or near the same) time.
                        >
                        > My suggestion of using BTU or some other indicator is just so the other side knows you are really finished typing and not just thinking of more to say with an empty queue. It is not at all required to cause the ISS<>IRS turnover. That is and always has been the idea of V4Chat. Maybe there is a better way to communicate that?
                        >
                        > One thing that is important in making these suggestions is to think through and get some feedback on the changes before going ahead. E.g. the third window is probably 2-3 days or so worth of programming and testing and really conveys no more information than what is there now using the outbound queue indicator.
                        >
                        > 73,
                        >
                        > Rick KN6KB
                        >
                        > .
                        >

                      • Ron Werthman
                        Well it sounded good in my head.  I should have known better. With all the time you have invested in V4 you must have tried all the tricks.  Excellent
                        Message 11 of 30 , Sep 6, 2011
                        View Source
                        • 0 Attachment
                          Well it sounded good in my head.  I should have known better. With all the time you have invested in V4 you must have tried all the tricks.  Excellent explanation of the process, thanks for that.  I think I have a better understanding of v4 now.


                          From: Rick Muething <rmuething@...>
                          To: V4Protocol@yahoogroups.com
                          Sent: Tuesday, September 6, 2011 9:54:45 AM
                          Subject: Re: [V4Protocol] Re: V4 GUI improvement proposal

                           
                          Ron,
                          You’re trying to circumvent the “no free lunch” theorem!....Everything has a cost.  If you send data back with the ACK you HALF the throughput (data takes time ~3+ seconds, ACK/NAK take very little time ~300 ms).   The ISS has to know how long to wait to repeat so if the IRS can optionally  send data the ISS must wait to see if that is happening or you get “doubles”.
                           
                          Now you CAN send more data in less time by: (the theory for this is well known and proven)
                          1) Increasing the bandwidth (now 200 Hz, and can go into any spot on the band) You would have to increase the power proportionally to keep the same S/N ratio and bit error rate of course. And of course you get fewer QSO’s per KHz. (You can thank Claude Shannon for that channel capacity vs. S/N theory that is so often quoted!)
                           
                          and/or
                           
                          2) Increasing the bits/symbol (now 2 including 1 FEC bit)  e.g. PSK can send more than 2 bits/symbol but requires a stronger signal to keep the bit error rate the same. 4FSK is near optimum in terms of bandwidth and robustness especially in multipath propagation.
                           
                          and/or
                           
                          3) You can decrease the FEC coding (now at 50%) but that increases the bit error rate (and repeats) unless the signals are strong (The current V4 Viterbi encoding probably yields a coding gain of something >  than 3 dB so you would have to more than double the power to keep the same bit error rate)
                           
                          And then there is the real problem....How do you manage two data senders in a half duplex ARQ environment? ...virtually all half duplex HF protocols use an IRS ISS concept...and it is very difficult (under all missed frames, missed data and missed ACKs situations) to insure both stations don’t ever become the ISS or the IRS at the same time.
                           
                          Maybe I have missed something but I don’t know how to make it more straight forward:
                          You can type and enter data at ANY Time.... You don’t have to wait for anything. You never HAVE to send over or break or anything but typed text.
                          When the current sending station ISS runs out of data (all outbound data has been confirmed received) he Automatically sends IDLs
                          If the Current Receiving station has data to send (queued) and sees an IDL from the ISS it automatically starts the IRS>ISS switchover sequence to become the new ISS.
                          Repeat!
                           
                          Rick KN6KB
                           


                        • SV1UY
                          Rick, Thanks for all explanation OM. Much appreciated. 73 de Demetre SV1UY
                          Message 12 of 30 , Sep 6, 2011
                          View Source
                          • 0 Attachment
                            Rick,

                            Thanks for all explanation OM. Much appreciated.

                            73 de Demetre SV1UY
                          • la7um
                            Rick. Off course. I just wondered how that P3 Picture transfer in one direction worked while some chat (450hz?) came the other way during the acks? It was said
                            Message 13 of 30 , Sep 6, 2011
                            View Source
                            • 0 Attachment
                              Rick. Off course. I just wondered how that P3 Picture transfer in one direction worked while some chat (450hz?) came the other way during the acks? It was said to work like that.

                              I don't know the GOLD P3 program myself, so I may have got it wrong. SW perhaps only from time to time made some ordinary turnarounds ISS/IRS/ISS.

                              Anyway forget about it. I didn't intend squeezing picture through the 200hz channel. Irrelevant to V4 and the genious 200Hz solution.

                              The different font issue for helping hams having coulour disabled visual is maybe something to consider down the lane. I don't have that problem myself, so don't really know myself.

                              73 Finn/LA7UM

                              --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                              >
                              > Finn,
                              >
                              > Pactor 3 uses 12 x the bandwidth of V4 (2400 Hz vs 200 Hz). You can’t have narrow bandwidth while sending large amounts of data UNLESS you have very high S/N. This goes back to Claude Shannon’s landmark theorem relating theoretical channel capacity (bits/second/Hz) vs. S/N. We are dealing here with HF where S/N is low, sometimes negative and multipath fading is common or severe at times. You simply can’t get the same bits/second/Hz as you do on a land line telephone with a stable channel at 40 dB S/N.
                              >
                              > Rick KN6KB
                              >
                            • SV1UY
                              Hi Rick and Finn, Perhaps the 3rd window idea is great because it suits everybody. I understand that V4 cannot be made a pseudo fullduplex mode just like
                              Message 14 of 30 , Sep 6, 2011
                              View Source
                              • 0 Attachment
                                Hi Rick and Finn,

                                Perhaps the 3rd window idea is great because it suits everybody.
                                I understand that V4 cannot be made a pseudo fullduplex mode just like Pactor 2 or 3 can, but the 3rd window seems a good idea.
                                That is of course whenever you have the spare time.

                                73 de Demetre SV1UY

                                --- In V4Protocol@yahoogroups.com, "la7um" <la7um@...> wrote:
                                >
                                > Rick. Off course. I just wondered how that P3 Picture transfer in one direction worked while some chat (450hz?) came the other way during the acks? It was said to work like that.
                                >
                                > I don't know the GOLD P3 program myself, so I may have got it wrong. SW perhaps only from time to time made some ordinary turnarounds ISS/IRS/ISS.
                                >
                                > Anyway forget about it. I didn't intend squeezing picture through the 200hz channel. Irrelevant to V4 and the genious 200Hz solution.
                                >
                                > The different font issue for helping hams having coulour disabled visual is maybe something to consider down the lane. I don't have that problem myself, so don't really know myself.
                                >
                                > 73 Finn/LA7UM
                              • Bob Thornton
                                Constellation score shows how well we are receiving but something to indicate how well we are being received would be nice. Very good reasons of throughput
                                Message 15 of 30 , Sep 6, 2011
                                View Source
                                • 0 Attachment
                                  Constellation score shows how well we are receiving but something to indicate how well we are being received would be nice. Very good reasons of throughput why you don't want to bring that back, but could something simpler be done based on the counting of ACK and NACK frames. (ACK-NACK)/(ACK+NACK) sounds like a possible measure. Or effective data rate based on throughput.

                                  Bob

                                  G3WKW

                                  --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                                  >
                                  > Pete,
                                  >
                                  > It is hard to measure one or two parameters and show link quality. There is already one very good indicator and that is the constellation display and its score. This shows the “tightness of the symbolsâ€� and scores them 0 to 100. 100 is near perfect (4 very small dots in the corners of the constellation plot). A score > 50 is usually decodable without errors. The S/N is also computed and measures the average (across the frame) of the Desired signal (one of the 4FSK tones) compared to the other three tones. Its possible to add more frills, graphs and plots but the goal should be to communicate some useful information not just show and glitz. Its important to remember that the TNC does not actually have to be visible at all...its form is primarily for operator entertainment as there are few controls that are really required.
                                  >
                                  > I’ll consider putting something else in if it makes sense and communicates something of value to the user. There really is not much one can do to improved the decoding other than trying with the filter IN or Out.
                                  >
                                  > Rick KN6KB
                                  >
                                • Rick Muething
                                  Bob, The sender (ISS) and the receiver (IRS) always have the information to calculate true throughput (NET Characters/min or WPM). ACK NAKs are only part
                                  Message 16 of 30 , Sep 7, 2011
                                  View Source
                                  • 0 Attachment
                                    Bob,

                                    The sender (ISS) and the receiver (IRS)  always have the information to calculate true throughput (NET Characters/min or WPM).  ACK NAKs are only part (what about missed ACK/NAK ....they cause repeats too).  I’ll look at calculating and displaying something  like a rolling average (say one minute) of actual throughput (bytes Accepted /minute). None of this causes any impact to the throughput (minor CPU load increase)  but does of course clutter up the screen with more “widgets”.
                                     
                                    Rick KN6KB
                                     
                                  • k1dow_4
                                    My input regarding the user interface on V4 First and foremost congratulations to you Rick on getting the V4 code running very well indeed! I would find the
                                    Message 17 of 30 , Sep 7, 2011
                                    View Source
                                    • 0 Attachment
                                      My input regarding the user interface on V4

                                      First and foremost congratulations to you Rick on getting the V4 code running very well indeed!

                                      I would find the interface much more comfortable to use if nothing but received text appeared in the receive window and of course a separate window like we have now to type in. What would be VERY helpful is a small third window displaying the outgoing text that has been received by the IRS. This way you would be aware of your throughput and not get too verbose  under poor conditions. You would be seeing exactly what the IRS has displayed to the moment. 

                                      The constellation, while interesting, is something I would gladly do without to have this third window of  received text by the IRS displayed, if  keeping the amount of program code to a minimum is is important, and I think of course that it is.

                                      From all the posts I have read this morning, I think that the majority of the uses want to see the actual transmitted text they send as it is displayed at he IRS.

                                      Oh.. A last thought on the on the tendency of many of us to want to do the "BTU OM" thing, even though we understand the changeover from ISS to IRS is automatic. I simply end my typing by typically asking a question. This seems to to work pretty well in getting the other guy to type a reply. ;-)   

                                      73/Russ
                                      K1DOW
                                      Arcadia, FL
                                       

                                      --- In V4Protocol@yahoogroups.com, "Bob Thornton" <bob.thornton@...> wrote:
                                      >
                                      > Constellation score shows how well we are receiving but something to indicate how well we are being received would be nice. Very good reasons of throughput why you don't want to bring that back, but could something simpler be done based on the counting of ACK and NACK frames. (ACK-NACK)/(ACK+NACK) sounds like a possible measure. Or effective data rate based on throughput.
                                      >
                                      > Bob
                                      >
                                      > G3WKW
                                      >
                                      > --- In V4Protocol@yahoogroups.com, "Rick Muething" rmuething@ wrote:
                                      > >
                                      > > Pete,
                                      > >
                                      > > It is hard to measure one or two parameters and show link quality. There is already one very good indicator and that is the constellation display and its score. This shows the “tightness of the symbolsâ€&#65533; and scores them 0 to 100. 100 is near perfect (4 very small dots in the corners of the constellation plot). A score > 50 is usually decodable without errors. The S/N is also computed and measures the average (across the frame) of the Desired signal (one of the 4FSK tones) compared to the other three tones. Its possible to add more frills, graphs and plots but the goal should be to communicate some useful information not just show and glitz. Its important to remember that the TNC does not actually have to be visible at all...its form is primarily for operator entertainment as there are few controls that are really required.
                                      > >
                                      > > I’ll consider putting something else in if it makes sense and communicates something of value to the user. There really is not much one can do to improved the decoding other than trying with the filter IN or Out.
                                      > >
                                      > > Rick KN6KB
                                      > >
                                      >
                                    • la7um
                                      Russ. Reminds me of +? Wasn t that the original change over using AMTOR? 73 Finn/LA7UM
                                      Message 18 of 30 , Sep 7, 2011
                                      View Source
                                      • 0 Attachment
                                        Russ. Reminds me of +? Wasn't that the original change over using AMTOR?
                                        73 Finn/LA7UM

                                        --- In V4Protocol@yahoogroups.com, "k1dow_4" <russtower@...> wrote:
                                        >
                                        > My input regarding the user interface on V4
                                        > First and foremost congratulations to you Rick on getting the V4 code
                                        > running very well indeed!
                                        > I would find the interface much more comfortable to use if nothing but
                                        > received text appeared in the receive window and of course a separate
                                        > window like we have now to type in. What would be VERY helpful is a
                                        > small third window displaying the outgoing text that has been received
                                        > by the IRS. This way you would be aware of your throughput and not get
                                        > too verbose under poor conditions. You would be seeing exactly what the
                                        > IRS has displayed to the moment.
                                        > The constellation, while interesting, is something I would gladly do
                                        > without to have this third window of received text by the IRS
                                        > displayed, if keeping the amount of program code to a minimum is is
                                        > important, and I think of course that it is.
                                        > From all the posts I have read this morning, I think that the majority
                                        > of the uses want to see the actual transmitted text they send as it is
                                        > displayed at he IRS.
                                        > Oh.. A last thought on the on the tendency of many of us to want to do
                                        > the "BTU OM" thing, even though we understand the changeover from ISS to
                                        > IRS is automatic. I simply end my typing by typically asking a question.
                                        > This seems to to work pretty well in getting the other guy to type a
                                        > reply. ;-)
                                        > 73/RussK1DOWArcadia, FL
                                        > --- In V4Protocol@yahoogroups.com, "Bob Thornton" <bob.thornton@>
                                        > wrote:
                                        > >
                                        > > Constellation score shows how well we are receiving but something to
                                        > indicate how well we are being received would be nice. Very good
                                        > reasons of throughput why you don't want to bring that back, but could
                                        > something simpler be done based on the counting of ACK and NACK frames.
                                        > (ACK-NACK)/(ACK+NACK) sounds like a possible measure. Or effective data
                                        > rate based on throughput.
                                        > >
                                        > > Bob
                                        > >
                                        > > G3WKW
                                        > >
                                        > > --- In V4Protocol@yahoogroups.com, "Rick Muething" rmuething@ wrote:
                                        > > >
                                        > > > Pete,
                                        > > >
                                        > > > It is hard to measure one or two parameters and show link quality.
                                        > There is already one very good indicator and that is the constellation
                                        > display and its score. This shows the “tightness of the
                                        > symbols�� and scores them 0 to 100. 100 is near perfect (4
                                        > very small dots in the corners of the constellation plot). A score > 50
                                        > is usually decodable without errors. The S/N is also computed and
                                        > measures the average (across the frame) of the Desired signal (one of
                                        > the 4FSK tones) compared to the other three tones. Its possible to add
                                        > more frills, graphs and plots but the goal should be to communicate some
                                        > useful information not just show and glitz. Its important to remember
                                        > that the TNC does not actually have to be visible at all...its form is
                                        > primarily for operator entertainment as there are few controls that are
                                        > really required.
                                        > > >
                                        > > > I’ll consider putting something else in if it makes sense and
                                        > communicates something of value to the user. There really is not much
                                        > one can do to improved the decoding other than trying with the filter IN
                                        > or Out.
                                        > > >
                                        > > > Rick KN6KB
                                        > > >
                                        > >
                                        >
                                      • Rick Muething
                                        Thanks, Russ. I am working on some tweaks but since these all relate to GUI there is no “Right” answer and it is possible to throw too much clutter in
                                        Message 19 of 30 , Sep 7, 2011
                                        View Source
                                        • 0 Attachment
                                          Thanks,  Russ. 
                                           
                                          I am working on some tweaks but since these all relate to GUI there is no “Right” answer and it is possible to throw too much clutter in there and make things more confusing.
                                          I am working now on some fairly simple but useful items: (These are ALL related to the V4Chat program NOT the Virtual V4 TNC program)
                                              1) Moving some of the less used menu items to the File drop down list...this clears up the menu bar for the items below.
                                              2) Adding a Out bound Queue readout and progress bar to the main menu line (this will “repeat” the Outbound Queue value now shown on the V4 TNC)
                                              3) Adding an average (1 minute rolling average) throughput readout and progress bar to the main menu line
                                           
                                          I will investigate changes to the text boxes but I am reluctant to add yet another (third) text box.  That means an additional set of sliders for adjustment and gets messy.
                                          An alternative I am considering is letting the current keyboard text box just show entered text.  Text that can still be “edited” (that has not be committed to the outbound Queue) would be shown say in blue italic text.  Once text is committed to the outbound queue it would be shown (in the same text box) as black Italic font.  This clearly shows which text has been sent to the queue and keeps all the outbound text together in one scrolling text box.  The session screen can either be kept the way it is (that is really good for logging since it contains both inbound and outbound text and status messages or it could be purged of outbound text.  The issue with this is one has to look at the entire picture...e.g.  What do you want the log to contain and in what sequence in addition to what the Text box functions are. 
                                           
                                          The constellation display is on the V4 TNC...and that is useful for several reasons in addition to showing received symbol quality....It does not affect the text windows or any of the V4 Chat GUI. (you can operate V4Chat fine with the V4 TNC minimized if desired) It is important to remember that the Virtual TNC function (the V4 TNC.exe program) and the GUI user interface (The V4Chat.exe program) are separate. In the future there will probably be other developers that wish to implement their own GUI interface and still use the V4 TNC Virtual TNC or include V4 into existing host programs (that has already been done with WINMOR which also uses the “Virtual TNC” concept).  Although some have trouble grasping the concept most now understand that these software implemented “Virtual TNCs” operate almost exactly the same as a physical TNC and appear to the host program as just another TNC with a specific set of commands just like a KAM or PTC II or other hardware TNC.  All that is required to add V4 or WINMOR to and existing host program is to write the correct driver for the virtual TNC.  This is not a difficult task and the interfaces and commands for both V4 and WINMOR are well documented.
                                           
                                          It is important NOT to get too bogged down and attempt to make the V4 Chat program the software equivalent of a Swiss army knife!  There are are still important tweaks that can be done to improve the robustness and reliability of the raw V4 protocol. Those steps usually take time and are in small increments but they do add up (Pactor for example is now over 20 years old and has been advanced from modest Pactor 1 at 100 bits/second to now Pactor 4 at over 4000 bits/second)  All that happened by taking advantage of advancing hardware and software technology and DSP theory with a very heavy dose of just plain good engineering work.
                                           
                                          Whenever I look at adding functions and other “bells and whistles” I always  try and remind myself of an inspired saying: “ More software dies of indigestion than starvation!”
                                           
                                          Your inputs always welcome but at this stage it is also important to “think through” each suggestion to asses its total impact to all parts of the program, logging, user complexity etc. The GUI functionality is not always obvious and not simple to implement well.
                                           
                                          73,
                                          Rick KN6KB
                                           
                                        • Chris
                                          Hi Rick, Interesting thread. I think an EAS option (echo as sent) should simply transfer the sent text, as it was acked, from bottom window to top. In a
                                          Message 20 of 30 , Sep 7, 2011
                                          View Source
                                          • 0 Attachment
                                            Hi Rick,

                                            Interesting thread.

                                            I think an EAS option (echo as sent) should simply transfer the sent text, as it was acked, from bottom window to top. In a distinctive color. The speed at which that happened would be a direct indication of link quality. It worked very well in Amtor.

                                            As for IRS ability to force the link around, here again this was a very useful feature in Amtor (ACHG). Impolite to use in normal QSO but sometimes handy - like when you were communicating with an unattended station.

                                            I am calling and listening on 14073 right now!

                                            73, Chris ZL1BOE

                                            --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                                            >
                                            > Pete,
                                            >
                                            > It is hard to measure one or two parameters and show link quality. There is already one very good indicator and that is the constellation display and its score. This shows the “tightness of the symbols” and scores them 0 to 100. 100 is near perfect (4 very small dots in the corners of the constellation plot). A score > 50 is usually decodable without errors. The S/N is also computed and measures the average (across the frame) of the Desired signal (one of the 4FSK tones) compared to the other three tones. Its possible to add more frills, graphs and plots but the goal should be to communicate some useful information not just show and glitz. Its important to remember that the TNC does not actually have to be visible at all...its form is primarily for operator entertainment as there are few controls that are really required.
                                            >
                                            > I’ll consider putting something else in if it makes sense and communicates something of value to the user. There really is not much one can do to improved the decoding other than trying with the filter IN or Out.
                                            >
                                            > Rick KN6KB
                                            >
                                          • Rick Muething
                                            Chris, Thanks for the inputs. I am cleaning up some additions now that should be useful and don’t clutter up the display much. e.g. Rx and Tx throughput
                                            Message 21 of 30 , Sep 8, 2011
                                            View Source
                                            • 0 Attachment
                                              Chris,
                                               
                                              Thanks for the inputs. I am cleaning up some additions now that should be useful and don’t clutter up the display much. e.g. Rx and Tx throughput measurements  shown on the V4Chat form (1 minute rolling average) .  I think users will find this helpful
                                               
                                              Re the IRS ability to interrupt (grab back the ISS status while the ISS is sending data). This is technically possible but I am not sure I understand  the need and it can easily add confusion... e.g. what do you do with the buffered unsent outbound data at the ISS?  Dump it?,  Keep it for the next time it is the ISS etc.  These are important details that if not implemented well and consistently will likely confuse the user.
                                               
                                              The unattended station issue should not a factor here. An unattended station will never generate outbound data so the IRS can always “force the link around” by simply typing data to send. If the unattended station were the ISS it would be sending IDLs (until timeout occurred) so the IRS does not have to “interrupt” the ISS.  
                                               
                                              V4 Chat is not really intended for unattended operation. There are other sound card protocols (e.g. WINMOR) that are specifically designed for message transfer and would be a better choice for unattended operation.
                                               
                                              73,
                                               
                                              Rick
                                            • k1dow_4
                                              Yes Finn! AMTOR was my first experience with HF ARQ operation. It was very effective too. I do remember the +? :-) 73/ RussK1DOW ... AMTOR? ... code ... but
                                              Message 22 of 30 , Sep 8, 2011
                                              View Source
                                              • 0 Attachment
                                                Yes Finn! AMTOR was my first experience with HF ARQ operation. It was very effective too. I do remember the +?   :-)

                                                73/ Russ
                                                K1DOW

                                                --- In V4Protocol@yahoogroups.com, "la7um" <la7um@...> wrote:
                                                >
                                                > Russ. Reminds me of +? Wasn't that the original change over using AMTOR?
                                                > 73 Finn/LA7UM
                                                >
                                                > --- In V4Protocol@yahoogroups.com, "k1dow_4" russtower@ wrote:
                                                > >
                                                > > My input regarding the user interface on V4
                                                > > First and foremost congratulations to you Rick on getting the V4 code
                                                > > running very well indeed!
                                                > > I would find the interface much more comfortable to use if nothing but
                                                > > received text appeared in the receive window and of course a separate
                                                > > window like we have now to type in. What would be VERY helpful is a
                                                > > small third window displaying the outgoing text that has been received
                                                > > by the IRS. This way you would be aware of your throughput and not get
                                                > > too verbose under poor conditions. You would be seeing exactly what the
                                                > > IRS has displayed to the moment.
                                                > > The constellation, while interesting, is something I would gladly do
                                                > > without to have this third window of received text by the IRS
                                                > > displayed, if keeping the amount of program code to a minimum is is
                                                > > important, and I think of course that it is.
                                                > > From all the posts I have read this morning, I think that the majority
                                                > > of the uses want to see the actual transmitted text they send as it is
                                                > > displayed at he IRS.
                                                > > Oh.. A last thought on the on the tendency of many of us to want to do
                                                > > the "BTU OM" thing, even though we understand the changeover from ISS to
                                                > > IRS is automatic. I simply end my typing by typically asking a question.
                                                > > This seems to to work pretty well in getting the other guy to type a
                                                > > reply. ;-)
                                                > > 73/RussK1DOWArcadia, FL
                                                > > --- In V4Protocol@yahoogroups.com, "Bob Thornton" <bob.thornton@>
                                                > > wrote:
                                                > > >
                                                > > > Constellation score shows how well we are receiving but something to
                                                > > indicate how well we are being received would be nice. Very good
                                                > > reasons of throughput why you don't want to bring that back, but could
                                                > > something simpler be done based on the counting of ACK and NACK frames.
                                                > > (ACK-NACK)/(ACK+NACK) sounds like a possible measure. Or effective data
                                                > > rate based on throughput.
                                                > > >
                                                > > > Bob
                                                > > >
                                                > > > G3WKW
                                                > > >
                                                > > > --- In V4Protocol@yahoogroups.com, "Rick Muething" rmuething@ wrote:
                                                > > > >
                                                > > > > Pete,
                                                > > > >
                                                > > > > It is hard to measure one or two parameters and show link quality.
                                                > > There is already one very good indicator and that is the constellation
                                                > > display and its score. This shows the “tightness of the
                                                > > symbols�&#65533; and scores them 0 to 100. 100 is near perfect (4
                                                > > very small dots in the corners of the constellation plot). A score > 50
                                                > > is usually decodable without errors. The S/N is also computed and
                                                > > measures the average (across the frame) of the Desired signal (one of
                                                > > the 4FSK tones) compared to the other three tones. Its possible to add
                                                > > more frills, graphs and plots but the goal should be to communicate some
                                                > > useful information not just show and glitz. Its important to remember
                                                > > that the TNC does not actually have to be visible at all...its form is
                                                > > primarily for operator entertainment as there are few controls that are
                                                > > really required.
                                                > > > >
                                                > > > > I’ll consider putting something else in if it makes sense and
                                                > > communicates something of value to the user. There really is not much
                                                > > one can do to improved the decoding other than trying with the filter IN
                                                > > or Out.
                                                > > > >
                                                > > > > Rick KN6KB
                                                > > > >
                                                > > >
                                                > >
                                                >
                                              • k1dow_4
                                                Rick, Thanks for your very clear and concise reply to my input regarding the third widow showing where the the IRS station was at regarding receiving the
                                                Message 23 of 30 , Sep 8, 2011
                                                View Source
                                                • 0 Attachment
                                                  Rick,

                                                  Thanks for your very clear and concise  reply to my input regarding "the third widow" showing where the the IRS station was at regarding receiving the actual text to the moment that you, as the ISS are typing to him.  I also appreciate your defining the difference between the V4 portion and the interface portion of your program. Points well explained. I can see why you do not want to create a "Swiss Army Knife" out to the interface. ;-)

                                                   I very much like your idea of keeping all the text I type in the text typing window. I find it messy and unsettling  to have  it appear inter spaced with received text in the incoming  window. Your idea of having what the ISS station types change color regarding it's state (while keeping all typed text in the typing window) would be great, save for those who are color blind. I still would like to see a one line only window (like a ticker tape) between the TX window and the RX window. It could scroll horizontally (as ticker tapes do) showing a  few of the words you have typed that are about to be transmitted  and having them drop off the display as they are acked. It's my feeling that this would give a very positive reassuring feel to the program, and since "the single line ticker tape window" would not require scrolling, slide bars, etc,  could this be implemented with out to much duress?

                                                  The only other thing I can think of at this time (which I don't think would be too difficult) would be to be able to mark text with my mouse in the RX & TX windows  and copy it. Not essential, but handy..

                                                  73/Russ
                                                  K1DOW


                                                   
                                                  --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                                                  >
                                                  > Thanks, Russ.
                                                  >
                                                  > I am working on some tweaks but since these all relate to GUI there is no “Right” answer and it is possible to throw too much clutter in there and make things more confusing.
                                                  > I am working now on some fairly simple but useful items: (These are ALL related to the V4Chat program NOT the Virtual V4 TNC program)
                                                  > 1) Moving some of the less used menu items to the File drop down list...this clears up the menu bar for the items below.
                                                  > 2) Adding a Out bound Queue readout and progress bar to the main menu line (this will “repeat” the Outbound Queue value now shown on the V4 TNC)
                                                  > 3) Adding an average (1 minute rolling average) throughput readout and progress bar to the main menu line
                                                  >
                                                  > I will investigate changes to the text boxes but I am reluctant to add yet another (third) text box. That means an additional set of sliders for adjustment and gets messy.
                                                  > An alternative I am considering is letting the current keyboard text box just show entered text. Text that can still be “edited” (that has not be committed to the outbound Queue) would be shown say in blue italic text. Once text is committed to the outbound queue it would be shown (in the same text box) as black Italic font. This clearly shows which text has been sent to the queue and keeps all the outbound text together in one scrolling text box. The session screen can either be kept the way it is (that is really good for logging since it contains both inbound and outbound text and status messages or it could be purged of outbound text. The issue with this is one has to look at the entire picture...e.g. What do you want the log to contain and in what sequence in addition to what the Text box functions are.
                                                  > The constellation display is on the V4 TNC...and that is useful for several reasons in addition to showing received symbol quality....It does not affect the text windows or any of the V4 Chat GUI. (you can operate V4Chat fine with the V4 TNC minimized if desired) It is important to remember that the Virtual TNC function (the V4 TNC.exe program) and the GUI user interface (The V4Chat.exe program) are separate. In the future there will probably be other developers that wish to implement their own GUI interface and still use the V4 TNC Virtual TNC or include V4 into existing host programs (that has already been done with WINMOR which also uses the “Virtual TNC” concept). Although some have trouble grasping the concept most now understand that these software implemented “Virtual TNCs” operate almost exactly the same as a physical TNC and appear to the host program as just another TNC with a specific set of commands just like a KAM or PTC II or other hardware TNC. All that is required to add V4 or WINMOR to and existing host program is to write the correct driver for the virtual TNC. This is not a difficult task and the interfaces and commands for both V4 and WINMOR are well documented.
                                                  > It is important NOT to get too bogged down and attempt to make the V4 Chat program the software equivalent of a Swiss army knife! There are are still important tweaks that can be done to improve the robustness and reliability of the raw V4 protocol. Those steps usually take time and are in small increments but they do add up (Pactor for example is now over 20 years old and has been advanced from modest Pactor 1 at 100 bits/second to now Pactor 4 at over 4000 bits/second) All that happened by taking advantage of advancing hardware and software technology and DSP theory with a very heavy dose of just plain good engineering work.
                                                  > Whenever I look at adding functions and other “bells and whistles” I always try and remind myself of an inspired saying: “ More software dies of indigestion than starvation!”
                                                  > Your inputs always welcome but at this stage it is also important to “think through” each suggestion to asses its total impact to all parts of the program, logging, user complexity etc. The GUI functionality is not always obvious and not simple to implement well.
                                                  > 73,
                                                  > Rick KN6KB
                                                  >
                                                • gm4zqh
                                                  Well we can always send the +? mark out of habit to let the other party know we have finished and are waiting for Topsy to switch the link LOL.... :) I did
                                                  Message 24 of 30 , Sep 10, 2011
                                                  View Source
                                                  • 0 Attachment
                                                    Well we can always send the +? mark out of habit to let the other party know we have finished and are waiting for Topsy to switch the link LOL.... :) I did last night.



                                                    --- In V4Protocol@yahoogroups.com, "k1dow_4" <russtower@...> wrote:
                                                    >
                                                    > Yes Finn! AMTOR was my first experience with HF ARQ operation. It was
                                                    > very effective too. I do remember the +? :-)
                                                    > 73/ RussK1DOW
                                                    > --- In V4Protocol@yahoogroups.com, "la7um" <la7um@> wrote:
                                                    > >
                                                    > > Russ. Reminds me of +? Wasn't that the original change over using
                                                    > AMTOR?
                                                    > > 73 Finn/LA7UM
                                                    > >
                                                    > > --- In V4Protocol@yahoogroups.com, "k1dow_4" russtower@ wrote:
                                                    > > >
                                                    > > > My input regarding the user interface on V4
                                                    > > > First and foremost congratulations to you Rick on getting the V4
                                                    > code
                                                    > > > running very well indeed!
                                                    > > > I would find the interface much more comfortable to use if nothing
                                                    > but
                                                    > > > received text appeared in the receive window and of course a
                                                    > separate
                                                    > > > window like we have now to type in. What would be VERY helpful is a
                                                    > > > small third window displaying the outgoing text that has been
                                                    > received
                                                    > > > by the IRS. This way you would be aware of your throughput and not
                                                    > get
                                                    > > > too verbose under poor conditions. You would be seeing exactly what
                                                    > the
                                                    > > > IRS has displayed to the moment.
                                                    > > > The constellation, while interesting, is something I would gladly do
                                                    > > > without to have this third window of received text by the IRS
                                                    > > > displayed, if keeping the amount of program code to a minimum is is
                                                    > > > important, and I think of course that it is.
                                                    > > > From all the posts I have read this morning, I think that the
                                                    > majority
                                                    > > > of the uses want to see the actual transmitted text they send as it
                                                    > is
                                                    > > > displayed at he IRS.
                                                    > > > Oh.. A last thought on the on the tendency of many of us to want to
                                                    > do
                                                    > > > the "BTU OM" thing, even though we understand the changeover from
                                                    > ISS to
                                                    > > > IRS is automatic. I simply end my typing by typically asking a
                                                    > question.
                                                    > > > This seems to to work pretty well in getting the other guy to type a
                                                    > > > reply. ;-)
                                                    > > > 73/RussK1DOWArcadia, FL
                                                    > > > --- In V4Protocol@yahoogroups.com, "Bob Thornton" <bob.thornton@>
                                                    > > > wrote:
                                                    > > > >
                                                    > > > > Constellation score shows how well we are receiving but something
                                                    > to
                                                    > > > indicate how well we are being received would be nice. Very good
                                                    > > > reasons of throughput why you don't want to bring that back, but
                                                    > could
                                                    > > > something simpler be done based on the counting of ACK and NACK
                                                    > frames.
                                                    > > > (ACK-NACK)/(ACK+NACK) sounds like a possible measure. Or effective
                                                    > data
                                                    > > > rate based on throughput.
                                                    > > > >
                                                    > > > > Bob
                                                    > > > >
                                                    > > > > G3WKW
                                                    > > > >
                                                    > > > > --- In V4Protocol@yahoogroups.com, "Rick Muething" rmuething@
                                                    > wrote:
                                                    > > > > >
                                                    > > > > > Pete,
                                                    > > > > >
                                                    > > > > > It is hard to measure one or two parameters and show link
                                                    > quality.
                                                    > > > There is already one very good indicator and that is the
                                                    > constellation
                                                    > > > display and its score. This shows the “tightness of the
                                                    > > > symbols�� and scores them 0 to 100. 100 is near perfect
                                                    > (4
                                                    > > > very small dots in the corners of the constellation plot). A score
                                                    > > 50
                                                    > > > is usually decodable without errors. The S/N is also computed and
                                                    > > > measures the average (across the frame) of the Desired signal (one
                                                    > of
                                                    > > > the 4FSK tones) compared to the other three tones. Its possible to
                                                    > add
                                                    > > > more frills, graphs and plots but the goal should be to communicate
                                                    > some
                                                    > > > useful information not just show and glitz. Its important to
                                                    > remember
                                                    > > > that the TNC does not actually have to be visible at all...its form
                                                    > is
                                                    > > > primarily for operator entertainment as there are few controls that
                                                    > are
                                                    > > > really required.
                                                    > > > > >
                                                    > > > > > I’ll consider putting something else in if it makes sense
                                                    > and
                                                    > > > communicates something of value to the user. There really is not
                                                    > much
                                                    > > > one can do to improved the decoding other than trying with the
                                                    > filter IN
                                                    > > > or Out.
                                                    > > > > >
                                                    > > > > > Rick KN6KB
                                                    > > > > >
                                                    > > > >
                                                    > > >
                                                    > >
                                                    >
                                                  • Rick Muething
                                                    Russ, The next version will have the functionally you wish: 1) The text entered (either via keyboard or pasted file) will always be shown in the current
                                                    Message 25 of 30 , Sep 10, 2011
                                                    View Source
                                                    • 0 Attachment
                                                      Russ,
                                                      The next version will have the functionally you wish:
                                                      1) The text entered (either via keyboard or pasted file) will always be shown in the current keyboard window.  The portion of the text that has been sent or in the process of sending (e.g. waiting in the OB queue) will be dark gray, text you can edit will be blue. You can clear the window if desired or just let it scroll. (BIG scroll buffer)
                                                       
                                                      2) There is no need for a third “text in process” window.  The new scheme copies data as sent (sometimes called Echo as Sent)  to the session window when it is actually sent so you can always see exactly what text has been sent (and in the case of ARQ, ACKed).  This also has the nice affect of making the log completely chronologic...text appears in the log when it was sent/ACKed by the other side. For non full duplex operation this will automatically separate received text from sent text both by color and by time/grouping. For ARQ operation you know that when the sent data (blue italic font) appears on your Session window it ALSO and Simultaneously appears on the remote stations Session window. No question as to what data the other side has received!
                                                       
                                                      3) You can already copy text in either window as described in help...
                                                              Use a left mouse click and drag to highlight text
                                                              Use Ctrl C to copy the highlighted text to the clip board.
                                                              Position the cursor where you want to paste (can be a different application if desired)
                                                              Use Ctrl V to paste at the cursor.
                                                       
                                                      The Ctrl C and Ctrl V are pretty standard for copy and paste.  I could go to use the right mouse click for that but then we need a different key stroke (not standard) to allow erasing the entire Keyboard or Session windows.  Those windows can hold a lot of type so it is not always practical trying to select all the window data to clear it.
                                                       
                                                      I should have this out today or tomorrow.
                                                       
                                                      Rick KN6KB
                                                       
                                                    • k1dow_4
                                                      Most excellent Rick! I think the other testers will be very pleased with these refinments, too. Watching for you next release! 73/RussK1DOWArcadia, FL ... be
                                                      Message 26 of 30 , Sep 11, 2011
                                                      View Source
                                                      • 0 Attachment
                                                        Most excellent Rick!  I think the other testers will be very pleased with these refinments, too. Watching for you next release!

                                                        73/Russ
                                                        K1DOW
                                                        Arcadia, FL

                                                        --- In V4Protocol@yahoogroups.com, "Rick Muething" <rmuething@...> wrote:
                                                        >
                                                        > Russ,
                                                        > The next version will have the functionally you wish:
                                                        > 1) The text entered (either via keyboard or pasted file) will always be shown in the current keyboard window. The portion of the text that has been sent or in the process of sending (e.g. waiting in the OB queue) will be dark gray, text you can edit will be blue. You can clear the window if desired or just let it scroll. (BIG scroll buffer)
                                                        >
                                                        > 2) There is no need for a third “text in process” window. The new scheme copies data as sent (sometimes called Echo as Sent) to the session window when it is actually sent so you can always see exactly what text has been sent (and in the case of ARQ, ACKed). This also has the nice affect of making the log completely chronologic...text appears in the log when it was sent/ACKed by the other side. For non full duplex operation this will automatically separate received text from sent text both by color and by time/grouping. For ARQ operation you know that when the sent data (blue italic font) appears on your Session window it ALSO and Simultaneously appears on the remote stations Session window. No question as to what data the other side has received!
                                                        >
                                                        > 3) You can already copy text in either window as described in help...
                                                        > Use a left mouse click and drag to highlight text
                                                        > Use Ctrl C to copy the highlighted text to the clip board.
                                                        > Position the cursor where you want to paste (can be a different application if desired)
                                                        > Use Ctrl V to paste at the cursor.
                                                        >
                                                        > The Ctrl C and Ctrl V are pretty standard for copy and paste. I could go to use the right mouse click for that but then we need a different key stroke (not standard) to allow erasing the entire Keyboard or Session windows. Those windows can hold a lot of type so it is not always practical trying to select all the window data to clear it.
                                                        >
                                                        > I should have this out today or tomorrow.
                                                        >
                                                        > Rick KN6KB
                                                        >
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.