locked Re: Any plans to add more RX squares ?


TomK
 

I had thought of this myself but, as Laurie has previously noted and as I’ve now come understand, it is not just a matter of visual real-estate but, more importantly, the time it takes for (1) painting (aka “rendering”) the squares and (2) the user to read, interpret and react to the squares.  Perhaps even most important is, after all the above, there is no more time for the user to execute their desired action before the grid start to re-render the next time slice.

 

The nifty feature Laurie added a while back to retain the grid cell data as log as possible up to a limit does not help when all the grid cells are already populated.

 

In so much as it can take at least 1-6 secs to render all the squares based on PC and code speed plus another 1-2 secs for typical cognitive brain response.  That leaves less than 8-10 secs to visually, decipher and react to their analysis of 50 info boxes? 

 

I may be maturing but I challenge anyone to keep that up for more than a few minutes without entering something us data nerds used to call “data wash” or “data-out”.

 

However, assuming there are no other limiting factors and it is technically possible, I am not opposed to allowing a user to select another 1 row and column for a total of 50 grid cells.  Such an option would be inherently self-limiting when the user realizes they can’t respond to the resulting deluge. 

 

Just my 13 cents.

TomK KT1TK 73

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of HamApps Support (VK3AMA)
Sent: Thursday, September 24, 2020 8:49 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Any plans to add more RX squares ?

 

On 25/09/2020 10:15 am, ed.n5dg@... wrote:

36 RX squares is fine on most bands . 20m and 40m being the busy bands an extra 16 squares would be about right . instead of 4 x 9 squares 4 X 13 would make the width about the same as WSJTX.
Thanks for the great SW , Ed N5DG


Ed,

This has been discussed many time. See https://hamapps.groups.io/g/Support/message/29940

IMHO, 36 displayed Callsigns is TOO many. It is a chaotic mess of multiple colored callsigns. A better option is to filter out most of the unwanted Callsigns. Use the Alert Filters to help reduce the number displayed. Try filtering out B4s and non-alerting callsigns.

A JTAlert window with few callsigns displayed due to filtering makes for a more enjoyable (IMO) experience in the shack. It is less stressful time without trying to decide every 15 seconds which Callsign could be a possible QSO candidate. It is a far less chaotic experience.

The beauty with filtering is that a Callsign that is displayed in JTAlert (has passed the filtering) is likely a good candidate for a QSO. But this approach wont appeal to those more interested in racking up a high QSO count, that is qso "quantity" rather than qso "quality".

Currently, there is code with the Test Team (not yet available for public release) that removes the limit on the number of displayed Callsigns. While this new code allows for more than 36 callsigns, its primary focus is providing a flexible display window without any size restriction (width or height) with flexible sizing comes the additional benefit of increased callsigns displayed. Sorry, there is no ETA on when this will be available publicly.

de Laurie VK3AMA

Join Support@HamApps.groups.io to automatically receive all group messages.