Date   

Re: HRD Duplicate log entries - Was #HamSpots

HamApps Support (VK3AMA)
 

Subject changed to reflect true nature of the message.

If you want to prevent duplicate log entries in HRD, the are a couple of places to check and turn off if enabled.
  1. WSJT-X Settings -> Reporting tab -> "Secondary UDP Server (depreciated)". Uncheck the "Enable logged contact ADIF broadcast" checkbox.

  2. JTAlert "Settings -> Manage Settings" menu -> Settings window -> "Applications -> WSJT-X/JTDX" section. Uncheck the "Resend WSJT-X UDP packets (received only)" checkbox.

de Laurie VK3AMA


Re: Not ignoring /MM stations - ISSUE Found, ACLog Defect

HamApps Support (VK3AMA)
 

Pat,

Thanks for your ACLog file. I provided me with the clue as to what was happening.

JTAlert when it performs the rebuild operation pre-loads the log into a fast memory-based database. This applies to all the supported log types, not just ACLog. This allows for a standard set of routines to be run against a very fast lookup database that is independent of the differences in the different logs (lack of indexes, inconsistent data recording, missing data, bad qsos, etc). This operation does not consider callsigns, just the raw data recorded for each QSO in the log. It ignores Country names, which can be spelt differently on different systems and relies on the unique dxcc number recorded in the QSO to determine dxcc needs. That was the problem.

ACLog, while it correctly had no Country name recorded in the log for /MM stations, it incorrectly recorded dxcc numbers for /MM stations. That is a defect in ACLog IMO. /MM QSOs should have no dxcc number recorded. JTAlert was seeing the dxcc number and the confirmations set for the /MM QSOs and applying credit during the rebuild.

   

Check you email, I have sent you a new JTAlert build to test. Let me know if this works for you.

Note: During this testing, there were some additional /MM callsigns in your log that were given incorrect credit. I note that on 17m you had credit for Ukraine due to the UW5EJX/MM QSO. Once I coded the ACLog /MM patch into JTAlert, your 17m credit count was reduced by 2 rather than the expected one for the RA0LQ/MM qso only.

de Laurie VK3AMA


Re: Not ignoring /MM stations

Joe Subich, W4TV
 

Check your confirmation on LotW *carefully*. It probably *DOES NOT*
specify "Asiatic Russia" but only confirms the grid. It is possible
for /MM stations to get certificates that specify no country in order
to provide grid confirmations.

If that's the case, your logging program has a significant bug!

73,

... Joe, W4TV

On 2021-10-18 10:27 PM, Patrick St. Jean wrote:
Unfortunately, that wasn’t the case this time. I’ve got a confirmed grid square in the middle of the Pacific Ocean. :)
Pat

On Oct 18, 2021, at 21:12, Dave Garber <ve3wej@gmail.com> wrote:


maybe the ra0lq/mm was docked on land at the time, so it was accepted..  check his grid, and maybe email him to confirm

Dave Garber
VE3WEJ / VE3IE


On Mon, Oct 18, 2021 at 9:26 PM Patrick St. Jean <stjeanp@pat-st-jean.com <mailto:stjeanp@pat-st-jean.com>> wrote:

Thanks,

Unfortunately I can reproduce this. While it shouldn’t count, it
does. I only have one Asiatic Russia confirmed, that being on 20m
FT8. The /MM on 17m FT8 is giving me credit for Asiatic Russia. I
was manually removing it to confirm that JTAlert is incorrectly
giving me credit for a /MM confirmation.

Steps to reproduce:

1. Have a 17m FT8 confirmed contact with RA0LQ/MM in ACLog. That
being the only confirmed contact with Asiatic Russia on that band,
regardless of mode.

2. Rebuild alert database. You will get credit for it.

I'm attaching screenshots showing the following:

1. I do not have any contacts with Asiatic Russia on 17m in my log.

2. The contact with RA0LQ/MM, showing that it is confirmed, and
that the country field is blank.

3. The rebuilt alert database showing credit for Asiatic Russia on
17m FT8.

Please let me know if I'm doing something wrong or if you would
like more data.

Pat


On Oct 18, 2021, at 19:39, HamApps Support (VK3AMA)
<vk3ama.ham.apps@gmail.com> <mailto:vk3ama.ham.apps@gmail.com> wrote:


On 19/10/2021 12:34 am, Patrick St. Jean wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As
part of my normal routine, I rebuilt my alert databases. It
credited me with Asiatic Russia on 17m thanks to that one. I
went in and manually removed the country from the have list for
17m/FT8 and then rebuilt again. It got added back. This is my
only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this
doesn't keep happening, and so that I don't have to go in and
remove that DXCC entity every time I rebuild the alerts?
Firstly do not perform both manual updating of your wanted dxccs
and running the rebuild operation. The rebuild, which uses the
content of your log, ignores any manual changes you have applied.
Your log should be used to determine what is needed and not needed.

As for RA0LQ/MM, that is not valid for dxcc purposes. The
confirmation you received from Lotw would not (or should not)
have confirmed Asiatic Russia. All /MM callsigns are not valid
for dxcc.

de Laurie VK3AMA


Re: Not ignoring /MM stations

HamApps Support (VK3AMA)
 

On 19/10/2021 12:26 pm, Patrick St. Jean wrote:

Unfortunately I can reproduce this. While it shouldn’t count, it does. I only have one Asiatic Russia confirmed, that being on 20m FT8. The /MM on 17m FT8 is giving me credit for Asiatic Russia. I was manually removing it to confirm that JTAlert is incorrectly giving me credit for a /MM confirmation.

Steps to reproduce:

1. Have a 17m FT8 confirmed contact with RA0LQ/MM in ACLog. That being the only confirmed contact with Asiatic Russia on that band, regardless of mode.

2. Rebuild alert database. You will get credit for it.

I'm attaching screenshots showing the following:

1. I do not have any contacts with Asiatic Russia on 17m in my log.

2. The contact with RA0LQ/MM, showing that it is confirmed, and that the country field is blank.

3. The rebuilt alert database showing credit for Asiatic Russia on 17m FT8.

Please let me know if I'm doing something wrong or if you would like more data.

Pat
Pat,

If ACLog is not showing a country in its log for RA0LQ/MM, than the JTAlert rebuild should not be crediting you with AS Russia for that callsign. Something is not right. I will need to check the JTAlert code and see if I can reproduce the problem.

Please send me via direct email (vk3ama.ham.apps [at] gmail.com) a zipped copy of your ACLog log file so I can examine it for potential clues as to the cause.

de Laurie VK3AMA


Re: Not ignoring /MM stations

Patrick St. Jean
 

Unfortunately, that wasn’t the case this time. I’ve got a confirmed grid square in the middle of the Pacific Ocean. :)

Pat


On Oct 18, 2021, at 21:12, Dave Garber <ve3wej@...> wrote:


maybe the ra0lq/mm was docked on land at the time, so it was accepted..  check his grid, and maybe email him to confirm

Dave Garber
VE3WEJ / VE3IE


On Mon, Oct 18, 2021 at 9:26 PM Patrick St. Jean <stjeanp@...> wrote:
Thanks,

Unfortunately I can reproduce this. While it shouldn’t count, it does. I only have one Asiatic Russia confirmed, that being on 20m FT8. The /MM on 17m FT8 is giving me credit for Asiatic Russia. I was manually removing it to confirm that JTAlert is incorrectly giving me credit for a /MM confirmation. 

Steps to reproduce:

1. Have a 17m FT8 confirmed contact with RA0LQ/MM in ACLog. That being the only confirmed contact with Asiatic Russia on that band, regardless of mode.

2. Rebuild alert database. You will get credit for it. 

I'm attaching screenshots showing the following:

1. I do not have any contacts with Asiatic Russia on 17m in my log.

2. The contact with RA0LQ/MM, showing that it is confirmed, and that the country field is blank.

3. The rebuilt alert database showing credit for Asiatic Russia on 17m FT8.

Please let me know if I'm doing something wrong or if you would like more data.

Pat


On Oct 18, 2021, at 19:39, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 19/10/2021 12:34 am, Patrick St. Jean wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?

Firstly do not perform both manual updating of your wanted dxccs and running the rebuild operation. The rebuild, which uses the content of your log, ignores any manual changes you have applied. Your log should be used to determine what is needed and not needed.

As for RA0LQ/MM, that is not valid for dxcc purposes. The confirmation you received from Lotw would not (or should not) have confirmed Asiatic Russia. All /MM callsigns are not valid for dxcc.

de Laurie VK3AMA


Re: Not ignoring /MM stations

Dave Garber
 

maybe the ra0lq/mm was docked on land at the time, so it was accepted..  check his grid, and maybe email him to confirm

Dave Garber
VE3WEJ / VE3IE


On Mon, Oct 18, 2021 at 9:26 PM Patrick St. Jean <stjeanp@...> wrote:
Thanks,

Unfortunately I can reproduce this. While it shouldn’t count, it does. I only have one Asiatic Russia confirmed, that being on 20m FT8. The /MM on 17m FT8 is giving me credit for Asiatic Russia. I was manually removing it to confirm that JTAlert is incorrectly giving me credit for a /MM confirmation. 

Steps to reproduce:

1. Have a 17m FT8 confirmed contact with RA0LQ/MM in ACLog. That being the only confirmed contact with Asiatic Russia on that band, regardless of mode.

2. Rebuild alert database. You will get credit for it. 

I'm attaching screenshots showing the following:

1. I do not have any contacts with Asiatic Russia on 17m in my log.

2. The contact with RA0LQ/MM, showing that it is confirmed, and that the country field is blank.

3. The rebuilt alert database showing credit for Asiatic Russia on 17m FT8.

Please let me know if I'm doing something wrong or if you would like more data.

Pat


On Oct 18, 2021, at 19:39, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 19/10/2021 12:34 am, Patrick St. Jean wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?

Firstly do not perform both manual updating of your wanted dxccs and running the rebuild operation. The rebuild, which uses the content of your log, ignores any manual changes you have applied. Your log should be used to determine what is needed and not needed.

As for RA0LQ/MM, that is not valid for dxcc purposes. The confirmation you received from Lotw would not (or should not) have confirmed Asiatic Russia. All /MM callsigns are not valid for dxcc.

de Laurie VK3AMA


Re: Not ignoring /MM stations

Jim Reisert AD1C
 

/MM grids can and do count for the CQ DX Field Award:

https://cq-amateur-radio.com/cq_awards/cq_dx_awards/cq_dx_field_award/cq_dx_field_award.html

Working /MM stations is the *only* way to get some of the fields that
are water-only.

F5MYK/MM does accept Club Log OQRS requests and I received some
confirmations from him recently.

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, https://www.ad1c.us


Re: Not ignoring /MM stations

Patrick St. Jean
 

Thanks,

Unfortunately I can reproduce this. While it shouldn’t count, it does. I only have one Asiatic Russia confirmed, that being on 20m FT8. The /MM on 17m FT8 is giving me credit for Asiatic Russia. I was manually removing it to confirm that JTAlert is incorrectly giving me credit for a /MM confirmation. 

Steps to reproduce:

1. Have a 17m FT8 confirmed contact with RA0LQ/MM in ACLog. That being the only confirmed contact with Asiatic Russia on that band, regardless of mode.

2. Rebuild alert database. You will get credit for it. 

I'm attaching screenshots showing the following:

1. I do not have any contacts with Asiatic Russia on 17m in my log.

2. The contact with RA0LQ/MM, showing that it is confirmed, and that the country field is blank.

3. The rebuilt alert database showing credit for Asiatic Russia on 17m FT8.

Please let me know if I'm doing something wrong or if you would like more data.

Pat


On Oct 18, 2021, at 19:39, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 19/10/2021 12:34 am, Patrick St. Jean wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?

Firstly do not perform both manual updating of your wanted dxccs and running the rebuild operation. The rebuild, which uses the content of your log, ignores any manual changes you have applied. Your log should be used to determine what is needed and not needed.

As for RA0LQ/MM, that is not valid for dxcc purposes. The confirmation you received from Lotw would not (or should not) have confirmed Asiatic Russia. All /MM callsigns are not valid for dxcc.

de Laurie VK3AMA


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

conradtrautmann@...
 

Thanks for clarifying desktop vs console. I did follow the links in the program to the .net site and downloaded what I thought was right for my computer. I also read the setup instructions but must have missed this. 

I’ll give desktop a try. 


Re: Not ignoring /MM stations

HamApps Support (VK3AMA)
 

On 19/10/2021 12:34 am, Patrick St. Jean wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?

Firstly do not perform both manual updating of your wanted dxccs and running the rebuild operation. The rebuild, which uses the content of your log, ignores any manual changes you have applied. Your log should be used to determine what is needed and not needed.

As for RA0LQ/MM, that is not valid for dxcc purposes. The confirmation you received from Lotw would not (or should not) have confirmed Asiatic Russia. All /MM callsigns are not valid for dxcc.

de Laurie VK3AMA


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

HamApps Support (VK3AMA)
 

On 18/10/2021 12:00 pm, Dave Garber wrote:
I've tried to set everything the same..no joy..
maybe it is just port settings or something like that?

At least the old version of JTA 2.16.3 still is logging to HRD.

Install the correct .NET Desktop Runtime. If you cant or wont, than your only option it to stay with the old JTAlert 2.16.x releases.

All current 2.50.x releases AND ALL future releases require the .NET Desktop Runtime! It is not optional, it cannot be substituted with the non-desktop runtime. Without the Desktop Runtime, JTAlert 2.50.x will not function correctly with many parts of it not working.

de Laurie VK3AMA


Re: #HamSpots #HamSpots

Ernest L. Kapphahn
 

It doesn't count for a country but it does for a grid square if you collect those.  RA0LQ/MM logs his grid square at https://t.me/RA0LQ_mm

You receive all messages sent to this group.


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

HamApps Support (VK3AMA)
 

On 19/10/2021 11:07 am, Joe Subich, W4TV wrote:

