Date   

locked Re: New Windows 10 update and audio selection

Joe Dz
 

I mainly run Ubuntu Linux and my TS590SG, but my backup rig is my older IC746PRO, RIGblaster, and everything works just fine using the latest version of Windows 10.  I am glad the USB cable reinstalled fixed the problems.

 

One side note:  the last Microsoft Edge update messed-up saving files from a PDF window (like saving a PDF of a cancelled bank check).  Always something.  LOL.  To save a PDF file from a PDF window image, you now have to use the print function, then select PDF, and it will save a PDF file.  I guess they want to keep us on our toes.  LOL.

 

73

Joe

K1YOW

 


From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Wanda
Sent: Sunday, June 21, 2020 12:12 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] New Windows 10 update and audio selection

 

FIXED:  I uninstalled the USB Audio Codec, disconnected the USB and then reconnected.  Now working.  You guys have me nervous to install the 2004 Windows 10 update.  Maybe after Field Day.  Thanks.  KK4EGZ 


locked N1MM WSJT-X for Field Day

Rick Ellison
 

 

I was able to duplicate the issue with FT4 mode not dupe checking correctly. I have corrected the issue and it will be in the next build before Field Day.

This only effected FT4 mode.

 

73 Rick N2AMG




Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com



locked Re: Replying to CQ, etc.

Jim Shorney
 

Pet peeves are bad for your health. I have a pet cat. Her name is Sally. She frequently makes me laugh.

I also try not to have high expectations. That way I am more often pleasantly surprised.

Life rule #1: Don't sweat the small stuff.

Life rule #2: It's ALL small stuff.

Have a nice day.

73

-Jim
NU0C


On Sun, 21 Jun 2020 12:04:41 -0400
careyfisher@... wrote:

Wow, you sure have a lot of pet peeves! Do you have a list of rules people
should use when contacting you?

On Sun, Jun 21, 2020 at 11:29 AM K8BL BOB LIDDY <k8bl@...> wrote:

Group,

1- It irritates me when someone answers WITHOUT their Grid. So, I then
have to look it up before I log them. Otherwise, the WSJT notification
is defeated that is intended to show a "New Grid". (Yes, I know that
the complex Calls don't show Grids now due to length, etc.)

2 - Another pet peeve is when someone calls while also calling another
Station(s) at the same time. They hop back and forth between us and
it gets chaotic seeing my Call, their Call, some other Calls, etc.
until
we finally complete OUR QSO, if at all, minutes later.

3 - Last pet peeve (for now) is having my CQ answered by a Station on
"my" frequency and having them STAY there and start their own CQ.
(Yes, I know we're on opposite time slots, but it just seems very
rude.)
Meanwhile, there might be someone trying to call ME on that time slot
and will have to fight it out with the group of us!! (Spread out,
please.)

BTW... Happy Fathers' Day to all you OM's.

73, Bob K8BL


On Sunday, June 21, 2020, 08:16:33 AM EDT, Bill Somerville <
g4wjs@...> wrote:


On 21/06/2020 13:10, groups@... wrote:

I had a couple of stations reply to my CQ with Tx 3 last night. Tx 2 is
bad enough but Tx 3 seems bizarre to me.

Does anyone have any idea what they were expecting of me or the reasoning
behind this?

73

Roger
G4HZA

Hi Roger,

that makes no sense. The 'R' is an acknowledgement of receipt of a signal
report. Unless you had a recent partial QSO with them where you did get as
far as sending a signal report to them, you can only respond with an
R+report message and hope that they reply with 'RRR' or 'RR73'.

73
Bill
G4WJS.


locked Re: Disable TX After 73

VE3KTN
 

I just did another test to change TX4 from RR73 to RRR and find in that case, the TX will remain enabled and stick on TX4 until receiving the final "73" as TX5 from the remote.  After receiving that 73, the autosequencer will inhibit TX and drop down to TX6.

If TX4 is "RR73", then the autosequencer immediately disables TX and messaging drops down to TX6 without waiting for the remote to send his TX5.  This action is independent of the "Disable TX after sending 73" setting.

So, the way the "Disable after sending 73" logic works for ft8, and presumably for ft4, in V2.2.1 is dependent on the text contained in TX4 and the "Disable ..." setting.  If you want the autosequencer to hold off inhibiting TX until receiving TX5 from the remote, then set TX4 to <remotecall><mycall>RRR.  If you don't want to wait for that final 73 from the remote, set TX4 to <remotecall><mycall>RR73.

It's too bad the logic is set up to detect the "73" string instead of just whether TX4 is being sent, as I've pointed out in a similar parallel thread on this forum.  This way, I can't send my 73 and hold off the TX inhibit to wait for the return 73 - I (and the remote) will have to be satisfied with an RRR.

With respect to comments that the developers didn't want to make wsjtx more robotic, I understand and support that concept.  However, the autosequencer is rather robotic in that it automates the TX messaging all the way; it only stops after reaching TX 4 or 5 depending on the CQ origination - something akin to the difference between full and semi-auto.   The issue being discussed in this thread is to gain a better understand of exactly how the autosequencer behaves when reaching TX4.  Hopefully the above discussion provides clarification, even though it's a tad unfortunate that it's dependence is on the text of TX4, but that's just my opinion.

Hugo, ve3ktn.



locked Re: New Windows 10 update and audio selection

Wanda
 

FIXED:  I uninstalled the USB Audio Codec, disconnected the USB and then reconnected.  Now working.  You guys have me nervous to install the 2004 Windows 10 update.  Maybe after Field Day.  Thanks.  KK4EGZ 


locked Re: Replying to CQ, etc.

careyfisher@...
 

Wow, you sure have a lot of pet peeves! Do you have a list of rules people should use when contacting you?

On Sun, Jun 21, 2020 at 11:29 AM K8BL BOB LIDDY <k8bl@...> wrote:
Group,

1- It irritates me when someone answers WITHOUT their Grid. So, I then
     have to look it up before I log them. Otherwise, the WSJT notification
     is defeated that is intended to show a "New Grid". (Yes, I know that
     the complex Calls don't show Grids now due to length, etc.)

2 - Another pet peeve is when someone calls while also calling another
     Station(s) at the same time. They hop back and forth between us and
     it gets chaotic seeing my Call, their Call, some other Calls, etc. until
     we finally complete OUR QSO, if at all, minutes later.

3 - Last pet peeve (for now) is having my CQ answered by a Station on
     "my" frequency and having them STAY there and start their own CQ.
    (Yes, I know we're on opposite time slots, but it just seems very rude.)
    Meanwhile, there might be someone trying to call ME on that time slot
    and will have to fight it out with the group of us!! (Spread out, please.)

BTW... Happy Fathers' Day to all you OM's.

73,  Bob  K8BL
 

On Sunday, June 21, 2020, 08:16:33 AM EDT, Bill Somerville <g4wjs@...> wrote:


On 21/06/2020 13:10, groups@... wrote:
I had a couple of stations reply to my CQ with Tx 3 last night.  Tx 2 is bad enough but Tx 3 seems bizarre to me.

Does anyone have any idea what they were expecting of me or the reasoning behind this?

73

Roger
G4HZA

Hi Roger,

that makes no sense. The 'R' is an acknowledgement of receipt of a signal report. Unless you had a recent partial QSO with them where you did get as far as sending a signal report to them, you can only respond with an R+report message and hope that they reply with 'RRR' or 'RR73'.

73
Bill
G4WJS.




--
Carey Fisher


--
73, Carey, WB4HXE


locked Possible log bug

Bengt SM6MUY
 

Hi

Got a strange logging error with the start time of a QSO.

We definitely  didn't start the QSO at 12:45

I did a look in All.txt and AB4IQ answered my CQ at 13:16.

Using WSJT-x 2.2.0, Raspberry version.

73/Bengt, SM6MUY



locked Re: WSJT-X V2.2.1 CAT Test Fails for TS440s

Bill Somerville
 

John,

that's Microsoft's fault with their funky URL scheme. Try this:


You will have to navigate to the right page from there. Open "Error Handling Reference" on the left-hand sidebar menu, then open "System Error Codes" under that. Select "System Error Codes (0-499)" and you will be there.

73
Bill
G4WJS.

On 21/06/2020 16:08, JP Tucson, AZ wrote:
Bill,

Ironically funny  : )

Clicked on the link for the code 31 error...  got a 404 page not found error.

Thanks for the info.






73 - John - N7GHZ




On Sun, Jun 21, 2020, 7:38 AM Bill Somerville <g4wjs@...> wrote:
John,

I will only persist with helping users with queries if they believe what I am saying, your attitude was generally to tell me that I was wrong and you were right. The error message reported was this:
Hamlib: tcsetattr:SetCommState: Serial error 31: A device attached to the system is not functioning.
SetCommState is a Microsoft Windows function used to do various things with serial ports including setting the RTS or DTR pins on or off, as used by Hamlib for PTT. You can look at the documentation for that function here:


You will find error 31 documented here:


The error was not happening every time the function was called, it seemed to be intermittent, which is probably a plausible explanation for your assertion that it is working OK now.

73
Bill
G4WJS.

On 21/06/2020 15:02, JP Tucson, AZ wrote:
Bill, 

Ok, you said that, but you never responded when I asked for the specific errors you saw - a printout would be nice.

Which is curious, as I see absolutely nothing in the way of problems now; while using v2.2.0.

And as I stated before, over & over, I have NOT EVER had a bit of problem with N1MM, which does not rely on Hamlib, using my CAT interface cable.  [But hey, if you want to dig into your wallet & acquire a different cable & send to me, we can compare those as well!  I simply don't have $ to keep spending needlessly, when I have a working solution].

No sir, after the folks over at Hamlib did whatever they did, and after you guys went from 2.1.2 and rc1 - to rc2, the rc2 & versions since have worked fine.

After field day, (because I ain't gonna take a chance to mess with the present setup), if you want to send a new instrumented version of v2.2.0 I will run that so you can compare.

Last point, the "offering [of] settings configuration advice" is exactly the same advice you sent me! So I am confused as to why I am getting static tor repeating that same advice...


73 - John - N7GHZ




On Sun, Jun 21, 2020, 6:39 AM Bill Somerville <g4wjs@...> wrote:
John,

as I explained at the time, your CAT issues with your TS-440s were due to device driver errors from you USB to serial device built into your CAT interface lead. You should not be offering settings configuration advice based on your experiences with faulty hardware.

73
Bill
G4WJS.

On 21/06/2020 14:35, JP Tucson, AZ wrote:
Joe,

Do you operate a TS-440S?



73 - John - N7GHZ

On Sun, Jun 21, 2020, 6:27 AM Joe Subich, W4TV <lists@...> wrote:


> Note, this all works fine on V2.2.1 if I use DXLabs Commander to
> control the TS440s
What are your *exact* Ports settings for the TS-440S in Commander?

In general, unless your CAT interface holds the RTS pin high or the
CAT connector has a jumper between the CTS and RTS pin, all Kenwood
transceivers require handshake from the computer.  For WSJTX that
would be HANDSHAKE = HARDWARE or HANDSHAKE = DEFAULT.  Once the
RTS (and CTS) line is used for handshake,  it can not be used for
PTT!

I suggest you try HANDSAHKE= DEFAULT and PTT= CAT.

If you need hardware PTT (e.g. for activating audio from the
ACC2 connection), you will need to add a second serial port or
USB to serial adapter or use the "VOX" PTT from your MFJ.

73,

    ... Joe, W4TV


On 2020-06-21 8:51 AM, Glenn Van Benschoten wrote:
> Thanks for the reply John,
>
>   
>
> Interesting, you had Hamlib problems on V2.1.0 and not on V2.2.1 – I’m just the opposite.
>
> I tried the config changes you suggested, same Hamlib timeout error, even after restarting WSJT-X.
>
>   
>
> I’m using MFJ-1204 for audio (which should be neither here nor there for CAT purposes) and the CAT connection between the TS440 and my laptop is a USB Serial cable with FDDI chipset.
>
>   
>
> Note, this all works fine on V2.2.1 if I use DXLabs Commander to control the TS440s but trying to have WSJT-X control the radio isn’t working. In case you wonder why not just let Commander run it - I need DXLabs Commander to control my IC746 – can’t have 2 simultaneous primary radios under Commander.
>
>   
>
> Glenn Van Benschoten
>
> gtvanben@...
>
>   
>
> From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of JP Tucson, AZ
> Sent: Saturday, June 20, 2020 10:37 PM
> To: main@wsjtx.groups.io
> Subject: Re: [WSJTX] WSJT-X V2.2.1 CAT Test Fails for TS440s
>
>   
>
> Hi Glenn,
>
>   
>
> I have a TS-440S as well and ran into major issues too! I run a signalink for audio, & separate usb for CAT control.
>
>   
>
> Ok, first, you need to upgrade that old version to ver. 2.2.0. or 2.2.1. as they did some work in Hamlib & now it seems to work.
>
>   
>
> Set the radio settings handshake to none, not default.
>
>   
>
> Set PTT to CAT (not rts) & Split to none.
>
>   
>
> You didn't specify how exactly you are connecting for CAT or audio. Could you specify what kind of cat cable you are running.
>
>   
>
>   
>
> Hope this helps!
>
>   
>
>   
>
> 73 - John - N7GHZ
>
>   
>
> On Sat, Jun 20, 2020, 6:18 PM Glenn Van Benschoten <gtvanben@...> wrote:
>
> I’ve been struggling to get my Kenwood TS440s set up with WSJT-X V2.2.1, keep getting all kinds of Hamlib errors depending on what I changed.
>
>   
>
> Then I recalled that there were some issues posted about Hamlib errors with various rigs on V2.2.1 and so since I had the prior version 2.1.0 running on a different laptop I tried configuring/testing there. I was able to successfully connect and then CAT control the radio (band changes, etc). So something broke between V2.1.0 and V2.2.1
>
>   
>
> Here is the config that works on V2.1.0
>
> cid:image001.png@...
>
>   
>
> Is this a known problem and is there a plan to fix?
>
>   
>
> In the meantime, I can run the TS440s with the Radio set to “None”, but then I lose the CAT control stuff and have to switch bands manually, etc. Switching bands in itself is a pain in that if you change the band via the radio (which you have to do with no CAT control) and you forget to also change the band in WSJT-X you wind up logging contacts for the wrong band.
>
>   
>
> Please advise, thanks
>
>   
>
> N0VB
>
> Glenn Van Benschoten



locked Re: #audio_issues #microphone #AudioIssues

Bill Somerville
 

On 21/06/2020 16:43, Gregory Reichenbach wrote:
Bill: Agreed that "the built in mic should be disabled when you plug in something to the line in, or combined line in/mic socket. If your mic is live then I would check that the plug is correctly inserted."  Tried that previously; didn't work.

HOWEVER, your comment led me to testing the audio gain on the rig.  And... it turns out WSJT-X is not getting the audio signal from the cable, but from audio coupling, despite the fact that the cable is plugged in all the way.  So I think either windows or WSJT-X is not recognizing the audio from the cable at all. Further suggestions?
Hi Greg,

I suspected that you were only getting Rx audio via the built in mic. You still could have a hardware issue with the line-in/mic socket, but given the coincidence with a Windows Update there has to be some suspicion it is an operating system issue. Are you on the Fast Ring windows update schedule? If not then you should contact Microsoft Support and ask why your Line-in/mic socket has stopped working after a general Windows 10 update.

73
Bill
G4WJS.


locked Re: #audio_issues #microphone #AudioIssues

Gregory Reichenbach
 

Bill: Agreed that "the built in mic should be disabled when you plug in something to the line in, or combined line in/mic socket. If your mic is live then I would check that the plug is correctly inserted."  Tried that previously; didn't work.

HOWEVER, your comment led me to testing the audio gain on the rig.  And... it turns out WSJT-X is not getting the audio signal from the cable, but from audio coupling, despite the fact that the cable is plugged in all the way.  So I think either windows or WSJT-X is not recognizing the audio from the cable at all.  Further suggestions?


locked Re: #audio_issues #microphone #AudioIssues

Gregory Reichenbach
 

VE3KI: I tried that; didn't work.  There's only one "device" - no separate settings for line in or mic.

Ian: I tried that too.  Strangely, disabling the mic from device manager doesn't seem to have any effect on anything.  Windows says the mic is disabled, but WSJT-X still receives audio from the rig AND from the laptop mic.

Unless someone has something else, I think I'll try undoing the 2004 update, and then just not updating windows for a while, hoping Micro$oft straightens it out.

Thanks all,
73

Greg Reichenbach
Stony Ridge OH
W8GSR


On Sun, Jun 21, 2020 at 11:08 AM Ian Kahn <nv4c.ian@...> wrote:
You might need to go into Device Manager and completely disable the mic at the hardware level. That, of course, would disable it for all future use, until you re-enable it.

73 de,

Oan, MV4C

On Sun, Jun 21, 2020, 10:11 AM Gregory Reichenbach <gsreichenbach@...> wrote:
After updating Windows yesterday, my laptop's microphone picks up ambient audio from the room and WSJT-X hears it, mixes it with the radio's received audio, and it shows up in the waterfall and interferes with decoding.  Can't figure out how to make the laptop microphone stop without turning off the audio from the radio too.  Must be a windows setting, but can't find it.  Help please.


Greg Reichenbach
Stony Ridge OH
W8GSR



locked Re: #audio_issues #microphone #AudioIssues

Istvan Nyul
 

The link returns a “Page Not Found” on the MS webpage.

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Lars Berg
Sent: Sunday, June 21, 2020 10:59
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #audio_issues #microphone

 

Stay away from the 2004 update . See

https://answers.microsoft.com/en-us/insider/forum/all/windows-10-version-2004-audio-bug-latest/

 

73 de Lars SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Bill Somerville
Skickat: den 21 juni 2020 16:50
Till:
main@WSJTX.groups.io
Ämne: Re: [WSJTX] #audio_issues #microphone

 

On 21/06/2020 15:46, Gregory Reichenbach wrote:
> Bill, thanks very much for the reply.  Unfortunately, that's not the
> problem.  I have only one device each on the laptop for mic and
> speakers. Just in case, I tried changing the selection to "default"
> then back to the specific audio devices, but that made no difference.
> I suspect there's a windows setting somewhere that is allowing access
> to the mic.

Greg,

the built in mic should be disabled when you plug in something to the
line in, or combined line in/mic socket. If your mic is live then I
would check that the plug is correctly inserted.

73
Bill
G4WJS.

 


locked Re: #audio_issues #microphone #AudioIssues

Reino Talarmo
 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Lars Berg
Sent: 21. kesäkuuta 2020 17:59
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] #audio_issues #microphone

 

Stay away from the 2004 update . See

https://answers.microsoft.com/en-us/insider/forum/all/windows-10-version-2004-audio-bug-latest/

 

73 de Lars SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Bill Somerville
Skickat: den 21 juni 2020 16:50
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] #audio_issues #microphone

 

On 21/06/2020 15:46, Gregory Reichenbach wrote:
> Bill, thanks very much for the reply.  Unfortunately, that's not the
> problem.  I have only one device each on the laptop for mic and
> speakers. Just in case, I tried changing the selection to "default"
> then back to the specific audio devices, but that made no difference.
> I suspect there's a windows setting somewhere that is allowing access
> to the mic.

Greg,

the built in mic should be disabled when you plug in something to the
line in, or combined line in/mic socket. If your mic is live then I
would check that the plug is correctly inserted.

73
Bill
G4WJS.

 


locked Re: Replying to CQ, etc.

K8BL BOB LIDDY <k8bl@...>
 

Group,

1- It irritates me when someone answers WITHOUT their Grid. So, I then
     have to look it up before I log them. Otherwise, the WSJT notification
     is defeated that is intended to show a "New Grid". (Yes, I know that
     the complex Calls don't show Grids now due to length, etc.)

2 - Another pet peeve is when someone calls while also calling another
     Station(s) at the same time. They hop back and forth between us and
     it gets chaotic seeing my Call, their Call, some other Calls, etc. until
     we finally complete OUR QSO, if at all, minutes later.

3 - Last pet peeve (for now) is having my CQ answered by a Station on
     "my" frequency and having them STAY there and start their own CQ.
    (Yes, I know we're on opposite time slots, but it just seems very rude.)
    Meanwhile, there might be someone trying to call ME on that time slot
    and will have to fight it out with the group of us!! (Spread out, please.)

BTW... Happy Fathers' Day to all you OM's.

73,  Bob  K8BL
 

On Sunday, June 21, 2020, 08:16:33 AM EDT, Bill Somerville <g4wjs@...> wrote:


On 21/06/2020 13:10, groups@... wrote:
I had a couple of stations reply to my CQ with Tx 3 last night.  Tx 2 is bad enough but Tx 3 seems bizarre to me.

Does anyone have any idea what they were expecting of me or the reasoning behind this?

73

Roger
G4HZA

Hi Roger,

that makes no sense. The 'R' is an acknowledgement of receipt of a signal report. Unless you had a recent partial QSO with them where you did get as far as sending a signal report to them, you can only respond with an R+report message and hope that they reply with 'RRR' or 'RR73'.

73
Bill
G4WJS.


locked Re: WSJT-X V2.2.1 CAT Test Fails for TS440s

JP Tucson, AZ
 

Bill,

Ironically funny  : )

Clicked on the link for the code 31 error...  got a 404 page not found error.

Thanks for the info.






73 - John - N7GHZ




On Sun, Jun 21, 2020, 7:38 AM Bill Somerville <g4wjs@...> wrote:
John,

I will only persist with helping users with queries if they believe what I am saying, your attitude was generally to tell me that I was wrong and you were right. The error message reported was this:
Hamlib: tcsetattr:SetCommState: Serial error 31: A device attached to the system is not functioning.
SetCommState is a Microsoft Windows function used to do various things with serial ports including setting the RTS or DTR pins on or off, as used by Hamlib for PTT. You can look at the documentation for that function here:


You will find error 31 documented here:


The error was not happening every time the function was called, it seemed to be intermittent, which is probably a plausible explanation for your assertion that it is working OK now.

73
Bill
G4WJS.

On 21/06/2020 15:02, JP Tucson, AZ wrote:
Bill, 

Ok, you said that, but you never responded when I asked for the specific errors you saw - a printout would be nice.

Which is curious, as I see absolutely nothing in the way of problems now; while using v2.2.0.

And as I stated before, over & over, I have NOT EVER had a bit of problem with N1MM, which does not rely on Hamlib, using my CAT interface cable.  [But hey, if you want to dig into your wallet & acquire a different cable & send to me, we can compare those as well!  I simply don't have $ to keep spending needlessly, when I have a working solution].

No sir, after the folks over at Hamlib did whatever they did, and after you guys went from 2.1.2 and rc1 - to rc2, the rc2 & versions since have worked fine.

After field day, (because I ain't gonna take a chance to mess with the present setup), if you want to send a new instrumented version of v2.2.0 I will run that so you can compare.

Last point, the "offering [of] settings configuration advice" is exactly the same advice you sent me! So I am confused as to why I am getting static tor repeating that same advice...


73 - John - N7GHZ




On Sun, Jun 21, 2020, 6:39 AM Bill Somerville <g4wjs@...> wrote:
John,

as I explained at the time, your CAT issues with your TS-440s were due to device driver errors from you USB to serial device built into your CAT interface lead. You should not be offering settings configuration advice based on your experiences with faulty hardware.

73
Bill
G4WJS.

On 21/06/2020 14:35, JP Tucson, AZ wrote:
Joe,

Do you operate a TS-440S?



73 - John - N7GHZ

On Sun, Jun 21, 2020, 6:27 AM Joe Subich, W4TV <lists@...> wrote:


> Note, this all works fine on V2.2.1 if I use DXLabs Commander to
> control the TS440s
What are your *exact* Ports settings for the TS-440S in Commander?

In general, unless your CAT interface holds the RTS pin high or the
CAT connector has a jumper between the CTS and RTS pin, all Kenwood
transceivers require handshake from the computer.  For WSJTX that
would be HANDSHAKE = HARDWARE or HANDSHAKE = DEFAULT.  Once the
RTS (and CTS) line is used for handshake,  it can not be used for
PTT!

I suggest you try HANDSAHKE= DEFAULT and PTT= CAT.

If you need hardware PTT (e.g. for activating audio from the
ACC2 connection), you will need to add a second serial port or
USB to serial adapter or use the "VOX" PTT from your MFJ.

73,

    ... Joe, W4TV


On 2020-06-21 8:51 AM, Glenn Van Benschoten wrote:
> Thanks for the reply John,
>
>   
>
> Interesting, you had Hamlib problems on V2.1.0 and not on V2.2.1 – I’m just the opposite.
>
> I tried the config changes you suggested, same Hamlib timeout error, even after restarting WSJT-X.
>
>   
>
> I’m using MFJ-1204 for audio (which should be neither here nor there for CAT purposes) and the CAT connection between the TS440 and my laptop is a USB Serial cable with FDDI chipset.
>
>   
>
> Note, this all works fine on V2.2.1 if I use DXLabs Commander to control the TS440s but trying to have WSJT-X control the radio isn’t working. In case you wonder why not just let Commander run it - I need DXLabs Commander to control my IC746 – can’t have 2 simultaneous primary radios under Commander.
>
>   
>
> Glenn Van Benschoten
>
> gtvanben@...
>
>   
>
> From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of JP Tucson, AZ
> Sent: Saturday, June 20, 2020 10:37 PM
> To: main@wsjtx.groups.io
> Subject: Re: [WSJTX] WSJT-X V2.2.1 CAT Test Fails for TS440s
>
>   
>
> Hi Glenn,
>
>   
>
> I have a TS-440S as well and ran into major issues too! I run a signalink for audio, & separate usb for CAT control.
>
>   
>
> Ok, first, you need to upgrade that old version to ver. 2.2.0. or 2.2.1. as they did some work in Hamlib & now it seems to work.
>
>   
>
> Set the radio settings handshake to none, not default.
>
>   
>
> Set PTT to CAT (not rts) & Split to none.
>
>   
>
> You didn't specify how exactly you are connecting for CAT or audio. Could you specify what kind of cat cable you are running.
>
>   
>
>   
>
> Hope this helps!
>
>   
>
>   
>
> 73 - John - N7GHZ
>
>   
>
> On Sat, Jun 20, 2020, 6:18 PM Glenn Van Benschoten <gtvanben@...> wrote:
>
> I’ve been struggling to get my Kenwood TS440s set up with WSJT-X V2.2.1, keep getting all kinds of Hamlib errors depending on what I changed.
>
>   
>
> Then I recalled that there were some issues posted about Hamlib errors with various rigs on V2.2.1 and so since I had the prior version 2.1.0 running on a different laptop I tried configuring/testing there. I was able to successfully connect and then CAT control the radio (band changes, etc). So something broke between V2.1.0 and V2.2.1
>
>   
>
> Here is the config that works on V2.1.0
>
> cid:image001.png@...
>
>   
>
> Is this a known problem and is there a plan to fix?
>
>   
>
> In the meantime, I can run the TS440s with the Radio set to “None”, but then I lose the CAT control stuff and have to switch bands manually, etc. Switching bands in itself is a pain in that if you change the band via the radio (which you have to do with no CAT control) and you forget to also change the band in WSJT-X you wind up logging contacts for the wrong band.
>
>   
>
> Please advise, thanks
>
>   
>
> N0VB
>
> Glenn Van Benschoten




locked Re: #audio_issues #microphone #AudioIssues

Ian Kahn
 

You might need to go into Device Manager and completely disable the mic at the hardware level. That, of course, would disable it for all future use, until you re-enable it.

73 de,

Oan, MV4C

On Sun, Jun 21, 2020, 10:11 AM Gregory Reichenbach <gsreichenbach@...> wrote:
After updating Windows yesterday, my laptop's microphone picks up ambient audio from the room and WSJT-X hears it, mixes it with the radio's received audio, and it shows up in the waterfall and interferes with decoding.  Can't figure out how to make the laptop microphone stop without turning off the audio from the radio too.  Must be a windows setting, but can't find it.  Help please.


Greg Reichenbach
Stony Ridge OH
W8GSR


locked Re: #audio_issues #microphone #AudioIssues

ve3ki
 

In the Windows Sound Control Panel applet "Properties" settings for the microphone input, there may be a check box called "Listen to this device". If that check box is checked, input from that device will be echoed directly to the specified output device. In your situation, you don't want your microphone echoed to your speaker output, so that check box should be unchecked.

If the Windows Sound Control Panel applet shows separate input devices for microphone and line in (for example, if you have separate jacks for each input), you may be able to mute the microphone input without affecting the line input.

73,
Rich VE3KI


On Sun, Jun 21, 2020 at 10:50 AM, Bill Somerville wrote:
On 21/06/2020 15:46, Gregory Reichenbach wrote:
Bill, thanks very much for the reply.  Unfortunately, that's not the
problem.  I have only one device each on the laptop for mic and
speakers. Just in case, I tried changing the selection to "default"
then back to the specific audio devices, but that made no difference.
I suspect there's a windows setting somewhere that is allowing access
to the mic.
Greg,

the built in mic should be disabled when you plug in something to the
line in, or combined line in/mic socket. If your mic is live then I
would check that the plug is correctly inserted.

73
Bill
G4WJS.


locked Re: #audio_issues #microphone #AudioIssues

Lars Berg
 

Stay away from the 2004 update . See

https://answers.microsoft.com/en-us/insider/forum/all/windows-10-version-2004-audio-bug-latest/

 

73 de Lars SM3CCM

 

Skickades från E-post för Windows 10

 

Från: Bill Somerville
Skickat: den 21 juni 2020 16:50
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] #audio_issues #microphone

 

On 21/06/2020 15:46, Gregory Reichenbach wrote:
> Bill, thanks very much for the reply.  Unfortunately, that's not the
> problem.  I have only one device each on the laptop for mic and
> speakers. Just in case, I tried changing the selection to "default"
> then back to the specific audio devices, but that made no difference.
> I suspect there's a windows setting somewhere that is allowing access
> to the mic.

Greg,

the built in mic should be disabled when you plug in something to the
line in, or combined line in/mic socket. If your mic is live then I
would check that the plug is correctly inserted.

73
Bill
G4WJS.

 


locked Re: #audio_issues #microphone #AudioIssues

Bill Somerville
 

On 21/06/2020 15:46, Gregory Reichenbach wrote:
Bill, thanks very much for the reply.  Unfortunately, that's not the problem.  I have only one device each on the laptop for mic and speakers. Just in case, I tried changing the selection to "default" then back to the specific audio devices, but that made no difference. I suspect there's a windows setting somewhere that is allowing access to the mic.
Greg,

the built in mic should be disabled when you plug in something to the line in, or combined line in/mic socket. If your mic is live then I would check that the plug is correctly inserted.

73
Bill
G4WJS.


locked Re: #audio_issues #microphone #AudioIssues

Gregory Reichenbach
 
Edited

Bill, thanks very much for the reply.  Unfortunately, that's not the problem.  I have only one device each on the laptop for mic and speakers.  Just in case, I tried changing the selection to "default" then back to the specific audio devices, but that made no difference.  I suspect there's a windows setting somewhere that is allowing access to the mic.

I have tried switching off "allow apps to access your microphone" and "allow desktop apps to access your microphone" but either of those prevents wsjt-x from receiving the rig audio. I have switched off mic access from all the "microsoft store apps." Here is a screenshot of the "desktop apps" that have access to my mic. My best guess is that maybe the "scripted diagnostics native host" is the problem?