Date   

locked Re: Callsign Database Question

HamApps Support (VK3AMA)
 

On 10/06/2020 2:09 pm, HamApps Support (VK3AMA) via groups.io wrote:
Either they have changed the location of the database dump file and I am downloading an old version or they are no longer updating the file (pandemic restrictions perhaps).
FYI,
I found the problem. The FCC has changed the location of the daily and weekly files. The old https: address still works and can be browsed but all the images are broken and only delivers files last updated in March. The new files are now hosted at an ftp: address.

de Laurie VK3AMA


locked Re: Callsign Database Question

Michael Black
 

I just checked here

And the files are dated 2020-06-07 and WI9D is now in Wisconsin

EN.dat:EN|2716963|||WI9D|L|L00870765|HANSEN, RANDALL L|RANDALL|L|HANSEN|||||318 E 9th St|Westfield|WI|53964|||000|0011002607|I|||



On Tuesday, June 9, 2020, 11:09:18 PM CDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


On 10/06/2020 12:53 pm, JT Croteau wrote:
Thanks for the reply.  I double checked before posting and the FCC website showed WI. I'm fact, I just checked the website again and it is still showing WI. Very strange.  I'm going to have to email the OP.

N1ESE

OM,

Your observation prompted me to look closer at what I am getting from the FCC.
Either they have changed the location of the database dump file and I am downloading an old version or they are no longer updating the file (pandemic restrictions perhaps).

The files listed in the zip file are all dated 2020-3-02, March 2nd for the file downloaded June 8th.

   

If the Callsign in question updated their FCC address from AZ to WI after that date, then JTAlert would not know about it due to these out-of-date file.

I'll investigate.

de Laurie VK3AMA


locked Re: Callsign Database Question

HamApps Support (VK3AMA)
 

On 10/06/2020 12:53 pm, JT Croteau wrote:
Thanks for the reply.  I double checked before posting and the FCC website showed WI. I'm fact, I just checked the website again and it is still showing WI. Very strange.  I'm going to have to email the OP.

N1ESE

OM,

Your observation prompted me to look closer at what I am getting from the FCC.
Either they have changed the location of the database dump file and I am downloading an old version or they are no longer updating the file (pandemic restrictions perhaps).

The files listed in the zip file are all dated 2020-3-02, March 2nd for the file downloaded June 8th.

   

If the Callsign in question updated their FCC address from AZ to WI after that date, then JTAlert would not know about it due to these out-of-date file.

I'll investigate.

de Laurie VK3AMA


locked Re: ESET Internet Security stops install of JTalert

Andrew Buza
 

Frank; For the first time I'm having a problem installing JTalert running ESET.   I'm a real novice with the computer.  Unable to read your screen shots.  Increasing the screen does not help as the text blurs.  Could you possibly list the screens and steps?


locked Re: Callsign Database Question

JT Croteau
 

Thanks for the reply.  I double checked before posting and the FCC website showed WI. I'm fact, I just checked the website again and it is still showing WI. Very strange.  I'm going to have to email the OP.

N1ESE

On Tuesday, June 9, 2020, Laurie, VK3AMA <hamapps.support@...> wrote:


On 10/06/2020 10:30 am, JT Croteau wrote:
How does JTAlert determine the US state of a station?

Today, I worked WI9D. He was showing on JTAlert as being in Arizona
despite his Wisconsin grid square (EN53).  It was logged as Arizona
with the WI grid.

I have looked at the FCC database, QRZ.com, HamCall, and HamQTH.  All
list his location as Wisconsin.

I'm wondering where JTAlert is pulling this state from when the
logbooks and the FCC state WI.  The OM did post to his QRZ bio back in
2016 that he is in AZ a few months a year but this was four years ago
and I wouldn't think this software would pull from a user written bio
over callbook data.

Thanks
N1ESE

The FCC database is the primary source.

If the most recent FCC download (downloaded 8-June 2020) , WI9D is listed as in AZ.
EN|2716963|||WI9D|L|L00870765|HANSEN, RANDALL L|RANDALL|L|HANSEN|||||250 s tomahawk rd, Site 346|apache junction|AZ|85119|||000|0011002607|I|||

The Callsign database is the only source of US State data that JTAlert uses for the real-time alerting of States. However once your in QSO and have an XML lookup enabled, you will observe the log fields area will show initially AZ and a couple of seconds later after the XML results have been received you will observe the info change to WI.

The use of the FCC database is not foolproof, but it is the best there is at the moment.

Dynamic State determination based on the on-air grid used is on the todo list and has been partially coded for a while now but not high-priority. A State by Grid lookup will not be 100% foolproof either when Grids straddle multiple State boundaries. My plan is to combine the FCC data with the a grid based lookup and use the FCC data when a grid that straddles multiple States lists a State that matches the FCC data the FCC grid will be used. If a grid is wholly within a single State, the FCC data will not be used instead using the State returned by the internal Grid-to-State mapping.

de Laurie VK3AMA






locked download ver 2.16.6

Andrew Buza
 

Having much trouble, for the first time, getting 2.16.7 to run.  In the mean time I want to download the previous ver. 2.16.6.  But I can only find ver 2.16.4
Where can I find it.,


locked Re: Question on how Grid alerts are handled

HamApps Support (VK3AMA)
 

On 10/06/2020 11:08 am, Paul AC9O wrote:
It looks like the grid may be determined on the fly and only cached once a decode with the grid is shown. If so, then grids may not alert for a while until a decode actually contains a grid.

Do I have this correct?

Yes, your correct.

Grids once identified by a decode are cached in memory. This allows for generating Grid Alerts on a Station that may not have transmitted their grid in their last decode.
If a Station never calls CQ with their grid (eg /MM stations) or answers other CQs with his grid will never generate a grid alert as their grid will be unknown.

This in-memory cache or on-air grids is automatically deleted (it is only held in memory) when JTAlert is closed, and is empty when JTAlert is first started.

de Laurie VK3AMA


locked Re: Version 2.16.7 Multiple Grids Works!

HamApps Support (VK3AMA)
 

On 10/06/2020 11:45 am, Robert Wright wrote:
In case anyone wants to see the history on this, the original thread was called
"

Multiple Grids per QSO - Grid boundaries and corners.

"
started on 7/22/19

I had long forgotten about that message thread, but not the need to support 1,2 or 4 grids per single QSO record.

Once I stopped for 5 minutes over a good cup of coffee I had the "light-bulb-moment" when I realized the implementation of multi-grid support was a trivial matter. Since I don't have to worry about JTAlert logging multiple grids, only the discovery of the multiple grids during a Log Scan or B4 lookup, which only involves a minor change to the sql queries involved, the coding was done in a couple of minutes with the cup of coffee unfinished and
still hot ;-)

de Laurie VK3AMA


locked Re: Version 2.16.7 Multiple Grids Works!

Laurie, VK3AMA
 

On 10/06/2020 11:38 am, Robert Wright wrote:

I just tested the new multiple grids per QSO feature.  Now my grid count in JTAlert exactly matches that in DXKeeper. (19 additional grids found by JTAlert)  Very nice!  And just in time for the spring VHF contest this weekend as the rovers are gearing up to go to those grid lines and corners.

One small possible oddity.  I did a re-scan all and the grid total did not change.  Then I did just a grid re-scan and then the total updated correctly.  (using only LoTW confirmations)  I am about 90% sure this was the order of operations.  I'll keep an eye on this as new grids are confirmed.

Thanks for implementing this.
73, Bob, N7ZO
Hi Bob,

Thanks for the feedback. I am surprised that the Scan All returned different results compared to the Grid only Scan. Under-the-hood, there is should be no difference in the Grid scan code being run. I'll investigate.

It's encouraging to hear that the results match DXKeeper.

