View Issue Details

IDProjectCategoryView StatusLast Update
0002958Ham Radio DeluxeBugpublic2019-03-31 11:13
ReporterKB3NPHAssigned ToKB3NPH 
PrioritynormalSeverityminorReproducibilityrandom
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.5.0.207 
Summary0002958: Spotted stations not appearing in Bandmap
DescriptionTicket #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 ReproduceOpen 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.

TagsNo tags attached.
ModuleLogbook
Sub-ModuleDX Cluster
Testing Beta Successful

Relationships

related to 0003140 closedK7ZCZ SystemTimeTotimet() copy-paste function is broken 

Activities

K7ZCZ

2019-01-30 22:15

manager   ~0007174

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.

K7ZCZ

2019-03-06 22:04

manager   ~0007608

With 3140 resolved, has this issue improved?

WA9PIE

2019-03-21 15:58

administrator   ~0007718

We need to test and see if the DX cluster filter is preventing spots from going into the bandmap.

WA9PIE

2019-03-28 15:51

administrator   ~0007784

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.

K7ZCZ

2019-03-30 15:56

manager   ~0007807

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?

K7ZCZ

2019-03-30 15:56

manager   ~0007808

Last edited: 2019-03-30 15:56

View 2 revisions

Fixed, as much as described above, with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4911

WA9PIE

2019-03-31 11:04

administrator   ~0007811

Validated (recognizing the limitations)

Issue History

Date Modified Username Field Change
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 => 6.5.0.205
2019-03-31 09:30 K7ZCZ Fixed in Version 6.5.0.205 => 6.5.0.206
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 6.5.0.206 => 6.5.0.207
2019-03-31 11:13 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe