Date   

locked Re: WSJT-X Audio Output Reduces

Roger- AC6BW
 

FT-450D is another rig that needs some ALC, otherwise power output will drop. It needs to be at least 1/3 of full scale.


On Sat, Feb 20, 2021 at 06:33 AM, Michael Black wrote:
ALC is the canary-in-the-coal-mine -- symptomatic and not the cause.
 
Here's our paper on setting audio levels that works on every rig in existence.  Some rigs have to have ALC like Elecraft.
 
 
Mike W9MDB
 
 
On Saturday, February 20, 2021, 08:30:32 AM CST, Bill Mader <billamader@...> wrote:
 
 
It is well-documented that using ALC to control power levels frequently creates IMD and its resultant  QRM.  ALC from a transmitter to an amplifier should be set and used to prevent accidentally over-driving the amplifier.

Using a dummy load, adjust TX audio levels so that ALC just begins to show.  You'll note that this level occurs when reducing TX audio begins to reduce power output.  That point prevents unnecessary splatter (IMD) regardless of the SSB mode.

I'm looking at an FT8 signal on 30m as I write this that is twice as broad as it should be and I'll bet the op's ALC is way too high.  Listen to 20m and you'll find all kinds of signals with over-driven ALC, many of them created by the ALC Voltage creating distortion in the amplifier to add to the distortion created in the rig.
--
73, Bill, K8TE

 
--
73,
Roger
AC6BW


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Dave
 

I updated all the call sign databases in log4om.
On 20m FT8 I clicked on DL/OK3RIC and pressed the JTDX Log QSO button to manually log the call. It was logged as Germany in Log4om. I then worked, W2/JR1AQN and it was automatically logged as JAPAN not USA.

I went through and looked at a few settings.
In JTAlert under Web Services; I do not have xml for QRZ or HAMQTH enabled. In Log4om 'Info providers' I do have QRZ xml (primary) set & HAMQTH (secondary) set; I have disabled HAMQTH.
In JTDX; File, settings, near the top of page; there is a setting for Compound callsigns; 'Message generation for type 2 compound callsign holders'. Mine was set for 'Full call in TX3'. I changed it to 'Full call in TX5 only'. I have no idea if this is the issue or not, there are few compound callsigns on FT8 right now.
I will try and work as many compound calls and see what happens.

Thanks so much for all the responses,
Dave
k4em


locked Re: WSJT-X Audio Output Reduces

Michael Black
 

ALC is the canary-in-the-coal-mine -- symptomatic and not the cause.

Here's our paper on setting audio levels that works on every rig in existence.  Some rigs have to have ALC like Elecraft.


Mike W9MDB


On Saturday, February 20, 2021, 08:30:32 AM CST, Bill Mader <billamader@...> wrote:


It is well-documented that using ALC to control power levels frequently creates IMD and its resultant  QRM.  ALC from a transmitter to an amplifier should be set and used to prevent accidentally over-driving the amplifier.

Using a dummy load, adjust TX audio levels so that ALC just begins to show.  You'll note that this level occurs when reducing TX audio begins to reduce power output.  That point prevents unnecessary splatter (IMD) regardless of the SSB mode.

I'm looking at an FT8 signal on 30m as I write this that is twice as broad as it should be and I'll bet the op's ALC is way too high.  Listen to 20m and you'll find all kinds of signals with over-driven ALC, many of them created by the ALC Voltage creating distortion in the amplifier to add to the distortion created in the rig.
--
73, Bill, K8TE


locked Re: WSJT-X Audio Output Reduces

Bill Mader
 

It is well-documented that using ALC to control power levels frequently creates IMD and its resultant  QRM.  ALC from a transmitter to an amplifier should be set and used to prevent accidentally over-driving the amplifier.

Using a dummy load, adjust TX audio levels so that ALC just begins to show.  You'll note that this level occurs when reducing TX audio begins to reduce power output.  That point prevents unnecessary splatter (IMD) regardless of the SSB mode.

I'm looking at an FT8 signal on 30m as I write this that is twice as broad as it should be and I'll bet the op's ALC is way too high.  Listen to 20m and you'll find all kinds of signals with over-driven ALC, many of them created by the ALC Voltage creating distortion in the amplifier to add to the distortion created in the rig.
--
73, Bill, K8TE


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Michael Black
 

What would make more sense to me is a warning dialog that says callsign not found and perhaps a QRZ link to the root callsign in that case.

Mike W9MDB




On Saturday, February 20, 2021, 07:28:41 AM CST, Dave Garber <ve3wej@...> wrote:


I have seen many calls logging as the home operators call.   it seems that the home call is all that qrz knows, the dx call should have been added as a new call, seperate from his home call, with the correct country selected.  if you have jtdx or jtalert using qrz, or maybe the others too, then log4om logs what is sent via udp from jtalert

garbage in garbage out..

I always try to check before logs are uploaded to eqsl or lotw, and especially log4om, so country counts become correct

Dave Garber
VE3WEJ / VE3IE


On Fri, Feb 19, 2021 at 7:39 AM Dave <k4em@...> wrote:
I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.

Thanks,
Dave
k4em


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Dave Garber
 

I have seen many calls logging as the home operators call.   it seems that the home call is all that qrz knows, the dx call should have been added as a new call, seperate from his home call, with the correct country selected.  if you have jtdx or jtalert using qrz, or maybe the others too, then log4om logs what is sent via udp from jtalert

garbage in garbage out..

I always try to check before logs are uploaded to eqsl or lotw, and especially log4om, so country counts become correct

Dave Garber
VE3WEJ / VE3IE


On Fri, Feb 19, 2021 at 7:39 AM Dave <k4em@...> wrote:
I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.

Thanks,
Dave
k4em


locked Re: WSJT-X Audio Output Reduces

Fred Roberts
 

Mark,
     What is the ALC level of the audio? Are you using an amp, and if so, is the ALC line connected?
Fred
WB4QOC



Sent from my phone.....Fred


On Fri, Feb 19, 2021, 12:34 AM Mark via groups.io <m.weiss=yahoo.com@groups.io> wrote:

My WSJT-X audio level starts out at the desired level, but it declines substantially during the 15 second cycle.  That, of course, reduces the RF power out of the transceiver.

 

Does anyone also have that experience?  If so, what is the fix?

 

Tnx & 73,

 

Mark, K6FG


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Joe Subich, W4TV
 

JTAlert is certainly changing the "country" as a result of the XML
lookup. The country is correct without XML lookup:
<za-in3pph-za.jpg>
but is incorrect when XML lookup is enabled via HamQTH:
<za-in3pph-i.jpg>

1) I do not display log fields as I am severely "screen constrained."
At the very least, those fields should be displayed in the pop-up
prior to logging particularly if the XML results do not agree with
the callsign.

2) It seems to me that the results of the XML lookup *SHOULD NOT*
change the Country (DXCC/ADIF ID) reported to a logging program
as that would be determined entirely *BY THE CALLSIGN* (presumably
with the assistance of a reference like AD1C's CTY list) except
for the (rare) ambiguous prefix like FO, TO, 3D2, GB, etc. that
might not appear in the reference.

73,

... Joe, W4TV

On 2021-02-19 3:17 PM, HamApps Support (VK3AMA) wrote:
On 20/02/2021 6:38 am, Joe Subich, W4TV wrote:
2) both ZA/IN3PPH and KP2/NK4DX return *HOME ADDRESS* when
   Ham QTH is used for the lookup.
3) JT Alert apparently parses the XML lookup for country rather
   that the callsign thus the TCP "log" directive to DXKeeper
   (DXLab Suite) contains the country of the home address, not
   the country indicated by the (compound) callsign used for the
   QSO.
Wrong!
JTAlert *DOES NOT* parse any sort of address returned from an XML lookup to determine correct dxcc. It never has and never will. It uses the unambiguous dxcc field returned in the XML lookup.
JTAlert correctly identifies both ZA/IN3PPH and KP2/NK4DX as Albania and VI respectively prior to an XML lookup. The XML lookups for both returned correct dxcc.
eg both these images after the XML lookup (note the filling in of the name & qth & 6 char grid indicating these values came from an external source)
The XML results (from QRZ) both correctly identify the correct DXCC...
<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>KP2/NK4DX</call>
*<dxcc>285</dxcc>*
<attn>EZ PRADO SR.</attn>
<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>ZA/IN3PPH</call>
*<dxcc>7</dxcc>*
<fname>Sandro</fname>
If you free XML service is known to produce incorrect results than you as the operator should take extra care that data is correct before logging. The Log Fields area of JTAlert allows for user modification and any changes made will be reflected in the logged QSO.
de Laurie VK3AMA


locked Changes to XML lookups in next JTAlert release.

HamApps Support (VK3AMA)
 

FYI,

The next release of JTAlert includes changes to how XML results are used.
When an XML lookup is performed (triggered by a change in WSJT-X DXCall) if the results returned from the XML lookup are for a
Callsign different than the Callsign sent in the original lookup request, the lookup results are ignored and not used.

This is being done due to the HamQTH XML service routinely returning incorrect results for compound callsigns.
As recently discussed, for callsigns like  ZA/IN3PPH and KP2/NK4DX HamQTH is returning xml data for the base callsign only not the compound callsign, eg.IN3PPH and NK4DX respectively, which are for the wrong DXCC (and zones and grids, etc).

With the next version of JTAlert if the Callsign returned in the xml data does not match the original request callsign exactly, the xml data is discarded and ignored. This is not restricted to HamQTH only, it also applies to the QRZ (any any future supported service).

BTW, for the two specific callsign mentioned, the QRZ XML service returned correct data for those callsigns.

de Laurie VK3AMA
 


locked Re: AutoIT Error

Laurie, VK3AMA
 


On 20/02/2021 7:05 am, ke4s via groups.io wrote:
Laurie,
Consistently, shortly after starting JTAlert and WSJT-X, I get the AutoIT Error message shown here:


Suggestions, please!

Dave KE4S
_._,_._,_



Dave,

Since JTAlert doesn't crash immediately after starting and that you can open the About window suggests that it is the incoming decodes from WSJT-X that is the trigger.

How many Callsign display lines do you have set in JTAlert?
Try turning off WSJT-X monitor, starting JTAlert then changing the number of Callsign lines to a different value, wait for JTAlert to redraw itself then set the number of lines back to the original. Do that still experience the error once you enable WSJT-X monitor after making the Callsign Lines changes?

Please start JTAlert with WSJT-X monitor turned off (to prevent receiving decodes) then use the "Help" -> "Contact Support" menu, on the main JTAlert window, to send me your JTAlert files for analysis.

de Laurie VK3AMA




locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Jim N6VH
 


On 2/19/2021 12:32 PM, HamApps Support (VK3AMA) wrote:
On 20/02/2021 3:22 am, Jim N6VH wrote:

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH


Jim,

I get the same correct results in my tests.

The fault lies in using the free HamQTH XML service returning incorrect results. The QRZ xml service returns the correct results.

de Laurie VK3AMA

_

Laurie,

Yes, very true. The chance of incorrect data is the main reason I don't normally use lookups. I prefer to trust the data sent from JTAlert.

73,

Jim N6VH

._,_._,_


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

HamApps Support (VK3AMA)
 

On 20/02/2021 3:22 am, Jim N6VH wrote:

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH


Jim,

I get the same correct results in my tests.

The fault lies in using the free HamQTH XML service returning incorrect results. The QRZ xml service returns the correct results.

de Laurie VK3AMA


locked AutoIT Error

ke4s@...
 

Laurie,
Consistently, shortly after starting JTAlert and WSJT-X, I get the AutoIT Error message shown here:


When I ack the error message, JTAert terminates.  If I take no action, JTAlert terminates.  The line number shown in the message is consistent - it does not change.  This error started appearing followiing a rebuild of my system due to hard dixk crash, but I have not been able to identify or correct the problem.  It is identical for WSJT-X 2.2.2 and 2.3.0, also for JTAlert version 2.16.17 and its predecessor.
The JTAlert About panel gives me the following information:
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   :
WSJT-X   --rig-name   :
WSJT-X Config File    : C:\Users\dave_\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              : 2237
WSJT-X UDP Server            : 127.0.0.1
WSJT-X UDP MCast on Loopback : True
WSJT-X UDP Max Schema        :

==================================================
UDP Ports used
--------------------------------------------------
JTAlert.exe           : 55896 65319
JTAlertV2.Manager.exe : 63263 63264
JTAlertV2.Decodes.exe :


==================================================
Audio output devices
--------------------------------------------------
[1] Speakers (2- USB Sound Device        )
[2] Speakers (2- High Definition Audio Device)


==================================================
JTAlertV2.Manager (2.16.17.0) status
(2021-02-19 20:01:20 utc)
--------------------------------------------------
NET Framework    : .NET Framework 4.8.4300.0
CLR Version      : 4.0.30319.42000
--------------------------------------------------
UDP Router       : Initialized : YES (WSJT-X)
Audio            : Initialized : YES (2 output devices)
BandData         : Initialized : YES (started : 58)
Text Msgs        : Initialized : YES (started : 17)
HamSpots         : Initialized : YES
QRZ Xml          : Initialized : YES (KE4S)
HamQth Xml       : Initialized : YES
QRZ Log          : Initialized : YES
HamQth Log       : Initialized : YES
ClubLog Log      : Initialized : YES
Eqsl Log         : Initialized : YES
HrdLog Log       : Initialized : YES
DXLab DDE        : Initialized : YES
User Alert       : Initialized : YES
Updates Chk      : Initialized : YES
Maintenance      : Initialized : YES

Suggestions, please!

Dave KE4S


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

HamApps Support (VK3AMA)
 

On 20/02/2021 6:38 am, Joe Subich, W4TV wrote:
(apparently because JTAlert
relies on the XML rather than parse the call directly and DXKeeper
uses the ADIF number supplied in the "Log" directive from JTAlert).

JTAlert does parse the Callsign to determine country of origin and if an XML lookup returns a result it will use that data from that. With the large number of special event callsigns that abound plus lid operators who use the incorrect prefix/suffix parsing of the Callsign alone can be problematic. JTAlert assumes that the XML data is correct as it will any previous QSOs in the log.

de Laurie VK3AMA


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

HamApps Support (VK3AMA)
 

On 20/02/2021 6:38 am, Joe Subich, W4TV wrote:
2) both ZA/IN3PPH and KP2/NK4DX return *HOME ADDRESS* when
   Ham QTH is used for the lookup.
3) JT Alert apparently parses the XML lookup for country rather
   that the callsign thus the TCP "log" directive to DXKeeper
   (DXLab Suite) contains the country of the home address, not
   the country indicated by the (compound) callsign used for the
   QSO.

Wrong!

JTAlert DOES NOT parse any sort of address returned from an XML lookup to determine correct dxcc. It never has and never will. It uses the unambiguous dxcc field returned in the XML lookup.

JTAlert correctly identifies both ZA/IN3PPH and KP2/NK4DX as Albania and VI respectively prior to an XML lookup. The XML lookups for both returned correct dxcc.
eg both these images after the XML lookup (note the filling in of the name & qth & 6 char grid indicating these values came from an external source)





The XML results (from QRZ) both correctly identify the correct DXCC...
<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>KP2/NK4DX</call>
<dxcc>285</dxcc>
<attn>EZ PRADO SR.</attn>

<?xml version="1.0" encoding="utf-8" ?>
<QRZDatabase version="1.34" xmlns="http://xmldata.qrz.com">
<Callsign>
<call>ZA/IN3PPH</call>
<dxcc>7</dxcc>
<fname>Sandro</fname>

If you free XML service is known to produce incorrect results than you as the operator should take extra care that data is correct before logging. The Log Fields area of JTAlert allows for user modification and any changes made will be reflected in the logged QSO.

de Laurie VK3AMA


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Joe Subich, W4TV
 

On 2021-02-19 9:53 AM, Michael Black via groups.io wrote:
JTAlert gets it correct too. This would be a successful QRZ lookup.
OK, I've gotten to the bottom of this. The issue is JTAlert ...

1) I'm using the free "Ham QTH" XML lookup in JTAlert
2) both ZA/IN3PPH and KP2/NK4DX return *HOME ADDRESS* when
Ham QTH is used for the lookup.
3) JT Alert apparently parses the XML lookup for country rather
that the callsign thus the TCP "log" directive to DXKeeper
(DXLab Suite) contains the country of the home address, not
the country indicated by the (compound) callsign used for the
QSO.

If I were willing to pay for QRZcom's XML service, things might
be different but I have no way of testing that thesis. However,
both ZA/IN3PPH and KP2/NK4DX are logged with an incorrect (home)
country when using the HamQTH XML lookup (apparently because JTAlert
relies on the XML rather than parse the call directly and DXKeeper
uses the ADIF number supplied in the "Log" directive from JTAlert).

73,

... Joe, W4TV


On 2021-02-19 9:53 AM, Michael Black via groups.io wrote:
JTAlert gets it correct too.  This would be a successful QRZ lookup.
Mike W9MDB
Inline image
On Friday, February 19, 2021, 08:49:37 AM CST, OM Marlon via groups.io <du3cwm=yahoo.ca@groups.io> wrote:
Hi Joe,
Log4OM sees this as Albania here,I supposed it will be logged that way once we have a QSO
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Joe Subich, W4TV <mailto:lists@subich.com>
*Sent: *Friday, 19 February 2021 10:03 pm
*To: *Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
*Subject: *Re: [HamApps] Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om
In my case ZA/IN3PPH logged as ITALY.  There were no previous
QSOs with either ZA/IN3PPH, IN3PPH or */IN3PPH.
73,
    ... Joe, W4TV
On 2021-02-19 8:55 AM, Michael Black via groups.io wrote:

> Check your log for a previous QSO where it's logged as U.S.

>

> Mike W9MDB

>

>

>

>

> On Friday, February 19, 2021, 07:42:48 AM CST, Joe Subich, W4TV

> <lists@subich.com> wrote:

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx

>  > that I just worked. Log4om logs it as United States instead of US

>  > Virgin Islands.

> I think I can remove Log4OM and JTDX from the issue.  I saw the same

> incorrect entity when logging ZA/IN3PPH from WSJTX 2.4.0-rc1 to

> DXKeeper (DXLab Suite) via JT-Alert.

>

> 73,

>

>      ... Joe, W4TV

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1
month ago

>  > and have Log4om configured to receive logging info from JTAlert. When

>  > Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I

>  > just worked. Log4om logs it as United States instead of US Virgin

>  > Islands. It does this on all compound calls worked. It only
started this

>  > after I configured JTDX & JTAlert. I had no issue with WSJT-X &
JTAlert,

>  > Log4om.

>  > So I'm not sure where the issue might be. I looked over all 3 apps and

>  > saw nothing that I could change.

>  >

>  > Thanks,

>  > Dave

>  > k4em


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Joe Subich, W4TV
 

On 2021-02-19 9:49 AM, OM Marlon via groups.io wrote:

Log4OM sees this as Albania here,I supposed it will be logged that way
once we have a QSO
DXKeeper (DXLab Suite) also sees ZA/IN3PPH as Albania if I enter it
directly. However, it logged as Italy when worked in WSJTX 3.4.0
and logged by JTAlert 2.16.17.

73,

... Joe, W4TV


On 2021-02-19 9:49 AM, OM Marlon via groups.io wrote:
Hi Joe,
Log4OM sees this as Albania here,I supposed it will be logged that way once we have a QSO
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Joe Subich, W4TV <mailto:lists@subich.com>
*Sent: *Friday, 19 February 2021 10:03 pm
*To: *Support@HamApps.groups.io <mailto:Support@HamApps.groups.io>
*Subject: *Re: [HamApps] Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om
In my case ZA/IN3PPH logged as ITALY.  There were no previous
QSOs with either ZA/IN3PPH, IN3PPH or */IN3PPH.
73,
    ... Joe, W4TV
On 2021-02-19 8:55 AM, Michael Black via groups.io wrote:

> Check your log for a previous QSO where it's logged as U.S.

>

> Mike W9MDB

>

>

>

>

> On Friday, February 19, 2021, 07:42:48 AM CST, Joe Subich, W4TV

> <lists@subich.com> wrote:

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx

>  > that I just worked. Log4om logs it as United States instead of US

>  > Virgin Islands.

> I think I can remove Log4OM and JTDX from the issue.  I saw the same

> incorrect entity when logging ZA/IN3PPH from WSJTX 2.4.0-rc1 to

> DXKeeper (DXLab Suite) via JT-Alert.

>

> 73,

>

>      ... Joe, W4TV

>

>

> On 2021-02-19 6:52 AM, Dave wrote:

>  > I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1
month ago

>  > and have Log4om configured to receive logging info from JTAlert. When

>  > Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I

>  > just worked. Log4om logs it as United States instead of US Virgin

>  > Islands. It does this on all compound calls worked. It only
started this

>  > after I configured JTDX & JTAlert. I had no issue with WSJT-X &
JTAlert,

>  > Log4om.

>  > So I'm not sure where the issue might be. I looked over all 3 apps and

>  > saw nothing that I could change.

>  >

>  > Thanks,

>  > Dave

>  > k4em


locked Re: WSJT-X Audio Output Reduces

Michael Black
 

If it's ALC it would more likely be that audio level is too high and the ALC starts reducing it slowly.

Mike W9MDB




On Friday, February 19, 2021, 10:56:52 AM CST, Roger M via groups.io <ac6bw@...> wrote:


Maybe your rig's ALC is set right on the hairy edge, where it starts to drop power. Try increasing the audio level just a little, to increase ALC a bit.
--
73,
Roger
AC6BW


locked Re: WSJT-X Audio Output Reduces

Roger- AC6BW
 

Maybe your rig's ALC is set right on the hairy edge, where it starts to drop power. Try increasing the audio level just a little, to increase ALC a bit.
--
73,
Roger
AC6BW


locked Re: Not logging compound call signs in Log4om. using JTDX, JTalert, Log4om

Jim N6VH
 


On 2/19/2021 3:52 AM, Dave wrote:
I am using JTDX, JTAlert & Log4OM. I switched to JTDX about 1 month ago and have Log4om configured to receive logging info from JTAlert. When Log4om receives QSO info from a compound callsign ex: kp2/nk4dx that I just worked. Log4om logs it as United States instead of US Virgin Islands. It does this on all compound calls worked. It only started this after I configured JTDX & JTAlert. I had no issue with WSJT-X & JTAlert, Log4om.
So I'm not sure where the issue might be. I looked over all 3 apps and saw nothing that I could change.

Thanks,
Dave
k4em
_._,_._,_


Dave,

I did a test log to Log4OM using WSJT-X 2.3.0  and JTAlert 2,16.17, and kp2/nk4dx logged correctly as US Virgin Islands. I then deleted that QSO from Log4OM and did the same test, except I used JTDX 2.2.0-rc153, with the same results. Both times the QSO loged correctly.

73,

Jim N6VH

3221 - 3240 of 36363