FT710: Connection to radio issues

[TecnoTalarn]

Hello, good morning everyone

I've been using Qlog on my radio computer for a few days now.
I really like how it works, and it's really comfortable.

Right now I only have one complaint. And I don't know if it's really something from the program itself, or if it comes from hamlib.
My current radio is a yaesu FT710. I've found that it doesn't seem to be properly supported by hamlib, and it works best for me by tricking the software into telling it that I have an FTDX10. With this configuration the program works correctly.

I understand that this is a matter of hamlib, and not of qlog.

Even so, there are errors, sometimes, especially if I go to a frequency from the cluster window, for example, if I'm with the radio tuning the 20m USB, and in the cluster I click on a station on 40M, when changing the frequency on the radio, forgets to go to LSB and stays in USB. Then I click again on the same station in the cluster and it changes to LSB. It's like you only run one thing at a time.

I have also encountered errors and warnings that disconnect the control if I am on an SSB frequency and have the CW mode set. Then it won't let me connect the serial port until I go to SSB.

And last thing.
When I turn off the yaesu FT710 radio, the USB port stops (I think yaesu has not done this correctly) and the program detects that it cannot connect and gives an error. This seems logical, but when you connect the radio again, the program does not connect again, you have to do it manually, even if you have the option to save the configuration and have the option to connect to the radio checked.

73 from Catalonia
EB3AM

[foldynl]

Even so, there are errors, sometimes, especially if I go to a frequency from the cluster window, for example, if I'm with the radio tuning the 20m USB, and in the cluster I click on a station on 40M, when changing the frequency on the radio, forgets to go to LSB and stays in USB. Then I click again on the same station in the cluster and it changes to LSB. It's like you only run one thing at a time.

I have done tests and I can't replicate it. But I think, according to your description, that it's actually a QLog problem. It will not easy to find the issue.

I have also encountered errors and warnings that disconnect the control if I am on an SSB frequency and have the CW mode set. Then it won't let me connect the serial port until I go to SSB.

but this no longer sounds like a QLog issue. I assume you are using some kind of Linux. Have you tried the flatpak version where hamlib version is 4.5.5 and where your rig is already supported?

And last thing.
When I turn off the yaesu FT710 radio, the USB port stops (I think yaesu has not done this correctly) and the program detects that it cannot connect and gives an error. This seems logical, but when you connect the radio again, the program does not connect again, you have to do it manually, even if you have the option to save the configuration and have the option to connect to the radio checked.

that's the desired behavior. The option in the menu is only about remembering the state of the rig when the application is closed. Qlog does not auto-reconnect the rig if it is reconnected during running QLog.

[TecnoTalarn]

Yes, I'm using Linux, Ubuntu specifically.
The hamlib libraries are the last ones I have and the Yaesu FT710 already appears, but, for example, it says that the power is 32w when the radio is at 100w. other parameters are altered, if I look at it with FLrig, such as mic gain, or other levels.
If I set the radio to FTDX10, everything seems to be more correct.
Hamlib libraries are really complicated, they have always given me problems, previously with my other radios, the Xiegu G90 and the Icom 7300, but they were finally resolved. Even, some software such as JTDX needs a specific library to work well.

We will continue to provide better support for yaesu radio.

When I have some time, I'll see if the problems I have with the yaesu, like not switching from USB to LSB, are reproduced on the Icom. Lest this be another hamlib blunder.

[foldynl]

I have an additional question

Even so, there are errors, sometimes, especially if I go to a frequency from the cluster window, for example, if I'm with the radio tuning the 20m USB, and in the cluster I click on a station on 40M, when changing the frequency on the radio, forgets to go to LSB and stays in USB. Then I click again on the same station in the cluster and it changes to LSB. It's like you only run one thing at a time.

how exactly does the mode change. If you click on a spot in the DX Window, does this happen?

1. Callsign is in the New contact window
2. New Frequency and new mode is transferred to the New contact window
3. The rig sets the frequency, but does not set the correct mode?

or New Contact contains also an incorrect mode until you click on DX Spot again?

After clicking on the DX contact, Qlog sets the mode and then the frequency in two steps. it is strange that the mode is not set but the frequency is.

[TecnoTalarn]

Enregistrament de pantalla des de 2024-04-14 14-51-11.webm If you can see the screen recording, I've made a recording.
First I'm at 20m and on USB, and I click a station from the cluster at 15m and the radio changes to the desired frequency, on USB. correct
Then I look in the cluster window for a station at 40m and click on it. The radio switches to the correct frequency, but stays on USB. And then I click it again. Now yes, it goes to LSB.
I'm sorry but the cursor has not been recorded

[foldynl]

Many thanks for your video. I can see several problems in this video that are unusual for me.

1. what you reporter, the switching mode
2. your first click on DX tunes 7.103 - the same freq as DX Spot contains. But your second click tunes 7.10440. this is not unusual in the case that new information about the frequency for the callsign comes from the DX Cluster between the first and second click But I don't see any newer DX Spot for M0MJA in DX Cluster window. So this tuning is unusual.
3. QLog removes timezone from all Time fields. But I can see that all times have string UTC.

it will be interesting to find out the behavior of your other rig(s). I use ic7300 for testing and I have no problems with it.

in the meantime, please, could you send me a result of following command env | grep LC_? I wonder why you see the timezone that should be removed by QLog.

The hamlib libraries are the last ones I have and the Yaesu FT710 already appears, but, for example, it says that the power is 32w when the radio is at 100w.

Power level is fully under control of hamlib. Maybe Yaesu FT710 needs a different calculation algorithm than all the others. I'll try googling

[TecnoTalarn]

jordi@radio:~$ env | grep LC
LC_ADDRESS=ca_ES.UTF-8
LC_NAME=ca_ES.UTF-8
LC_MONETARY=ca_ES.UTF-8
LC_PAPER=ca_ES.UTF-8
LC_IDENTIFICATION=ca_ES.UTF-8
LC_TELEPHONE=ca_ES.UTF-8
LC_MEASUREMENT=ca_ES.UTF-8
LC_TIME=ca_ES.UTF-8
LC_NUMERIC=ca_ES.UTF-8

I just tested with the Icom 7300 and everything works fine, or at least I haven't managed to see any errors.

[TecnoTalarn]

Good morning, again

I discovered that there is an option on the radio that changes the frequency depending on the mode. Interestingly, this option is for CW, but it affects all operating modes.

It is in the CW setting section, CW Mode, and is called CW FREQ DISPLAY
By default it is in "PITCH OFFSET" but if it is set to "DIRECT FREQ" there is no longer any frequency modification when changing the radio mode.
What you saw in the video, when changing from LSB to USB was not a QLOG thing, it was because of this option. I also saw that it was changing through the screen of the radio itself.
YAESU stuff.

[foldynl]

thanks for the mention here on the forum. Maybe it will be useful for others.

[TecnoTalarn]

Hi again
I have been doing tests and noticed the following:

The error when changing from USB to LSB mentioned above, only occurs with the serial port connection of the Yaesu FT710. IF I make the connection to the Icom 7300 it doesn't happen, and it also doesn't happen if I connect the yaesu ft710 through FLRIG as a bridge via XML tcp. This last method also avoids warnings when turning off the radio, etc., but band or frequency changes are slow, even 5 seconds. This also happens with connections via this way to ICOM, and I think it is a problem with the connection via XMLtcp.
From all this I draw the conclusion that the problem is not in QLOG, but in hamlib. For some reason the configuration for the Yaesu FT710 does not work as it should, and it does not understand the mode change correctly. Maybe need more time between orders? no idea.

Hopefully hamlib will improve the connection to the FT710...

[TecnoTalarn]

Another mistake I found, with the communication of the Yaesu FT-710
When trying to switch from USB mode to DATA-U mode, whether I do it in the radio or in the program (PKTUSB), an error is triggered and the serial communication is disconnected.

With the Icom 7300, everything works OK.

in the video you can see how when clicking on PKTUSB the error occurs.
The radio switches to DATA-U
Enregistrament de pantalla des de 2024-04-22 13-56-27.webm

[TecnoTalarn]

Well, picking up on this thread, I've been noticing several issues with my FT710 and how the CAT works.
I don't know if this should be addressed here, or if the problem is with HAMLIB's external libraries, but since we've started it...

When connecting the radio, whether I use the definition of FT-710 or FTDX10 I have communication, and, in principle, it works.

But there are several functions that either fail or do not behave correctly.
In short, I tend to use the FTDX10 configuration before that of the radio since at least the split works well, and I only use the Yaesu FT710 configuration if I have previously done digital modes, since if the bands are configured in DATA-U in connected QLOG gives me an error, with the definition FTDX10.

[TecnoTalarn]

Hi, it seems that version 0.38.0 supports yaesu's FT710 better
I haven't found any errors in the reported power or modality change, accepting PKTUSB, split, etc

I will keep testing if everything works

Thank you!

