JTALERT - Dxcluster


Paul&Tracy Richards
 

Hello Laurie

I am a big fan of JTAlert for many reasons but two of the big reasons are the way your program sets out the incoming data in box format - rather than as a list as we see with dxcluster programs and gridtracker for example. I also like the simple control I have over the data that is output in terms of Awards and the ability to scan my logbook etc.

Have you ever given consideration to creating an alert program in the same format as JTAlert but for dxcluster data rather than incoming digital data. I would guess (maybe incorrectly) that the concept of JTAlert would not require that much change as we are simply substituting a different source  of incoming data. I have tried most of the dxcluster programs around, both stand alone and within logbook programs and I always come away thinking I wish they would work in the same way as JTAlert. I guess it is congrats to your program design skills more than anything else. Anyways, something for your consideration, I am guessing such a program could / would be very popular as I am sure I am not the only dxer that feels this way.

If there is a dxcluster program out there that presents in the same way as JTAlert, that I may have missed I would also be keen to hear about it.

Cheers
Paul - vk4ma


HamApps Support (VK3AMA)
 

On 11/01/2022 1:05 pm, Paul&Tracy Richards wrote:

I am a big fan of JTAlert for many reasons but two of the big reasons are the way your program sets out the incoming data in box format - rather than as a list as we see with dxcluster programs and gridtracker for example. I also like the simple control I have over the data that is output in terms of Awards and the ability to scan my logbook etc.

Have you ever given consideration to creating an alert program in the same format as JTAlert but for dxcluster data rather than incoming digital data. I would guess (maybe incorrectly) that the concept of JTAlert would not require that much change as we are simply substituting a different source  of incoming data. I have tried most of the dxcluster programs around, both stand alone and within logbook programs and I always come away thinking I wish they would work in the same way as JTAlert. I guess it is congrats to your program design skills more than anything else. Anyways, something for your consideration, I am guessing such a program could / would be very popular as I am sure I am not the only dxer that feels this way.

If there is a dxcluster program out there that presents in the same way as JTAlert, that I may have missed I would also be keen to hear about it.

Cheers
Paul - vk4ma
Paul,

Having JTAlert take an external spot feed is on my todo list. There is a lot to consider and test, it is not a trivial implementation.

The biggest issue is how to best handle a high-volume high-throughput spot feed while keeping JTAlert responsive and keep cpu & memory usage low. A data-point to give some context, a typical day of FT8 spots feeding HamSpots averages around 50 million spots per day at around 12Gbyte of data. That sort of data feed is not really suitable, so some sort of filtering is needed and needs to happen at the source of the spots. and not at the destination (JTAlert) of the spots IMO.

This is not something that will be implemented in the short term. All I can say is it is on my todo-list and that some initial coding/testing has been undertaken. It is not high-priority, I can't provide a realistic ETA.

de Laurie VK3AMA


Michael Black
 

I have a cluster utility that sits between Log4OM and the cluster spotting.  I've not released it for public consumption yet but it's about time to do so.  I need to build a help file for it but it's mostly operable from tool tips though some things may need explanation.

If there's a Log4OM user out there that would like to be a guinea pig please speak up.

It does the following
#1 QRZ lookups and ignores invalid callsigns based on bad QRZ lookup.
#2 Caches QRZ lookups to avoid hitting QRZ too much.
#3 Caches callsigns to avoid repeats
#4 Dumps spots to client periodically in 1,15,30,60 second intervals selected by the user (keeps cluster program from scrolling too much)
#5 Allows curating spotters.
And for JTAlert would want to filter out CW and RTTY spots.  Most spots are CW.
Also a good thing to do is filter spots by your own state and maybe one state in each direction to make the spots more relevant.

Mike W9MDB
Inline image





On Wednesday, January 12, 2022, 03:08:52 PM CST, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 11/01/2022 1:05 pm, Paul&Tracy Richards wrote:
>
> I am a big fan of JTAlert for many reasons but two of the big reasons
> are the way your program sets out the incoming data in box format -
> rather than as a list as we see with dxcluster programs and
> gridtracker for example. I also like the simple control I have over
> the data that is output in terms of Awards and the ability to scan my
> logbook etc.
>
> Have you ever given consideration to creating an alert program in the
> same format as JTAlert but for dxcluster data rather than incoming
> digital data. I would guess (maybe incorrectly) that the concept of
> JTAlert would not require that much change as we are simply
> substituting a different source  of incoming data. I have tried most
> of the dxcluster programs around, both stand alone and within logbook
> programs and I always come away thinking I wish they would work in the
> same way as JTAlert. I guess it is congrats to your program design
> skills more than anything else. Anyways, something for your
> consideration, I am guessing such a program could / would be very
> popular as I am sure I am not the only dxer that feels this way.
>
> If there is a dxcluster program out there that presents in the same
> way as JTAlert, that I may have missed I would also be keen to hear
> about it.
>
> Cheers
> Paul - vk4ma

Paul,

Having JTAlert take an external spot feed is on my todo list. There is a
lot to consider and test, it is not a trivial implementation.

The biggest issue is how to best handle a high-volume high-throughput
spot feed while keeping JTAlert responsive and keep cpu & memory usage
low. A data-point to give some context, a typical day of FT8 spots
feeding HamSpots averages around 50 million spots per day at around
12Gbyte of data. That sort of data feed is not really suitable, so some
sort of filtering is needed and needs to happen at the source of the
spots. and not at the destination (JTAlert) of the spots IMO.

This is not something that will be implemented in the short term. All I
can say is it is on my todo-list and that some initial coding/testing
has been undertaken. It is not high-priority, I can't provide a
realistic ETA.

de Laurie VK3AMA