开云体育

I've gone through "Alpha" testing of the opensource hamlib interface library code (v4.0). The ft-980 code (ft-980.c) is listed at "Alpha", or untested.

? ? ?The Alpha code only has 6 functions listed: get_frequ, set freq, get_mem {number}, set_mem {number}, get_mode, set_mode.?

? ? ?I found only one error: the set_mem error has a bug in a line that limits the ability to set the active memory number from 1 - 15, not 1-16. I found the bug in the 'C' code.

My next step is to report this to the developers ... although I plan to set up a toolchain and finish the development myself.

If anyone is interested, let me know: I'll set up a Dropbox with my documentation and progress.

--
-Mat Breton, N8TW

I'd love to see this fully completed and can help debug, develop, what have you. See my comments in the WSJT-X thread regarding flrig - that's another package in need of update.

73 - Fred, N8YX

I created a Dropbox folder for "work in progress" type material, and uploaded my current hamlib alpha-testing directory. Let me know if you don't receive and email invitation ...

fldigi has a number of different CAT method options built-in supposedly, including hamlib. However, I was unable to get it to connect via hamlib to the FT-980. I'll try again.

flrig appears to be closed-source, which is a potential issue (have to convince the developers to assist if the base code needs to be modified. The rig description files are .xml-based, which helps ... but the FT-980 has a particular quirk that could be a problem. The FT-980 CAT system uses an echo back PLUS an "execute" command, in addition to the command. While a few other rigs seem to have the "echo-back", the "execute" command seems to be unique.

1. PC -> Rig: Command
2. Rig-> PC: Echo-back
3. PC-> Rig: Execute

If the flrig base code doesn't support both the echo-back and execute quirks (so we can just create the .xml file), then we would need the developer support.

But first things first for me: I'm going to concentrate on hamlib (fix bugs, add functionality). What is really intriguing is the rigctlcom program (TS-2000 translator) that might even help workaround fldigi/flrig.
--
-Mat Breton, N8TW

Update: progress is slow since I work during the day, but this is still moving forward.

I've been making a linux?

Since I didn't want to add another PC to the mix, I decided to dual-boot my shack PC. I purchased two 256GB SSDs, reinstalled W10-64 on one and put Ubuntu on the other. Configured grub2 as a triple boot for now (Ubuntu, Old win-hd, New win-ssd) until I can get everything copied over/reinstalled/reconfigured on the Windows half.


Tomorrow I'll load the necessary programs (Git, GCC, astyle, etc) and files to compile hamlib. I'm thinking of using "Atom" as my IDE (development environment) ... I'll give it a go at least.?

That is it for now.

--
-Mat Breton, N8TW

Had a great evening:
Summary: I can now make changes to the hamlib FT-980 backend and submit them to the open-source project. I also wrote the instructions and can pass them along to anyone else who wants to.

Onward and upward: I will now be starting to add new features to hamlib. These will start appearing to the general public when official releases are done (at least twice/year).

--
-Mat Breton, N8TW

Wow.?

Just a quick update: I'm continuing the FT-980 Hamlib development effort. I've completed testing/fixing the existing code, and have now started to add functionality.

First up was "targetable VFO": previously you could only change the "active" settings (ex if you were operating GEN, you could only change the GEN mode, frequ). Now you tell the API which VFO you want to modify. This was first because I need it to do other stuff, like program memories, run test scripts, etc.

I'll add a more low-hanging fruit and will push this "Alpha-2" version up to the root Github repository. Since this is a low-priority hobby effort, I expect it to be a couple months before I have all the FT-980 functionality?

Please please please: we need beta testers! I can help get you set up (easy if you have a Linux box), but we need more eyes, more PCs, and more FT-980's than just mine to ensure a robust work-product.

--
-Mat Breton, N8TW

I can compile whatever is needed on this system to test your changes. What are you using for a front end to Hamlib?

73 - Fred, N8YX

That is awesome!

There are a number of "test programs" included with the package. The specific one designed for testing the back ends is "rigctl".?

Note: I plan to also make an automated test vector routine (to avoid the potential of screwing up something already working with a later change) ... but that won't work for first time testing, and examining corner cases.

Versions:


--
-Mat Breton, N8TW

I have rigctl installed on the system I'm using to post this, and I downloaded ft980.c this morning. Will that file build a library which I can copy into an existing Hamlib directory?

73 - Fred, N8YX

You have to download the entire Hamlib structure (all the rig backends, the support routines, etc), as the various libraries are all cascaded dependencies. But you really only need to do it once.

Note: If you download the "release", I believe all the makefiles are already generated. If you download the "daily" scrum, then you need to autogenerate them (at least I had to).

There are 3 ways to compile once you have the files/makefiles downloaded:
1. You can compile the makefile in ./rigs/yaesu. This is where ft980.x is. I do this as a periodic quick check, as I don't fully trust the linter I'm using yet. However, this ONLY compiles the yaesu backends locally
2. You can compile the entire hamlib by doing a "make" in the "root" directory. I do this after I complete a series of changes ... just to make sure my local changes don't break something somewhere else.
3. You can compile and install (usually in your /usr directory) with a "sudo make install"

You are correct that the only files I think that we need to worry about are the ft980.x ones ... but we can't compile/test them by themselves.

The only files I'm currently working on are ft980.c & ft980.h (new). So, once you have it compiling I can send them to you, you can replace them in ./rigs/yaesu.

Note: at some point I will modify or make a new test-vector binary in ./tests ... after the VFOs are proven out maybe.


--
-Mat Breton, N8TW

The hamlib team moved the FT-980 backend from Alpha -> Beta status.

The next thing I have tried to do is add the clarifier functions. These actually consist of five routines:
1. Set (Turn on/off) the TX or RX Clarifier
2. Get the on/off status of the TX or RX Clarifier
3. Get the RX/TX Clarifier "offset" (same routine for both)
4. Set the RX Clarifier frequency
5. Set the TX Clarifier frequency (it is possible that 4 & 5 may be combined ... not sure yet)

The first three work fine. But when I try to set either the TX or RX Clarifier frequency, the FT-980 sets op_freq = HAM_vfo_freq = vfo_clar_freq = the new freq. Basically, instead of just changing the vfo_clar_freq, it sets all of them.

My procedure:
? ?i. turn on RX Clarifier
? ?ii. Set the operating frequency to the new value

Any thoughts from anyone?

--
-Mat Breton, N8TW

Bumping the thread up:

I have the latest flrig/fldigi/hamlib sources on this system (which I'm using to post) and have successfully compiled all three programs. I've also written and tested flrig drivers for the IC-751 and R-71. Let's have a crack at more FT-980 stuff.

The only problem being that the PC and gear under test is the upstairs office/shack, and my '980s live in the main shack in the basement. So I'll have to duplicate PCs down there. LOL.

73 - Fred, N8YX