Date   

locked Re: RTTY RU Worked Before Problem

JTAlert Support (VK3AMA)
 

On 14/01/2022 8:19 am, Jeff Young wrote:
Yes. I receive a confirmation from JTAert that the contest was logged and the logged QSO shows up immediately in the N3FJP log on my second screen. 

Also, there was no restart of JTAlert during the contest. What would happen if the software is restarted?

Thanks 
Jeff KB3HF 

Jeff,

If JTAlert is confirming the QSO was logged, which involves a direct read of the physical log file, then the B4 checks which are performed against the physical log file should also be accurate. I don't have an explanation at this time why the B4 status is lost on a band change, it appears that something is not working correctly. It may be in the JTAlert code in relation to the changes necessary to utilize one of the N3FJP contest loggers rather than ACLog.

I will need to reinstall my N3FJP software and setup a contest test environment to run some tests and hopefully can replicate the issue. If you don't mind, it would be helpful if I could get a zipped copy of your N3FJP RU contest log. It is best if I can test against real log data rather than artificial data.
Please send it to me direct if you can. to VK3AMA.Ham.Apps [at] gmail.com

Regarding my question about JTAlert restarts, that would only have been an issue if the wrong log file was being referenced and the internal B4 status cache being cleared on restarts. You can ignore the question since you were getting logging confirmations indicating the correct log was set.

de Laurie VK3AMA


locked Re: accented international characters

Barry VA7GEM
 

On Fri, Jan 7, 2022 at 02:09 PM, HamApps Support (VK3AMA) wrote:
On 8/01/2022 6:18 am, Barry VA7GEM via groups.io wrote:
Mike from HRD picked this up and has a developer working on fixing it.

de Barry
Tnx for the update Barry.

de Laurie VK3AMA
For those following this threead.
Quote from Mike
"But I have this and we'll tackle it. (That said - 100% of the dev hours right now are going into the current feature release. We'll need to get that out first.)"
Will see how long this takes to fix.
cheers de Barry



locked Re: Add option to only Read HRD Database #HRD

Ferry PD9FER
 
Edited

Yes. The callsign lookup in HRD Logbook runs when the QSO goes into HRD Logbook using the UDP "QSO Forwarding" method.

The callsign lookup does not function with the "TCP logging" that was put in-place "long before the QSO Forwarding interface."

Because of this, HRD users who wish to use the data in their log to populate lookup information (previous Comments; more detailed location information that may be in their logs in previous QSOs with that station) are unable to do so using the "TCP logging" method "from long ago."

We realize that there's not much information on this TCP logging method. Now that most applications support the UDP (QSO Forwarding) method, it's likely that the TCP logging method will be depreciated in time.

We would like to prepare for this now by asking if there's a way that JTAlert can connect to the log to load the data necessary to build the B4 and "wanted" items... but use the UDP QSO Forwarding method for sending QSOs to the log.

As Mike (WA9PIE) tells me, "We fully embrace JTAlert. We don't want anything to break in JTAlert as we move HRD forward." With that in mind, is there a solution possible?

 

73,

Ferry PD9FER


locked Re: RTTY RU Worked Before Problem

Jeff Young
 

In previous email, contest logged should be contact logged. Darn auto correct.
Jeff

-------- Original message --------
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Date: 1/13/22 3:00 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem

On 13/01/2022 9:49 am, Jeff Young wrote:

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.


Was there a JTAlert restart between your initial 20m activity and when you went back to 20m after working other bands?

Did JTAlert confirm that the QSO was correctly logged? If you had confirmations turned off, it may be a case of JTAlert not reading the correct log file and you never seeing the warning.

What you describe suggests to me that you don't have the correct logfile selected in the manual configuration, A JTAlert logging confirmation success or failure popup will answer that question for me.

de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem

Jeff Young
 

Laurie,

Yes. I receive a confirmation from JTAert that the contest was logged and the logged QSO shows up immediately in the N3FJP log on my second screen. 

Also, there was no restart of JTAlert during the contest. What would happen if the software is restarted?

Thanks 
Jeff KB3HF 

-------- Original message --------
From: "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...>
Date: 1/13/22 3:00 PM (GMT-06:00)
To: Support@HamApps.groups.io
Subject: Re: [HamApps] RTTY RU Worked Before Problem

On 13/01/2022 9:49 am, Jeff Young wrote:

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.


Was there a JTAlert restart between your initial 20m activity and when you went back to 20m after working other bands?

Did JTAlert confirm that the QSO was correctly logged? If you had confirmations turned off, it may be a case of JTAlert not reading the correct log file and you never seeing the warning.

What you describe suggests to me that you don't have the correct logfile selected in the manual configuration, A JTAlert logging confirmation success or failure popup will answer that question for me.

de Laurie VK3AMA


locked Re: Add option to only Read HRD Database #HRD

JTAlert Support (VK3AMA)
 

On 13/01/2022 7:13 pm, Ferry PD9FER via groups.io wrote:
I want to use the callsign lookup logic in HRD.
The method that JTAlert uses bypasses it.
So I don't get the benefit of the additional sources available to me in HRD.

Are you saying that HRDLogbook behaves differently depending on which mechanism is used to log QSOs?

What is different about the QSO forwarding logging and the TCP logging, what is HRD Logbook doing or not doing depending on how the QSO entered the logbook? Please explain the difference. Perhaps there is a command available on the HRDLogbook TCP logging api that could bn set in JTAlert to allow for what you want to see happen, see my later comments about lack of api documentation

JTAlert uses the TCP logging interface for logging which was introduced by HRD V6.3 long before the QSO forwarding interface. There are users with older HRD V6 installations that cannot use the QSO forwarding method as it is not available in their version. I don't recall which version of HRD V6 introduced the QSO forwarding mechanism. I do know, the TCP interface that JTAlert uses still works so I will be keeping that option for HRD Logbook logging.

Note: JTAlert does not write direct to the HRD log file, all writing to the log file is done by HRDLogbook itself in response to the logging instruction sent to its TCP interface, except for version earlier than V 6.3 which had no interface at all. I don't know the exact version number when that was added as all past documentation on the logging API along with associated user messages
have been purged from the HRD forums. I no longer have access to any HRD documentation on its logging interface and its requirements so will likely not be changing the JTAlert -> HRD logging over TCPIP as it currently is working.


de Laurie VK3AMA


locked Re: RTTY RU Worked Before Problem

JTAlert Support (VK3AMA)
 

On 13/01/2022 9:49 am, Jeff Young wrote:

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.


Was there a JTAlert restart between your initial 20m activity and when you went back to 20m after working other bands?

Did JTAlert confirm that the QSO was correctly logged? If you had confirmations turned off, it may be a case of JTAlert not reading the correct log file and you never seeing the warning.

What you describe suggests to me that you don't have the correct logfile selected in the manual configuration, A JTAlert logging confirmation success or failure popup will answer that question for me.

de Laurie VK3AMA


locked Re: Add option to only Read HRD Database #HRD

Ferry PD9FER
 

Laurie,

I want to use the callsign lookup logic in HRD.
The method that JTAlert uses bypasses it.
So I don't get the benefit of the additional sources available to me in HRD.

 

 
 


locked Re: CQ Marathon Alert ignors station worked in past years. #FT8

Bill Ahillen
 

I have made the changes you suggested and resolved my problem. 

73
Bill W9JJB 


On Jan 12, 2022, at 11:50 AM, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 13/01/2022 3:26 am, Dennis wrote:
I asked because I know that DXKeeper, which I use, requires adjustments to some settings to recognize that we are now in a new year.  This is important because I believe JTAlert gets its information regarding what is needed from the logging program.  Perhaps HRD has some similar setting that needs adjustment?

Dennis, N1RDN

FYI, the DXKeeper Marathon settings you refer to are needed for the award tracking within the DXLab suite. JTAlert does not use those settings, it does its own alerting determination based on the current year and what entities are set in its internal alert database which typically gets updated whenever the Rebuild operation is performed.

de Laurie VK3AMA


locked RTTY RU Worked Before Problem

Jeff Young
 

I have a problem that occurred during the RTTY Roundup.

 

I was running N3FJP RTTY Contest Log ver. 3.9, WSJT-X ver. 2.3.1 and JTAlert Ver. 2.50.9 on a WIN10 Pro computer.

 

My problem was the Worked Before (B4) function did not find/show contacts worked before in the contest if I started on 20m for instance, then changed bands to 40m for a while and then later changed back to the 20m band. B4 worked on the initial start of the both 20m and 40m bands, but when I returned to 20m from 40m a later point, the B4 function did not find/show B4 decoded stations from the first session in the 20m band resulting in me working dupes.

 

The actual logging of a contact to the N3FJP software worked fine but for some reason, it appears that JTAlert was not reading the entire database log for same band in different sessions during the contest.

 

I have attached the settings pages below that I thought were need for this to work.



Thanks,
Jeff KB3HF


locked Re: address not logging

Jim Cooper
 

On 13 Jan 2022 at 8:50, HamApps Support (VK3AMA)
wrote:

One of the reasons I try to include
long descriptions on checkboxes is
that what the setting is for should
be evident.
Since verbose descriptions are not shunned,
may I suggest the following for that item?

* Include address returned from XML or previous QSO
lookup in QSO log.

Basically says the same thing, but starts out talking
about the subject (address) not the target (Log)...

w2jc


locked Re: address not logging

Michael Black
 

I've talked to a LOT of operators who are simply overwhelmed by all the computer stuff involved now.
Then there's the younger computer illiterate crowd who have a mental block when things don't work the first time.
Then there's the ones who start clicking/changing all sorts of stuff and get themselves wrapped around the proverbial axle.
Then there's the forgetful crowd which applies to many seniors losing some of their mental acuity.

So lots of people for whom all these options are not clear.  Don't know how we could make it any simpler really...this stuff just gets more and more complex/complicated.

Mike





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


On 13/01/2022 8:36 am, Michael Black via groups.io wrote:
This stuff is getting very complicated for many users.
So many options and so many programs running at once.

One of the reasons I try to include long descriptions on checkboxes is that what the setting is for should be evident.

That setting shown in your image requires no further explanation in my opinion. It is the setting the user claimed in the initial post was enabled which turned out wasn't.

I don't buy the "too complicated" argument so often touted.

de Laurie VK3AMA


locked Re: address not logging

JTAlert Support (VK3AMA)
 

On 13/01/2022 8:36 am, Michael Black via groups.io wrote:
This stuff is getting very complicated for many users.
So many options and so many programs running at once.

One of the reasons I try to include long descriptions on checkboxes is that what the setting is for should be evident.

That setting shown in your image requires no further explanation in my opinion. It is the setting the user claimed in the initial post was enabled which turned out wasn't.

I don't buy the "too complicated" argument so often touted.

de Laurie VK3AMA


locked Re: address not logging

Michael Black
 

This stuff is getting very complicated for many users.
So many options and so many programs running at once.

He had checked these
Inline image

But not
Inline image


Mike




On Wednesday, January 12, 2022, 12:51:39 PM CST, Laurie, VK3AMA <hamapps.support@...> wrote:




On 13/01/2022 5:38 am, Michael Black via groups.io wrote:
> Problem was he didn't have the Logging option checked for saving the
> Address in JTAlert.
>
> Mike W9MDB

Tnx Mike.

In the first post to this message thread it was stated that "I have
checked log full name and address" was that not the case?

de Laurie VK3AMA







locked Re: JTALERT - Dxcluster

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







locked Re: Add option to only Read HRD Database #HRD

JTAlert Support (VK3AMA)
 

On 11/01/2022 10:22 pm, Ferry PD9FER via groups.io wrote:

Would it be possible to add a checkbox with HRD Logging to disable Database writes?

This is useful when using the Last QSO option when forwarding to UDP 2333

When the above is checked it creates duplicate entries in HRD Logbook.
To prevent it, i can disable HRD Logging, but then I lose all Alert options.

73,

Ferry PD9FER
What are you trying to achieve by using this alternate logging path?

If you want to have HRD logging WSJTX QSOs direct without JTAlert doing the logging JTAlert will not be reading the HRD logbook so its alerting will very likely be inaccurate as it will not know what is in your HRD log.

de Laurie VK3AMA


locked Re: JTALERT - Dxcluster

JTAlert 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


locked Re: address not logging

Michael Black
 

Correct...that was not the case.

Mike W9MDB




On Wednesday, January 12, 2022, 12:51:39 PM CST, Laurie, VK3AMA <hamapps.support@...> wrote:




On 13/01/2022 5:38 am, Michael Black via groups.io wrote:
> Problem was he didn't have the Logging option checked for saving the
> Address in JTAlert.
>
> Mike W9MDB

Tnx Mike.

In the first post to this message thread it was stated that "I have
checked log full name and address" was that not the case?

de Laurie VK3AMA







locked Re: address not logging

Laurie, VK3AMA
 

On 13/01/2022 5:38 am, Michael Black via groups.io wrote:
Problem was he didn't have the Logging option checked for saving the Address in JTAlert.

Mike W9MDB
Tnx Mike.

In the first post to this message thread it was stated that "I have checked log full name and address" was that not the case?

de Laurie VK3AMA


locked Re: address not logging

Michael Black
 

Problem was he didn't have the Logging option checked for saving the Address in JTAlert.

Mike W9MDB




On Wednesday, January 12, 2022, 12:37:14 PM CST, AH0U <bruce@...> wrote:


Big thanks to Mike W9MDB who logged on to my system and fixed it!!!!!TNX Mike!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
73 de AH0U

2461 - 2480 of 40825