Date   

locked Re: Feature Suggestion Allow specifying eQSL AG activity date#FT8

Pat N6PAT
 

Laurie,

The file I'm using was included in a ham call lookup app. It appears to be a very clean derivative of the FCC file and very consistent with eQSL. I just recently started concentrating on counties and have 1,020 confirmed in eQSL ,thanks in large part to JTAlert, with every QSO county agreeing with the county in the call master file.

In terms of impacting JTAlert, I imported the call file (CSV format) into Access and queries against it take about 1 second to complete so I don't think the overhead would be noticeable.

Reviewing the eQSL activity (or lack thereof) for US hams has been interesting. Using 1/1/21 as a starting point there are only about 1,600 counties listed with any activity from US hams in eQSL. This means that you must resort to paper QSL's to get beyond the 1,500 endorsement level. Given that there are over 3,000 US counties that could be an expensive and time consuming effort to get them all. The best solution would be for ARRL to implement a county function in LOTW similar to what is provided for  CQ WAZ and WPX.

I always thought there were many more US hams currently using eQSL but that appears to not be the case. I don't consider a member who hasn't uploaded a log in the past 6 months an active user.

Looking forward to the next release.

73 Pat N6PAT


locked Re: UDP port error

CLOVIS VONGHON
 
Edited

I understood Laurie. Fortunately, I'm not using multicast.
Thanks once more for your help.
Congratulations for the fantastic JTAlert!

73 de Clovis, PY3OG


locked Re: Feature Suggestion Allow specifying eQSL AG activity date#FT8

Jim N6VH
 


On 5/7/2021 1:21 PM, HamApps Support (VK3AMA) wrote:


Regarding the 777,000 master file, I assume you're referring to the official FCC database. Is that the case? My experience with that database is that County names recorded is not entirely accurate. During my County Alert implementation testing I discovered many FCC listed County names that don't exist with the official USA-CA list. What has been you're experience?

de Laurie VK3AMA

_._,_._,_

Laurie,

Thought I would add my two cents worth. There are definitely some differences between the FCC list and the USA-CA list. A very good example is Alaska. The FCC list uses the county name (actually 22 boroughs in Alaska), while USA-CA only uses the four Judicial Districts.  Another problem is spelling. The FCC list might have one spelling for a county, while the USA-CA list might have a slightly different spelling - Saint Tammany in the FCC list, St. Tammany in the USA-CA list, for example. None of these problems are insurmountable, but I wonder if the processing would have an impact on the speed of JTAlert.

Another related issue is that various loggers don't necessarily have the same listing for the counties.

73,

Jim N6VH

USA-CA 429



locked Re: JT Alert - Worked B4

Bob Frostholm
 

Yes, sort of....

but I'm only interested in contacting a worked B4 on a different band is it is a Japan station...That's the objective of their award

Here's an example... I have set Ignore Band...

I have worked JA0QVJ on 17m previously, so I don't want to call him... It also tells me I have not worked JI3VUB or JI1LET on 17m...since JI1LET just signed 73, I would call him... because he could help advance me toward the award I reference earlier. Or I might try to call JI3VUB.

I'm not interested in filling my log by working every station on every band except for Japan.

So if there were no Japan stations on the air, I might want to try to contact KL7GY...but I'm not interested to make another contact with him if I've worked him B4 on another band. I can not tell if I already have KL7GY in my log. Yes, I know I can right click and left click the JT Alert box to find out but that's cumbersome and time consuming.


73

Bob

Ko6Lu
On 5/7/2021 2:42 PM, HamApps Support (VK3AMA) via groups.io wrote:

On 8/05/2021 7:24 am, Bob Frostholm wrote:
when I see a Japan station I have worked B4 and I know I've not worked him on this band, I'll contact him

That's what the "Ignore Band" setting works. With it unchecked, A previously worked station on a different band will not show as a B4 on an un-worked Band. That's how I understand what you want from your above statement.

de Laurie VK3AMA


--
Bob
KO6LU


locked Re: JT Alert - Worked B4

HamApps Support (VK3AMA)
 

On 8/05/2021 7:24 am, Bob Frostholm wrote:
when I see a Japan station I have worked B4 and I know I've not worked him on this band, I'll contact him

That's what the "Ignore Band" setting works. With it unchecked, A previously worked station on a different band will not show as a B4 on an un-worked Band. That's how I understand what you want from your above statement.

de Laurie VK3AMA


locked Re: JT Alert - Worked B4

Bob Frostholm
 

Hi Laurie and Mike,