If you haven't done so already, make sure the "Ignore Grid" option is NOT SET for the B4 alert. This will allow you to catch those roving stations that frequently change grid. With that option un-checked the B4 alert will not be triggered if a B4 station pops up on a Grid from which they have not been previously worked.

de Laurie VK3AMA


locked Re: Version 2.16.7 Multiple Grids Works!

Robert Wright
 

In case anyone wants to see the history on this, the original thread was called
"

Multiple Grids per QSO - Grid boundaries and corners.

"
started on 7/22/19


locked Re: Callsign Database Question

Laurie, VK3AMA
 

On 10/06/2020 10:30 am, JT Croteau wrote:
How does JTAlert determine the US state of a station?

Today, I worked WI9D. He was showing on JTAlert as being in Arizona
despite his Wisconsin grid square (EN53). It was logged as Arizona
with the WI grid.

I have looked at the FCC database, QRZ.com, HamCall, and HamQTH. All
list his location as Wisconsin.

I'm wondering where JTAlert is pulling this state from when the
logbooks and the FCC state WI. The OM did post to his QRZ bio back in
2016 that he is in AZ a few months a year but this was four years ago
and I wouldn't think this software would pull from a user written bio
over callbook data.

Thanks
N1ESE
The FCC database is the primary source.

If the most recent FCC download (downloaded 8-June 2020) , WI9D is listed as in AZ.
EN|2716963|||WI9D|L|L00870765|HANSEN, RANDALL L|RANDALL|L|HANSEN|||||250 s tomahawk rd, Site 346|apache junction|AZ|85119|||000|0011002607|I|||
The Callsign database is the only source of US State data that JTAlert uses for the real-time alerting of States. However once your in QSO and have an XML lookup enabled, you will observe the log fields area will show initially AZ and a couple of seconds later after the XML results have been received you will observe the info change to WI.

The use of the FCC database is not foolproof, but it is the best there is at the moment.

Dynamic State determination based on the on-air grid used is on the todo list and has been partially coded for a while now but not high-priority. A State by Grid lookup will not be 100% foolproof either when Grids straddle multiple State boundaries. My plan is to combine the FCC data with the a grid based lookup and use the FCC data when a grid that straddles multiple States lists a State that matches the FCC data the FCC grid will be used. If a grid is wholly within a single State, the FCC data will not be used instead using the State returned by the internal Grid-to-State mapping.

de Laurie VK3AMA


locked Version 2.16.7 Multiple Grids Works!

Robert Wright
 

Hi Laurie,

I just tested the new multiple grids per QSO feature.  Now my grid count in JTAlert exactly matches that in DXKeeper. (19 additional grids found by JTAlert)  Very nice!  And just in time for the spring VHF contest this weekend as the rovers are gearing up to go to those grid lines and corners.

One small possible oddity.  I did a re-scan all and the grid total did not change.  Then I did just a grid re-scan and then the total updated correctly.  (using only LoTW confirmations)  I am about 90% sure this was the order of operations.  I'll keep an eye on this as new grids are confirmed.

Thanks for implementing this.
73, Bob, N7ZO


locked Question on how Grid alerts are handled

Paul AC9O
 

Hi,

I have a question as to how grid alerts are handled. Is the grid part of the call sign database? In the picture below, WV4P is initially alerted as a needed prefix. In the next section, calling CQ, the grid is now alerted (it has the higher priority).

It looks like the grid may be determined on the fly and only cached once a decode with the grid is shown. If so, then grids may not alert for a while until a decode actually contains a grid.

Do I have this correct?



Thanks and 73
Paul, AC9O


locked Re: JTAlert 2.16.7 is available

neil_zampella
 

You're only turning it off in order to be able to download the file from a known SAFE site.    You then add the HAMAPPS directory to your SAFE exemptions on your antivirus, and turn it back on.

An antivirus just checks to make sure anything you run is not infected you're not going to run the install until after you do the exemption, and restart the antivirus.

There is a reason most antivirus programs have a way to turn off the antivirus for 5 or 10 minutes.

Neil, KN3ILZ


On Tue, Jun 9, 2020 at 12:30 PM, Carlos Reboreda wrote:

Hi Neil,

 

Turning off the antivirus? Bad deal, in my opinión. I trust n my antivirus.. not a single virus in my PC since I installed it, many years ago. I download a lot of files and never had this experience, so I just want to know what the developer says, if he has anything to say about it. I trust on JTalert and so do I with my ESET antivirus.

 

73s Carlos  EA1DWI

 


locked Callsign Database Question

JT Croteau
 

How does JTAlert determine the US state of a station?

Today, I worked WI9D. He was showing on JTAlert as being in Arizona
despite his Wisconsin grid square (EN53). It was logged as Arizona
with the WI grid.

I have looked at the FCC database, QRZ.com, HamCall, and HamQTH. All
list his location as Wisconsin.

I'm wondering where JTAlert is pulling this state from when the
logbooks and the FCC state WI. The OM did post to his QRZ bio back in
2016 that he is in AZ a few months a year but this was four years ago
and I wouldn't think this software would pull from a user written bio
over callbook data.

Thanks
N1ESE


locked jtalert settings wont open

rsagun
 

Hi,

I just installed jtalert 2.16.7 on my Win10 pc.  I'm having a problem opening the settings window...nothing happens when I try to open
settings.  I happen to recall a post talking about windows security
taking out the jtalert settings executable but can't find it.  Any
tips?  Thanks,

ross w6rss

--
Ross Sagun



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


locked Re: JTAlert 2.16.7 is available

John Petrocelli
 

I ran into a similar issue with the download.

I turned off "Avast", successfully downloaded, turned on "Avast" & then installed successfully.

Environment is Win 7 64-bit and not running defender.
John R. Petrocelli - WA2HIP
¶¶¶¶¶¶¶¶¶¶
Primary Home Page:
   http://wa2hip.com
On 6/9/2020 11:30 AM, Hasan Schiers N0AN wrote:
Further hints: For Defender 
...and spare us the "Defender sucks" comments.  This is advice for those who run Defender and are staying with it.

On another machine Chrome blocked it but allowed me to let it continue after I read the warning at the file download window.

If you can't get the file to download at all:

(Do this ONLY if you are confident that the file is safe) Any file from Laurie is SAFE as far as I am concerned)

Virus & Threat Protection > Manage Settings > 

1. Turn Real-time protection OFF
2. Turn Cloud-delivered OFF
3. Turn Automatic sample submission OFF
4. Turn Tamper Protection OFF

(Do this ONLY if you are confident that the file is safe) Any file from Laurie is SAFE as far as I am concerned)

Download the file

Then turn all of the above back ON
73, N0AN
Hasan


On Tue, Jun 9, 2020 at 5:51 AM Hasan Schiers N0AN via groups.io <hbasri.schiers6=gmail.com@groups.io> wrote:
2.16.7 Downloaded and Installed without any issues with Win10Pro and Windows Defender, as long as

1. Windows Defender is Up to Date and...
 
2. Proper exclusions were set up ahead of time (and they have been for months)

Running just fine on two different machines.

73, N0AN
Hasan


On Tue, Jun 9, 2020 at 3:51 AM <dk1wb@...> wrote:
Laurie,
Windows Defender warned that Trojan:Win32/Azden.A!cl was found in
x86)\HamApps\JTAlert\plugins\JTAlertSettings.exe and deleted it.
Please confirm.
73,
Hans, DK1WB

Carlos Reboreda schrieb am 09.06.2020 10:18 (GMT +02:00):

Hi all,

 

My experience here is the same… when there are abt 100 Kb left to finish the download, the ESET (for the first time) cancels the download, because it has detected something dangerous on dnl.hamapps.com … I’m not saying that this is the real matter, I just describe what ESET is doing about this download. I’m user of this antivirus for more tan 15 years, every euro i pay every

