Date   

locked Re: #WARNING : Latest HamApps Callsign Database (2018.09.13) problems.

Alfred Reeves
 

Thanks for the heads up Laurie!

Al
W1JHU

On 9/13/2018 6:11 AM, HamApps Support (VK3AMA) wrote:
The latest database (2018.09.13) was created with an updated sqlite.dll file and it looks like it is not compatible with the current JTAlert 2.12.5 which uses an older sqlite.dll

If anyone is experiencing missing LoTW/eQSL flags and country names replaced with a "0" they will need to install an earlier version of the database. HamApps.com is now listing the previous version, 2018.08.27, which is compatible with the current and earlier JTAlert.

Let me know if that doesn't work for you.

de Laurie VK3AMA


locked Re: #WARNING : Latest HamApps Callsign Database (2018.09.13) problems.

Ed Wilson
 

Laurie,

The older version is working as expected.

Ed, K0KC

k0kc@...
http://k0kc.us/


On Thursday, September 13, 2018, 6:11:37 AM EDT, HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:


The latest database (2018.09.13) was created with an updated sqlite.dll file and it looks like it is not compatible with the current JTAlert 2.12.5 which uses an older sqlite.dll

If anyone is experiencing missing LoTW/eQSL flags and country names replaced with a "0" they will need to install an earlier version of the database. HamApps.com is now listing the previous version, 2018.08.27, which is compatible with the current and earlier JTAlert.

Let me know if that doesn't work for you.

de Laurie VK3AMA

Virus-free. www.avast.com


locked #WARNING : Latest HamApps Callsign Database (2018.09.13) problems.

HamApps Support (VK3AMA)
 

The latest database (2018.09.13) was created with an updated sqlite.dll file and it looks like it is not compatible with the current JTAlert 2.12.5 which uses an older sqlite.dll

If anyone is experiencing missing LoTW/eQSL flags and country names replaced with a "0" they will need to install an earlier version of the database. HamApps.com is now listing the previous version, 2018.08.27, which is compatible with the current and earlier JTAlert.

Let me know if that doesn't work for you.

de Laurie VK3AMA


locked Re: logging with DXKeeper

Dave AA6YQ
 

+ AA6YQ comments below

I notice that after an FT* contact is made and JT alert logs it, it does not set the QSL requested flag to R. Am I just missing a check mark that I dont find?

+ On the LoTW tab of DXKeeper's "QSL Configuration" window, check the "Initialize LoTW Sent to 'R' for each logged QSO or imported QSO" box.

73,

Dave, AA6YQ


locked Re: logging with DXKeeper

HamApps Support (VK3AMA)
 

On 13/09/2018 5:36 AM, scot wrote:
Hello,
I notice that after an FT* contact is made and JT alert logs it, it does not set the QSL requested flag to R.  Am I just missing a check mark that I dont find?

Scott
N2SAB
Scott,

Use the QSL checkbox in the Log fields area of JTAlert.
This is for card requests and has to be set on a per-QSO basis.
Visit the Settings, Logging section, and check the "Remember QSL Request..." option to have the option permanently enabled.
 
   

   

For LoTW and eQSL, they can be set on an all-QSO basis. Visit the settings, Logging section, and enable the appropriate option.

   

   
de Laurie VK3AMA


locked logging with DXKeeper

scot
 

Hello,
I notice that after an FT* contact is made and JT alert logs it, it does not set the QSL requested flag to R.  Am I just missing a check mark that I dont find?

Scott
N2SAB


locked Re: Changing my call results in a Error.

vdlaken@...
 

Thanks Laurie

Your guess was right. The problem I had was that although I chose a file as logfile, I forgot to go up to the "logging" item before I was able to save the configuration. It's up and running now.

73 de Wil, pe3t (pa0bwl)


locked Re: Need to find WSJT-X JTAlert-X setting

Jim - N4ST
 

I believe what you are looking for is when using the MSK144 mode you can offset your receive frequency to allow for rig calibration errors.

 

_____________

73,

Jim – N4ST

 

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of k6vib@q.com
Sent: Tuesday, September 11, 2018 13:13
To: Support@HamApps.groups.io
Subject: [HamApps] Need to find WSJT-X JTAlert-X setting

 

