Dave,

Glad to hear you planning to expand the ArgoV interface. I really
like the ArgoV. Is has a few quirks, but--all in all--is a great
little rig.

As you expand the ArgoV control program, will it eventually be able to
track frequency and mode changes, etc., made at the rig?

73,
John - WL7M

Thanks for the report John. You are the first user from Alaska. Just about every flavor of Linux is now running the modified gmfsk.

How do you like the ArgoV interface? I have one also and it is a grand little rig. Right now I'm using the "on loan" Kachina for the development work going on there. Eventually that will spill over to the ArgoV and it will look more and more like a full blown rig control program. Take a look at the Kachina screen shot to see what may be in store for the ArgoV.

See you on 20 meters.

BTW, I lived in Yakutat, AK from 1963 to 1965. Was there for the big one.

Dave (hkj)

w1hkj wrote:

edw3nr wrote:

--- In linuxham@..., w1hkj <w1hkj@...> wrote:

Ed wrote:

I still am unable to configure .48 with Hamlib. I made the

changes per

the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does

anyone

know what I'm missing from .48 ??? or what I am not doing

corredtly. ??

Ed W3NR

Ed, Did you execute the command

./configure

before doing the recompile?

Dave (hkj)

Dave, this is the basics that I did.
1. untarred the tarball (File Roller)
2. cd to the hkj folder
3. ./configure
4. make the necessary changes to the src hkj config file. Set tentec mod to zero and also the Kachina mod to zero.
5. set the want_hamlib to 1 in config.h
6. make (this is when the errors show up. I set the scrollback in Gterminal to 1500 lines and that still does not get me back to the command line "make" entry.

As I said, .7pre1 compiled against Hamlib just fine. Now, after all this, I decided I may have a corrupted download. So, I moved the hkj.48 folder to the trash as well as the tarball. Started all over again fresh. What happened next is beyond my Linux knowledge, I ran ./configure from the hkj.48 folder, so far so good. Made the changes as above, then ran make. Well instead of make running in the folder, it changed (automagically) to the trash folder and compiled with zero (0) errors. I thought, oh OK lets run make install (as root)....again zero errors. This left me at the /trash/hkj.48 folder. I typed in "gmfsk" and up came .48 complete with Hamlib. All of my settings,Hamlib settings,color,fonts,macros from .7pre1 with .48 mods where there. I copied this back to my /home folder after renaming the existing .48 folder and it again just worked with Hamlib and all the settings from .7pre1. I checked my .7pre1 and it had not changed at all. Now, the only change I had made was to install all 4 versions of Automake as I was not sure exactly what version you used. And if I read it correctly the versions are not compatiable. I'll leave this up to all the gurus' to figure out, as I would be really interested how all this happened.
Ed W3NR

If you want hamlib support in the gmfsk program you need to "configure" as follows:
./configure --enable-hamlib
I do not recommend you fool around with AutoConf or AutoMake Ed. Those are primarily tools for use by the developers. I always create a new "configure" script file with each distribution. If you execute AutoConf then you will be overwriting the one that comes with the distributed source code.
Dave (hkj)

Dave, I did not run autimake, just made sure they were there. On to .48,
success, it compiled just fine , I would say its all there and
functioning properly. In .47 if I did ./configure --enable -hamlib, the
hkj-config.h would have both the Tentec and Kachina mods set to zero and
config.h would also have want_hamlib set to zero. This time around
hkj-config.h had both set to 1 and config.h was also set to one for
want_hamlib.

Now on to a bigger problem, my HD is full. About 300 meg left. I'm going
to go with Hamish's suggestion on apt-get dep-build. You would not
beleive all the files I installed to get this and PA0Rs' TLF and PSKmail
working. Thanks for all the tips and tricks, also for making a good
program even better.

Ed W3NR

w1hkj wrote:

edw3nr wrote:

--- In linuxham@..., w1hkj <w1hkj@...> wrote:

Ed wrote:

I still am unable to configure .48 with Hamlib. I made the

changes per

the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does

anyone

know what I'm missing from .48 ??? or what I am not doing

corredtly. ??

Ed W3NR

Ed, Did you execute the command

./configure

before doing the recompile?

Dave (hkj)

Dave, this is the basics that I did.
1. untarred the tarball (File Roller)
2. cd to the hkj folder
3. ./configure
4. make the necessary changes to the src hkj config file. Set tentec mod to zero and also the Kachina mod to zero.
5. set the want_hamlib to 1 in config.h
6. make (this is when the errors show up. I set the scrollback in Gterminal to 1500 lines and that still does not get me back to the command line "make" entry.

As I said, .7pre1 compiled against Hamlib just fine. Now, after all this, I decided I may have a corrupted download. So, I moved the hkj.48 folder to the trash as well as the tarball. Started all over again fresh. What happened next is beyond my Linux knowledge, I ran ./configure from the hkj.48 folder, so far so good. Made the changes as above, then ran make. Well instead of make running in the folder, it changed (automagically) to the trash folder and compiled with zero (0) errors. I thought, oh OK lets run make install (as root)....again zero errors. This left me at the /trash/hkj.48 folder. I typed in "gmfsk" and up came .48 complete with Hamlib. All of my settings,Hamlib settings,color,fonts,macros from .7pre1 with .48 mods where there. I copied this back to my /home folder after renaming the existing .48 folder and it again just worked with Hamlib and all the settings from .7pre1. I checked my .7pre1 and it had not changed at all. Now, the only change I had made was to install all 4 versions of Automake as I was not sure exactly what version you used. And if I read it correctly the versions are not compatiable. I'll leave this up to all the gurus' to figure out, as I would be really interested how all this happened.
Ed W3NR

If you want hamlib support in the gmfsk program you need to "configure" as follows:
./configure --enable-hamlib
I do not recommend you fool around with AutoConf or AutoMake Ed. Those are primarily tools for use by the developers. I always create a new "configure" script file with each distribution. If you execute AutoConf then you will be overwriting the one that comes with the distributed source code.
Dave (hkj)

Dave, I did not run autimake, just made sure they were there. On to .48, success, it compiled just fine , I would say its all there and functioning properly. In .47 if I did ./configure --enable -hamlib, the hkj-config.h would have both the Tentec and Kachina mods set to zero and config.h would also have want_hamlib set to zero. This time around hkj-config.h had both set to 1 and config.h was also set to one for want_hamlib.

Now on to a bigger problem, my HD is full. About 300 meg left. I'm going to go with Hamish's suggestion on apt-get dep-build. You would not beleive all the files I installed to get this and PA0Rs' TLF and PSKmail working. Thanks for all the tips and tricks, also for making a good program even better.

Ed W3NR

Hello all,

New to the group. Just wanted to say thanks do Dave and everyone else
who has supported this effort.

I'm up and running now with ArgoV CAT, gMFSK.hkj.47 and xlog. My
distro is Mandriva 2006. I first tried using Debian, but just had too
many problems with my Sound Blaster Live Value soundcard.

Only glitch I ran into with Mandriva was the software was looking in
the wrong directory for libfftw.so.2. The following solved the problem.

# ln -s /usr/local/lib/libfftw.so.2 /usr/lib/libfftw.so.2

# ldconfig

Hope to see you around 14.07015!

Thanks & 73,
John Pfeifer - WL7M
Soldotna, Alaska

Improvements in the NRAM data dialog.

Dave (hkj)

On Wed, Apr 12, 2006 at 11:14:39AM -0000, edw3nr wrote:

Dave, FYI, I use Debian testing....I had no problems in hkj-config.h
the only mods I did not use were the Tentec and Kachina mods. My
biggest problem was tryin to figure out what all was needed to
compile gmfsk in the first place. I found I was needing several
libs,dev and others. The one that threw me the most was fftw-dev.

"apt-get build-dep gmfsk" would pull in all the dependencies of the
prepackaged gmfsk, which is probably identical to what's needed by
Dave's branch.

Hamish
--
Hamish Moffatt VK3SB <hamish@...> <hamish@...>

开云体育

edw3nr wrote:

--- In linuxham@..., w1hkj  wrote:
  

Ed wrote:

    

I still am unable to configure .48 with Hamlib. I made the 
      

changes per
  

the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does 
      

anyone
  

know what I'm missing from .48 ??? or what I am not doing 
      

corredtly. ??
  

Ed W3NR
      

Ed,  Did you execute the command

./configure

before doing the recompile?

Dave (hkj)
    

Dave, this is the basics that I did. 

1. untarred the tarball (File Roller)
2. cd to the hkj folder
3. ./configure
4. make the necessary changes to the src hkj config file. Set tentec 
mod to zero and also the Kachina mod to zero.
5. set the want_hamlib to 1 in config.h
6. make (this is when the errors show up. I set the scrollback in 
Gterminal to 1500 lines and that still does not get me back to the 
command line "make" entry.

As I said, .7pre1 compiled against Hamlib just fine. Now, after all 
this, I decided I may have a corrupted download. So, I moved the 
hkj.48 folder to the trash as well as the tarball. Started all over 
again fresh. What happened next is beyond my Linux knowledge, I 
ran ./configure from the hkj.48 folder, so far so good. Made the 
changes as above, then ran make. Well instead of make running in the 
folder, it changed (automagically) to the trash folder and compiled 
with zero (0) errors. I thought, oh OK lets run make install (as 
root)....again zero errors. This left me at the /trash/hkj.48 
folder. I typed in "gmfsk" and up came .48 complete with Hamlib. All 
of my settings,Hamlib settings,color,fonts,macros from .7pre1 
with .48 mods where there. I copied this back to my /home folder 
after renaming the existing .48 folder and it again just worked with 
Hamlib and all the settings from .7pre1. I checked my .7pre1 and it 
had not changed at all. Now, the only change I had made was to 
install all 4 versions of Automake as I was not sure exactly what 
version you used. And if I read it correctly the versions are not 
compatiable. I'll leave this up to all the gurus' to figure out, as 
I would be really interested how all this happened. 

Ed W3NR







 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    

<*> To unsubscribe from this group, send an email to:
    linuxham-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
    
 





  

If you want hamlib support in the gmfsk program you need to "configure" as follows:

./configure --enable-hamlib

I do not recommend you fool around with AutoConf or AutoMake Ed.? Those are primarily tools for use by the developers.? I always create a new "configure" script file with each distribution.? If you execute AutoConf then you will be overwriting the one that comes with the distributed source code.

Dave (hkj)

--- In linuxham@..., w1hkj <w1hkj@...> wrote:

Hamish etal,

My original intent with the gmfsk mods was to provide a way to
conveniently test changes to the application that would eventually

be

incorporated into the mainstream gmfsk source tree. That has not
happened. Tomi Manninen, OH2BNS, the author of gmfsk has not been
available to discuss the mods. So I am left with an unwanted

dilemma.

I have been considering the issue of whether to change the compile

time

modifications to permanent code changes whose features can be

enabled

and/or modified by configuration dialogs. That would satisfy the

Debian

distribution problem. I think that this would require renaming

the

application since it would not then be as tightly linked to the

original

gmfsk.

I know that Ed has been having some problems getting the .48

version to

recognize his hamlib install at compile time. A Debian distro

would

probably help him out of the compile dependency issue. Has anyone

else

experienced similar compile-time problems?

I would appreciate hearing from the present users of gmfsk on this
idea. What mods do you incorporate? Which ones should be

retained and

which discarded? How difficult do you find the compile time

decision

tree that you need to navigate via the hkj-config.h file

Dave (hkj)

Dave, FYI, I use Debian testing....I had no problems in hkj-config.h
the only mods I did not use were the Tentec and Kachina mods. My
biggest problem was tryin to figure out what all was needed to
compile gmfsk in the first place. I found I was needing several
libs,dev and others. The one that threw me the most was fftw-dev.

Ed W3NR

--- In linuxham@..., w1hkj <w1hkj@...> wrote:

Ed wrote:

I still am unable to configure .48 with Hamlib. I made the

changes per

the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does

anyone

know what I'm missing from .48 ??? or what I am not doing

corredtly. ??

Ed W3NR

Ed, Did you execute the command

./configure

before doing the recompile?

Dave (hkj)

Dave, this is the basics that I did.

1. untarred the tarball (File Roller)
2. cd to the hkj folder
3. ./configure
4. make the necessary changes to the src hkj config file. Set tentec
mod to zero and also the Kachina mod to zero.
5. set the want_hamlib to 1 in config.h
6. make (this is when the errors show up. I set the scrollback in
Gterminal to 1500 lines and that still does not get me back to the
command line "make" entry.

As I said, .7pre1 compiled against Hamlib just fine. Now, after all
this, I decided I may have a corrupted download. So, I moved the
hkj.48 folder to the trash as well as the tarball. Started all over
again fresh. What happened next is beyond my Linux knowledge, I
ran ./configure from the hkj.48 folder, so far so good. Made the
changes as above, then ran make. Well instead of make running in the
folder, it changed (automagically) to the trash folder and compiled
with zero (0) errors. I thought, oh OK lets run make install (as
root)....again zero errors. This left me at the /trash/hkj.48
folder. I typed in "gmfsk" and up came .48 complete with Hamlib. All
of my settings,Hamlib settings,color,fonts,macros from .7pre1
with .48 mods where there. I copied this back to my /home folder
after renaming the existing .48 folder and it again just worked with
Hamlib and all the settings from .7pre1. I checked my .7pre1 and it
had not changed at all. Now, the only change I had made was to
install all 4 versions of Automake as I was not sure exactly what
version you used. And if I read it correctly the versions are not
compatiable. I'll leave this up to all the gurus' to figure out, as
I would be really interested how all this happened.

Ed W3NR

Hamish etal,

My original intent with the gmfsk mods was to provide a way to conveniently test changes to the application that would eventually be incorporated into the mainstream gmfsk source tree. That has not happened. Tomi Manninen, OH2BNS, the author of gmfsk has not been available to discuss the mods. So I am left with an unwanted dilemma.

I have been considering the issue of whether to change the compile time modifications to permanent code changes whose features can be enabled and/or modified by configuration dialogs. That would satisfy the Debian distribution problem. I think that this would require renaming the application since it would not then be as tightly linked to the original gmfsk.

I know that Ed has been having some problems getting the .48 version to recognize his hamlib install at compile time. A Debian distro would probably help him out of the compile dependency issue. Has anyone else experienced similar compile-time problems?

I would appreciate hearing from the present users of gmfsk on this idea. What mods do you incorporate? Which ones should be retained and which discarded? How difficult do you find the compile time decision tree that you need to navigate via the hkj-config.h file

Dave (hkj)

Ed wrote:

I still am unable to configure .48 with Hamlib. I made the changes per
the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does anyone
know what I'm missing from .48 ??? or what I am not doing corredtly. ??

Ed W3NR



Yahoo! Groups Links








.

Ed, Did you execute the command

./configure

before doing the recompile?

Dave (hkj)

I still am unable to configure .48 with Hamlib. I made the changes per
the readme. The error I get is:

hamlib.o: In function 'riglist_get_list':

Then I get undefined reference to various hamlib functions. gMFSK
compiles just fine with Hamlib using .7pre1, as well as .6,does anyone
know what I'm missing from .48 ??? or what I am not doing corredtly. ??

Ed W3NR

开云体育

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)

--- In linuxham@..., 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.

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@...>

开云体育

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 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)

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@...>