[TecnoTalarn]

I add,
the best configuration, where everything seems to work, is NOT the one that uses the parameters of the ft710, but that of the Yaesu FTDX10, and version of QLOG 0.38.0.

[TecnoTalarn]

I don't know why it has been working properly for a while.
But right now it's doing the same thing again, the same errors I've been seeing previously.
It should be noted that the version of hamlib 4.5.5 that QLOG uses is old.
For example, the latest Wsjt-X, uses version 4.6 and I have no problem in radio management.

I think if it were possible to update the hamlib, the problems I have (and I'm sure all FT710 owners have) would be solved.

Or, is there any way to change the hamlib library that QLOG uses manually, by the user?

image of Wsjt-X conf:

[foldynl]

4.6 is not an official release. It is a developer version which, in my opinion, is in a state of constant change. To be honest, I don't understand why the Hamlib maintainer is going this way. But that's his decision. The last official version is 4.5.5, which is distributed for Windows, MacOS and the Flatpak version. The last versions are dependent on the current version in the OS. QLog can be recompiled against Hamlib 4.6.

The fact that the WSJT-X developers decided to distribute the package with 4.6 is their decision. But after reading the issues in Hamlib, I wouldn't recommend it for now.

You can start to push on the Hamlib maintainer to release a stable version after more than a year.

[TecnoTalarn]

Hello
"QLog can be recompiled against Hamlib 4.6."

I wish I could do that.
What tools do I need? I would do it for linux, Ubuntu specifically.

It's really frustrating not being able to play the radio properly. I have an Ic7300 as well, but now I have it on the second QTH (parents) and I have it connected to the shack via vpn and wfview and the qlog works perfectly in remote.

About writing to hamlib? yes, maybe it should be done.

Thanks!

[TecnoTalarn]

I just write to hamlib people:

Hamlib/Hamlib#1605

[kyleboyle]

Somewhat related for ft710 hamlib - on macos drivers I've found that if I use the audio devices from the radio the CAT control gets messed up. Hamlib/Hamlib#1559

[foldynl]

I've been thinking for quite a while about how to proceed with Hamlib. I'm not very happy with how the project is managed. The maintainer's communication isn't very friendly, but unfortunately, I haven't found an alternative that could replace Hamlib.

Another problem with Hamlib is its unpredictable release management. New features are added instead of focusing on fixing bugs and releasing a stable version.

So, the options are either finding a replacement or using the unstable Hamlib directly from the repository. What do you think about this?

[TecnoTalarn]

Hello, it might be interesting to make a compilation of the new version of this software with the two hamlibs, and see how the beta hamlib works, compared to the stable one, in the different radios we have, and that people can have their say .
It would seem that the beta version should not work badly, especially with older radios where there should be no changes. And maybe, on the new radios, we win something.

It's an idea...
73

[aa5sh]

I think based off of the way the maintainer of HamLib is proceeding it is inevitable that a change would need to be made to switch to the repository - bleeding edge versions. Because based on statements he made, he wouldn't make a new release until all bugs are fixed. I for one have never experienced any bug free software. It's just a matter of "reported" or "repeatable" bugs. But something as expansive as HamLib is going to have bugs forever more. For Mac in my github I have it pulling the latest version of HamLib when it generates a new build. Since I've been playing a little with Windows here lately I tried to use a recent snapshot of 4.6 and I wasn't successful in it running. It would give me loads of errors about things being redefined. I think it has an issue with an included header file - off of memory like windows.h and w32tcp.h or something like that. It was giving hundreds of errors. I switched from that and tried to get it to compile and run with 4.5.5. Now that I know I can get that to build successfully maybe I can look back at 4.6 versions of hamlib.

…

On Tue, Nov 19, 2024 at 1:52 PM Jordi Vidal ***@***.***> wrote: Hello, it might be interesting to make a compilation of the new version of this software with the two hamlibs, and see how the beta hamlib works, compared to the stable one, in the different radios we have, and that people can have their say . It would seem that the beta version should not work badly, especially with older radios where there should be no changes. And maybe, on the new radios, we win something. It's an idea... 73 — Reply to this email directly, view it on GitHub <#348 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXT2PCAZALS3IGU3RQT2BOJGJAVCNFSM6AAAAABGD37UDOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZRGA4DIMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aa5sh]

I was able to get 4.6 to work on windows but I don't understand why I had to comment out the line I did to get it to work. But I modified the system windows.h file to comment out it calling winsock.h when I did that is compiled without issue. I found a forum post in the QT forums that said to check that file: