Hi all, I have been using Cqrlog for many years and it has always worked great for me.
I had problems with live qso loading in clublog for a while, but I installed a few days ago the latest version, I think, num: 2.6.0 (116) and since then clublog has been working fine.
Now, however, I have another problem that has never happened to me before.
When I manually enter a correspondent when changing fields, it does not put me in the default mode, either with AUTO activated or deactivated. If I put it manually no problem, but if I leave it and accept the contact, neither HRDlog nor Hamqth accept the upload because the mode is missing.
What's more, if I fix it in the database, it doesn't fix the upload on these two platforms either.
I have no choice but to upload the ADIF manually and mark that everything is already uploaded.
On the other hand, if I put the callsign from the cluster, I have no problem, the mode is loaded, and everything works.
The habit of not having to set the mode means that this often happens to me. Too many years using the program and too wealthy, maybe. ;-)
Maybe it's already fixed in another version?
Thanks.
George
EB3AM (formerly eb3dva)
Hi George!
(116) is my Alpha version that exist also in ready compiled binary. At source side there already is (117) but this kind of error is not reported/fixed with that.
So you do not have any rig CAT connection, all qsos logged manually?
Alpha versions (might be also in official, I do not remember) do start virtual rig if #1 Dummy is selected (previous Cqrlogs did not start it)
It is then defaulting to 145Mhz FM. If "offline" is selected you can select frequency and mode.
If you do not select "offline" you can open TRXControl window set the mode from buttons and frequency by click on MHz display then press Ctrl+A and then enter frequency and press enter.
Or press first mode button and after that one of Band buttons. Then frequency of dummy rig will default to default frequency of that mode and they exist also in NewQSO then (auto selected)
I guess you are used to version of Cqrlog that does not start virtual rig when #1 Dummy rig is selected at preferences/TRXControl,
If you want preferences/newqso default freq and mode to appear then give false name for preferences/TRXControl "path to rigctld binary".
Then entering to preferences will prompt that path to rigctld binary is wrong, but just accept that with OK. This will avoid Dummy rig loading.
--
Saku
OH1KH
I don't know if I understood it right.
Yes, I have radio control. I have an icom 7300 and an icom 705
Both radios have always worked well, at least until now.
I really don't know if the radio is not reporting the mode correctly.
I explain my configuration:
The radio is connected to the WFview program through the usb port and then this program generates a rigctl service.
To this service I connect the cqrlog, and also the JTDX.
This has always been fine with me.
Now that you have commented on the subject of radio control, it is true that the TRXcontrol does not have the mode marked.
and another thing, strange.
If I try to configure cqrlog to work directly against the radio on the /dev/ttyUSB0 port that corresponds to my Icom I see that it tries to connect via rigctld:
...
Waiting for rigctld 2 @ localhost:4545
Waiting for rigctld 3 @ localhost:4545
Waiting for rigctld 4 @ localhost:4545
Waiting for rigctld 5 @ localhost:4545
Waiting for rigctld 6 @ localhost:4545
...
I haven't found a way to make the rigctld not work.
I tried removing the path to the executable, but then I couldn't choose the radio, of course.
In the past I used the transceiver without going through wfview and it worked. I can't now.
Maybe this is fixed in version 117?
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
Hi! OK!
I was thinking you do not have CAT control.
How good is WFview rigctld emulation? Can it all rigctld commands, or just basic set?
I have never tested WFview, so I can not know that.
When WFview is running open command console and type:
telnet 127.0.0.1 4532
When telnet is connected type:
+\dump_caps (and press enter)
You should see long list what your rig can do. This MUST work with Cqrlog
After that type:
+\chk_vfo (and press enter)
You should get reply saying either 0 or 1. This is also needed by Cqrlog to know what kind of command format rig polling uses. How ever you can disable this question from :
Then Cqrlog polls rig same way as when \chk_vfo reply would have been "0"
If +\chk_vfo reply was "0" (or \chk_vfo is uncheked) type:
+f +m +v (and press enter)
That should give frequency mode and vfo from rig (from WFview)
if +\chk_vfo reply was "1" type:
+f currVFO +m currVFO +v
That should then give fequency, mode and vfo from rig (from WFview).
These commands must work from telnet console because Cqrlog uses them to poll rig. If they do not work with WFview you can not get rig data.
----------------------------
Are you sure your ic7300 is device /dev/ttyUSB0?
Is your username in "dialout" group (I think it is if WFview works)?
Have you stopped WFview and started rigctld from preferences/TRXControl? (run rigctld when program starts)
(you can not run WFview and rigctld at same time)
Check also the serial speed to be same as your ic7300 has.
Rig menu CI-V Baud rate.
It is best to select some baud rate instead of using "Auto". "Auto" works, but just to be sure...
--
Saku
OH1KH
hi Saku
Well, I don't know how well WFview handles rigctld, but with the old version of cqrlog it always worked fine.
I pass you the telnet results.
jordi@radio:~$ telnet 127.0.0.1 4545
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
+\dump_caps
Caps dump for model: 148
Model Name: IC-7300
Mfg Name: Icom
Backend version: 0.1
Backend copyright: 2021
Rig type: Transceiver
PTT type: Rig capable
DCD type: Rig capable
Port type: Network link
RPRT 0
+\chk_vfo
ChkVFO: 1
RPRT 0
The USB port is the one I mentioned /dev/ttyUSB0 and it's the one I have on the WFview to connect to the radio. By the way, absolutely everything works there, including the waterfall.
The only thing I can tell you is that with the non-beta version I have always been able to do everything I needed with CQRLog and WFview together, and also with FLrig. I've never seen anything go wrong before.
Yes, obviously when I try to connect the CQRlog directly to the usb port, I turn off any other program that makes the same connection.
Precisely, the grace of using wfview, in addition to having a beautiful interface and the waterfall on the screen, is that it generates the rigctld for me and I can connect multiple programs to it.
I certainly think I will put the last version of 2021 back even if I don't get the clublog.
I attach screenshots of the CQRlog, and wfview configurations.
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
full display
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
WFview USB port connection
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
rigctld settings on wfview
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
I try to connect directly on USB port again (wfview stop, of course)
I put the path: /dev/ttyUSB0 like on the others programs in order to connect.
I remove port and host, but in the console I see how is triing to connect to a null host and default port. why?
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
Hi again SAKU
I don't understand anything anymore.
I changed the rigctld executable to one I have for JTDX and it seems I was able to connect to the USB port directly.
Once done, the mode buttons have appeared activated in TRX control.
I thought that the rigctld I had was not what was needed, but interestingly, I tried it again and now it also connects me via usb port.
I repeat, I don't understand anything anymore.
Well, it is clear that for some reason the information that the cqrlog receives through wfview is not complete, since if I connect directly, I have all the information, and not through the bridge program.
But interestingly, this was not happening to me with the previous version of cqrlog.
I'll post the question to the wfview forum and see what they say.
Thank you very much for your patience.
George
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
HI George!
I downloaded and installed WFview. Poor instructions, I needed to dig out some extra qt5 packages, that were not mentioned in instructions, before getting it run.
The rigctld emulation of WFview is poor and does not have all needed capabilities.
I dig the Gitlab bug reporting page of WFview and found out that once there has been a request to add support for command "fmv" that was the previous Cqrlog polling command string,
How ever Hamlib has changed and Cqrlog has changed and now polling command format of Cqrlog is "+f +m +v" and the is one that WFviev can not handle. It understands "+f" and forgets rest (mode and vfo),
That is why you get only frequency and the is all.
The main problem is that WFview can not handle compound commands (several commands at same line), It can do one command per line, but not more.
But there are also other problems.
I made a new issue reporting what should be fixed to be compatible with current Hamlib (and Cqrlog)
see: https://gitlab.com/eliggett/wfview/-/issues/133
Before they fix it you can not latest Cqrlogs properly.
--
Saku
OH1KH
Hi George!
I have just uploaded (117) source (2023-07-17) that has a checkbox "compound poll" in preferences/TRXControl.
Uncheck that (default checked) will break the compound poll +f +m +v to three lines, each having just one command.
This will help poor emulators like WFview to survive with polling.
Tested with VFview 1.61.
While testing I found that WFview gives different response to +m (get mode) command than original rigctld.
WFview: "TX MODE:", rigctld: "MODE:" this new version can also handle this difference.
--
Saku
OH1KH
thanks a lot Saku
I test it and works as espected. Now I can use de band buttons in TRX control and no go to CW when I running on SSB... Also, I can upload every contact to hamqth beacause the mode is correct.
I'm very busy this last days, and no time to revise this forum.
thanks again from Catalonia
File:
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA
Hi again, I've had time to do some more testing.
With the split orders option in version 117 it works fine. I've only found it missing instead of VFO change, but I don't think wfview handles that well either, yet.
A while ago, instead of using wfview I was using FLrig, and everything was fine.
The fact is that wfview allows you to view the waterfall remotely, and this is a plus. But the Split, for example, is still not very operational. I hope that over time they will polish the software, and these things will be resolved.
Today I downloaded the latest version of wfview, 1.64, and I see that the rigctld is still the same. I saw your comment on gitlab, and I think they closed it, stating that they are rewriting the whole rigctld emulation system. We will wait, and with your button (compound poll), it will be easier for us.
Thank you very much SAKU!
And just to congratulate you for this well-made software!
EB3AM, Jordi
Catalonia
Former call sign: EB3DVA