I ran across a setting in one of the "settings" of the subject matter that allowed me to set my received frequency +/- a certain number of Hz. I cannot find that again after going through several of the available pages to make changes in either program. Any help?


locked Re: Changing my call results in a Error.

HamApps Support (VK3AMA)
 

On 11/09/2018 5:14 AM, vdlaken@xs4all.nl wrote:
JTAlertX 2.12.5 After changing my call (in the startup directory) I get an error message about AdifImport.exe : Bad or missing command line parameters -  and than the filename and location: C: \Program Files\HamApps\JTAlert\plugins\AdifImport.exe followed by all that is missing (call out trace and lock)
I suppose I did something wrong but I cannot get it working again properly.
Any ideas?
OM,

Without seeing the error message, I can only guess as to the cause.

Most likely the error message is showing --in="". Is that the case? If so, it indicates that your adif file path set in JTAlert is empty. Which may happen if you changed your Callsign which then alters file paths were critical JTAlert files are stored.

de Laurie VK3AMA


locked Re: Changing my call results in a Error.

HamApps Support (VK3AMA)
 

On 11/09/2018 5:14:
TAlertX 2.12.5 After changing my call (in the startup directory) I get an error message about AdifImport.exe : Bad or missing command line parameters -  and than the filename and location: C: \Program Files\HamApps\JTAlert\plugins\AdifImport.exe followed by all that is missing (call out trace and lock)
I suppose I did something wrong but I cannot get it working again properly.
Any ideas?
OM,

What is the changed Callsign? Does it contain any non-standard characters?

Please use the "? -> Contact Support" menu, on the JTAlert title-bar, to send me your Configuration and Session files for analysis.

de Laurie VK3AMA


locked Changing my call results in a Error.

vdlaken@...
 

JTAlertX 2.12.5  After changing my call (in the startup directory) I get an error message about AdifImport.exe : Bad or missing command line parameters -  and than the filename and location: C: \Program Files\HamApps\JTAlert\plugins\AdifImport.exe followed by all that is missing (call out trace and lock)
I suppose I did something wrong but I cannot get it working again properly.
Any ideas?


locked Re: JTAlert and QRZ.com lookup

W
 

Laurie,

That was it, did not have the XML Log lookup set, once I did that, works perfectly.

Thanks again and apologize for taking your time with this.  I should have figured it out.

Wally

K5WLY


locked Re: Lat Long Handling Request

Tom Melvin
 

Accuracy of beam heading - 6 digit does not quite get there in some cases. AirScout at vhf/uhf  for AS prefers 8 digit - must admit not used 10 digit up to now.

Nothing really to with JTalert other than your question as to why it’s needed.

No contests - just very sharp beams

As bulk of users here HF Junkies will will drop topic.

Tom
GM8MJV @ IO85MU49

On 8 Sep 2018, at 22:17, Tom Ramberg via Groups.Io <oh6vda@...> wrote:

10 digits gets you down to 10X10 meters, but I fail to see the point of this. 
 De Tom OH6VDA, KP12cl43nh

8. sep. 2018 kl. 23:55 skrev Michael Black via Groups.Io <mdblack98@...>:

Why is 8 digits needed for higher frequencies?
And what does this have to do with JTAlert?
Is there some contest that requires grids to a higher degree?
And yes...I'm an HF junkie.

de Mike W9MDB



On Saturday, September 8, 2018, 3:16:56 PM CDT, Tom Melvin <tom@...> wrote:


You can use:


Will take you up to 10 characters


Tom
GM8MJV

P.S. Mike not every one just uses HF - 8 digits is needed as a minimum for some of the higher frequences



David Rounds <ak9f_ham@...> wrote:

That site requires registration and a  login but but there is no link on the page for registering.
Regards,
David

On 9/8/2018 10:40 AM, roamer wrote:
Here is the URL to get your 4,6 or 8 digit GS info.  Neat place.







locked Re: Lat Long Handling Request

Michael Black
 

Interesting...doesn't add that for Log4OM so must be unique to JTAlert's HRD logging....Laurie?

de Mike W9MDB




On Sunday, September 9, 2018, 8:00:07 AM CDT, Dan Srebnick K2DLS <dan@...> wrote:


In fact, JT Alert IS sending lat/log via the TCP API.

 

This is what Wireshark shows for a sample QSO:

 

db add "K2DLS Logbook" {CALL="WA9IVB" DXCC="291" COUNTRY="United States" QSO_DATE="20180909" QSO_DATE_OFF="20180909" TIME_ON="125000" TIME_OFF="125000" FREQ="10137202" FREQ_RX="10136929" BAND="30m" BAND_RX="30m" MODE="FT8" QSL_SENT="N" QSL_RCVD="N" GRIDSQUARE="EM79au" DISTANCE="1000" TX_PWR="25" LAT="N039 51.250" LON="W085 57.500" NAME="David" QTH="Indianapolis" STATE="IN" CNTY="Marion" CQZ="5" ITUZ="8" PFX="WA9" CONT="NA" MY_LAT="40.395833" MY_LON="-74.208333" MY_GRIDSQUARE="FN20vj" MY_CQ_ZONE="5" MY_ITU_ZONE="8" STATION_CALLSIGN="K2DLS" }

quit

 

Note the value for MY_LAT and MY_LON.  They exactly match the values given in my initial post for the ones that slightly differ with the ones I have manually set because they are being derived from the value of MY_GRIDSQUARE.

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Michael Black via Groups.Io
Sent: Saturday, September 8, 2018 23:36
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

I believe Laurie wrote "never used in logging".

You must be looking at the lat/lon in the rotator boxes?

HRD is computing lat/lon from the 6-char grid sent by JTAlert.

You can't even put more then 6 chars in HRD's grid square box (or station info) so I doubt they will even compute an 8-char grid.

 

de MIke W9MDB

 

 

 

 

 

On Saturday, September 8, 2018, 8:25:36 PM CDT, Dan Srebnick K2DLS <dan@...> wrote:

 

 

Hi Laurie:

 

FN20vj rather than FN20jv as you typed it!

 

OK, I believe I understand that JT Alert is going to send lat/long values in my case via the HRD TCP API and that they are derived from the 6 char gridsquare entered in the WSJT-X My Grid field.

 

Is that understanding correct?  I want to at least understand where the data is originating.

 

Thank you.

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, September 8, 2018 20:37
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

On 8/09/2018 7:40 PM, Dan Srebnick K2DLS wrote:

They are not identical, which is my preference since I'm sitting in the same
chair in both cases :->
  
Where JT Alert says I am based upon 6 char grid of FN20vj:
  
40.395833 / -74.208333
  
Where I say I am based upon my own assessment:
  
40.396 / 74.20867
  
73, Dan K2DLS

Dan,

Looks like you have some typos in the numbers your quoting.
For FN20jv JTAlert gives 40.895833 lat x -75.208333 lon, not the 40.395833 lat x -754.208333 lon quoted.

Regardless, you can ignore the values given by JTAlert as they are never used in logging.
They were originally provided for that purpose, but never implemented as JTAlert dynamically determines the lat/lon values based on your grid set within WSJT-X and passed when logging a QSO.

JTAlert uses the WSJT-X provided Grid (and also Station Callsign) when logging as this allows for operators who frequently change Grids (and sometimes Callsign) to make that change in WSJT-X without having to remember to also change JTAlert.

WSJT-X only supports grids up to 6 characters so the lat/lon values logged will never be to the precision you require, which appears to rely on a grid specifier of more than 6 characters.

de Laurie VK3AMA


locked Re: Lat Long Handling Request

Dan K2IE
 

In fact, JT Alert IS sending lat/log via the TCP API.

 

This is what Wireshark shows for a sample QSO:

 

db add "K2DLS Logbook" {CALL="WA9IVB" DXCC="291" COUNTRY="United States" QSO_DATE="20180909" QSO_DATE_OFF="20180909" TIME_ON="125000" TIME_OFF="125000" FREQ="10137202" FREQ_RX="10136929" BAND="30m" BAND_RX="30m" MODE="FT8" QSL_SENT="N" QSL_RCVD="N" GRIDSQUARE="EM79au" DISTANCE="1000" TX_PWR="25" LAT="N039 51.250" LON="W085 57.500" NAME="David" QTH="Indianapolis" STATE="IN" CNTY="Marion" CQZ="5" ITUZ="8" PFX="WA9" CONT="NA" MY_LAT="40.395833" MY_LON="-74.208333" MY_GRIDSQUARE="FN20vj" MY_CQ_ZONE="5" MY_ITU_ZONE="8" STATION_CALLSIGN="K2DLS" }