dot NET 5.0.11 *DESKTOP* works just fine with the most recent version
of Windows 10.  If "rolling back" to 5.0.5 made a difference, you
probably have the console version of 5.0.11 (wrong product).

73,

   ... Joe, W4TV

Exactly! You beat me to it Joe.

If rolling back the .NET version corrects the JTAlert operation it is because the original version was the non-desktop version and the rolled-back version was the "Desktop Runtime" as is required by JTAlert, which is a Desktop application.

In ALL cases I have seen where people have a broken JTAlert install related to the .NET install, it has been due to the non-desktop runtime being installed, despite the many posts about this, the online documentation with direct links to the correct runtimes and the JTAlert help file instructions. Once the affected users took the time to read the instructions or follow the posted instructions and installed the "Desktop Runtime" JTAlert starts operating as designed.

de Laurie VK3AMA


Re: #HamSpots #HamSpots

Dave Garber
 

get into the settings on jtalert and remove the logging settings you have  
Dave Garber
VE3WEJ / VE3IE


On Mon, Oct 18, 2021 at 9:47 AM Neil Foster <archernf@...> wrote:
I should have added that I use Ham Radio Deluxe and have WSJT to do the logging. Now I get a proper log entry into HRD from WSJT and a partial log entry from JT Alert. I do not want a double entry. So how can I sttop JT Alert from logbook entry. I do not always have JT Alert running 
Thahanks all and stay well   Neil   N4FN


Re: Not ignoring /MM stations

Dave Garber
 

probably not the correct answer, but I stopped working them...  My first /mm was thrilling, until I never got a card, and then was told /MM have no dxcc value, unless they are docked.  is this case they are no longer /mm.   I found no solution, except to remove the country, and if you can, leave it blank, it should not be counted by jtalert, then   I think

Dave Garber
VE3WEJ / VE3IE


On Mon, Oct 18, 2021 at 2:24 PM Patrick St. Jean <stjeanp@...> wrote:
I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

Joe Subich, W4TV
 

dot NET 5.0.11 *DESKTOP* works just fine with the most recent version
of Windows 10. If "rolling back" to 5.0.5 made a difference, you
probably have the console version of 5.0.11 (wrong product).

73,

... Joe, W4TV

On 2021-10-18 7:34 PM, conradtrautmann via groups.io wrote:
Vince, I think you may be on to something. I got a new computer, did fresh installs of Win 10 and WSJT-X and JTAlert and could not get it to work. I rolled back .net just like you did by uninstalling and loading 5.0.0 and boom, everything was happy. It would not work with 5.0.11 at all. I was going to report it as a fresh discovery but saw you had the same issue. Apparently .11 was released recently so maybe something in that recent release changed.


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

conradtrautmann@...
 

Vince, I think you may be on to something. I got a new computer, did fresh installs of Win 10 and WSJT-X and JTAlert and could not get it to work. I rolled back .net just like you did by uninstalling and loading 5.0.0 and boom, everything was happy. It would not work with 5.0.11 at all. I was going to report it as a fresh discovery but saw you had the same issue. Apparently .11 was released recently so maybe something in that recent release changed. 


Re: Which version of JT Alert works now with my HRD v6.7.0.391 Release

Vince Loschiavo
 

Ok...I'm almost back to normal..
Im guessing that WSJT-x reports to HRD Log..
or I managed to screw it up so that I'm logging contacts again...so I'll assume that is fixed.
My concern is:
I've deprecated the .NET from 5.0.11 back to 5.0.0
I keep running your app to see if it is installed (and I can see that it is installed) and I still get the nag to download it cause it isn't..
ugg..
also
nothing is populated on JTAlert with any of the decodes..
and I see ???m up on the top row.
Vince
N2AIE..
UGG


Re: JT Alert quit working after Windows 10 Update

Tommy Evans
 

Just running WSJTX and JTAlert only still no decode.  This problem started after a Windows 10 update.  I currently have version 20H2.  Not sure what the update did but I think something changed that is causing the issue.  Let me know of any other things I need to check.

Thanks.

Tommy NE4J


Not ignoring /MM stations

Patrick St. Jean
 

I just worked RA0LQ/MM and got a LOTW confirmation overnight. As part of my normal routine, I rebuilt my alert databases. It credited me with Asiatic Russia on 17m thanks to that one. I went in and manually removed the country from the have list for 17m/FT8 and then rebuilt again. It got added back. This is my only 17m contact with an Asiatic Russia prefix, regardless of mode.

I'm running JTAlert 2.50.6 and ACLog 7.0.2.

Are there any further steps I can take to ensure that this doesn't keep happening, and so that I don't have to go in and remove that DXCC entity every time I rebuild the alerts?

1 - 20 of 37213