Hello,
This is something very difficult to test, and I have noticed it before but with the ARRL Sweepstakes on right now, it is very apparent.
This is the issue:
Spots come in on the DX cluster, they get added to the bandmap. At some point, no more spots get added to the bandmap. At first I thought there was a limit on how many could be added on each band, like 20m right now I have 73 on the bandmap, but on 30m I only have 4, yet I see spots on the DX cluster that are no longer added to the bandmap. I'm guessing it's a question of buffer size that would need to be increased, or at least have the option to be increased in a setting.
I realize this is not a priority as most of the time it's not an issue, but the bug happens regardless of mode or band.
Hopefully it's easy to fix.
Thank you,
Marc-Andre, VE2EVN/VA2EI
Attached is a screenshoot. Sorry it's so wide, it's bacause I use dual-screen when using CQRLog.
I highlighted two cluster spots and same on the bandmap where they are missing. There were many more but I think you get the idea from these two.
Marc-Andre, VE2EVN/VA2EI
File:
How about your filter settings?
Click on top left of Bandmap form the color arrows icon. Did the dialog have "Show all" radio button selected?
Right scroll bar shows you have many more items than fit on showing part of form. Did you check that calls weren't there (I.E. just not in freq order)?
--
Saku
oh1kh
--
Saku
OH1KH
Saku,
I never mess with that. It's still at "Show All"
I checked for the spots. Like I said, this is not the first time this happens, but it's hard to test unless there's a big contest since it seems to be a saturated buffer.
On 30m (not shown) it was easy to check, since I only had 4 calls on the bandmap, and new ones weren't being added.
Marc-Andre, VE2EVN/VA2EI
Hi Marc-Andre,
it seems you have the spots in the text editor. How many lines was there? I think there is a limit, but I can increase it a bit.
73 Petr, OK7AN
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hi Petr,
Yes, I copied them to a text editor exactly to be able to count them.
It varied. At first I thought it was stuck at 73, but then I checked a bit later and it was at 85. That's just for 20m.
Could it be that the maximum count is for all bands together? That would explain why I got 85 on 20m, but stuck on only 4 calls on 30m. Oh, also you can't add a spot by CTRL-A or + when then bandmap is full.
I'm afraid I didn't count all of the bands. I guess I should have done that.
I just noticed another bug.. The callsign alert doesn't work anymore. It used to work and I haven't changed anything. But I'll create a new post for that.
Btw Petr, many thanks for this Logger (and for Hamqth). It's by far the best one on Linux. I can't speak for Windows as other than N1MM, I don't use Windows. :-)
Marc-Andre, VE2EVN/VA2EI
Hi Marc-Andre,
the limit for bandmap spots is se to 200:
https://github.com/ok2cqr/cqrlog/blob/master/src/fBandMap.pas#L18
When the bandmap has 200 items, it stops receiving new items. I can increase it to 300 or more but it may be slower a bit.
I also don't use Windows for my ham radio activities at all. I've bought WinTest licence and use it under Wine, for casual contesting use Contest windows develped by Saku, OH1KH. It works very well.
73 Petr
--
http://HamQTH.com/ok2cqr
https://ok2cqr.com
Hello Petr,
Could it be made a config option? That way it doesn't need to slow down the casual user.
I do think it needs to be increased some though, since it affects all bands (ex. 4 spots on 30m..)
I use a few windows apps under Wine as well (MMTTY most often), but for contests I do in a team, I use N1MM, since more people know it. I wish there was a way to run it under Wine.. I'll have to try running it with VirtualBox.
I used Saku's Contest Window last time as I was on my own. It works well, except for the focus switching after every QSO. Other than that it's great, esp the ADIF export that separates into the right fields to ADIF to Cabrillo. That I much prefer to my previous method of doing SQL export, and then making the cabrilo by hand.
Marc-Andre, VE2EVN/VA2EI
Hi !
" It works well, except for the focus switching after every QSO."
Could you open this a bit more, please?
I know there is focusing problem (mentioned in source code) but at least with my Fedora 26/LXDE the practical use does not have any problem.
Just tested the basic entries:
CA1LL (TaB-KEY) 001(ENTER-KEY) -qso logged and focus back at Contest/callsign field
CA2LL (TaB-KEY) 002(ENTER-KEY) -qso logged and focus back at Contest/callsign field
CA3LL (TaB-KEY) 003(ENTER-KEY) -qso logged and focus back at Contest/callsign field
The only focusing event I noticed is that if the NewQSO is minimized when you save qso at Contest form NewQSO will pop up to background but focus returns to Contest form after saving.
Is that what you mean?
How ever it should be visible !
On the top of NewQSO form (show recent QSO records) you can see if you have worked station before. Recent list will appear after focus leaves Contest/callsign field and you can avoid dupes when answering to CQ callers.
Of course if you just run own pileup without checking any other CQ callers you do not need NeWQSO information.
In that case just take low right corner of NewQSO form with mouse left and drag up the form size to minimum (only few millimeters wide top stripe) and it does not bother you so much.
--
Saku
OH1KH
Saku,
Simple. After I press enter when entering the exchange in the contest window, the cursor switches to the Call field on the New QSO window, instead of back to the contest windows. So I have to remember to click on the Contest window every time, otherwise the exchange wont be entered.
I just tested it here now, and still does it. Unlike you, it does not return to the Contest/callsign field.
I'm use MATE, maybe that has something to do with it?
It might be so that the desktop difference does that.
As said I use LXDE because it is light and still has all needed functions, but no more.
It would be interesting to know what happens with other desktops like KDE, Gnome etc.
I could install Mate to my Fedora, but do not like to do so as previous tests with desktops have shown always some changes also to currently used one.
I should have a test machine (maybe VM) for that.
During contest tests I noticed some problems with focus and I did then wrote it down to this procedure:
procedure TfrmContest.InitInput;
begin
...
...
EscFirstTime := True;
{
Next 3 lines of procedure will cause
----
either (dbg msg:input finale):
NOTE: Window with stalled focus found!, faking focus-out event
NOTE: Window with stalled focus found!, faking focus-out event
NOTE: Window with stalled focus found!, faking focus-out event
(cqrlog:2643): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed
(cqrlog:2643): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed
(cqrlog:2643): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed
(cqrlog:2643): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed
----
or(dbg msg: Clear all done next focus ):
NOTE: Window with stalled focus found!, faking focus-out event
NOTE: Window with stalled focus found!, faking focus-out event
----
All works, but this needs attention and I can not resolve this at the moment.
}
frmContest.ShowOnTop;
frmContest.SetFocus;
edtCall.SetFocus;
end;
So those 3 lines are just ones that should return focusing back to Contest/Call input.
--
Saku
OH1KH
--
Saku
OH1KH
Without checking code (in morning coffee table) could this be stored in dynamic variable like merge #63 of LoTW call table ?
Just take as much space as needed should not slow down things.
--
Saku
OH1KH
--
Saku
OH1KH