View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002958||Ham Radio Deluxe||Bug||public||2018-11-29 08:59||2019-03-31 11:13|
|Target Version||Fixed in Version||18.104.22.168|
|Summary||0002958: Spotted stations not appearing in Bandmap|
|Description||Ticket #839503 - We have had customers reporting that when they spot a contact they have worked on the WA9PIE and other nodes in the DX Cluster, the spot will immediately appear on the cluster node but will not appear as a new spot on the bandmap. |
This also happens with many new spots that appear on the DX Cluster node, they show up on the node but are not transferred to the bandmap. When a new spot comes in on the node, the spotted callsign should appear in RED on the bandmap related to spotted band. It will remain on the bandmap in RED until the time limit has been reached that the user has configured, then it will be shown in BLACK.
This has been reported in many different releases of Ham Radio Deluxe going back for years. It's not a common issue that's reported but some operators do notice it and would like it corrected.
|Steps To Reproduce||Open Logbook and activate DX Cluster to the WA9PIE node.|
Click the "SPOT" button on the DX Cluster toolbar
Enter a callsign to spot on the node.
The spot will immediately show up in the DX Cluster node, but NOT in the bandmap that's selected for the band the call was spotted on.
|Tags||No tags attached.|
Not much to go on, here. It would be useful to know the duration of the filter setting, for example.
The documentation doesn't describe this (see Mantis 3141), but from my read of the code, spots that miss the cutoff of the filter are not displayed at all. Coloring is selected based on count; the 5 most recent spots are red, the next 15 are black, and the rest are "dark slate gray".
If this evaluation of the code is true, and the filer is 60 minutes or less, then Mantis 3140 can be the root cause of at least some of the missing spots. When spots arrive, they're in UTC. The system converts them to local time, then figures out how old they are. If that conversion is off by an hour (because of 3140) then some spots will sporadically miss the filter and won't appear.
||With 3140 resolved, has this issue improved?|
||We need to test and see if the DX cluster filter is preventing spots from going into the bandmap.|
From our observations today in the meeting...
The bandmap seems to be loaded from the initial spots received... but no subsequent spots received are displayed in the bandmap.
I spent a few hours playing with this feature to try and isolate what might be happening. Because the issue doesn't contain descriptive steps, I had to examine several different settings to see if they have influence on the problem. There are several (up to 10!) DX Cluster Dial windows. Each can have its own filters and font settings, and will show only the items that match that filter. Further, I discovered that the problem isn't immediately apparent when the initial population of the cluster window is low (0 or 50 initial spots) but is much more easily observed when the initial population of the cluster window is high (500 initial spots).
There's lots to puzzle over in the implementation, which is in DXClusterDial.cpp and DXClusterDialWnd.cpp. However, it seems like it's mostly stable.
I think the issue here is that there hasn't been consideration given to the desired behaviour in light of a built-in limitation of the UI. Spots arrive to the application from a server, and there might be a dozen or so spots per minute in a busy time. When first connecting, the user might set the application to request many -- up to 500 -- spots from the server to be downloaded on the initial connection.
The cluster dial pane doesn't scale to a large number of visible spots. At an absolute maximum it can display 50 spots. The effective number is usually lower due to the window size.
Since the DX Cluster dial UI can't nearly as many spots as received, what is the desired behaviour?
It seems like one idea is to display only the newest spots. This directly resolves the perception that new spots aren't shown. The spots must be sorted first by age, the oldest spots (which can't be displayed) are discarded. Then, the spots which remain are sorted in frequency order so their presentation is neat along the order of the frequency gage in the window.
It's conceivable that some other priority order can be invented for deciding which spots to display. For example, maybe spots which have a "more worked" WSI are discarded first, and spots with a "more needed" WSI are kept and displayed longer. Spots matching an alarm might be given a higher priority, too, and kept longer.
I'm comfortable with this solution with exception that the code makes it clear that conscious effort was made to evaluate the oldest spots first rather than the newest first. Has the design changed? Was there just an egregious bug?
Fixed, as much as described above, with this checkin:
||Validated (recognizing the limitations)|
|2018-11-29 08:59||KB3NPH||New Issue|
|2019-01-30 22:15||K7ZCZ||Note Added: 0007174|
|2019-01-30 22:15||K7ZCZ||Relationship added||related to 0003140|
|2019-01-30 23:14||WA9PIE||Relationship deleted||related to 0003140|
|2019-01-31 15:16||K7ZCZ||Relationship added||related to 0003140|
|2019-02-27 17:02||WA9PIE||Module||(select) => Logbook|
|2019-03-06 22:04||K7ZCZ||Assigned To||=> KB3NPH|
|2019-03-06 22:04||K7ZCZ||Status||new => feedback|
|2019-03-06 22:04||K7ZCZ||Note Added: 0007608|
|2019-03-21 15:58||WA9PIE||Note Added: 0007718|
|2019-03-28 15:51||WA9PIE||Note Added: 0007784|
|2019-03-30 15:56||K7ZCZ||Note Added: 0007807|
|2019-03-30 15:56||K7ZCZ||Status||feedback => resolved|
|2019-03-30 15:56||K7ZCZ||Resolution||open => fixed|
|2019-03-30 15:56||K7ZCZ||Note Added: 0007808|
|2019-03-30 15:56||K7ZCZ||Note Edited: 0007808||View Revisions|
|2019-03-31 09:24||K7ZCZ||Project||1 - Backlog => 3 - Current Dev List|
|2019-03-31 09:24||K7ZCZ||Fixed in Version||=> 22.214.171.124|
|2019-03-31 09:30||K7ZCZ||Fixed in Version||126.96.36.199 => 188.8.131.52|
|2019-03-31 09:30||K7ZCZ||Sub-Module||(select) => DX Cluster|
|2019-03-31 11:04||WA9PIE||Status||resolved => closed|
|2019-03-31 11:04||WA9PIE||Testing||Not Started => Beta Successful|
|2019-03-31 11:04||WA9PIE||Note Added: 0007811|
|2019-03-31 11:13||WA9PIE||Fixed in Version||184.108.40.206 => 220.127.116.11|
|2019-03-31 11:13||WA9PIE||Project||3 - Current Dev List => Ham Radio Deluxe|