开云体育

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

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

w1hkj wrote:

w1hkj wrote:

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

Improvements in the NRAM data dialog. Dave (hkj)

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

edw3nr wrote:

be dilemma. time enabled Debian the original version to would

changes per anyone corredtly. ?? 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

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.

Ed wrote: 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

Hamish Moffatt wrote: 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

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

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

Hamish Moffatt wrote: 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

BTW, for the purposes of distributions (like Debian), compile-time options are no good... cheers Hamish -- Hamish Moffatt VK3SB <hamish@...> <hamish@...>