Date   

locked Re: Replying to CQ, etc.

Carl - WC4H
 

Bob, read carefully, Carey did include his name and call.

Roger,  technically speaking the 4 components that make a contact a valid QSO are:
Band, Mode, the QSO partner's callsign, and the time of the QSO (Normally in UTC and ARRL uses Start Time).

Report and grid are notably NOT required to have a valid QSO as is no other information.

So, my guess is that the folks that call you with Tx3 are looking for the minimum info required.  If you answer RR73, they come back with a 73 and you have fullfilled the content of the 4 components.


I have gotten Tx3 calls also.  I just let the program respond with RR73 and I get a 73 back and log it.

It's not ideal if you are looking for grids and want WSJT-X to highlight the caller with the appropriate color.  If you upload to LoTW, the and the QSO partner is in LoTW, you will still get credit for that grid.

I always remind people to think of a DX Expedition.  Extremely minimal info to work the most people possible, and nobody complains that they did not get a 73 or a grid.  They are just happy to get that ATNO. 

73.
Carl - WC4H


locked Re: Replying to CQ, etc.

Jim Brown
 

On 6/21/2020 10:59 AM, K8BL BOB LIDDY wrote:
But, when I post to a Ham Radio Group, I always include
my Name/Call so everyone knows who I am. That's called
good manners.
Yes, and so are the #2 and #3 issues that Bob raised. They are both bad operating practice and bad manners. I disagree about #1 -- there are (at least) 100,000 QSOs in my log without a grid as part of the exchange. As to keeping track of worked and un-worked on a band -- that's easily done with JTAlert working in conjunction with one of the logging programs it supports. I've used DXKeeper since getting back on the air in 2003, and love it. It interacts well with WSJT-X and JTAlert, with LOTW, eQSL, and ClubLog, and keeps track of many awards. It's FREE. In addition to logging directly from WSJT-X/JTAlert, I export ADIF from N1MM after each contest, and use DXKeeper to upload/download LOTW, eQSL, and ClubLog. DXKeeper is FREEware.

73, Jim K9YC


locked Re: Replying to CQ, etc.

K8BL BOB LIDDY <k8bl@...>
 

Carey,  

No, I want EVERYONE to have a QSO with me 24/7.

But, when I post to a Ham Radio Group, I always include
my Name/Call so everyone knows who I am. That's called
good manners.

GL/73,     Bob  K8BL


On Sunday, June 21, 2020, 12:05:04 PM EDT, <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.




--
Carey Fisher


--
73, Carey, WB4HXE


locked Re: TS2000 TX stopped working after WSJT-X 2.1.0 to 2.2.1 upgrade

Karl Beckman WA8NVW - NNV5BH
 

GM0PJD -
I'm also running a TS-2000 here and had the same "No Audio" problem after I updated both Windows10 and WSJT in the same session.  Microsoft pushed out yet another update about the same day that 2.2.1 was released.  Once again the Windows10 patch update affected the audio volume control settings for lots of ham users.  I had to set the entire chain of computer, USB interface, and tramsmitter output levels again. 
First put a dummy load on the transmitter, then bring up the WSJTx control panel and click the TUNE button.  Now access the Windows10 Sound control panel and adjust the PLAYBACK (transmit) signal level to 0 db.  (NOTE: WSJT-x has to put transmitter into TUNE to adjust the audio Tx Level.control),  Next move to the WSJT-x slider, and finally to the Tx pot on your SL-USB.  Set the SL-USB Tx control so that you see only a small amount of ALC on the meter.  Last, adjust the TS-2000 PWR setting to your desired power output.   Back to the WSJT controls, exit the TUNE mode, replace dummy load with antenna, and resume filling the logbook on WSJT! 

--
Karl  WA8NVW  OH
WA8NVW@...
in WSJTX@groups.io


locked Re: It's AL1VE!

iain macdonnell - N6ML <ar@...>
 

AL1VE's currently (2020-06-21) active on 6m FT8 from the DN47/48 line.
He was in DN73 and DN75 last week too. He's not on LoTW yet, but plans
to get it set up when he gets back home.

73,

~iain / N6ML


On Sun, Jun 21, 2020 at 6:41 AM Philip Rose via groups.io
<pvrose@...> wrote:

Don’t know,



But he’s on QRZ.com. Recently moved to WA.



73 Phil GM3ZZA



Sent from Mail for Windows 10



From: Kermit Lehman via groups.io
Sent: 21 June 2020 00:49
To: ken@...; main@WSJTX.groups.io
Subject: Re: [WSJTX] It's AL1VE!







IT CAME FROM THE IONOSPHERE !! MEGAHERTZ OF RADIATION !!







Does it use LoTW?





73,

Ken, AB1J

-----Original Message-----
From: Ken Arck <ken@...>
To: main@WSJTX.groups.io
Sent: Sat, Jun 20, 2020 11:07 pm
Subject: [WSJTX] It's ALIVE!

------------------------------------------------------------------------------
President and CTO - Arcom Controllers
Makers of repeater controllers and accessories.
https://www.arcomcontrollers.com/
Authorized Dealers for Kenwood and Telewave.
We we offer complete turn-key repeater packages!
AH6LE/R - IRLP Node 3000
http://www.irlp.net
"We don't just make 'em. We use 'em!"


[]




--
73 Phil GM3ZZA


locked Re: Disable TX After 73

Reino Talarmo
 

>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.
Hugo, ve3ktn.
Hi Hugo,
Perhaps knowing how RR73 came into the autosequence would help to understand why Tx 4 seems to behave ‘wrongly’. Originally R+nn report were confirmed by RRR and a 73 was sent later to indicate ‘I am happy now and have logged QSO’. At some stage it was noted that locator RR73 can be sent in the Tx 4 message and that is a combination of RRR and 73 in a single message. The meaning was taken from message Tx 5 i.e. it is the final message from me, tnx.
73, Reino OH3mA


locked Re: Uninstalling Old Versions of WSJT-X

neil_zampella
 

Marlo,


On 6/21/2020 1:18 PM, Marlo Montanaro - KA2IRQ wrote:

Correct- I'm just wanting to clean up Windows 10's installed
Applications which lists many versions of WSJT-X.  I am running WSJT-X
V2.2.1 and want that to stay.

However, it appears that there is only one wsjtx.exe file in the
C:\WSJT\WSJTX\bin folder.  I can't imagine that doing this clean-up in
Windows will be seamless or harmless.  Correct me if I'm wrong, but if
I remove an old version, I see the Windows uninstall routine wiping
out the current version.
As mentioned previously, all the settings, logs, and so on are kept
completely separate from the WSJT directory tree.  Even if the
uninstallers take out the v2.2.1 directory, a simple reinstall of 2.2.1
will fix that issue, and it will find all the settings.

Neil, KN3ILZ



Normally, if a program being installed onto the Windows platform is
going to leave the old version lying around, it is moved to a
different folder and/or renamed so that uninstalling the old version
does not later clobber the new version.

Am I wrong?
Some do, some don't.  Its usually up to the program creator/company.    
As far as WSJT-X, I just create a new directory based on the version
number.   As I mentioned in another post, I just removed a bunch of
versions from v2.0.1 thru 2.2.0-rc3 without an issue

73,
Marlo
Neil, KN3ILZ


--
This email has been checked for viruses by AVG.
https://www.avg.com


locked Re: Uninstalling Old Versions of WSJT-X

Marlo Montanaro - KA2IRQ
 

Correct- I'm just wanting to clean up Windows 10's installed Applications which lists many versions of WSJT-X.  I am running  WSJT-X V2.2.1 and want that to stay.

However, it appears that there is only one wsjtx.exe file in the C:\WSJT\WSJTX\bin folder.  I can't imagine that doing this clean-up in Windows will be seamless or harmless.  Correct me if I'm wrong, but if I remove an old version, I see the Windows uninstall routine wiping out the current version.

Normally, if a program being installed onto the Windows platform is going to leave the old version lying around, it is moved to a different folder and/or renamed so that uninstalling the old version does not later clobber the new version.

Am I wrong?

 

73,
Marlo
KA2IRQ


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

Joe Subich, W4TV
 

Do you operate a TS-440S?
I have in the past. However, I have been supporting serial
interface products for 15+ years and multiple generations
of Elecraft, Kenwood, Icom, TenTec and Yaesu transceivers.

See: www.microHAM-USA.com or www.microHAM.com

I have a library that covers nearly every computer controllable
transceiver sold by those manufacturers in the last 35 years or
so, including CAT protocols and interface specifications so I'm
not someone who discovered the newest "hot" digital mode last
night or read an article in a magazine.

73,

... Joe, W4TV


On 2020-06-21 9:35 AM, 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

gtvanben@...




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

JP Tucson, AZ
 

Thanks Bill, that got me there.

A shaking fist at ms - damn those fools!


Really curious...

First that it is not triggering a failure message on windows or in the device manager! That's just weird!


However, I still contend that it's an issue with the old version(s)[v2.1.2 & rc1](...and by that - mostly Hamlib); because ; since I still have 2.1.2 in a separate folder with it's own desktop shortcut,  I went back to it & it fails & verified under the ms device mgr. properties that it says it's working properly!!!

As soon as I quit 2.1.2 & restarted 2.2.0 it works like a champ. That does not appear to me as a hardware failure, but as a software issue; either an improper setup, or bug in Hamlib (which they worked on between rc1 & rc2!), or... there was/is a conflict in some combo of the ms, hamlib, driver or wsjt-x (2.1.2, rc1)...  


Aa I mentioned, after next weekend FD here in U.S.,  if you want to create/send an instrumented version of 2.2.0, I'll be happy to delve deeper into this in order to find the exact cause if we can - if for no other reason than to avoid reintroducing that error... 

Thanks again for the info.

73 - John - N7GHZ


On Sun, Jun 21, 2020, 9:00 AM Bill Somerville <g4wjs@...> wrote:
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

Lars Berg
 

Sorry for the broken link. Reino’s link is OK.

It seems that Microsoft has been aware of the audio bug since April. In spite of that they made a general release, including the bug, of 2004. Shame…

73 Lars SM3CCM

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

 

Från: Reino Talarmo
Skickat: den 21 juni 2020 17:32
Till: main@WSJTX.groups.io
Ämne: Re: [WSJTX] #audio_issues #microphone

 

The link was broken, at least for me. I found it as:

https://answers.microsoft.com/en-us/insider/forum/all/windows-10-version-2004-audio-bug-latest/5f1e54bf-2031-478d-a903-6cd3037236f3

 

73, Reino OH3mA

 

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: 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.