Date   

locked Re: JTAlert--->DXKeeper problem

HamApps Support (VK3AMA)
 

On 5/02/2021 10:16 am, Jim Monroe wrote:
Thanks for your reply and I thought you solved my problem as I didnt have those checkmarked, I have only been hitting the Logging button and down to the DXLab DXKeeper tab without double hitting the Logging button. So now when I log a qso it filles the name and qth window in DXKeeper but not the address square unless I manually hit the CBA button than it fills with name and complete address. So close....In JTAlert I do have check marked "log full qth from xml lookups" I assume that should include the complete address. 
Jim, n7esu

I don't know what you mean by double hitting the Log button. There should only be one Log button clicked. That is the "OK" button on the WSJT-X "Log QSO" window only. Once you click that JTAlert automatically picks up the new QSO data, combines it with what ever data it has retrieved from the XML lookup (which can be seen in the Log fields area of JTAlert), formats the necessary command and sends to DXKeeper.

If you don't hit the "OK" button, than JTAlert will never log anything, that operation is mandatory and is how it has always worked, otherwise JTAlert will have no knowledge of what you want to log.

The XML data JTAlert downloads is not populated in DXKeeper prior to logging, only the DX Call callsign is sent to DXKeeper prior to logging. You should not be trying to log from within DXKeeper, I suspect that is what your doing. Let JTAlert do its thing in passing the WSJT-X QSO data with the XML data onto to DXKeeper.

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Jim Monroe
 

Ron,
Thanks for your reply and I thought you solved my problem as I didnt have those checkmarked, I have only been hitting the Logging button and down to the DXLab DXKeeper tab without double hitting the Logging button. So now when I log a qso it filles the name and qth window in DXKeeper but not the address square unless I manually hit the CBA button than it fills with name and complete address. So close....In JTAlert I do have check marked "log full qth from xml lookups" I assume that should include the complete address. 
Jim, n7esu

On Thu, Feb 4, 2021 at 8:17 AM Ron W3RJW via groups.io <w3rjw=verizon.net@groups.io> wrote:
Perhaps checks missing?


--
73
Ron, W3RJW


locked Re: CQ Marathon query

Phil Cooper
 

Hi Laurie,

 

Wow, many thanks for clearing that up!

I was feeling very confused, and will re-set that tomorrow.

It was not set, partly because I wasn’t clear about the meaning, although it did seem to be the answer given by Jim N6VH. However, when you sent your reply, I was starting to think that it would mean I would no longer get alerts for new band-slots.

 

Thanks again for all your support with JTAlert. I could not live without it now.

 

73 de Phil GU0SUP

 

From: Support@HamApps.groups.io [mailto:Support@HamApps.groups.io] On Behalf Of HamApps Support (VK3AMA)
Sent: 04 February 2021 18:56
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query

 

On 4/02/2021 11:25 pm, Phil Cooper via groups.io wrote:

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

Rereading my response I can understand your confusion. The relevant part "This option is available for all the Alert types" could have been reworded. "This option is available for all the Alert types on a per Alert basis" may be better wording.

In a nut-shell, each Alert type has multiple options, each being independent of the same options in another Alert type. So you could set the Marathon Alert to track by any band and any mode while at the same time have the DXCC Alert track individual Bands and Modes. The same applies for the "Auto clear triggered Alert entity after logging" option. You can safely apply that option for the Marathon Alert without affecting your DXCC Alerts which you could have set for individual Bands and Modes and require a QSL confirmation (eg LoTW confirmed) for an Entity to be no longer Alerted.

de Laurie VK3AMA


locked Re: CQ Marathon query

HamApps Support (VK3AMA)
 

On 4/02/2021 11:25 pm, Phil Cooper via groups.io wrote:

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

Rereading my response I can understand your confusion. The relevant part "This option is available for all the Alert types" could have been reworded. "This option is available for all the Alert types on a per Alert basis" may be better wording.

In a nut-shell, each Alert type has multiple options, each being independent of the same options in another Alert type. So you could set the Marathon Alert to track by any band and any mode while at the same time have the DXCC Alert track individual Bands and Modes. The same applies for the "Auto clear triggered Alert entity after logging" option. You can safely apply that option for the Marathon Alert without affecting your DXCC Alerts which you could have set for individual Bands and Modes and require a QSL confirmation (eg LoTW confirmed) for an Entity to be no longer Alerted.

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Ron W3RJW
 

Perhaps checks missing?


--
73
Ron, W3RJW


locked Re: CQ Marathon query

Steve, N3SL
 

Phil,
The checkbox is on "every" alert/award page, so each is individually configurable.  

On Thu, Feb 4, 2021 at 6:25 AM Phil Cooper via groups.io <pcooper=suremail.gg@groups.io> wrote:

Hi Laurie,

 

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Laurie, VK3AMA" <hamapps.support@...>
Sent: Thursday, 4 February, 2021 01:35
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert not working??

Morris WA4MIT
 
Edited

Thank you guys for the response but I am not using the new modes and why has Alert stopped working with JTDX. I spent most of yesterday trying to get Alert working but have had no success.
Do these new setting affect using Alert with JTDX? I tried going back to a older version of Alert I could not even get it to work I get a Alert is not responding and the Alert title bar and
what is on screen would not shut down or at least disappear I had to restart computer to get Alert off the screen. Strange happenings. This started with Alert at times not responding 
then after restarting Alert it worked but now it will not. I use JTDX 90% of time only on FT8/4 i have not used or tried the new modes at all. Attached a picture of what I am seeing using
JTDX. This is all I am able to get out of JTAlert right now. This latest Alert .17 My WSJTX (now 2.4.0 rc1) does not have the screen you guys are showing it and JTDX look like the picture I put up??
Thanks 73`s
Morris WA4MIT


locked Re: CQ Marathon query

Phil Cooper
 

Hi Laurie,

 

Ah, so you are saying that if this box is checked, and I work (for example) P5XXX on 20m FT8, I will NOT get an alert when he pops up on another band?

 

I only want to stop alerts for any given country worked in the current year for CQ Marathon, as countries only count once, regardless of band/mode.

 

For now, i have unchecked that box again, as I don't wish to miss new DXCC slots.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Laurie, VK3AMA" <hamapps.support@...>
Sent: Thursday, 4 February, 2021 01:35
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

Jim Monroe
 

Laurie,
Yes in JTAlert under web services --> online xml callbooks I have qrz.com xml lookup running, it even shows last lookup time and date and it working ok. Under the logging tab I have enabled dxlab dxkeeper logging . When I log qso everything populates DXKeeper except qrz.com data name and address...yet it shows last look up time and date with no errors...not sure what else I am missing,
Jim, n7esu

On Wed, Feb 3, 2021 at 4:46 PM HamApps Support (VK3AMA) <vk3ama.ham.apps@...> wrote:
On 4/02/2021 11:18 am, Jim Monroe wrote:
I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu

It is automatic. If the name & qth fields in JTAlert contain data they will be logged. If they are empty then nothing is logged. Those fields can be populated either manually, from a previous QSO in your log or from the results of an XML lookup. My guess, is your not logging that data for QSOs with previously unworked (so not in your log) stations and don't have an XML service enabled in JTAlert.

de Laurie VK3AMA


locked Re: CQ Marathon query

Laurie, VK3AMA
 



On 4/02/2021 3:28 am, Jim N6VH wrote:

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".


That will be the answer.

That setting causes an Entity to be automatically marked as no-longer needed in the Alert database. This option is available for all the Alert types, useful for those users who don't require a QSL confirmation to have an Entity set as no-longer need (so will not alert), that is they are happy for just working the Entity. Prior to this option being introduced, there was no automatic flagging of worked Entities, thus requiring the "Rebuild Alert Database" operation (previously called the Log Scan) to update the Alert database. For Entities that require just a worked status (like the Marathon) it is a simple set and forget option. Of course if you require a QSL confirmation (like LoTW for DXCC) donot enable that option.

Note: When I use the word "Entity", I am not referring to DXCC Entities, but using it to describe all the Alert type entities (DXCC, State, Zones, Grids, etc).

de Laurie VK3AMA


locked Re: JTAlert not working??

Laurie, VK3AMA
 



On 4/02/2021 4:04 am, neil_zampella wrote:


In addition to having a loopback interface selected in WSJT-X (a new requirement for 2.3.0), JTAlert needs to have the "Settings -> WSJT-X UDP Multicast on Loopback" menu ticked in order to work with the new WSJT-X interface changes.

   

de Laurie VK3AMA


locked Re: JTAlert--->DXKeeper problem

HamApps Support (VK3AMA)
 

On 4/02/2021 11:18 am, Jim Monroe wrote:
I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu

It is automatic. If the name & qth fields in JTAlert contain data they will be logged. If they are empty then nothing is logged. Those fields can be populated either manually, from a previous QSO in your log or from the results of an XML lookup. My guess, is your not logging that data for QSOs with previously unworked (so not in your log) stations and don't have an XML service enabled in JTAlert.

de Laurie VK3AMA


locked Re: Post WSJTX 2.3 Install Issues

HamApps Support (VK3AMA)
 

On 4/02/2021 5:07 am, Patrick Hung wrote:
After installing WSJTX v.2.3 GA, JTAlert keeps showing me the following alert box, which will not go away after software or computer reboot; I also reinstalled v. 2.16.17, to no avail. Clicking on the OK button quits out of JTAlert.



No settings were changed on either WSJT-X or JTAlert throughout the WSJT-X upgrade; here they are below:





Any thoughts? Thanks in advance.

--
73,

Patrick - W6AJR

You have JTAlert set to resend received UDP traffic to port 2237. You have WSJT-X set to transmit UDP to port 2237. That is very very wrong and would result in JTAlert re-sending received UDP data back to the listening port which it would try and process and resend again in an endless infinite loop. This is likely the cause of the internal JTAlert error that brings down the program. If you need to resend UDP traffic it needs to be on a different port, other wise change the port and disable the setting.

de Laurie VK3AMA


locked Re: UDP Link to WSJT-X

HamApps Support (VK3AMA)
 

On 4/02/2021 6:39 am, Monty Wilson wrote:

Yesterday, as I was troubleshooting another issue, the communications between WSJT-X (2.3.0) and JTALERT (2.16.17) stopped for reasons unknown.

 

In troubleshooting I re-installed WSJT-X 2.2.2 since everything worked under that version, however, since the reload, I still do not have a connection between WSJT-X and JTALERT.

 

Anyone have an idea what to look for, what to try?

 

Monty, NR0A


Based on your posting in the WSJT-X group, my guess is that you have been playing with the UDP servers settings.

My response to your WSJT-X group message...

Looks like you have been playing with your WSJT-X UDP settings. Port 2333 is the default for the secondary UDP Server (depreciated). JTAlert uses the primary settings, and according to your error message is reading 2333. That looks wrong. My guess, without see your actual settings dialog, is that you have both the primary and secondary UDP servers set to use port 2333. Try changing back to the defaults, 2237 for the primary and 2333 for the secondary and don't enable the secondary server.

   

de Laurie VK3AMA



locked JTAlert--->DXKeeper problem

Jim Monroe
 

I cant figure out or remember how to get JTAlert to send to DXKeeper the name and address of a qso when logged. DXKeeper logs it ok when manually doing a look up or using the capture window. JTAlert shows last qso looked up when logging to its adi log. I am using QRZ hml. JTAlert and WSJT-X all working good and talking to each other and other logged info is saving in DXKeeper. This use to work until I re-built my computer and installed all fresh installs of everything. Thanks in advance for the help.
Jim, n7esu


locked Re: UDP Link to WSJT-X

Monty Wilson, NR0A
 

Yesterday, as I was troubleshooting another issue, the communications between WSJT-X (2.3.0) and JTALERT (2.16.17) stopped for reasons unknown.

 

In troubleshooting I re-installed WSJT-X 2.2.2 since everything worked under that version, however, since the reload, I still do not have a connection between WSJT-X and JTALERT.

 

Anyone have an idea what to look for, what to try?

 

Monty, NR0A

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of Monty Wilson
Sent: Monday, February 1, 2021 05:10 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] UDP Link to WSJT-X

 

Thanks Bill,

 

That got it running.  I do not know how the loop back got set to blank.  I do know that I did not change it but did check all of the UDB values to make sure they were the same.  I did notice it was blank when I was checking values.

 

Anyway, I’m back up and operating again.

 


Thanks

 

73  de

 

Monty, NR0A

 

From: Support@HamApps.groups.io <Support@HamApps.groups.io> On Behalf Of g4wjs
Sent: Monday, February 1, 2021 04:56 PM
To: Support@HamApps.groups.io
Subject: Re: [HamApps] UDP Link to WSJT-X

 

On 01/02/2021 22:45, Monty Wilson wrote:

Hello,

 

I downloaded the new version of WSJT-X (2.3.0) today and installed the program.  Now I do not get any transfer of information between WSJT-X and JTAlert (version 2.16.17). 

I am using the multicast process and have the following set in both WSJT-X:

 

UDP Server = 239.255.0.0

UDP Server port number = 2333

Outgoing interfaces is blank

Multicast TTL = 1

 

Accept UDP requests is checked in WSJT-X

Notify on accepted UDP request is checked

Accepted UDP request restores window is checked

 

JTALERT has the following configuration:

 

Logging > Last QSO API – Enable transmission of last QSO check and UDP port set to 2333

Logging > HRD V5/V6 – Version 6.3 or later selected

                                             This is a version 6.7.0.269 or later adif 3.1 compliant log

                                             Log Name is correct (no change)

                                             PC IPv4 address = 239.255.0.0

 

As far I know all of this is same as the old version of WSJT-X (2.2.2)

 

I get the following error message from JTALERT

 

Unable to communicate with the WSJT-X process.

  UDP Port : 2333

  IP Address : 239.255.0.0

  Values read from WSJT-X config file...

    C:\Users\jwils\AppData\Local\WSJT-X\WSJT-X.ini

 

WSJT-X Detected Instance...

  Process Window Title : WSJT-X   v2.3.0   by K1JT, G4WJS, and K9AN

  Process Command Line : "C:\WSJT\wsjtx\bin\wsjtx.exe"

 

Decode alerts and logging will be unavailable until corrected.

 

About JTAlert shows

 

JTAlert Instance      : #1

JTAlert Start Params  : /wsjtx

WSJT-X Window Title   : WSJT-X   v2.3.0   by K1JT, G4WJS, and K9AN

WSJT-X Command Line   : "C:\WSJT\wsjtx\bin\wsjtx.exe"

WSJT-X   --rig-name   :

WSJT-X Config File    : C:\Users\jwils\AppData\Local\WSJT-X\WSJT-X.ini

WSJT-X Version               :

WSJT-X Revision              :

WSJT-X Spec Op Mode          : None

WSJT-X UDP ID                :

WSJT-X UDP Port              : 2333

WSJT-X UDP Server            : 239.255.0.0

WSJT-X UDP MCast on Loopback : True

WSJT-X UDP Max Schema        :

 

It is obvious something is missing, but I’m not sure why or where I need to “tickle” either software package to get them to talk to each other.

 

What am I missing?

 

Thanks

 

Monty, NR0A

jwilson16@...

Hi Monty,

you should not be able to set the WSJT-X multicast outgoing interfaces to blank. As JTAlert and WSJT-X must run on the machine you should set the loopback interface as the outgoing interface and also check the use loopback interface option on the JTAlert Settings menu. that should get thing running.


--
73
Bill
G4WJS.


locked Re: CQ Marathon query

Phil Cooper
 

Hi Jim,

 

That wasn't checked, but is now. I will see what happens now, and report back.

I had not checked that simply because I wasn't clear on the implications of doing so.

Reading it again, I can see that this may be the very thing I need.

 

73 de Phil GU0SUP

 

-----Original Message-----
From: "Jim N6VH" <N6VH@...>
Sent: Wednesday, 3 February, 2021 16:28
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query

 

On 2/3/2021 6:24 AM, Phil Cooper via groups.io wrote:

Hi Steve,

 

Yes, that's checked too....

 

73 de Phil GU0SUP

 

Phil,

Go to Settings - Alerts - Wanted CQ Marathon.

Check "Auto clear triggered Alert entity after logging".

See attached picture.

 


locked Re: CQ Marathon query

Phil Cooper
 

Hi Patrick,

 

What alerted me was that it was the same station on two different bands that triggered the same alert.

That was what made me query it in the first place.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Patrick Hung" <pathung@...>
Sent: Wednesday, 3 February, 2021 16:25
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query

A possible answer - CQ Marathon counts both DX and CQ Zones (each combination counts once), so if a station in the same country but different CQ Zone appears, the alert is triggered.
--
73,

Patrick - W6AJR


locked Re: CQ Marathon query

Phil Cooper
 

Hi Dave,

 

Yes, everything is up to date.

 

73 de Phil GU0SUP

 

 

-----Original Message-----
From: "Dave Cole" <dave@...>
Sent: Wednesday, 3 February, 2021 15:00
To: Support@HamApps.groups.io
Subject: Re: [HamApps] CQ Marathon query

Wow... I am at a loss as well... Try reinstalling, I am assuming you
are at the latest version?

73, and thanks,
Dave (NK7Z)
https://www.nk7z.net
ARRL Volunteer Examiner
ARRL Technical Specialist, RFI
ARRL Asst. Director, NW Division, Technical Resources

On 2/3/21 6:24 AM, Phil Cooper via groups.io wrote:
> Hi Steve,
>
> Yes, that's checked too....
>
> 73 de Phil GU0SUP
>
> -----Original Message-----
> From: "Steve, N3SL" <n3sl@...>
> Sent: Wednesday, 3 February, 2021 14:16
> To: Support@hamapps.groups.io
> Subject: Re: [HamApps] CQ Marathon query
>
> Have you checked the "No QSL Confirmation" box - presuming you're not
> wanting/needing a confirmation?
>
> On Wed, Feb 3, 2021 at 8:07 AM Phil Cooper via groups.io
> <http://groups.io> <pcooper@...
> <mailto:suremail.gg@groups.io>> wrote:
>
> Hi Dave,
>
> That is exactly what IS set in my settings under CQ Marathon, but I
> am still seeing the same country being alerted on 20m when it has
> already been worked on 17m.
>
> Same goes if I work something on FT8, and change to FT4, a
> previously worked country still alerts as a wanted CQ Marathon.
>
> 73 de Phil GU0SUP
>
> -----Original Message-----
> From: "Dave Cole" <dave@... <mailto:dave@...>>
> Sent: Wednesday, 3 February, 2021 13:34
> To: Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
> Subject: Re: [HamApps] CQ Marathon query
>
> Hi,
>
> Yes! Perform the following steps:
>
> 1. Go to "Settings".
> 2. Select "Manage Settings".
> 3. Click the "+" to the left of the words "Wanted CQ Marathon", in the
> settings hierarchical list.
> 3. Click the word "Bands", directly under under "Wanted CQ Marathon".
> 4. A dialog box opens up, with many ooptions in it, under the
> "Tracking" area, select "Any Band", then additionally select "Any
> Mode",
> and save your settings, then exit.
>
> That should set you up for the Marathon...
>
> 73, and thanks,
> Dave (NK7Z)
> https://www.nk7z.net
> ARRL Volunteer Examiner
> ARRL Technical Specialist, RFI
> ARRL Asst. Director, NW Division, Technical Resources
>
> On 2/3/21 3:17 AM, Phil Cooper via groups.io <http://groups.io> wrote:
> > Hi all,
> >
> > Is there a simple way to get the CQ Marathon alerts to only work
> with
> > one country over all bands?
> >
> > To explain, if I work - say - OY1R on 20m FT8, I also get a New
> Marathon
> > alert for that call on FT4, and also on any other band/mode.
> >
> > As the CQ Marathon award only considers countries once,
> regardless of
> > band (or mode), it would be useful if JTAlert followed that.
> >
> > Maybe I am just missing something?
> >
> > 73 de Phil GU0SUP
> >
> >
>
>
>
>
>
>






locked Re: JTAlert not working??

neil_zampella
 

What do you show for your UDP interface settings?    WSJT-X v2.3.0 has new settings that you should select and use.  Here's mine:

 

 

Neil, KN3ILZ

2361 - 2380 of 35329