Re: [wsjt-devel] Callsign lockout

[David Gilbert]

It's pretty difficult to ignore a LID  on CW or SSB, but it's really 
easy to do so on FT8.  I do it all the time when I'm calling CQ DX and 
somebody stateside insists upon calling me over and over again. I 
consider it to be one of the beauties of FT8.  If I'm actively working 
stations he doesn't even significantly affect scrolling.


I'm rather astounded that others find that so hard to do.  On FT8, LIDs 
are only annoying if you let them.


Dave   AB7E


On 12/2/2019 6:26 PM, Ron WV4P wrote:
There are Many reasons to block a caller, they may be a Lid, they may 
be disrupting a QSO, they may just be Very annoying. As it stands we 
have No way to deal with them. We need a way. Just last night I had a 
PA station I had never worked send me RR73 over and over for 30 min. 
Ron, WV4P






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Sam W2JDB via wsjt-devel]

Hi Ron, In your particular situation, I would send them a 73 (tx5) and don't 
log them. If they ever ask for a confirmation, I reject it.  73,  Sam W2JDB
  -Original Message-
From: Ron WV4P 
To: WSJT software development 
Sent: Mon, Dec 2, 2019 8:29 pm
Subject: Re: [wsjt-devel] Callsign lockout

There are Many reasons to block a caller, they may be a Lid, they may be 
disrupting a QSO, they may just be Very annoying. As it stands we have No way 
to deal with them. We need a way. Just last night I had a PA station I had 
never worked send me RR73 over and over for 30 min. Ron, WV4P
On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel 
 wrote:

 I agree. I believe a lockout feature could be abused. Case in point wasduring 
the heyday of packet radio (I call it the Packet Radio Wars).If you did not 
march to 'their' drum you were locked out of all nodes, BBS'gateways, etc. Such 
a thing should be banned. If it is there, someonewill use it to push their 
agenda. That's not in the spirit of amateur radio.
Best regards
Gary, K7EK

---

On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote:  
 
 
I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.

Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:
> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> In summary, I don't see any need whatsoever for any modification of 
>> the 'Call 1st' capability
>> to include any forms of queuing or callsign lockout
>
> Agreed. This is an operator issue, not a software one.
>
> 73, Jim K9YC
>



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Carey Fisher]

That's ridiculous. A "block" wouldn't keep a station from transmitting,
just from being displayed. Can't you just ignore it?

On Mon, Dec 2, 2019 at 8:29 PM Ron WV4P  wrote:

> There are Many reasons to block a caller, they may be a Lid, they may be
> disrupting a QSO, they may just be Very annoying. As it stands we have No
> way to deal with them. We need a way. Just last night I had a PA station I
> had never worked send me RR73 over and over for 30 min. Ron, WV4P
>
> On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel <
> wsjt-devel@lists.sourceforge.net> wrote:
>
>> I agree. I believe a lockout feature could be abused. Case in point was
>> during the heyday of packet radio (I call it the Packet Radio Wars).
>> If you did not march to 'their' drum you were locked out of all nodes,
>> BBS'
>> gateways, etc. Such a thing should be banned. If it is there, someone
>> will use it to push their agenda. That's not in the spirit of amateur
>> radio.
>>
>> Best regards
>>
>> Gary, K7EK
>>
>>
>> ---
>>
>>
>> On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert <
>> xda...@cis-broadband.com> wrote:
>>
>>
>>
>> I have the same opinion.  I almost never use "Call 1st" and I find it
>> trivial to operate without it no matter how many callers I get.
>>
>> Even FT8 should be able to handle some degree of operator proficiency.
>>
>> 73,
>> Dave AB7E
>>
>>
>>
>> On 12/2/2019 1:00 PM, Jim Brown wrote:
>> > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> >> In summary, I don't see any need whatsoever for any modification of
>> >> the 'Call 1st' capability
>> >> to include any forms of queuing or callsign lockout
>> >
>> > Agreed. This is an operator issue, not a software one.
>> >
>> > 73, Jim K9YC
>> >
>>
>>
>>
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>


-- 
Carey Fisher
careyfis...@gmail.com
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Bill Frantz]

Hi Gary -

Part of my reason for using Call 1st is philosophical: When I 
call CQ, I am saying I'm willing to work anybody who answers. If 
I say CQ ND, for example, I'm saying, "If you're in North 
Dakota, I'd really like a QSO." Other operators give CQ a 
different meaning.


I will note that I mostly call CQ when operating QRP, since 
that's the best way to ensure that the other station has heard 
my signal. (I don't operate from rare locations, so blind calls 
based on spots aren't a real problem.)


I do use Call 1st because by the time the decodes have been 
displayed, and my eyes have had a chance to look at them, I've 
lost the 15 second window, which really cuts into my rate. (I 
discovered early that I don't have the patience for JT9.)


I do sympathize with people who have stations calling them who 
can't hear them, and stations which don't complete the QSO. 
Michael's algorithm seems like a good one for handling these 
stations: Give new stations the first shot, and if there aren't 
any of those, retry the old stations in rotation.


73 Bill AE6JV

On 12/1/19 at 2:56 PM, mcduf...@ag0n.net (Gary McDuffie) wrote:

I’m curious why you use Call 1st anyway.  I never use it and 
have never found a use for it.  I want to have control over who 
I answer or call.

---
Bill Frantz| When an old person dies, a   | Periwinkle
(408)356-8506  | library burns. - Joe McGawon | 16345 
Englewood Ave
www.pwpconsult.com | Irish Ethnographer   | Los Gatos, 
CA 95032




___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Larry B. via wsjt-devel]

It was probably a robot! 

73 -- Larry -- W1DYJ



From: Ron WV4P 
Sent: Monday, December 02, 2019 20:26
To: WSJT software development 
Subject: Re: [wsjt-devel] Callsign lockout

There are Many reasons to block a caller, they may be a Lid, they may be 
disrupting a QSO, they may just be Very annoying. As it stands we have No way 
to deal with them. We need a way. Just last night I had a PA station I had 
never worked send me RR73 over and over for 30 min. Ron, WV4P

On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel 
 wrote:

  I agree. I believe a lockout feature could be abused. Case in point was
  during the heyday of packet radio (I call it the Packet Radio Wars).
  If you did not march to 'their' drum you were locked out of all nodes, BBS'
  gateways, etc. Such a thing should be banned. If it is there, someone
  will use it to push their agenda. That's not in the spirit of amateur radio.

  Best regards

  Gary, K7EK


  ---


  On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote: 



  I have the same opinion.  I almost never use "Call 1st" and I find it 
  trivial to operate without it no matter how many callers I get.

  Even FT8 should be able to handle some degree of operator proficiency.

  73,
  Dave AB7E




  On 12/2/2019 1:00 PM, Jim Brown wrote:
  > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
  >> In summary, I don't see any need whatsoever for any modification of 
  >> the 'Call 1st' capability
  >> to include any forms of queuing or callsign lockout
  >
  > Agreed. This is an operator issue, not a software one.
  >
  > 73, Jim K9YC
  >



  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel

  ___
  wsjt-devel mailing list
  wsjt-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wsjt-devel








___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Ron WV4P]

There are Many reasons to block a caller, they may be a Lid, they may be
disrupting a QSO, they may just be Very annoying. As it stands we have No
way to deal with them. We need a way. Just last night I had a PA station I
had never worked send me RR73 over and over for 30 min. Ron, WV4P

On Mon, Dec 2, 2019, 7:19 PM Gary Kohtala - K7EK via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> I agree. I believe a lockout feature could be abused. Case in point was
> during the heyday of packet radio (I call it the Packet Radio Wars).
> If you did not march to 'their' drum you were locked out of all nodes, BBS'
> gateways, etc. Such a thing should be banned. If it is there, someone
> will use it to push their agenda. That's not in the spirit of amateur
> radio.
>
> Best regards
>
> Gary, K7EK
>
>
> ---
>
>
> On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert <
> xda...@cis-broadband.com> wrote:
>
>
>
> I have the same opinion.  I almost never use "Call 1st" and I find it
> trivial to operate without it no matter how many callers I get.
>
> Even FT8 should be able to handle some degree of operator proficiency.
>
> 73,
> Dave AB7E
>
>
>
> On 12/2/2019 1:00 PM, Jim Brown wrote:
> > On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
> >> In summary, I don't see any need whatsoever for any modification of
> >> the 'Call 1st' capability
> >> to include any forms of queuing or callsign lockout
> >
> > Agreed. This is an operator issue, not a software one.
> >
> > 73, Jim K9YC
> >
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Gary Kohtala - K7EK via wsjt-devel]

 I agree. I believe a lockout feature could be abused. Case in point wasduring 
the heyday of packet radio (I call it the Packet Radio Wars).If you did not 
march to 'their' drum you were locked out of all nodes, BBS'gateways, etc. Such 
a thing should be banned. If it is there, someonewill use it to push their 
agenda. That's not in the spirit of amateur radio.
Best regards
Gary, K7EK

---

On Monday, December 2, 2019, 04:39:31 PM EST, David Gilbert 
 wrote:  
 
 
I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.

Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:
> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>> In summary, I don't see any need whatsoever for any modification of 
>> the 'Call 1st' capability
>> to include any forms of queuing or callsign lockout
>
> Agreed. This is an operator issue, not a software one.
>
> 73, Jim K9YC
>



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Paul Kube]

On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.
>

I had a dropout problem where WSJT-X audio output would occasionally switch
from the desired "Speakers (5- USB Audio CODEC)" to "Headphones (High
Definition Audio Device)" when I had headphones plugged in to my Windows 10
desktop machine. This of course caused loss of transmitter modulation. Kind
of a mystery, since I had only the USB codec selected as output for WSJT-X
both in WSJT-X's settings Audio tab and in Windows sound settings; I don't
know why Windows should ever take it upon itself to re-route that.

I tried ferrites on the headphone cable to fix this. Ultimately lots of
ferrites, including 10 turns through a 3/4" I.D. mix 31. (I already have
chokes on everything else, and no RFI-like problems except for this.) It
didn't help! But unplugging the headphones does eliminate the problem, so I
now just forego watching Netflix while working FT8 :).

Anyway, if you're having problems with TX audio dropout with Windows 10,
try popping up the Volume Mixer to see which output devices are connected
to WSJT-X; maybe the operating system has switched to using something other
than the one you want.

73, Paul K6PO



On Mon, Dec 2, 2019 at 4:34 AM Black Michael via wsjt-devel <
wsjt-devel@lists.sourceforge.net> wrote:

> Audio dropout like this is usually caused by the USB audio device
> disconnecting.
> And that is usually case by RFI.  Chokes on USB cables (and all other
> cables) usually solves the problem.
> Ensure your ethernet cables are shielded too.  Newer CAT 7 or CAT 8 cables
> are already shielded.  And ground your ethernet hub too (most don't have a
> built-in ground)
> I even put chokes on all my power lines going into the breaker box to
> reduce what's riding on the power.
>
> And, if you have an outside round rod (like many I have helped) that is
> not tied to the house ground either stop using it (and use the house
> ground) or tie the outside rod to the house ground properly.  That has also
> solved many RFI problems.
>
> de Mike W9MDB
>
>
>
>
> On Monday, December 2, 2019, 05:26:25 AM CST, Claude Frantz <
> claude.fra...@bayern-mail.de> wrote:
>
>
> On 12/1/19 10:46 PM, Frederic Beaulieu wrote:
>
> Hi Frederic,
>
> > I start to notice on my IC-7300's audio scope that occasionnaly, no
> > audio was sent to the radio. The problem seems to get worse (more
> > frequent) and now I'm seeing a kind of noise at the beginning of many
> > of my transmission. Anyone knows how I could verify if it is a
> > problem with my radio, the sound card (which is embedded in the radio
> > I think) or the WSJT-X software?
> This problem of occasional no audio output has been reported here by
> various users, included myself. I have encountered it while running with
> Windows XP and using Linux, on different hardware. I cannot remember
> that an valuable diagnostic has been reported about the reasons of these
> sporadic recurrences.
>
> Best wishes,
> Claude (DJ0OT)
>
>
>
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[James Shaver]

Same - I figure the automation functions are an operator aid, not an operator 
replacement. 

Jim S. 
N2ADV

> On Dec 2, 2019, at 4:37 PM, David Gilbert  wrote:
> 
> 
> I have the same opinion.  I almost never use "Call 1st" and I find it trivial 
> to operate without it no matter how many callers I get.
> 
> Even FT8 should be able to handle some degree of operator proficiency.
> 
> 73,
> Dave AB7E
> 
> 
> 
>> On 12/2/2019 1:00 PM, Jim Brown wrote:
>>> On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
>>> In summary, I don't see any need whatsoever for any modification of the 
>>> 'Call 1st' capability
>>> to include any forms of queuing or callsign lockout
>> 
>> Agreed. This is an operator issue, not a software one.
>> 
>> 73, Jim K9YC
>> 
> 
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Black Michael via wsjt-devel]

I'm all ears for opinions from operators who have had a call pileup on them.
If Call 1st is to be implemented at all it should be robust.
It's a trivial patch which I'll make myself and submit for consideration in 
WSJT-X.
de Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[David Gilbert]

I have the same opinion.  I almost never use "Call 1st" and I find it 
trivial to operate without it no matter how many callers I get.


Even FT8 should be able to handle some degree of operator proficiency.

73,
Dave AB7E



On 12/2/2019 1:00 PM, Jim Brown wrote:

On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:
In summary, I don't see any need whatsoever for any modification of 
the 'Call 1st' capability

to include any forms of queuing or callsign lockout


Agreed. This is an operator issue, not a software one.

73, Jim K9YC





___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Jim Brown]

On 12/2/2019 2:54 AM, Martin Davies G0HDB wrote:

In summary, I don't see any need whatsoever for any modification of the 'Call 
1st' capability
to include any forms of queuing or callsign lockout


Agreed. This is an operator issue, not a software one.

73, Jim K9YC


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Martin Davies G0HDB]

On 2 Dec 2019 at 17:06, Paul Randall wrote:

> It may be unrelated but a station very local to me on 2m transmits a
> huge wideband splat of noise at the start of his FT8 transmissions. I
> think what I am hearing is all the noise in his shack, the fan in his
> qro linear etc, all picked up by his microphone which presumably is
> still plugged in. With speech compression this can make a lot of power
> before the FT8 tones start and suppress it. 
> 
> Paul G3NJV

I've often observed a similar situation on primarily (IIRC) 80m FT8 - there's 
(at least!) one 
station whose transmissions always start with a huge burst of what sounds like 
background 
noise.  Unfortunately I haven't yet been able to identify which of the numerous 
stations on 
80m FT8 is the culprit.

My recently-acquired IC-7610 rig and I believe my previous couple of Icom rigs 
- IC-7600 and 
IC-756 Pro III - all had the facility for specifying the modulation signal 
source when in an SSB 
data mode.  I use the USB-D1 mode, and on the 7610 I've selected the modulation 
input for 
this mode to be the ACC1 rear-panel socket.  However, it does appear possible 
to select 
both ACC1 and MIC for the MOD input in USB-D1 mode which could cause problems 
of 
unwanted emanations if that option were to be selected.  The 7610's default MOD 
input when 
in USB-D1 mode is ACC1 alone.

I would assume that other makes of rig have a similar set of options for 
specifying the 
modulation input when an SSB data mode is selected; it shouldn't be beyond the 
wit of most 
operators to ensure that only the applicable option is selected via the menu 
system!

---
Martin, G0HDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Gary McDuffie]

> On Dec 2, 2019, at 10:06, Paul Randall  wrote:
> 
> It may be unrelated but a station very local to me on 2m transmits a huge 
> wideband splat of noise at the start of his FT8 transmissions. I think what I 
> am hearing is all the noise in his shack, the fan in his qro linear etc, all 
> picked up by his microphone which presumably is still plugged in. With speech 
> compression this can make a lot of power before the FT8 tones start and 
> suppress it.

I hear a lot of that.  One, the mic should not be plugged in if it is 
electrically active during PTT on the FT8 port.  Two, the processor should NOT 
be used on digital modes at all.  You need to educate this guy so he can “do it 
right”.  It’s really gross to listen someone like that who wipes out the entire 
band segment every time they key up or release PTT.

Gary - AG0N

___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Paul Randall]

It may be unrelated but a station very local to me on 2m transmits a huge 
wideband splat of noise at the start of his FT8 transmissions. I think what I 
am hearing is all the noise in his shack, the fan in his qro linear etc, all 
picked up by his microphone which presumably is still plugged in. With speech 
compression this can make a lot of power before the FT8 tones start and 
suppress it.

