Date   

locked Re: All Working

JTAlert Support (VK3AMA)
 

On 20/10/2021 12:37 pm, Vince Loschiavo wrote:
Thanks all for all the suggestions.
I've got all working smoothly now...(did have double logging so disabled WSJT-x push)
Love all the new bells and whistles.
Vince
n2aie

Good to hear! Thanks for updating us.

Now that you have the correct runtime installed, you no longer have to worry about it with future JTAlert updates. It's a one time requirement to get it installed. Windows as part of its normal updating procedure will keep it up-to-date. All recent updates to the runtime have been security updates applied automatically by Windows.

de Laurie VK3AMA


locked VE Provinces wanted not updating with rebuild

Stephen Hughey
 

I know I have seen this mentioned before.  I have latest JTAlert as of today, N3FJP log (AC Log).  Seems to work fine with DXCC, WAS…

Any ideas?


locked Re: .net 5.0.11 already installed and JTA not happy

RIchard Thorne
 

Be sure you didn't install the console. The download page is a bit deceiving.

You need to install the x64 or x32 in the middle of the page which seems to be under linux, but it's the windows version

That's what I did until I looked a little closer.

Rich - N5ZC

On 10/19/2021 8:00 PM, Vince Loschiavo wrote:
Ok,
So i've installed this and the checker for .net still says it isn't installed..
so
suggestions?
Vince
n2aie


locked Re: .net 5.0.11 already installed and JTA not happy

Joe Subich, W4TV
 

Have you installed the console version instead of the desktop version
of dotNET? JTAlert requires the DESKTOP version and will fail if the
console version (only) is installed.

73,

... Joe, W4TV

On 2021-10-19 9:00 PM, Vince Loschiavo wrote:
Ok,
So i've installed this and the checker for .net still says it isn't installed..
so
suggestions?
Vince
n2aie


locked All Working

Vince Loschiavo
 

Thanks all for all the suggestions.
I've got all working smoothly now...(did have double logging so disabled WSJT-x push)
Love all the new bells and whistles.
Vince
n2aie


locked Re: JTAlert not communicating with WSJT-X

Tommy Evans
 

I can not get JTAlert and N1MM working at the same time.  Apparently N1MM does not support multicast UDP.   I have tried the JTAlert rebroadcast and N1MM rebroadcast and can not get either to work..  An other ideas or input ?  Thanks.

Tommy NE4J


locked .net 5.0.11 already installed and JTA not happy

Vince Loschiavo
 

Ok,
So i've installed this and the checker for .net still says it isn't installed..
so 
suggestions?

Vince
n2aie


locked Re: JTAlert/WSJT-X Issues with AK and HI, plus B4 problem

Ronald Clanton
 

Okay... I finally got home and was able to do more testing.  The alert is for wanted "state".  I looked at the wanted state tab and it shows it as needed. So... the JTAlert application is working correctly, but it looks like I have a problem with the QRZ export or the JTAlert import.  Now that I know this, I can simply manually uncheck AK/HI in the wanted states tab.

I have JTAlert setup to track wanted states by band for any mode.  I don't track grids.  I also have it setup to require LOTW confirmation to consider it "confirmed" and I've verified that I have multiple LOTW confirmed contacts for that state in that band.

How do I test whether the QRZ export or the JTAlert import is the problem?

Thanks,

Ron
KE7NJ


locked Re: HRD Duplicate log entries - Was #HamSpots

JTAlert 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


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

JTAlert 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


locked 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


locked Re: Not ignoring /MM stations

JTAlert 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


locked 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


locked 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


locked 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


locked 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


locked 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. 


locked Re: Not ignoring /MM stations

JTAlert 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


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

JTAlert 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


locked 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.

2601 - 2620 of 39821