quit

 

Note the value for MY_LAT and MY_LON.  They exactly match the values given in my initial post for the ones that slightly differ with the ones I have manually set because they are being derived from the value of MY_GRIDSQUARE.

 

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of Michael Black via Groups.Io
Sent: Saturday, September 8, 2018 23:36
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

I believe Laurie wrote "never used in logging".

You must be looking at the lat/lon in the rotator boxes?

HRD is computing lat/lon from the 6-char grid sent by JTAlert.

You can't even put more then 6 chars in HRD's grid square box (or station info) so I doubt they will even compute an 8-char grid.

 

de MIke W9MDB

 

 

 

 

 

On Saturday, September 8, 2018, 8:25:36 PM CDT, Dan Srebnick K2DLS <dan@...> wrote:

 

 

Hi Laurie:

 

FN20vj rather than FN20jv as you typed it!

 

OK, I believe I understand that JT Alert is going to send lat/long values in my case via the HRD TCP API and that they are derived from the 6 char gridsquare entered in the WSJT-X My Grid field.

 

Is that understanding correct?  I want to at least understand where the data is originating.

 

Thank you.

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, September 8, 2018 20:37
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

On 8/09/2018 7:40 PM, Dan Srebnick K2DLS wrote:

They are not identical, which is my preference since I'm sitting in the same
chair in both cases :->
  
Where JT Alert says I am based upon 6 char grid of FN20vj:
  
40.395833 / -74.208333
  
Where I say I am based upon my own assessment:
  
40.396 / 74.20867
  
73, Dan K2DLS

Dan,

Looks like you have some typos in the numbers your quoting.
For FN20jv JTAlert gives 40.895833 lat x -75.208333 lon, not the 40.395833 lat x -754.208333 lon quoted.

Regardless, you can ignore the values given by JTAlert as they are never used in logging.
They were originally provided for that purpose, but never implemented as JTAlert dynamically determines the lat/lon values based on your grid set within WSJT-X and passed when logging a QSO.

JTAlert uses the WSJT-X provided Grid (and also Station Callsign) when logging as this allows for operators who frequently change Grids (and sometimes Callsign) to make that change in WSJT-X without having to remember to also change JTAlert.

WSJT-X only supports grids up to 6 characters so the lat/lon values logged will never be to the precision you require, which appears to rely on a grid specifier of more than 6 characters.

de Laurie VK3AMA


locked Re: Lat Long Handling Request

Michael Black
 

I believe Laurie wrote "never used in logging".
You must be looking at the lat/lon in the rotator boxes?
HRD is computing lat/lon from the 6-char grid sent by JTAlert.
You can't even put more then 6 chars in HRD's grid square box (or station info) so I doubt they will even compute an 8-char grid.

de MIke W9MDB





On Saturday, September 8, 2018, 8:25:36 PM CDT, Dan Srebnick K2DLS <dan@...> wrote:


Hi Laurie:

 

FN20vj rather than FN20jv as you typed it!

 

OK, I believe I understand that JT Alert is going to send lat/long values in my case via the HRD TCP API and that they are derived from the 6 char gridsquare entered in the WSJT-X My Grid field.

 

Is that understanding correct?  I want to at least understand where the data is originating.

 

Thank you.

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, September 8, 2018 20:37
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

On 8/09/2018 7:40 PM, Dan Srebnick K2DLS wrote:

They are not identical, which is my preference since I'm sitting in the same
chair in both cases :->
  
Where JT Alert says I am based upon 6 char grid of FN20vj:
  
40.395833 / -74.208333
  
Where I say I am based upon my own assessment:
  
40.396 / 74.20867
  
73, Dan K2DLS

Dan,

Looks like you have some typos in the numbers your quoting.
For FN20jv JTAlert gives 40.895833 lat x -75.208333 lon, not the 40.395833 lat x -754.208333 lon quoted.

Regardless, you can ignore the values given by JTAlert as they are never used in logging.
They were originally provided for that purpose, but never implemented as JTAlert dynamically determines the lat/lon values based on your grid set within WSJT-X and passed when logging a QSO.

JTAlert uses the WSJT-X provided Grid (and also Station Callsign) when logging as this allows for operators who frequently change Grids (and sometimes Callsign) to make that change in WSJT-X without having to remember to also change JTAlert.

WSJT-X only supports grids up to 6 characters so the lat/lon values logged will never be to the precision you require, which appears to rely on a grid specifier of more than 6 characters.

de Laurie VK3AMA



locked Re: JTAlert and QRZ.com lookup

W
 

Thanks Laurie for the explanation.

I will look at that and figure out how to do it.  Hopefully tomorrow or the next day.

Really appreciate you helping me out.

Wally 

K5WLY


locked Re: Lat Long Handling Request

Dan K2IE
 

Hi Laurie:

 

FN20vj rather than FN20jv as you typed it!

 

OK, I believe I understand that JT Alert is going to send lat/long values in my case via the HRD TCP API and that they are derived from the 6 char gridsquare entered in the WSJT-X My Grid field.

 

Is that understanding correct?  I want to at least understand where the data is originating.

 

Thank you.

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: Saturday, September 8, 2018 20:37
To: Support@HamApps.groups.io
Subject: Re: [HamApps] Lat Long Handling Request

 

On 8/09/2018 7:40 PM, Dan Srebnick K2DLS wrote:

They are not identical, which is my preference since I'm sitting in the same
chair in both cases :->
 
Where JT Alert says I am based upon 6 char grid of FN20vj:
 
40.395833 / -74.208333
 
Where I say I am based upon my own assessment:
 
40.396 / 74.20867
 
73, Dan K2DLS

Dan,

Looks like you have some typos in the numbers your quoting.
For FN20jv JTAlert gives 40.895833 lat x -75.208333 lon, not the 40.395833 lat x -754.208333 lon quoted.

Regardless, you can ignore the values given by JTAlert as they are never used in logging.
They were originally provided for that purpose, but never implemented as JTAlert dynamically determines the lat/lon values based on your grid set within WSJT-X and passed when logging a QSO.

JTAlert uses the WSJT-X provided Grid (and also Station Callsign) when logging as this allows for operators who frequently change Grids (and sometimes Callsign) to make that change in WSJT-X without having to remember to also change JTAlert.

WSJT-X only supports grids up to 6 characters so the lat/lon values logged will never be to the precision you require, which appears to rely on a grid specifier of more than 6 characters.

de Laurie VK3AMA



locked Re: Incorrect CQ and ITU Zones being Logged in Logbook

HamApps Support (VK3AMA)
 

On 8/09/2018 8:49 AM, pfullmer wrote:
  Thanks for the explanation.  I asked Scott (N3FJP) also, and he told me that ACLOG does have an "Override Existing Data" check block, so when you download from LOTW it will change/make corrections to fields such as the CQ and ITU zones.  We didn't have it checked.  

Pete KE7W
Pete,

Thanks for the feedback. Glad to hear that is now sorted.

de Laurie VK3AMA


locked Re: Incorrect CQ and ITU Zones being Logged in Logbook

HamApps Support (VK3AMA)
 

On 7/09/2018 4:51 PM, Zrinko Zibert wrote:
Laurie, what about Clublog?
Clublog exception list is very realible and they have a very fast update. I am using it automatically into Logger32...
 
Zik, DK8ZZ (VE3ZIK, YT3ZZ)
Zik,

ClubLog could be used (the code is written but never implemented) to determine Zone data for the current QSO partner for eventual logging if an XML service is not enabled. ClubLog does not always provide accurate data however.

An XML lookup of data maintained by the Callsign owner (who I assume knows where they are located) is the preferred option, IMHO.

Regardless, of XML or ClubLog lookup, I still need to correct the JTAlert zone determination based on Callsign structure/naming as it is used for the CQ Zone alerts which can't rely on a slow Internet lookup of many callsigns at the end of a decode period to determine if a Callsign Zone is wanted. That multiple lookup needs to remain within the JTAlert process.

de Laurie VK3AMA

16101 - 16120 of 37715