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

gmfsk-hkj version 0.48 posted

Expand Messages
  • David Freese
    Some requested changes to the gmfsk program. 1. rev toggle can be enabled for all modes 2. Precision for logging frequency can be specified at compile time.
    Message 1 of 9 , Apr 11, 2006
    • 0 Attachment
      Some requested changes to the gmfsk program.

      1. "rev" toggle can be enabled for all modes
      2. Precision for logging frequency can be specified at compile time.

      See the description of mods web page.

      Dave (hkj)
    • Hamish Moffatt
      ... Isn t rev irrelevant for some modes though, eg Hell & PSK31? Hamish -- Hamish Moffatt VK3SB
      Message 2 of 9 , Apr 11, 2006
      • 0 Attachment
        On Tue, Apr 11, 2006 at 11:46:47AM -0000, David Freese wrote:
        > Some requested changes to the gmfsk program.
        >
        > 1. "rev" toggle can be enabled for all modes
        > 2. Precision for logging frequency can be specified at compile time.
        >
        > See the description of mods web page.

        Isn't "rev" irrelevant for some modes though, eg Hell & PSK31?

        Hamish
        --
        Hamish Moffatt VK3SB <hamish@...> <hamish@...>
      • Hamish Moffatt
        ... BTW, for the purposes of distributions (like Debian), compile-time options are no good... cheers Hamish -- Hamish Moffatt VK3SB
        Message 3 of 9 , Apr 11, 2006
        • 0 Attachment
          On Tue, Apr 11, 2006 at 11:46:47AM -0000, David Freese wrote:
          > Some requested changes to the gmfsk program.
          >
          > 1. "rev" toggle can be enabled for all modes
          > 2. Precision for logging frequency can be specified at compile time.

          BTW, for the purposes of distributions (like Debian), compile-time
          options are no good...


          cheers
          Hamish
          --
          Hamish Moffatt VK3SB <hamish@...> <hamish@...>
        • w1hkj
          ... Yes and you can include CW to that list. The problem is that as written, gmfsk retains the rev setting between modes. So if you were operating RTTY and
          Message 4 of 9 , Apr 11, 2006
          • 0 Attachment
            Hamish Moffatt wrote:
            On Tue, Apr 11, 2006 at 11:46:47AM -0000, David Freese wrote:
              
            Some requested changes to the gmfsk program.
            
              1. "rev" toggle can be enabled for all modes
              2. Precision for logging frequency can be specified at compile time.
            
            See the description of mods web page.
                
            Isn't "rev" irrelevant for some modes though, eg Hell & PSK31?
            
            Hamish
              
            Yes and you can include CW to that list.  The problem is that as written, gmfsk retains the "rev" setting between modes.  So if you were operating RTTY and in the "rev" setting and then switched mode to Olivia the "rev" would be remembered, but the toggle disabled.  The operator must recognize that the "rev" is set or wonder forever why he or she cannot receive the Olivia signal (maybe trying various Tone/BW settings).  Having once recognized the problem it would be necessary to revert to a mode which allowed toggling the "rev"; and then returning to Olivia to try to decode the incoming signal.  Very user unfriendly.  Toggling the "rev" in those modes for which it is meaningless does not result in an upside down signal.

            I have found it necessary on several occassions to use the alternate sideband in order to be able to use 80 meters successfully when W1AW (the ARRL BBBRRROOOAAACCCAAASSSTTT station) is sending CW practice or bulletins.  That was the only way I could reduce AGC overload when trying to copy a weak digital signal.  In that case the "rev" capability is very import to those modes which are sensitive to frequency reversal.

            I chose the easy way out on this patch as it only required a single code line to be modified.  If I had made the "rev" completely definable by mode and/or band (my original thought) it would have required far too many patches in too many files.

            Dave (hkj)
          • w1hkj
            ... I am open to suggestions to resolve that issue Hamish. Some of the patches (the user interface for example) probably should just be made a part of the
            Message 5 of 9 , Apr 11, 2006
            • 0 Attachment
              Hamish Moffatt wrote:
              On Tue, Apr 11, 2006 at 11:46:47AM -0000, David Freese wrote:
                
              Some requested changes to the gmfsk program.
              
                1. "rev" toggle can be enabled for all modes
                2. Precision for logging frequency can be specified at compile time.
                  
              BTW, for the purposes of distributions (like Debian), compile-time
              options are no good...
              
              
              cheers
              Hamish
                
              I am open to suggestions to resolve that issue Hamish.  Some of the patches (the user interface for example) probably should just be made a part of the application.  Others, like the interface to the CAT programs (ArgoV, DeltaII, Icom728 and Kachina) could be run-time switches.

              Any thoughts from other users?

              Dave (hkj)
            • Hamish Moffatt
              ... Well in the case of the CAT-type changes, wouldn t it be proper for those changes to go into hamlib rather than directly into gMFSK? Hamish -- Hamish
              Message 6 of 9 , Apr 11, 2006
              • 0 Attachment
                On Tue, Apr 11, 2006 at 08:48:44AM -0400, w1hkj wrote:
                > Hamish Moffatt wrote:
                > >BTW, for the purposes of distributions (like Debian), compile-time
                > >options are no good...
                > I am open to suggestions to resolve that issue Hamish. Some of the
                > patches (the user interface for example) probably should just be made a
                > part of the application. Others, like the interface to the CAT programs
                > (ArgoV, DeltaII, Icom728 and Kachina) could be run-time switches.

                Well in the case of the CAT-type changes, wouldn't it be proper for
                those changes to go into hamlib rather than directly into gMFSK?

                Hamish
                --
                Hamish Moffatt VK3SB <hamish@...> <hamish@...>
              • jhaynesatalumni
                ... Well, one of the joys of Linux is that if you don t like the way the precompiled program works you are free to get the source and compile it yourself. Not
                Message 7 of 9 , Apr 11, 2006
                • 0 Attachment
                  --- In linuxham@yahoogroups.com, Hamish Moffatt <hamish@...> wrote:

                  > BTW, for the purposes of distributions (like Debian), compile-time
                  > options are no good...
                  >
                  Well, one of the joys of Linux is that if you don't like the way the
                  precompiled program works you are free to get the source and compile
                  it yourself. Not being a Real Programmer I can't say how hard it is
                  to convert a compile-time option into a run-time option.
                • Kevin der Kinderen
                  ... For something like gMFSK-hkj, I would compile it locally and then use something like checkinstall to create the .deb package and install it. I found this
                  Message 8 of 9 , Apr 11, 2006
                  • 0 Attachment
                    On 4/11/06, jhaynesatalumni <jhhaynes@...> wrote:

                    Well, one of the joys of Linux is that if you don't like the way the
                    precompiled program works you are free to get the source and compile
                    it yourself.  Not being a Real Programmer I can't say how hard it is
                    to convert a compile-time option into a run-time option.
                     
                    For something like gMFSK-hkj, I would compile it locally and then use something like checkinstall to create the .deb package and install it. I found this helped to keep track of software where I wanted to tweak the configuration and still keep it in the package tree.
                     
                    Kev - K4VD

                     
                  • w1hkj
                    ... Hamlib is a very nice general purpose one size fits all interface library. I have nothing against or for it. I tried using it from with gmfsk with limited
                    Message 9 of 9 , Apr 11, 2006
                    • 0 Attachment
                      Hamish Moffatt wrote:
                      On Tue, Apr 11, 2006 at 08:48:44AM -0400, w1hkj wrote:
                        
                      Hamish Moffatt wrote:
                          
                      BTW, for the purposes of distributions (like Debian), compile-time
                      options are no good...
                            
                      I am open to suggestions to resolve that issue Hamish.  Some of the 
                      patches (the user interface for example) probably should just be made a 
                      part of the application.  Others, like the interface to the CAT programs 
                      (ArgoV, DeltaII, Icom728 and Kachina) could be run-time switches.
                          
                      Well in the case of the CAT-type changes, wouldn't it be proper for
                      those changes to go into hamlib rather than directly into gMFSK?
                      
                      Hamish
                        
                      Hamlib is a very nice general purpose one size fits all interface library.  I have nothing against or for it.  I tried using it from with gmfsk with limited success (it doesn't support all of the i/o I desire).  It does not purport to be a rig interface program, just a rig i/o program.  The DeltaII, ArgoV, Icom728 and especially the Kachina CAT programs are rig control programs.  In fact the Kachina program is the only Linux program for controlling the Kachina (which is a computer interface only rig ... no front panel what-so-ever).  Controlling the Kachina using hamlib did not work very well.  I tried it.  So I elected to use my own i/o code to the transceivers.  But the mods to gmfsk do not impact on the continued use of hamlib for those users with a different transceiver or need.  If I had been successful in using hamlib for the CAT programs I still would have had to provide a means of communications between the gmfsk program and the transceiver control program.   Only one program at a time should be attempting to send commands to the transceiver.   If you look at the TenTecCAT.c source code you will see that gmfsk and the CAT programs communicate using shared memory.  Very fast, very efficient.  The actual i/o to the transceiver is done in the CAT programs, which by the way can also run stand-a-lone without gmfsk.

                      Dave (hkj)
                    Your message has been successfully submitted and would be delivered to recipients shortly.