I am aware of "Ignore Band"... but that doesn't fit my need. Here's the situation... JARL offers an award for contacting as many cities as possible on as many bands as possible ( https://www.jarl.org/English/4_Library/A-4-2_Awards/Award_Main.htm )

So, when I see a Japan station I have worked B4 and I know I've not worked him on this band, I'll contact him. At the same time, if I see a station from, say, Australia that I've worked B4, I don't want to duplicate and call him again on this band. So I'm seeking a way to distinguish  if the worked B4 was this band I'm on now or a different band.

I'm guessing the answer is no....but wanted to ask.

73

Bob

Ko6Lu
On 5/7/2021 2:06 PM, HamApps Support (VK3AMA) via groups.io wrote:

On 8/05/2021 6:51 am, Bob Frostholm wrote:
Is there a way to set the field color and / or border color for worked B4 to distinguish if a prior contact (workedB4) was on the current band or  a different band? I know I can right click and go the qso history but I'm interested to see at a glance.

-- 
73

Bob

Ko6Lu

Untick the "Ignore Band ..." setting for the "Worked B4" Alert

   

de Laurie VK3AMA


--
Bob
KO6LU


locked Re: v2.50.1 Second or third FT8 contact logged as FT8 with FT4 sub-mode. - DEFECT Confirmed

HamApps Support (VK3AMA)
 

On 7/05/2021 11:33 pm, Michael Black via groups.io wrote:
I assume the circled item should be "Remove from Wanted list" ?

Mike W9MDB

Tnx. Previously reported by Jim ADIC https://hamapps.groups.io/g/Support/message/34770

It's a cosmetic only issue, the backing property is correct.

de Laurie VK3AMA


locked Re: JT Alert - Worked B4

HamApps Support (VK3AMA)
 

On 8/05/2021 6:51 am, Bob Frostholm wrote:
Is there a way to set the field color and / or border color for worked B4 to distinguish if a prior contact (workedB4) was on the current band or  a different band? I know I can right click and go the qso history but I'm interested to see at a glance.

-- 
73

Bob

Ko6Lu

Untick the "Ignore Band ..." setting for the "Worked B4" Alert

   

de Laurie VK3AMA


locked Re: JT Alert - Worked B4

Michael Black
 

If you set your filter "by band" you won't see "B4" on a different band.

Mike W9MDB




On Friday, May 7, 2021, 03:51:30 PM CDT, Bob Frostholm <bob@...> wrote:


Is there a way to set the field color and / or border color for worked
B4 to distinguish if a prior contact (workedB4) was on the current band
or  a different band? I know I can right click and go the qso history
but I'm interested to see at a glance.

--
73

Bob

Ko6Lu



--
Bob
KO6LU






locked JT Alert - Worked B4

Bob Frostholm
 

Is there a way to set the field color and / or border color for worked B4 to distinguish if a prior contact (workedB4) was on the current band or  a different band? I know I can right click and go the qso history but I'm interested to see at a glance.

--
73

Bob

Ko6Lu



--
Bob
KO6LU


locked Re: Feature Suggestion Allow specifying eQSL AG activity date#FT8

HamApps Support (VK3AMA)
 

On 7/05/2021 4:30 pm, Pat N6PAT via groups.io wrote:
I downloaded the eQSL AG Member List Dated file containing the date of the last upload/import for each member. The raw file had 141,441 records. After filtering for US call signs the number was down to a little over 32,000 including almost 15,000 that had no activity in at least 10 years. Of the total calls only about 12,000 had uploaded or imported QSO's into eQSL since 1/1/2020 and only about 8,000 had uploaded or imported QSO's into eQSL since the beginning of 2021.

I suggest using the eQSL dated member file and adding an option to allow specifying a Last Activity Date threshold (i.e. filter for eQSL AG who had activity within the current year or last 6 months or since a specific date). There's no point in filtering for eQSL AG ops if the majority of them haven't been active in eQSL in many years and you cannot weed out the inactive members. .

It was discussed about the possibility of adding a Wanted County feature to aid in county hunting. That would only be valuable if the suggested Last Activity Date function was included as CQ currently only accepts QSO confirmations for the County award via eQSL AG and cards. Chasing down an AG op with a QTH in a wanted county who hasn't uploaded in a decade is a waste of time .

To handle this for right now I've created a database of all AG members with activity since 1/1/2021, retrieved their county from a master file of 770,000 US ham calls and compared the result to a list of the counties I still need. I then import the results in a comma delimited text file into the Wanted Call signs function. Seems to work well.

73 Pat N6PAT

Pat thanks for putting some thought and effort into documenting your request.

I am already capturing the new Eqsl AG members file ready for inclusion into the Callsigns database. It has not yet been enabled as the changed database schema will break old versions of JTAlert. I will be creating a new database distribution for future JTAlert versions. That will take a while as utilizing the Eqsl last upload date for alerting and flagging, similar to that for LoTW, will require some significant code changes.

Be assured that Eqsl by Date flagging and alerting will be implemented, but there will likely be a number of JTAlert releases before that happens.

Regarding the 777,000 master file, I assume you're referring to the official FCC database. Is that the case? My experience with that database is that County names recorded is not entirely accurate. During my County Alert implementation testing I discovered many FCC listed County names that don't exist with the official USA-CA list. What has been you're experience?

de Laurie VK3AMA


locked Re: UDP port error

HamApps Support (VK3AMA)
 

On 8/05/2021 12:36 am, CLOVIS VONGHON via groups.io wrote:
Solved!

Primary mistake on my part. I downloaded the 32-bit 2.50.1 version. That happens to old men. Now, with the 64-bit version, everything's ok. A thousand apologies to all of you.

73, Clovis- PY3OG

Good to hear.

I do note from one of your previous messages when you changed to using Multicast, you changed the IP address fro HRD as well, That is wrong, it needs to stay at either 127.0.0.1 or the IP address of your PC network card. HRD logging will not work with a multicast address.

   

de Laurie VK3AMA


locked Re: Single/double click within callsigns window not working

HamApps Support (VK3AMA)
 

On 7/05/2021 8:40 pm, BOB K5HX via groups.io wrote:
I am currently running JT-Alert, version 2.50.1 and WSJT-X version 2.3.1.

For some reason,  the clicking of callsigns within the Callsigns window stopped working.   Additionally,  right clicking within the callisigns window on any callsign and choosing any of the options does nothing.

My WSJT-x settings are shown below:



Any ideas would be appreciated.

Bob
K5HX

Is JTAlert following Band and Mode changes in WSJT-X? That is, does the main JTAlert titlebar and the Callsigns window status correctly report any Band/Mode changes in WSJT-X?

UDP Port 2334 is an unusual choice, the default is 2237. This suggests to me that you have altered it to accommodate some other application working directly with WSJT-X. What other WSJT-X inter-operating applications are you running? Are they correctly setup to use Multicast?

I suggest changing the port back to 2237 then restart both WSJT-X and JTAlert. Does JTAlert correctly report the Band and Mode?

If you still have no joy, open the JTAlert Help -> About window (from the main JTAlert window) and copy the "Current operating state" section, copy the content to the clipboard and paste it into a message to this group so I can have a look.

de Laurie VK3AMA


de Laurie VK3AMA


locked Re: Resend - All Worked B4 call sign displays are Displaying Needed, but Have Been Worked. #FT8

HamApps Support (VK3AMA)
 

On 8/05/2021 12:48 am, Brian Kassel K7RE wrote:
The call sign "worked B4" works as it should,
But no matter what I have tried, the States, VE and DXCC stations are always in Yellow
in both the calls in the Band Activity Window and the other window that displays calls and info.

(Yellow is the default color for NOT worked B4, and also my choice)

I tried the "Rebuild Database" many times.
Scrolling up on the list after the scan does show the correct totals os stations that have been worked on each band.




I am using the Standard ADIF File and JTAlert 2.50.1, with WSJTX 2.3.1.

JTAlert
    Settings
        Manage Settings
                Alerts
                    Wanted US State
                        Enable Wanted US State Alert (Checked)
                        Default Wave File Path
                        Sample Set to Yellow
                Logging
                    Standard ADIF File
                        Enable Standard ADIF File Logging (Checked)
                        C:\Users\Brian\AppData\Local\WSJT-X\wsjtx_log.adi (In red, uneditable)
                        Log File
                        C;\Users\Brian\Desktop\FT8 Log Spearfish.adi
                Log B4 Database File
                C:\Users\Brian\AppData\Local\HamApps\K7RE\logs\JTAlertX\B4logV2.MDB (Greyed, uneditable)

Could it be that the MDB database is corrupted?
If so, how do I fix that issue.

Thanks for reading this, and thanks for the wonderful program.

_

A couple of points, Rebuilding the Alert database will not influence the B4 reporting, it is used for Alerting only.
The greyed editable B4 Database entry is correct. It is not used by JTAlert if you have a logger enabled. A message to the effect is shown just above he B4 database path.

How do you know that the Yellowed callsigns is indicating worked B4? Your settings show the USState Alert set to use Yellow (the default). The default coloring for DXCCs is also Yellow. I suggest as a diagnostic step, change the B4 coloring to something unique, hot pink perhaps, so it stands out. Does the Callsign coloring change to that unique color, indicating worked B4, or do you still get Yellow, which indicates a State or DXCC alert?

My guess is that your getting USState Alerts for all the US decodes because the States are still set as needed. This would likely be due to having the US State Rebuild set to consider say Lotw confirmed status, while your ADIF log file does not contain entries with the LoTW receipt set. WHat is the source of your ADIF file/

de Laurie VK3AMA


locked Resend - All Worked B4 call sign displays are Displaying Needed, but Have Been Worked. #FT8

Brian Kassel K7RE
 

The call sign "worked B4" works as it should,
But no matter what I have tried, the States, VE and DXCC stations are always in Yellow
in both the calls in the Band Activity Window and the other window that displays calls and info.

(Yellow is the default color for NOT worked B4, and also my choice)

I tried the "Rebuild Database" many times.
Scrolling up on the list after the scan does show the correct totals os stations that have been worked on each band.




I am using the Standard ADIF File and JTAlert 2.50.1, with WSJTX 2.3.1.

JTAlert
    Settings
        Manage Settings
                Alerts
                    Wanted US State
                        Enable Wanted US State Alert (Checked)
                        Default Wave File Path
                        Sample Set to Yellow
                Logging
                    Standard ADIF File
                        Enable Standard ADIF File Logging (Checked)
                        C:\Users\Brian\AppData\Local\WSJT-X\wsjtx_log.adi (In red, uneditable)
                        Log File
                        C;\Users\Brian\Desktop\FT8 Log Spearfish.adi
                Log B4 Database File
                C:\Users\Brian\AppData\Local\HamApps\K7RE\logs\JTAlertX\B4logV2.MDB (Greyed, uneditable)

Could it be that the MDB database is corrupted?
If so, how do I fix that issue.

Thanks for reading this, and thanks for the wonderful program.


locked Re: UDP port error

CLOVIS VONGHON
 

Solved!

Primary mistake on my part. I downloaded the 32-bit 2.50.1 version. That happens to old men. Now, with the 64-bit version, everything's ok. A thousand apologies to all of you.

73, Clovis- PY3OG


locked Re: Single/double click within callsigns window not working

BOB K5HX
 
Edited

Yes, I do have that setting enabled.  This is really strange - all was functioning properly.

As a side note I am running Windows 8.1 with two screens.

Also,  If I click very fast on a given callsign, I sometimes do get the wsjt-x interaction to function properly or the right click on a callsign link to work properly.

Bob
K5HX


locked Re: v2.50.1 Second or third FT8 contact logged as FT8 with FT4 sub-mode. - DEFECT Confirmed

Michael Black
 

I assume the circled item should be "Remove from Wanted list" ?

Mike W9MDB
Inline image





On Thursday, May 6, 2021, 03:29:54 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 7/05/2021 2:26 am, Michael wrote:

I can reproduce the eeror by just switching to Mode FT4 and then back to Mode FT8 as sson as JTAlert has reconized that mode has been changed. And that's in both JTDX and WSJT-x. After doing that switch of mode the next QSO will be logged with FT4 as submode.

73 de Michael 5p1kzx


Tnx Michael,

I have a new Beta release of JTAlert that corrects this problem.

Please try and let me know if this defect is now fixed. I am unable to test HRD logging so need reports back from users who can test.


64bit (x64)  https://dnl.HamApps.com/Beta/JTAlert.2.50.1.build.0001.Beta.Install.X64.exe
32bit (x86)  https://dnl.HamApps.com/Beta/JTAlert.2.50.1.build.0001.Beta.Install.X86.exe


de Laurie VK3AMA


locked Re: UDP port error

CLOVIS VONGHON
 

Are 2 situations (using UNICAST .....or.... using MULTICAST adress). See images.

Thanks.

73, Clovis PY3OG


locked Re: Single/double click within callsigns window not working

Michael Black
 

Do you have multicast turned on in JTAlert?

Inline image

Mike W9MDB



On Friday, May 7, 2021, 05:40:13 AM CDT, BOB K5HX via groups.io <k5hx@...> wrote:


I am currently running JT-Alert, version 2.50.1 and WSJT-X version 2.3.1.

For some reason,  the clicking of callsigns within the Callsigns window stopped working.   Additionally,  right clicking within the callisigns window on any callsign and choosing any of the options does nothing.

My WSJT-x settings are shown below:



Any ideas would be appreciated.

Bob
K5HX

2281 - 2300 of 36991