year for it is worth it. I tried the download with Opera, Edge and Chrome, so I think it isn’t a matter of the web browser you use. Lets see if there any other members experimenting the same

problem or it happens to be a false detection.

 

73 to all!

 

Carlos R.

EA1DWI

 

Enviado desde Correo para Windows 10

 

De: chas cartmel
Enviado: martes, 9 de junio de 2020 9:50
Para: Support@hamapps.groups.io
Asunto: Re: [HamApps] JTAlert 2.16.7 is available

 

Jacques

08:48 BST – all OK here in the UK.
Have you tries a different browser? Occasionally this works for me if I have a ‘glitch’.

73 Charlie

G4EST

www.g4est.me.uk

 

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Jacques Corbu
Sent: 09 June 2020 07:09
To: Support@HamApps.groups.io
Subject: [HamApps] JTAlert 2.16.7 is available

 

HI Laurie

cannot access new version the website is given as non accessible when I hit download ?  I have never had this issue and it has all the exception requires in avast etc  but this come up 

any idea would be welcomed 

stay safe Jacques F1VEV

 

This email has been scanned by BullGuard antivirus protection.

For more info visit www.bullguard.com

 

 



Virus-free. www.avast.com


locked Re: JTAlert. Log fail.

sidney7539
 

Hello Laurie,
            Thank you for your reply. Despite the fact that I had looked at Log4Om settings several times I had not noticed that I had the wrong UDP INBOUND MESSAGE selected. Rectifying this and I have now logging into Log4om. When I looked into the help file on JTAlert when this first happened I only saw the V1 in the main window and did not see the drop down menu with V2 on in the left pane. Just goes to show with myself not being thorough.
Many thanks for a very fine program which is a boon. Also for your hard work in up dating ect.
Best regards,
Sid G3PQB.
 


locked Re: JTAlert. Log fail.

HamApps Support (VK3AMA)
 

On 10/06/2020 1:21 am, sidney7539 wrote:
         After my PC crashed and I restored to factory settings. I reinstalled JTAlert and upgraded Log4om to V2. Whenever I click on OK on the logging popup window. in WSJT-X I get the following.


All SQLite setting in both JTAlert and Log4om v2 match. And both test OK. 
I have searched the forum for an answer with no success.
I have upgraded to V2.16.7 and am using Win10.
Any advice would be appreciated.
Many thanks for taking the time to read this.
Sid G3PQB

Sid,

Does the QSO get logged despite the error popup?
If not, than likely you have not setup Log4OM correctly. See the JTAlert Help File "Settings -> Logging -> Lo44OM V2" topic.

de Laurie VK3AMA


locked Re: Midway?

g4wjs
 

On 09/06/2020 22:19, HamApps Support (VK3AMA) wrote:
On 10/06/2020 6:39 am, Michael Black via groups.io wrote:
Saw this.....but he's in Hawaii and working from a 4 zone.  So how do we get Midway?
2.16.7
I can just put his callsign in WSJT-X and it shows up like this.

Mike W9MDB


The problem is the "/4" AH6P is using.

The JTAlert cty.dat file parsing is returning KH4 which is Midway, I don't know if that is correct or not

If he had signed for the other US cq zones he comes up as..
    Zone 3: AH6P/3 -> KH3 Johnston Island
    Zone 5: AH6P/5 -> KH5 Palmyra & Jarvis Islands

Using DXLab DXView as my gold standard it returns the same results except for no DXCC for AH6P/4

I am not familiar with the US licensing requirements, but is it normal to indicate the operating zone in such a way? I don't recall ever seeing this before, signing using the operating Zone number as a portable suffix.

de Laurie VK3AMA

Hi Laurie,

I believe it is not zone but call area. Once it was required in the days when calls were strictly issued by call area, now calls can be moved at will there's no longer a requirement but it is useful with island entity like Hawaii when operated form the mainland.

73
Bill
G4WJS.


--
73
Bill
G4WJS.