Paul G3NJV


From: Reino Talarmo 
Sent: 02 December 2019 14:40
To: 'WSJT software development' 
Subject: Re: [wsjt-devel] Problem with radio's audio input

The original mail stated:
"I'm seeing a kind of noise at the beginning of many of my transmission.
Anyone knows how I could verify if it is a problem with my radio, the sound
card (which is embedded in the radio I think) or the WSJT-X software?"
The video shows some kind of instability, perhaps a low frequency pulse
train generating a wide spectrum. Perhaps audio actually goes to the radio,
but causes some unwanted transient before normal operation. It even could be
an ALC issue, if the audio level is too high hitting ALC. I would not rule
out RF problems either.
73, Reino oh3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Martin Davies G0HDB]

On 2 Dec 2019 at 10:34, Frederic Beaulieu wrote:
 
> You can see in the link below the noise at TX start:
> 
> https://youtu.be/peVSAZQ08yU
> 
> which cause power overshooting at the beginning of the timeslot.
> 
> 73,

Hello Fred (and all), I suspect that the 'overshoot' or 'splat' of noise you're 
seeing at the start 
of your transmissions might be an Icom-specific artefact - under certain 
conditions I observe 
the same effect with my IC-7610, which is fed with analogue Tx audio from an 
external codec 
via the ACC1 rear-panel socket.

When I use the WSJT-X 'Tune' button to key the Tx and send an audio tone from 
the PC to 
the rig, via the external codec and the ACC1 socket, I observe the 
short-duration burst of 
signal, be it noise or whatever, on the rig's spectrum scope and waterfall.  
This happens 
when the rig is connected to a dummy load and generating only a Watt or two of 
RF output 
so it's extremely unlikely that the cause of the unwanted burst of signal is RF 
somehow 
getting back into the audio chain.

The burst of signal appears to extend to approx 1kHz either side of the centre 
frequency on 
the rig's spectrum scope and waterfall; when I listen to the monitored Tx audio 
out of the rig I 
don't hear a clearly-identifiable burst of any sort of noise etc, but the onset 
of the 'Tune' audio 
tone does sound very 'hard' and abrupt.

I observe, and hear, a similar effect when I stop the 'Tune' operation and the 
rig returns to the 
Rx state - the cessation of the audio at the end of a 'Tune' transmission again 
sounds very 
'hard' and abrupt.

Interestingly, I only very occasionally observe the 2kHz-wide burst of noise or 
whatever on 
the rig's spectrum scope and waterfall when WSJT-X is Tx'ing normally; perhaps 
the fact that 
I've got my IC-7610's Tx delay set to 15msecs (on both HF and 6m) and the 
WSJT-X Tx 
delay set to 100msecs is having a bearing.

A question for Bill and the developers - is there any form of shaping of the 
leading and trailing 
edges of the audio waveform generated by WSJT-X when the 'Tune' button is 
operated?  If 
there isn't then I wonder if the unwanted, albeit short-duration burst of 
signal, which doesn't 
appear to have any adverse effect overall, is akin to a CW key-click caused by 
too steep a 
rising and trailing edge on the audio waveform.

---
Martin, G0HDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Bill Somerville]

Hi Fred,

thanks for that. The levels you list do not show the all the 
gain/attenuation stages as you are using the 64-bit version of WSJT-X 
(confirmed off list). There is an extra level slider in the MS Windows 
audio mixer panel for the WSJT-X application itself, this slider is only 
displayed when the application is in Tx mode.


I suspect you have excessive and unnecessary attenuation in the digital 
part of the audio chain, and this may be part of the issue. The issue 
appears to be RF being generated in the period of silence before the FT8 
transmission tones start, that should not happen and may be a fault in 
the transceiver, but before going further with that line I suggest you 
try and rationalize your various level settings to eliminate unnecessary 
attenuation and set the audio level only with the DATA MOD LEVEL in your 
rig's menu. This post contains a procedure that should achieve that:


https://groups.yahoo.com/neo/groups/wsjtgroup/conversations/messages/38922

73
Bill
G4WJS.

On 02/12/2019 12:55, Frederic Beaulieu wrote:


Hi Bill,

I usually use around -8dB on the slider which output around 25W. I set 
the Speaker output level to 50% and IC-7300’s USB Mod Level to 27%.


73,

*De :*Bill Somerville 
*Envoyé :* 2 décembre 2019 06:14
*À :* Frederic Beaulieu 
*Objet :* Re: [wsjt-devel] Problem with radio's audio input

Hi Fred,

what level do you have the "Pwr" slider on the WSJT-X main window set at?

73
Bill
G4WJS.

On 02/12/2019 10:34, Frederic Beaulieu wrote:

Ok, thanks.

You can see in the link below the noise at TX start:

https://youtu.be/peVSAZQ08yU



which cause power overshooting at the beginning of the timeslot.

73,

*From:*Black Michael via wsjt-devel


*Sent:* 1 décembre 2019 23:36
*To:* WSJT software development 

*Cc:* Black Michael  
*Subject:* Re: [wsjt-devel] Problem with radio's audio input

Yes you can post a web link.

de Mike W9MDB

On Sunday, December 1, 2019, 06:21:03 PM CST, Frederic Beaulieu
mailto:frederic.beaul...@trilliant.com>> wrote:

Hi,

I'm using WSJT-X/FT8 regularly for more than a year now. One month
ago, I start to notice on my IC-7300's audio scope that
occasionnaly, no audio was sent to the radio. The problem seems to
get worse (more frequent) and now I'm seeing a kind of noise at
the beginning of many of my transmission. Anyone knows how I could
verify if it is a problem with my radio, the sound card (which is
embedded in the radio I think) or the WSJT-X software?

73,

Fred VE2WFB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Claude Frantz]

On 12/2/19 1:27 PM, Black Michael via wsjt-devel wrote:


Audio dropout like this is usually caused by the USB audio device
disconnecting.And that is usually case by RFI.  Chokes on USB cables
(and all other cables) usually solves the problem.Ensure your
ethernet cables are shielded too.
I have observed the "no audio output problem" on installations without 
USB and Ethernet cables connected. In any case, which I have seen up to 
now, pressing "Halt TX" and then "Enable TX" has restored the audio, 
without any touching other as the mouse.


Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Reino Talarmo]

The original mail stated:
"I'm seeing a kind of noise at the beginning of many of my transmission.
Anyone knows how I could verify if it is a problem with my radio, the sound
card (which is embedded in the radio I think) or the WSJT-X software?"
The video shows some kind of instability, perhaps a low frequency pulse
train generating a wide spectrum. Perhaps audio actually goes to the radio,
but causes some unwanted transient before normal operation. It even could be
an ALC issue, if the audio level is too high hitting ALC. I would not rule
out RF problems either. 
73, Reino oh3mA



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Neil Zampella]

Could it be the OP is using the 64 bit version and Windows 10? Bill has
a message here on about certain audio settings for that combination.

Neil, KN3ILZ

On 12/2/2019 7:50 AM, Martin Davies G0HDB wrote:

On 2 Dec 2019 at 12:27, Black Michael via wsjt-devel wrote:


Audio dropout like this is usually caused by the USB audio device 
disconnecting.And that is

usually case by RFI.

The original posting stated that on occasions there doesn't appear to be any Tx 
audio going
into the IC-7300 rig - the poster didn't explicitly state whether he's using 
the rig's inbuilt audio
codec, with data from the WSJT-X software going via USB, or the rig's analogue 
audio input,
although the former can be inferred.

In the event of there being no Tx audio going into the rig there wouldn't be 
any RF output
from the rig, so how in such a scenario could the cause of the observed 
problems be RFI on
the USB connection between PC and the rig?  There's no RF to cause the I...!!

---
Martin, G0HDB






___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Frederic Beaulieu]

Hi Bill,

I usually use around -8dB on the slider which output around 25W. I set the 
Speaker output level to 50% and IC-7300’s USB Mod Level to 27%.

73,



De : Bill Somerville 
Envoyé : 2 décembre 2019 06:14
À : Frederic Beaulieu 
Objet : Re: [wsjt-devel] Problem with radio's audio input

Hi Fred,

what level do you have the "Pwr" slider on the WSJT-X main window set at?

73
Bill
G4WJS.

On 02/12/2019 10:34, Frederic Beaulieu wrote:
Ok, thanks.

You can see in the link below the noise at TX start:

https://youtu.be/peVSAZQ08yU

which cause power overshooting at the beginning of the timeslot.

73,

From: Black Michael via wsjt-devel 

Sent: 1 décembre 2019 23:36
To: WSJT software development 

Cc: Black Michael 
Subject: Re: [wsjt-devel] Problem with radio's audio input

Yes you can post a web link.

de Mike W9MDB




On Sunday, December 1, 2019, 06:21:03 PM CST, Frederic Beaulieu 
mailto:frederic.beaul...@trilliant.com>> wrote:



Hi,



I'm using WSJT-X/FT8 regularly for more than a year now. One month ago, I start 
to notice on my IC-7300's audio scope that occasionnaly, no audio was sent to 
the radio. The problem seems to get worse (more frequent) and now I'm seeing a 
kind of noise at the beginning of many of my transmission. Anyone knows how I 
could verify if it is a problem with my radio, the sound card (which is 
embedded in the radio I think) or the WSJT-X software?



73,

Fred VE2WFB


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Martin Davies G0HDB]

On 2 Dec 2019 at 12:27, Black Michael via wsjt-devel wrote:

> Audio dropout like this is usually caused by the USB audio device 
> disconnecting.And that is 
usually case by RFI.

The original posting stated that on occasions there doesn't appear to be any Tx 
audio going 
into the IC-7300 rig - the poster didn't explicitly state whether he's using 
the rig's inbuilt audio 
codec, with data from the WSJT-X software going via USB, or the rig's analogue 
audio input, 
although the former can be inferred.  

In the event of there being no Tx audio going into the rig there wouldn't be 
any RF output 
from the rig, so how in such a scenario could the cause of the observed 
problems be RFI on 
the USB connection between PC and the rig?  There's no RF to cause the I...!!

---
Martin, G0HDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] RR73 double click

[Black Michael via wsjt-devel]

Seems double-clicking an RR73 in 2.1.2 sends TX4 instead of TX5.  I guess 
either would work but TX5 seems more in line with a normal QSO.



de Mike W9MDB
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Black Michael via wsjt-devel]

Audio dropout like this is usually caused by the USB audio device 
disconnecting.And that is usually case by RFI.  Chokes on USB cables (and all 
other cables) usually solves the problem.Ensure your ethernet cables are 
shielded too.  Newer CAT 7 or CAT 8 cables are already shielded.  And ground 
your ethernet hub too (most don't have a built-in ground)I even put chokes on 
all my power lines going into the breaker box to reduce what's riding on the 
power.
And, if you have an outside round rod (like many I have helped) that is not 
tied to the house ground either stop using it (and use the house ground) or tie 
the outside rod to the house ground properly.  That has also solved many RFI 
problems.
de Mike W9MDB

 

On Monday, December 2, 2019, 05:26:25 AM CST, Claude Frantz 
 wrote:  
 
 On 12/1/19 10:46 PM, Frederic Beaulieu wrote:

Hi Frederic,

> I start to notice on my IC-7300's audio scope that occasionnaly, no
> audio was sent to the radio. The problem seems to get worse (more
> frequent) and now I'm seeing a kind of noise at the beginning of many
> of my transmission. Anyone knows how I could verify if it is a
> problem with my radio, the sound card (which is embedded in the radio
> I think) or the WSJT-X software?
This problem of occasional no audio output has been reported here by 
various users, included myself. I have encountered it while running with 
Windows XP and using Linux, on different hardware. I cannot remember 
that an valuable diagnostic has been reported about the reasons of these 
sporadic recurrences.

Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
  ___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Claude Frantz]

On 12/1/19 10:46 PM, Frederic Beaulieu wrote:

Hi Frederic,


I start to notice on my IC-7300's audio scope that occasionnaly, no
audio was sent to the radio. The problem seems to get worse (more
frequent) and now I'm seeing a kind of noise at the beginning of many
of my transmission. Anyone knows how I could verify if it is a
problem with my radio, the sound card (which is embedded in the radio
I think) or the WSJT-X software?
This problem of occasional no audio output has been reported here by 
various users, included myself. I have encountered it while running with 
Windows XP and using Linux, on different hardware. I cannot remember 
that an valuable diagnostic has been reported about the reasons of these 
sporadic recurrences.


Best wishes,
Claude (DJ0OT)


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Problem with radio's audio input

[Frederic Beaulieu]

Ok, thanks.

You can see in the link below the noise at TX start:

https://youtu.be/peVSAZQ08yU

which cause power overshooting at the beginning of the timeslot.

73,

From: Black Michael via wsjt-devel 
Sent: 1 décembre 2019 23:36
To: WSJT software development 
Cc: Black Michael 
Subject: Re: [wsjt-devel] Problem with radio's audio input

Yes you can post a web link.

de Mike W9MDB




On Sunday, December 1, 2019, 06:21:03 PM CST, Frederic Beaulieu 
mailto:frederic.beaul...@trilliant.com>> wrote:



Hi,



I'm using WSJT-X/FT8 regularly for more than a year now. One month ago, I start 
to notice on my IC-7300's audio scope that occasionnaly, no audio was sent to 
the radio. The problem seems to get worse (more frequent) and now I'm seeing a 
kind of noise at the beginning of many of my transmission. Anyone knows how I 
could verify if it is a problem with my radio, the sound card (which is 
embedded in the radio I think) or the WSJT-X software?



73,

Fred VE2WFB



P.S. I have a video on Youtube showing the audio noise but I'm not sure if I 
can post a Youtube link on this forum.v
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Callsign lockout

[Martin Davies G0HDB]

On 1 Dec 2019 at 12:56, Gary McDuffie wrote:

> > On Nov 30, 2019, at 15:15, Black Michael via wsjt-devel 
> >  wrote:
> > 
> > What is needed is the ability to block a callsign for an adjustable time 
> > out period defaulting perhaps to 15 minutes.
> 
> I´m curious why you use Call 1st anyway.  I never use it and have
> never found a use for it.  I want to have control over who I answer or
> call. 

You've absolutely hit the nail on the head, Gary - anyone who is troubled by 
their system 
replying to 'unwanted' callers simply needs to disable 'Call 1st' and then use 
a bit of skill and 
experience to decide which caller to respond to.  That's how it's always been 
done when 
using the 'legacy' modes of CW, SSB and RTTY and there's no obvious reason why 
a 
different, de-skilled modus operandi should be adopted for the JT/FT modes.

Although I do call CQ on a fairly regular basis I (almost) always prefer to 
leave 'Call 1st' 
unchecked which puts the onus on me to double-click on whichever callsign I 
decide I want to 
work in preference to others that appear in the list of decodes addressed to my 
callsign.  I 
never, ever feel obliged to have a QSO with a caller just because they've 
called me - I decide 
who I want to have the QSO with, and I regularly ignore persistent callers that 
I'm not 
interested in working!

As for it taking maybe a couple of seconds to decide which callsign from the 
list of decodes 
to work, that isn't usually an issue because the software at the distant end is 
generally quite 
capable of getting a good decode from my transmission even if it's started a 
bit late in the 
15sec timeslot.  However, there can be occasions when a retry is needed, but 
again that's no 
different to operating using the 'legacy' modes.

With regard to stations not sending their Tx3 message in response to a 'DX' 
station's (eg. the 
KL7 mentioned by the OP) Tx2, there can be numerous reasons (eg. QSB, QRM, QRN, 
etc 
etc) why the Tx2 message might not have been received by the caller - there's 
no way of 
knowing what the factors are so I'd suggest that if the 'DX' station hasn't 
received the caller's 
Tx3 message after say three or four retries then it's time to move on and try 
to complete a 
QSO with another caller.  This is after all what DX stations have done for 
decades when 
working CW, SSB and RTTY pileups; all it needs is the operator of the 'DX' 
station to use 
their skill and experience and not rely too heavily on the automation 
facilities that the WSJT-X 
software provides.

In summary, I don't see any need whatsoever for any modification of the 'Call 
1st' capability 
to include any forms of queuing or callsign lockout - IMO they would be 
entirely superfluous 
and unnecessary.  If a 'DX' station wants to have some form of queuing incoming 
callers then 
perhaps they should use the DXpedition Fox & Hounds mode.

---
Martin, G0HDB



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel