Hi there,
I'm just wondering, what good the mode-limits will do for me, if entered in the frequencies table.
My assumption was, that if no TRX-Connection is present, the mode will be picked as a suggestion from the table, though offering the option to overwrite it.
This is apparently not the case, as the setting ist taken from the Preferences - New QSO defaults.
My current understanding is as follows:
The frequencies table specifies the *starting* frequency for the relevant mode. That would make e.g. the following values for 80m in Germany:
- Begin (lower band limit): 3.500
- End (upper band limit): 3.800
- CW: 3.500
- RTTY: 3.570
- SSB: 3.620
So CW would be from 3.500 to 3.570, RTTY from 3.570 to 3.620, and SSB from 3.620 to 3.800 (not accounting form beacons and other digimodes).
If my understanding is correct, the question is, what good does this table to me if filled properly?
Thanks & 73
Stefan (currently operating as OZ/DB4ST)
Hi!
At least when you double click DXCluster spot it sets right mode taken form mode qrg's.
But it is not so clear there either. There the "tmp" holds spot frequency as follows:
if (tmp <= cw) then
mode := 'CW'
else begin
if (tmp >= ssb) then
mode := 'SSB'
else
mode := 'RTTY';
So you see setting RTTY frequency really has no use there as check is done only against CW(upper) and SBB(lower) freq.
If you have no rig connection (rig would be moved to freq and mode set) usage is quite minimal.
Then band limits (not modes) are used in ADIF import https://github.com/ok2cqr/cqrlog/pull/282
--
Saku
OH1KH
Hi Saku,
so in other words, CQRLOG treats everything between "Begin" and "CW" as CW, everything between "SSB" and "End" as SSB and the bit in between "CW" and "SSB" as RTTY. - OK. So it's rather for my own reference to quickly lookup, if I don't have a bandplan at hand and no internet ...
Seems to me like old code that got lost somewhere in the development process ;-)
73
Stefan (currently OZ/DB4ST)
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
Hi Saku,
... me again.
There are 2 different QRG-tables in the preferences!
... and they seem to be comletely unrelated. Moreover, what I'd expect is, that the latter is relevant for the case, that no TRX is connected via CAT ...
Well, interesting what you find, if you take some time to work through all the options ...
73
Stefan.
--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE
I recently updated to version 2.4.0 (135) becasue my TRX control was not communicating with the radio. It was related to my old version of hamlib 3.3 and fixed with hamlib 4.
I notice that whenever I double click a selected spot from the DXCluster window, the radio will QSY properly, but the mode will not change. I've reviewed the following items"
"Preferences - Bands - Frequencies" and also "Preferences - TRX Control - Change default frequencies" and all seems correct. Where else might I look to correct this issue?
Rig: FT-1000D
See
https://www.cqrlog.com/node/2510#comment-8543
Thanks,
Bob WG9L
HI Bob!
You are using my alpha test binary. There are some differences in mode section compared to official version.
Please try to upgrade to official version. It is now available also in my GitHub with alpha versions.
With running newupdate.sh select option #1 to install latest official version.
Does that change modes ok? (it can not change user defined data mode as alpha, only CW,RTTY and SSB work).
--
Saku
OH1KH
Hi Saku,
I updated to the latest official release using github. BTW, your YouTube video showing each step was wonderful. It walked me through every step (quite easy). Now I'm running version 2.5.1 (001), but still no luck. When I double click a spot in the Band Map window, the rig changes frequency, however the mode still doesn't change from CW to SSB. Has a newer Alpha version corrected this?
HI!
Go preferences TRXcontrol.
Set poll rate to 5000 to get littöe less lines to debug. You can return it later to value it was before.
Check bottom "Show communication with TRX in console". Then exit from preferences.
Close cqrlog.
open command console and write
cqrlog (enter)
You should now see only commands to rig/response from rig.
Open DXCLuster and click a spot. Do you see correct mode in console as rig command?
This is to check that cqrlog sends correct mode but rig does not change it.
If mode in console command to rig is wrong then check again preferences/bands/frequencies table.
There is no difference between official and alpha in this case.
--
Saku
OH1KH
HI!
Go preferences TRXcontrol.
Set poll rate to 5000 to get littöe less lines to debug. You can return it later to value it was before.
Check bottom "Show communication with TRX in console". Then exit from preferences.
Close cqrlog.
open command console and write
cqrlog (enter)
You should now see only commands to rig/response from rig.
Open DXCLuster and click a spot. Do you see correct mode there ?
This is to check that cqrlog sends correct mode but rig does not change it.
If mode in console command to rig is wrong then check again preferences/bands/frequencies table.
There is no difference between official and alpha in this case.
--
Saku
OH1KH
Hi Saku,
With those TRX settings, the console displays the proper vfo-A and frequency, but the mode still doesn't change properly. Maybe I don't understand how to properly edit the table. I have attached a copy of my table, and a console image of the proper CW results, along with the improper SSB results and shot of the log window for the SSB information. Double clicking a DX spot doesn't change the radio mode, or CQRLOG log window mode.
File:
HI !
According your frequencies table your 20m band has :
start from 14.000Mhx, end to 14.350Mhz
CW is from "Begin" 14.000 to 14.025Mhz
SSB is from 14.150Mhz to "End" 14.350Mhz
RTTY begins from 14.070Mhz and ends to SSB start 14.150MHz
"Grey area" is from CW end 14.025MHz to RTTY start 14.070MHz
There is a (poor) explanation,because of limited space, at the bottom of form where:
"Begin" - defined start frequency of band
"End" - defined end frequency of band
"f>=" - frequency (f) is bigger or equal
"f<=" - frequency (f) is smaller or equal
So we read this:
CW:(f>= Begin and f<=CW)
as:
CW frequency area is when frequency is bigger or equal than defined band begin frequency and frequency is smaller or equal as definition CW frequency
I admit this whole frequency table is deep from ... and it is hard to understand and set up.
Frequencies should be put in own extended database (at programmers side) and user interface should have clear band begin/end (as it is now), but also for each mode should have own begin/end setups and there should be as many modes user wants to define. Not just CW RTTY and SSB.
This is a bigger job to do, but should be done in sake of easy maintain.
I think your problem is in these settings. In my setup (in my region) 20m band is:
14.000 14.350 14.060 14.060 14.100
What I was looking from rig CAT traffic was that when you double click a DX spot you should see something like:
Sending: F 10105100
Sending: M CW 500
Msg from rig: RPRT 0
RPRT 0
There I did click a spot in 10.105Mhz and cqrlog sends first
"change frequency"= Sending: F 10105100
then it sends
"Change mode"=Sending: M CW 500
Those I was interested in. But it looks like you have to set up the frequencies table right frist. After that you can peek again rig communication if you still do not get right mode. I was using in test rig poll rate 5000 to get slow enough update rate to see all lines.
--
Saku
OH1KH
Saku,
I also am having this problem. I am using a Kenwood TS-570D rig. I started the program from the terminal and looked at the rigctl communications. I am not seeing any "Sending M CW xxx" or "Sending M SSB xxx" in the terminal after clicking a spot in the cluster window. There are commands to the rig "Sending F xxx" though. The righ does change frequency and the frequency populates the log properly, but the mode doesn't change or populate the log. Since I can't attach a zip or tgz file with several examples, I am attaching a single example here. I can email you captures of the other cases, as well as my bands-frequencies table and a capture of the rigctl startup parameters as shown in the terminal, if that helps.
I am also having an issue where rigctl seems to reset my CW keyer speed to 42WPM on startup. I am using Hamlib as the keyer, and have the default setting set to 31WPM. Every time I start CQRLog, or reload CW interface, the keyer changes speed to 42WPM.
Any ideas?
Thanks,
Dave
N1KX
File:
Hi Dave!
preferences/bands/frequencies table is a bit unclear. It should be rewritten so that it would be easy to configure and it should work also with bands where the order of modes is different than CW-RTTY(data)-SSB. How ever it is a bigger job. Maybe some day...
When you set preferences/TRXControl/Show communication with TRX in cosole and set poll something like 10000-15000 and start cqrlog from command console by typing cqrlog (enter) you will see, and have time to see, what happens. Do not use "--debug=1" in this case to get just TRX communication lines to console.
But be patient. With big poll rates everything happens slowly.
At the bottom of window there is an explanation how mode limits are set. It is written with bigger,smaller and equivalent marks to save space.
You should read is as follows:
CW segment frequencies(f) are bigger or equivalent of value band "begin" and smaller or equivalent of value "CW"
RTTY (here in my version it is called DATA) segment frequencies(f) are from bigger value than "DATA" and smaller or equivalent of value "SSB"
SSB segment frequencies(f) are bigger value than "SBB" and smaller or equivalent of value "End"
Below 10MHz and between 5-6MHz ssb is LSB otherwise USB
These settings control the mode setting when DXCluster spot is clicked.
Now, with slower rig poll rate you have to find out:
1) does the rig get the M command at all (now you have time to see it properly)
2) is the value for M command right (that is controlled by frequencies table)
I recommned to upgrade to the latest version. If you can not compile by your self then you can install ready compiled binary from my GitHub. There is a newupdate script that does the upgrading. You just have to download and start it.
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
Tell me what you find out, please.
--
Saku
OH1KH
Thanks for the tips. This is still not working for me. The only changes I have for my band-frequency table are to make the band edges conform to my local area (80M goes up to 4.00 here and 40M goes to 7.3). I have attached a screenshot of the table.
I tried clicking on spots in the cluster and as usual, the rig changes frequency fine and the log populates with the callsign and information, but the mode doesn't change. I see the frequency change command in the terminal window, but no mode change command. Here are some examples:
CW to SSB
Change from Msg from rig: GET_FREQ:
FREQUENCY: 21020400
RPRT 0
Msg from rig: GET_MODE:
MODE: CW
PASSBAND: 1000
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Sending: +F 21295000
Msg from rig: SET_FREQ: 21295000
RPRT 0
Poll Sending: +f +m +v
SSB to CW
Msg from rig: GET_FREQ:
FREQUENCY: 21295000
RPRT 0
Msg from rig: GET_MODE:
MODE: USB
PASSBAND: 500
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Sending: +F 14030000
Msg from rig: SET_FREQ: 14030000
RPRT 0
Poll Sending: +f +m +v
Msg from rig: GET_FREQ:
FREQUENCY: 14030000
RPRT 0
Msg from rig: GET_MODE:
MODE: USB
PASSBAND: 500
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Poll Sending: +f +m +v
I am not seeing the command to change mode happening. I *think* I have the band-frequency table correct.
Are you seeing anything I am missing?
Thanks!
Dave
File:
Hi Dave!
Let's do another test.
Open console (before cqrlog) and start rigctld manually with test rig:
rigctld -m1 -vvvv
Leave command console open (prompt does not return)
Then change cqrlog preferences/TRXcontrol in following way:
- change rig model to Hamlib Net rigctld (rig #2)
- uncheck "Run rigctld at program start"
- open TRXControl window of cqrlog
- you can use normal poll rate 500-1500 to check this. You can later make bigger value if you want to get more time to see what happens.
Then you should see frequency 145.000Mhz and every time cqrlog poll you should see debug texts appearing at command console where "rigctld -m1 -vvvv" is running.
Now double click a DX spot(s) and see if TRXControl changes frequency and mode (should set current mode button text to red)
Does that dummy rig follow the mode changes by DX spots.
I.E. I'm trying to clear out is this also somehow related to your rig model.
For me it is working ok with #2 Hamlib dummy rig and I see you are using my "test binary" as you have also "DATA" at frequency table, so it should work similar way for you. The latest is 2.5.2(112) in use here.
--
Saku
OH1KH
Thanks again, Saku.
OK, I set up the dummy rigctl and cqrlog settings as you suggested. I tried selecting spots, and as before, no change to mode was commanded (no "rig_set_mode" or "dummy_set_mode" command issued). Frequency changed and populated the log as expected, but no change to mode was see and the mode buttons did not change color either. However, if I clicked the mode buttons, I did see the mode_change command issued and the button changed color to match.
Here is an example of what I see in the terminal when selecting a spot:
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(1987):rigctl_set_freq entered
rig_set_freq called vfo=currVFO, freq=14236000
dummy.c(422):dummy_set_freq entered
dummy_set_freq called: VFOA 14.2360000 MHz
dummy.c(463):dummy_set_freq return(0)
rig.c(1997):rig_set_freq return(0)
rigctl_parse.c(1999):rigctl_set_freq return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2011):rigctl_get_freq entered
rig_get_freq(2038) called vfo=currVFO
rig.c(2047) vfo=currVFO, curr_vfo=VFOA
dummy.c(471):dummy_get_freq entered
dummy_get_freq called: VFOA
dummy.c(508):dummy_get_freq return(0)
rig.c(2219):rig_get_freq return(0)
rigctl_parse.c(2037):rigctl_get_freq return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
rigctl_parse.c(847):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2148):rigctl_get_mode entered
rig.c(2377):rig_get_mode entered
dummy.c(567):dummy_get_mode entered
dummy_get_mode called: currVFO
dummy.c(584):dummy_get_mode return(0)
rig.c(1411):set_cache_mode entered
rig.c(1475):set_cache_mode return(0)
rig.c(2486):rig_get_mode return(0)
rigctl_parse.c(2171):rigctl_get_mode return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
rigctl_parse.c(847):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2222):rigctl_get_vfo entered
rig.c(2805):rig_get_vfo entered
dummy.c(656):dummy_get_vfo entered
dummy.c(660):dummy_get_vfo return(0)
rig.c(2864):rig_get_vfo return(0)
rigctl_parse.c(2238):rigctl_get_vfo return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2011):rigctl_get_freq entered
rig_get_freq(2038) called vfo=currVFO
rig.c(2047) vfo=currVFO, curr_vfo=VFOA
dummy.c(471):dummy_get_freq entered
dummy_get_freq called: VFOA
dummy.c(508):dummy_get_freq return(0)
rig.c(2219):rig_get_freq return(0)
rigctl_parse.c(2037):rigctl_get_freq return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
rigctl_parse.c(847):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2148):rigctl_get_mode entered
rig.c(2377):rig_get_mode entered
dummy.c(567):dummy_get_mode entered
dummy_get_mode called: currVFO
dummy.c(584):dummy_get_mode return(0)
rig.c(1411):set_cache_mode entered
rig.c(1475):set_cache_mode return(0)
rig.c(2486):rig_get_mode return(0)
rigctl_parse.c(2171):rigctl_get_mode return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
rigctl_parse.c(847):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
mutex_rigctld: client lock engaged
rigctl_parse.c(2222):rigctl_get_vfo entered
rig.c(2805):rig_get_vfo entered
dummy.c(656):dummy_get_vfo entered
dummy.c(660):dummy_get_vfo return(0)
rig.c(2864):rig_get_vfo return(0)
rigctl_parse.c(2238):rigctl_get_vfo return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
As you can see, there is never any "rig_set_mode" or "dummy_set_mode" command issued. Is there any other setting that may inhibit setting mode from double-clicked cluster spot?
Here is what I see when clicking the Mode buttons on TRXControl:
mutex_rigctld: client lock engaged
rigctl_parse.c(2125):rigctl_set_mode entered
rig_parse_mode called
rig_set_mode called, vfo=currVFO, mode=CW, width=1000
dummy.c(518):dummy_set_mode entered
dummy_set_mode called: VFOA CW 1.0000 kHz
dummy.c(559):dummy_set_mode return(0)
rig.c(1411):set_cache_mode entered
rig.c(1475):set_cache_mode return(0)
rig.c(2343):rig_set_mode return(0)
rigctl_parse.c(2137):rigctl_set_mode return(0)
mutex_rigctld: client lock disengaged
rigctl_parse.c(1762):rigctl_parse return(0)
rigctl_parse.c(655):rigctl_parse entered
This is consistent for each of the Mode buttons, so they work just fine. Looks like the selection from cluster is the only problem I am having. If it proves too hard to figure out, I'll just live with it, because the logging program is just too good for me to worry too much about this.
Thanks for your help!
Cheers,
Dav
N1KX
OK Dave!
Let's check this:
Check that you have "mode Auto" checked at "NewQSO".
I was looking at source code and it seems to effect to DX spot clicking result. Without checking mode does not change with my system, when checked it does.
--
Saku
OH1KH
Hah! Son of a gun! That's it! Thanks for finding that, as I never would have thought of it!
Now the cluster spot populates the log and the rig changes frequency *and* mode.
Cheers!
Dave
N1KX
Hi !
Forgot the hamlib keyer., sorry.
Now when you have set rig poll rate bigger 10000-15000 you can start cqrlog with "--debug=1" and look at the console when you use NewQSO/File/Reload CW interface or when you press PgUP/PgDN keys.
Close all other cqrlog windows like DXCluster etc. and keep just NewQSO open. That reduces debug printing.
cqrlog should send command:
L KEYSPD
followed by WPM value. Is that what is expected?
You can also open command console and type:
telnet localhost 4532
And when you get prompt try manually change speed by typing:
L KEYSPD 31
Does it work from console?
--
Saku
OH1KH
OK, I'm not sure what the exact issue is here, but I tested this using commands from the terminal via telnet. I tried settings from 10 to 30 using the command "L KEYSPD xx" and got odd results. Settings of 10 and under result in 0 as the setting on the rig. Then I get this:
KEYSPD Rig Setting
11 2
12 4
13 6
14 8
15 10
16 12
17 14
18 16
19 18
20 20
and so on....
So setting 28 in the program gives me a speed of 36 on the rig. Now that I know that, I can deal with it and get a proper default setting on the rig. However, I do not know why this happens, but it is probably an issue with how the rig handles things. I know the lowest keyer setting on the rig is 10WPM, so that's not a mystery.
At any rate, I am satisfied that I can set the keyer to what I want. This is just a hamlib/rig issue and not a cqrlog issue, I am sure.
Thanks for the testing tips!
Cheers,
Dave
Hi Dave!
I opened a conversation about this @hamlib-developer list and got few comments already.
https://sourceforge.net/p/hamlib/mailman/hamlib-developer/?viewmonth=202...
Mike, W9MDB, has done lot of work with Hamlib and he is very kind and helpful. Perhaps he gets this fixed, too.
There is already first fix done, so you should get latest Hamlib source from GitHub compile and test it.
https://github.com/Hamlib/Hamlib
--
Saku
OH1KH
Thanks, Saku!
I just cloned and compiled the latest Hamlib a few days ago hoping it would fix the issue. I will pull the latest to try out the fix Mike added since your post (actually, compiling it now).
I'll keep track of this issue with the Hamlib folks, as you suggest. Thanks again for your help!
Just to see if it worked with cqrlog, I did try using flrig a while back but didn't get it to work right, so stuck with rigctl. I admit, I did not try very hard to get it working because rigctl worked fine, but I got the idea when setting up fldigi to participate in a RTTY contest.
Again, thanks for all your help! I think I have a grip on this now, and am completely cleared on the cluster spot issue too.
Cheers!
Dave
N1KX
By the way, I think I found the issue, in case others are having the same problem.
It is a bad implementation of a feature in the rig. The operator can adjust CW speed in steps, from 0 to 100. However, the "steps" do not equal "WPM." The back of the manual says CW speed can be adjusted from 10 to 60 WPM. So that gives us the issue with converting steps to WPM, which Mike correctly determined was (steps-10)*2. I posted to the comment thread on github.
So no issue for me now. I understand what is happening and can easily set my keyer speed now that I know this. Hamlib development may make changes, but I am not sure "the juice is worth the squeeze."
I compiled the latest hamlib and now it doesn't work at all with cqrlog, so I'll be rolling back to the last official release. :(
Thanks!
Dave
N1KX
Hi Dave !
Nice to hear that all is ok now. Fine that you are sharing this information that may help also others!
I did just compile latest Hamlib (and wsjtx) but for my icom 7300 it seems to work ok.
--
Saku
OH1KH
Hi Dave !
Nice to hear that all is ok now. Fine that you are sharing this information that may help also others!
I did just compile latest Hamlib (and wsjtx) but for my icom 7300 it seems to work ok.
--
Saku
OH1KH
Not sure what I did, but those last 2 commits Mike posted worked fine with cqrlog. So it turns out I did not have a problem with the latest hamlib build after all. So right now I'm running the latest cqrlog build and the latest hamlib build and all is well.
Thanks again for your help and for making cqrlog such a great logging program!
Cheers,
Dave
N1KX
cw vfo-A
File:
ssb vfo-A
File:
log window vfo-A
File: