Re: [wsjt-devel] F/H, hound unable to transmit on even times!

[Bill Frantz]

When I look back at my log, I see that I worked 3 other stations 
besides T31EU in the same FT8 subband at about the same time. We 
were on 17M and there was plenty of room for making other QSOs. 
In this particular case, it would have been a waste of bandwidth 
to allocate a full 4 KHz to this DXpedition.


On the other hand, I spent quite a bit of time before I worked 
HD8M on 40M in spite of strong signals in both directions (-6 
for their report to me and +6 for my report to them). They were 
filling at least 3 KHz with callers. They were a poster child 
for having a separate frequency allocation.


Moral of the story, not all DXpeditions are wanted enough to 
fill large blocks of spectrum. We should support one on one 
QSOs, somewhat popular stations, and the monster DXpedition that 
can fill 30+ KHz with CW callers. Handling the middle case well 
will make everyones life better.


73 Bill AE6JV

On 3/4/19 at 1:20 PM, mcduf...@ag0n.net (Gary McDuffie) wrote:




On Mar 4, 2019, at 14:03, Bill Frantz  wrote:

If there are not significant problems, then I suggest wsjt-x do just that.



Better yet, they should be on a separate frequency, not 
operating the normal FT8 segment.  They are taking up just as 
much space and causing just as much confusion as a DXpedition 
would when operating in the normal band.  I have no desire to 
contact stations that are going to do what they are.


Gary - AG0N


---
Bill Frantz| If you want total security, go to prison. 
There you're
408-356-8506   | fed, clothed, given medical care and so on. 
The only

www.pwpconsult.com | thing lacking is freedom. - Dwight D. Eisenhower



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

Re: [wsjt-devel] Busy CPU -- audio is lost

[jbozell]

Hi folks,

I'm a little late to the thread, but the symptoms described by the OP are 
similar to what I posted about earlier. During Tx/Rx cycles, ALL decodes can 
disappear for several minutes, and then return after the Tx portion is 
completed. I have been fiddling with the audio settings to see if I can change 
things but haven't been successful yet.

Joe/WB0CDY

On 3/4/19, 4:25 PM, "runninge...@gmail.com"  wrote:

Hi Mike,

Let me share my observations with Windows Remote Desktop (RDP). 
When you use Windows RDP in and out to a remote station, the remote station
will reconfigure all its audio devices each time the connection is opened or
closed. 
And this independently whether you bring the remote audio to the local PC or
not. That is a known Windows 10 problem (google : windows 10 rdp loses
remote audio). 
So any hiccup in the internet connection will result in a remote
reconfiguration of the remote audio devices. 

My solution was to abandon Windows RDP and use Teamviewer. With Teamviewer
you can happily RDP in and out without affecting the decoding. Remote
decoding was not affected and it works for a Raspberry Pi remote client as
well as a Windows Teamviewer remote client.

Hope this helps your particular case.
73's Erik
ON4PB.

Message: 1
Date: Mon, 4 Mar 2019 20:32:52 +
From: Mike Lewis 
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU
Message-ID:



Content-Type: text/plain; charset="utf-8"

Decodes do fail if the reads for the audio buffers are delayed too long and
unfortunately there is no easy way to spot this.  A debug version with audio
buffer timings displayed was used to diagnose my oddball case ultimately
tracked down to the Windows advanced power option for the Display Timeout,
had to set it to Never.  

Another case is if audio is briefly interrupted, the decoding and waterfall
stop, Monitor button remains green and the clock remains operational.  A
change to the audio in settings or restart of WSJT-X is required to get
things rolling again.  This is highly repeatable if you RDP in, start
decoding, drop the session (even quickly as an internet interruption for 1
second) and come back to see the results.  Decoding will have stopped.  

In the cases above decoding either stopped or cycles missed.  It would be
very helpful to put up a warning flag for these events.  A display or log
file message and/or Monitor button turned red or orange.  A further step
would be to attempt some self-healing such as buffer reinit after failure is
detected.  A use case: I run WSJT-X remote much of the time, mostly
monitoring in WSPR or FT8 with spotting at a remote site. I have to keep the
RDP session active all the time, and cannot tolerate any internet hiccups,
so cannot monitor through the nights reliably.

73,

Mike
K7MDL



___
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] VFO-B behavior

[Carey Fisher]

Paul,
I don't know what's different about your 7300 but mine takes too long
switching VFOs to make "rig" a viable option. Fakeit works well though.

On Mon, Mar 4, 2019 at 6:10 PM Paul Kube  wrote:

> "  perhaps there should be a note in the User Manual that, at least
> for Icom rigs, the 'Fake It' split mode is preferred/recommended?"
>
> "Rig" mode works fine with my IC-7200 and IC-7300.
>
> 73, Paul K6PO
>
> On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB 
> wrote:
>
>> On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:
>>
>> > Both conditions need to fixed.  VFO-A needs to be set as selected VFO
>> > and VFO-B set to the split freq at all times.  Otherwise a tune
>> > instigated from an external source will be on the wrong frequency.And
>> > yes...I know you can click Tune in WSJT-X and then VFO-B gets
>> > set...but that leaves the amplifier in-line with too much power to
>> > tune and for some could fry the amplifier.
>> > Mike
>>
>> Hi Mike (and all), for what it's worth I've found that using the 'Fake
>> It' split mode, rather than
>> the 'Rig' mode, works best with my Icom IC-7600.
>>
>> Some years ago, when I first tried using the 'Rig' mode with WSJT I found
>> that the time taken
>> to switch VFOs (from A to B in my case) and then to re-tune the
>> newly-selected VFO with the
>> desired offset (eg. +1kHz) was significantly longer than just re-tuning
>> the active VFO,
>> presumably because there was a longer command sequence to be received,
>> processed and
>> then actioned by the rig.  The delay in the rig switching VFOs and then
>> re-tuning was
>> resulting in the transmission not starting until (IIRC) some 2-3secs into
>> a Tx period.
>>
>> I would assume that using the 'Fake It' mode would work equally well
>> irrespective of which
>> VFO was the active one, so perhaps there should be a note in the User
>> Manual that, at least
>> for Icom rigs, the 'Fake It' split mode is preferred/recommended?
>>
>> --
>> 73, Martin G0HDB
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>>
>> ___
>> 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] VFO-B behavior

[Rebecca Milligan]

One more thought – if this group really is intended for software development 
issues, can a separate user support group be created to keep the programming 
and operator issues separate?  It could be mentioned on the WSJT-X webpage or 
in the documentation.  I think there are many who would volunteer to be in the 
group to take some of the burden off the developers.

 

73,

 

N4EFS

 

From: Rebecca Milligan [mailto:rebeccamilli...@comcast.net] 
Sent: Monday, March 4, 2019 6:47 PM
To: 'WSJT software development'
Subject: RE: [wsjt-devel] VFO-B behavior

 

I think it would be difficult for the developers  to address every rig out 
there and every circumstance.  I consider the software a gift as I did not have 
to pay for it and I am glad to put some effort into experimenting and reading 
available documentation to see what works best for my situation. There are a 
lot of forums, posts and videos posted on the web by Hams discussing such 
topics specific to WSJT-X.  

 

The manual does address “Fake It” by basically saying each user should choose 
what works best for them:

 

“Split Operation: Significant advantages result from using Split mode (separate 
VFOs for Rx and Tx) if your radio supports it. If it does not, WSJT-X can 
emulate such behavior. Either method will result in a cleaner transmitted 
signal, by keeping the Tx audio always in the range 1500 to 2000 Hz so that 
audio harmonics cannot pass through the Tx sideband filter. Select Rig to use 
the radio’s Split mode, or Fake It to have WSJT-X adjust the VFO frequency as 
needed, when T/R switching occurs. Choose None if you do not wish to use split 
operation.”

 

“On the Radio tab select Split Operation (use either Rig or Fake It; you may 
need to experiment with both options to find one that works best with your 
radio).”

 

“Be sure that your rig control has been set up for Split Operation, using 
either Rig or Fake It on the Settings | Radio tab.”

 

It is not my intent to offend anyone.  It just seems that this group, which I 
thought was intended for software development issues, such as bugs in the 
actual software, has been steered towards answering questions that are 
addressed in the manual or problems resulting from operator error (clocks, 
notch filters, QRM, etc.)  I may have misunderstood the purpose of this group 
so I could be way off base.

 

73,

 

Rebecca, N4EFS

 

 

 

From: Paul Kube [mailto:paul.k...@gmail.com] 
Sent: Monday, March 4, 2019 6:07 PM
To: marting0...@gmail.com; WSJT software development
Subject: Re: [wsjt-devel] VFO-B behavior

 

"  perhaps there should be a note in the User Manual that, at least 
for Icom rigs, the 'Fake It' split mode is preferred/recommended?"

 

"Rig" mode works fine with my IC-7200 and IC-7300.

 

73, Paul K6PO

 

On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB  
wrote:

On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:

> Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> and VFO-B set to the split freq at all times.  Otherwise a tune
> instigated from an external source will be on the wrong frequency.And
> yes...I know you can click Tune in WSJT-X and then VFO-B gets
> set...but that leaves the amplifier in-line with too much power to
> tune and for some could fry the amplifier. 
> Mike

Hi Mike (and all), for what it's worth I've found that using the 'Fake It' 
split mode, rather than 
the 'Rig' mode, works best with my Icom IC-7600.  

Some years ago, when I first tried using the 'Rig' mode with WSJT I found that 
the time taken 
to switch VFOs (from A to B in my case) and then to re-tune the newly-selected 
VFO with the 
desired offset (eg. +1kHz) was significantly longer than just re-tuning the 
active VFO, 
presumably because there was a longer command sequence to be received, 
processed and 
then actioned by the rig.  The delay in the rig switching VFOs and then 
re-tuning was 
resulting in the transmission not starting until (IIRC) some 2-3secs into a Tx 
period.

I would assume that using the 'Fake It' mode would work equally well 
irrespective of which 
VFO was the active one, so perhaps there should be a note in the User Manual 
that, at least 
for Icom rigs, the 'Fake It' split mode is preferred/recommended?

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
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] VFO-B behavior

[Rebecca Milligan]

I think it would be difficult for the developers  to address every rig out 
there and every circumstance.  I consider the software a gift as I did not have 
to pay for it and I am glad to put some effort into experimenting and reading 
available documentation to see what works best for my situation. There are a 
lot of forums, posts and videos posted on the web by Hams discussing such 
topics specific to WSJT-X.  

 

The manual does address “Fake It” by basically saying each user should choose 
what works best for them:

 

“Split Operation: Significant advantages result from using Split mode (separate 
VFOs for Rx and Tx) if your radio supports it. If it does not, WSJT-X can 
emulate such behavior. Either method will result in a cleaner transmitted 
signal, by keeping the Tx audio always in the range 1500 to 2000 Hz so that 
audio harmonics cannot pass through the Tx sideband filter. Select Rig to use 
the radio’s Split mode, or Fake It to have WSJT-X adjust the VFO frequency as 
needed, when T/R switching occurs. Choose None if you do not wish to use split 
operation.”

 

“On the Radio tab select Split Operation (use either Rig or Fake It; you may 
need to experiment with both options to find one that works best with your 
radio).”

 

“Be sure that your rig control has been set up for Split Operation, using 
either Rig or Fake It on the Settings | Radio tab.”

 

It is not my intent to offend anyone.  It just seems that this group, which I 
thought was intended for software development issues, such as bugs in the 
actual software, has been steered towards answering questions that are 
addressed in the manual or problems resulting from operator error (clocks, 
notch filters, QRM, etc.)  I may have misunderstood the purpose of this group 
so I could be way off base.

 

73,

 

Rebecca, N4EFS

 

 

 

From: Paul Kube [mailto:paul.k...@gmail.com] 
Sent: Monday, March 4, 2019 6:07 PM
To: marting0...@gmail.com; WSJT software development
Subject: Re: [wsjt-devel] VFO-B behavior

 

"  perhaps there should be a note in the User Manual that, at least 
for Icom rigs, the 'Fake It' split mode is preferred/recommended?"

 

"Rig" mode works fine with my IC-7200 and IC-7300.

 

73, Paul K6PO

 

On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB  
wrote:

On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:

> Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> and VFO-B set to the split freq at all times.  Otherwise a tune
> instigated from an external source will be on the wrong frequency.And
> yes...I know you can click Tune in WSJT-X and then VFO-B gets
> set...but that leaves the amplifier in-line with too much power to
> tune and for some could fry the amplifier. 
> Mike

Hi Mike (and all), for what it's worth I've found that using the 'Fake It' 
split mode, rather than 
the 'Rig' mode, works best with my Icom IC-7600.  

Some years ago, when I first tried using the 'Rig' mode with WSJT I found that 
the time taken 
to switch VFOs (from A to B in my case) and then to re-tune the newly-selected 
VFO with the 
desired offset (eg. +1kHz) was significantly longer than just re-tuning the 
active VFO, 
presumably because there was a longer command sequence to be received, 
processed and 
then actioned by the rig.  The delay in the rig switching VFOs and then 
re-tuning was 
resulting in the transmission not starting until (IIRC) some 2-3secs into a Tx 
period.

I would assume that using the 'Fake It' mode would work equally well 
irrespective of which 
VFO was the active one, so perhaps there should be a note in the User Manual 
that, at least 
for Icom rigs, the 'Fake It' split mode is preferred/recommended?

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
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] Busy CPU -- audio is lost

[runningerik]

Hi Mike,

Let me share my observations with Windows Remote Desktop (RDP). 
When you use Windows RDP in and out to a remote station, the remote station
will reconfigure all its audio devices each time the connection is opened or
closed. 
And this independently whether you bring the remote audio to the local PC or
not. That is a known Windows 10 problem (google : windows 10 rdp loses
remote audio). 
So any hiccup in the internet connection will result in a remote
reconfiguration of the remote audio devices. 

My solution was to abandon Windows RDP and use Teamviewer. With Teamviewer
you can happily RDP in and out without affecting the decoding. Remote
decoding was not affected and it works for a Raspberry Pi remote client as
well as a Windows Teamviewer remote client.

Hope this helps your particular case.
73's Erik
ON4PB.

Message: 1
Date: Mon, 4 Mar 2019 20:32:52 +
From: Mike Lewis 
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU
Message-ID:



Content-Type: text/plain; charset="utf-8"

Decodes do fail if the reads for the audio buffers are delayed too long and
unfortunately there is no easy way to spot this.  A debug version with audio
buffer timings displayed was used to diagnose my oddball case ultimately
tracked down to the Windows advanced power option for the Display Timeout,
had to set it to Never.  

Another case is if audio is briefly interrupted, the decoding and waterfall
stop, Monitor button remains green and the clock remains operational.  A
change to the audio in settings or restart of WSJT-X is required to get
things rolling again.  This is highly repeatable if you RDP in, start
decoding, drop the session (even quickly as an internet interruption for 1
second) and come back to see the results.  Decoding will have stopped.  

In the cases above decoding either stopped or cycles missed.  It would be
very helpful to put up a warning flag for these events.  A display or log
file message and/or Monitor button turned red or orange.  A further step
would be to attempt some self-healing such as buffer reinit after failure is
detected.  A use case: I run WSJT-X remote much of the time, mostly
monitoring in WSPR or FT8 with spotting at a remote site. I have to keep the
RDP session active all the time, and cannot tolerate any internet hiccups,
so cannot monitor through the nights reliably.

73,

Mike
K7MDL



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

Re: [wsjt-devel] VFO-B behavior

[Tag Loomis (Tag)]

I have an IC-7300 and I can confirm that VFO-B does not change on band
change until TX

On Mon, Mar 4, 2019 at 3:10 PM Paul Kube  wrote:

> "  perhaps there should be a note in the User Manual that, at least
> for Icom rigs, the 'Fake It' split mode is preferred/recommended?"
>
> "Rig" mode works fine with my IC-7200 and IC-7300.
>
> 73, Paul K6PO
>
> On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB 
> wrote:
>
>> On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:
>>
>> > Both conditions need to fixed.  VFO-A needs to be set as selected VFO
>> > and VFO-B set to the split freq at all times.  Otherwise a tune
>> > instigated from an external source will be on the wrong frequency.And
>> > yes...I know you can click Tune in WSJT-X and then VFO-B gets
>> > set...but that leaves the amplifier in-line with too much power to
>> > tune and for some could fry the amplifier.
>> > Mike
>>
>> Hi Mike (and all), for what it's worth I've found that using the 'Fake
>> It' split mode, rather than
>> the 'Rig' mode, works best with my Icom IC-7600.
>>
>> Some years ago, when I first tried using the 'Rig' mode with WSJT I found
>> that the time taken
>> to switch VFOs (from A to B in my case) and then to re-tune the
>> newly-selected VFO with the
>> desired offset (eg. +1kHz) was significantly longer than just re-tuning
>> the active VFO,
>> presumably because there was a longer command sequence to be received,
>> processed and
>> then actioned by the rig.  The delay in the rig switching VFOs and then
>> re-tuning was
>> resulting in the transmission not starting until (IIRC) some 2-3secs into
>> a Tx period.
>>
>> I would assume that using the 'Fake It' mode would work equally well
>> irrespective of which
>> VFO was the active one, so perhaps there should be a note in the User
>> Manual that, at least
>> for Icom rigs, the 'Fake It' split mode is preferred/recommended?
>>
>> --
>> 73, Martin G0HDB
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>>
>>
>> ___
>> 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] VFO-B behavior

[Paul Kube]

"  perhaps there should be a note in the User Manual that, at least
for Icom rigs, the 'Fake It' split mode is preferred/recommended?"

"Rig" mode works fine with my IC-7200 and IC-7300.

73, Paul K6PO

On Mon, Mar 4, 2019 at 1:45 PM Martin Davies G0HDB 
wrote:

> On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:
>
> > Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> > and VFO-B set to the split freq at all times.  Otherwise a tune
> > instigated from an external source will be on the wrong frequency.And
> > yes...I know you can click Tune in WSJT-X and then VFO-B gets
> > set...but that leaves the amplifier in-line with too much power to
> > tune and for some could fry the amplifier.
> > Mike
>
> Hi Mike (and all), for what it's worth I've found that using the 'Fake It'
> split mode, rather than
> the 'Rig' mode, works best with my Icom IC-7600.
>
> Some years ago, when I first tried using the 'Rig' mode with WSJT I found
> that the time taken
> to switch VFOs (from A to B in my case) and then to re-tune the
> newly-selected VFO with the
> desired offset (eg. +1kHz) was significantly longer than just re-tuning
> the active VFO,
> presumably because there was a longer command sequence to be received,
> processed and
> then actioned by the rig.  The delay in the rig switching VFOs and then
> re-tuning was
> resulting in the transmission not starting until (IIRC) some 2-3secs into
> a Tx period.
>
> I would assume that using the 'Fake It' mode would work equally well
> irrespective of which
> VFO was the active one, so perhaps there should be a note in the User
> Manual that, at least
> for Icom rigs, the 'Fake It' split mode is preferred/recommended?
>
> --
> 73, Martin G0HDB
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> 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] Busy CPU

[Mike Lewis]

Agreed, would love to see error messages for decode failure situations.  Should 
help to reduce the support burden as it is a difficult thing to diagnose.  One 
more item for a long list... 

-Original Message-
From: Joe Taylor  
Sent: Monday, March 4, 2019 17:27
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU

Hi Mike,

Neither of the cases you describe is the result of a slow or overburdened CPU, 
which is what K0VM thought he was observing.

Obviously you must have a properly functioning audio system with no buffer 
underruns, etc., or decoding will be compromised.
Power-save options that cause parts of your system to "sleep" can certainly 
cause problems.  Properly tuning and operating a remote system is non-trivial.

-- 73, Joe, K1JT

On 3/4/2019 15:32, Mike Lewis wrote:
> Decodes do fail if the reads for the audio buffers are delayed too long and 
> unfortunately there is no easy way to spot this.  A debug version with audio 
> buffer timings displayed was used to diagnose my oddball case ultimately 
> tracked down to the Windows advanced power option for the Display Timeout, 
> had to set it to Never.
> 
> Another case is if audio is briefly interrupted, the decoding and waterfall 
> stop, Monitor button remains green and the clock remains operational.  A 
> change to the audio in settings or restart of WSJT-X is required to get 
> things rolling again.  This is highly repeatable if you RDP in, start 
> decoding, drop the session (even quickly as an internet interruption for 1 
> second) and come back to see the results.  Decoding will have stopped.
> 
> In the cases above decoding either stopped or cycles missed.  It would be 
> very helpful to put up a warning flag for these events.  A display or log 
> file message and/or Monitor button turned red or orange.  A further step 
> would be to attempt some self-healing such as buffer reinit after failure is 
> detected.  A use case: I run WSJT-X remote much of the time, mostly 
> monitoring in WSPR or FT8 with spotting at a remote site. I have to keep the 
> RDP session active all the time, and cannot tolerate any internet hiccups, so 
> cannot monitor through the nights reliably.
> 
> 73,
> 
> Mike
> K7MDL
> 
> -Original Message-
> From: Joe Taylor 
> Sent: Monday, March 4, 2019 15:00
> To: WSJT software development 
> Subject: Re: [wsjt-devel] Busy CPU
> 
> Hi Al,
> 
> Decodes do not fail because of a slow or overburdened CPU.  They simply take 
> longer.
> 
> This is true for all modes supported in WSJT, MAP65, and WSJT-X.
> 
>   -- 73, Joe, K1JT
> 
> On 3/4/2019 2:37 PM, Al K0VM wrote:
>> (WSJT-X 2.0.1)
>>     I have noticed that at times while running FT8 or WSPR, that 
>> decodes failed or where missed.  Further observation reveals that 
>> this can occur when the CPU it at or near 100% load. In WSPR the 
>> decode button never highlighted. In FT8, the decode button 
>> highlighted but no decode where displayed. ( the time was correct and 
>> signals where displayed int the wide graph.
>>     It's easy to say to a user 'reduce the CPU load' or 'get a bigger 
>> CPU' but there is no clue for a new user that the decodes failed for 
>> CPU loading.
>>     I think it would be useful if WSJT-X could pop up a message 
>> stating 'Decode failed due to lack of CPU resources'
>>
>> AL, K0VM
> 
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%
> 7C380a1d0e5e8c42d7174108d6a0f0daa4%7C84df9e7fe9f640afb435%
> 7C1%7C0%7C636873353668149462sdata=46wWhUiIb%2BXK5DpCgPTpOvsQwMxp6
> 6RBCctNEK%2BsBWg%3Dreserved=0
> 
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%
> 7C380a1d0e5e8c42d7174108d6a0f0daa4%7C84df9e7fe9f640afb435%
> 7C1%7C0%7C636873353668159473sdata=6VHEirt1ZD45cYmoS8TftGxkST8yfvf
> RrE7F26edjrE%3Dreserved=0
> 


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C380a1d0e5e8c42d7174108d6a0f0daa4%7C84df9e7fe9f640afb435%7C1%7C0%7C636873353668159473sdata=6VHEirt1ZD45cYmoS8TftGxkST8yfvfRrE7F26edjrE%3Dreserved=0

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

Re: [wsjt-devel] Busy CPU

[Joe Taylor]

Hi Mike,

Neither of the cases you describe is the result of a slow or 
overburdened CPU, which is what K0VM thought he was observing.


Obviously you must have a properly functioning audio system with no 
buffer underruns, etc., or decoding will be compromised.
Power-save options that cause parts of your system to "sleep" can 
certainly cause problems.  Properly tuning and operating a remote system 
is non-trivial.


-- 73, Joe, K1JT

On 3/4/2019 15:32, Mike Lewis wrote:

Decodes do fail if the reads for the audio buffers are delayed too long and 
unfortunately there is no easy way to spot this.  A debug version with audio 
buffer timings displayed was used to diagnose my oddball case ultimately 
tracked down to the Windows advanced power option for the Display Timeout, had 
to set it to Never.

Another case is if audio is briefly interrupted, the decoding and waterfall 
stop, Monitor button remains green and the clock remains operational.  A change 
to the audio in settings or restart of WSJT-X is required to get things rolling 
again.  This is highly repeatable if you RDP in, start decoding, drop the 
session (even quickly as an internet interruption for 1 second) and come back 
to see the results.  Decoding will have stopped.

In the cases above decoding either stopped or cycles missed.  It would be very 
helpful to put up a warning flag for these events.  A display or log file 
message and/or Monitor button turned red or orange.  A further step would be to 
attempt some self-healing such as buffer reinit after failure is detected.  A 
use case: I run WSJT-X remote much of the time, mostly monitoring in WSPR or 
FT8 with spotting at a remote site. I have to keep the RDP session active all 
the time, and cannot tolerate any internet hiccups, so cannot monitor through 
the nights reliably.

73,

Mike
K7MDL

-Original Message-
From: Joe Taylor 
Sent: Monday, March 4, 2019 15:00
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU

Hi Al,

Decodes do not fail because of a slow or overburdened CPU.  They simply take 
longer.

This is true for all modes supported in WSJT, MAP65, and WSJT-X.

-- 73, Joe, K1JT

On 3/4/2019 2:37 PM, Al K0VM wrote:

(WSJT-X 2.0.1)
    I have noticed that at times while running FT8 or WSPR, that
decodes failed or where missed.  Further observation reveals that this
can occur when the CPU it at or near 100% load. In WSPR the decode
button never highlighted. In FT8, the decode button highlighted but no
decode where displayed. ( the time was correct and signals where
displayed int the wide graph.
    It's easy to say to a user 'reduce the CPU load' or 'get a bigger
CPU' but there is no clue for a new user that the decodes failed for
CPU loading.
    I think it would be useful if WSJT-X could pop up a message stating
'Decode failed due to lack of CPU resources'

AL, K0VM



___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C8dd1b8d042364306902d08d6a0dc492b%7C84df9e7fe9f640afb435%7C1%7C0%7C636873265307109935sdata=tslgcUZaShr%2F%2B4IiZQzyykUzo%2FeYNGE%2BNUZDwq4hjwg%3Dreserved=0

___
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] VFO-B behavior

[Martin Davies G0HDB]

On 4 Mar 2019 at 4:51, Black Michael via wsjt-devel wrote:

> Both conditions need to fixed.  VFO-A needs to be set as selected VFO
> and VFO-B set to the split freq at all times.  Otherwise a tune
> instigated from an external source will be on the wrong frequency.And
> yes...I know you can click Tune in WSJT-X and then VFO-B gets
> set...but that leaves the amplifier in-line with too much power to
> tune and for some could fry the amplifier. 
> Mike

Hi Mike (and all), for what it's worth I've found that using the 'Fake It' 
split mode, rather than 
the 'Rig' mode, works best with my Icom IC-7600.  

Some years ago, when I first tried using the 'Rig' mode with WSJT I found that 
the time taken 
to switch VFOs (from A to B in my case) and then to re-tune the newly-selected 
VFO with the 
desired offset (eg. +1kHz) was significantly longer than just re-tuning the 
active VFO, 
presumably because there was a longer command sequence to be received, 
processed and 
then actioned by the rig.  The delay in the rig switching VFOs and then 
re-tuning was 
resulting in the transmission not starting until (IIRC) some 2-3secs into a Tx 
period.

I would assume that using the 'Fake It' mode would work equally well 
irrespective of which 
VFO was the active one, so perhaps there should be a note in the User Manual 
that, at least 
for Icom rigs, the 'Fake It' split mode is preferred/recommended?

--
73, Martin G0HDB


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



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

Re: [wsjt-devel] F/H, hound unable to transmit on even times!

[Gary McDuffie]

> On Mar 4, 2019, at 14:03, Bill Frantz  wrote:
> 
> If there are not significant problems, then I suggest wsjt-x do just that.


Better yet, they should be on a separate frequency, not operating the normal 
FT8 segment.  They are taking up just as much space and causing just as much 
confusion as a DXpedition would when operating in the normal band.  I have no 
desire to contact stations that are going to do what they are.

Gary - AG0N

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

Re: [wsjt-devel] F/H, hound unable to transmit on even times!

[Bill Frantz]

When I worked T31EU today, I noticed that wsjt-x didn't 
understand that the message:


192015  -9  0.4 1529 ~  AB4UF RR73; AE6JV  -06

was a TX 2 message to me (AE6JV) and continued to send the TX 1 
message. I assume it didn't parse the message because it wasn't 
in fox/hound mode. What problems would parsing the message in 
normal mode and allowing the Auto Seq to work cause?


If there are not significant problems, then I suggest wsjt-x do 
just that.


73 Bill AE6JV

On 3/2/19 at 9:39 AM, n...@hotmail.com (Fred Price) wrote:

Not DXPedition mode but a clone running what they call 
multi-thread. Just use normal FT8 to work them if they are on 
normal FT8 frequencies as DXPedition mode doesn't work on the 
normal frequencies.


On Mar 2, 2019 11:39 AM, Bill Mullin  wrote:
New member here, forgive me if this has been asked before!

T31EU was on 3.574 in F/H mode, at least I thought he was after seeing the 
following line:

134545 -6 2.5 489 ~ JA0EBV RR73; UK8AEA  -14

As you can see, the Fox was transmitting on the odd seconds 
(15, 45).  But WSJT-X would not allow me to transmit on the 
even times (00, 30), only on the odds.  Because of this, I was 
unable to work the Fox.  I dug in the F/H documentation and saw 
no requirement that the Fox transmit on the even times.  So is 
this a bug in 2.0.1 or was I doing something wrong?  I also 
reloaded 2.0.0 as a test, but again I was unable to transmit as 
a Hound on even times.


Maybe I should ask if there is a requirement in F/H that the 
Fox stay on even times and the Hound on odd?  If so, how do you 
explain the above F/H line from T31EU?


73, Bill - AA4M



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


---
Bill Frantz| Truth and love must prevail  | Periwinkle
(408)356-8506  | over lies and hate.  | 16345 
Englewood Ave
www.pwpconsult.com |   - Vaclav Havel | Los Gatos, 
CA 95032




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

Re: [wsjt-devel] Busy CPU

[Mike Lewis]

Decodes do fail if the reads for the audio buffers are delayed too long and 
unfortunately there is no easy way to spot this.  A debug version with audio 
buffer timings displayed was used to diagnose my oddball case ultimately 
tracked down to the Windows advanced power option for the Display Timeout, had 
to set it to Never.  

Another case is if audio is briefly interrupted, the decoding and waterfall 
stop, Monitor button remains green and the clock remains operational.  A change 
to the audio in settings or restart of WSJT-X is required to get things rolling 
again.  This is highly repeatable if you RDP in, start decoding, drop the 
session (even quickly as an internet interruption for 1 second) and come back 
to see the results.  Decoding will have stopped.  

In the cases above decoding either stopped or cycles missed.  It would be very 
helpful to put up a warning flag for these events.  A display or log file 
message and/or Monitor button turned red or orange.  A further step would be to 
attempt some self-healing such as buffer reinit after failure is detected.  A 
use case: I run WSJT-X remote much of the time, mostly monitoring in WSPR or 
FT8 with spotting at a remote site. I have to keep the RDP session active all 
the time, and cannot tolerate any internet hiccups, so cannot monitor through 
the nights reliably.

73,

Mike
K7MDL

-Original Message-
From: Joe Taylor  
Sent: Monday, March 4, 2019 15:00
To: WSJT software development 
Subject: Re: [wsjt-devel] Busy CPU

Hi Al,

Decodes do not fail because of a slow or overburdened CPU.  They simply take 
longer.

This is true for all modes supported in WSJT, MAP65, and WSJT-X.

-- 73, Joe, K1JT

On 3/4/2019 2:37 PM, Al K0VM wrote:
> (WSJT-X 2.0.1)
>    I have noticed that at times while running FT8 or WSPR, that 
> decodes failed or where missed.  Further observation reveals that this 
> can occur when the CPU it at or near 100% load. In WSPR the decode 
> button never highlighted. In FT8, the decode button highlighted but no 
> decode where displayed. ( the time was correct and signals where 
> displayed int the wide graph.
>    It's easy to say to a user 'reduce the CPU load' or 'get a bigger 
> CPU' but there is no clue for a new user that the decodes failed for 
> CPU loading.
>    I think it would be useful if WSJT-X could pop up a message stating 
> 'Decode failed due to lack of CPU resources'
> 
> AL, K0VM


___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fwsjt-develdata=02%7C01%7C%7C8dd1b8d042364306902d08d6a0dc492b%7C84df9e7fe9f640afb435%7C1%7C0%7C636873265307109935sdata=tslgcUZaShr%2F%2B4IiZQzyykUzo%2FeYNGE%2BNUZDwq4hjwg%3Dreserved=0

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

Re: [wsjt-devel] Busy CPU

[Joe Taylor]

Hi Al,

Decodes do not fail because of a slow or overburdened CPU.  They simply 
take longer.


This is true for all modes supported in WSJT, MAP65, and WSJT-X.

-- 73, Joe, K1JT

On 3/4/2019 2:37 PM, Al K0VM wrote:

(WSJT-X 2.0.1)
   I have noticed that at times while running FT8 or WSPR, that decodes 
failed or where missed.  Further observation reveals that this can occur 
when the CPU it at or near 100% load. In WSPR the decode button never 
highlighted. In FT8, the decode button highlighted but no decode where 
displayed. ( the time was correct and signals where displayed int the 
wide graph.
   It's easy to say to a user 'reduce the CPU load' or 'get a bigger 
CPU' but there is no clue for a new user that the decodes failed for CPU 
loading.
   I think it would be useful if WSJT-X could pop up a message stating 
'Decode failed due to lack of CPU resources'


AL, K0VM



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

[wsjt-devel] Busy CPU

[Al]

(WSJT-X 2.0.1)
  I have noticed that at times while running FT8 or WSPR, that decodes 
failed or where missed.  Further observation reveals that this can occur 
when the CPU it at or near 100% load. In WSPR the decode button never 
highlighted. In FT8, the decode button highlighted but no decode where 
displayed. ( the time was correct and signals where displayed int the 
wide graph.
  It's easy to say to a user 'reduce the CPU load' or 'get a bigger 
CPU' but there is no clue for a new user that the decodes failed for CPU 
loading.
  I think it would be useful if WSJT-X could pop up a message stating 
'Decode failed due to lack of CPU resources'


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

Re: [wsjt-devel] What's causing this?

[Bill Mullin]

Another question - is there any way to turn off the time/band indicators 
at the left of the grid, without changing the height of the listening 
segments?


Thanks, AA4M

On 2019-03-04 06:55:47, Bill Somerville wrote:

Hi Bill,

looks like you have the notch filter engaged on your receiver.

73
Bill
G4WJS.

On 04/03/2019 13:52, Bill Mullin wrote:

Like this:
*
**http://aa4m.com/links/Flatten_Off.jpg*

That's definitely not the fix!

73

On 2019-03-04 06:39:47, Black Michael via wsjt-devel wrote:

What does it look like with Flatten turned off?

de Mike W9MDB




On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin 
 wrote:



I have "dead space" running from about 1300 - 1700 on all bands:

*http://aa4m.com/links/Problem.jpg*

This screen capture shows that this dead space is in the same 
location on 80, 40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and 
have been since the day it came out.  This problem started 
yesterday, so I don't think it's a glitch in the program.  I've 
probably (accidentally) screwed up a parameter but I have no idea 
which one.  Can anyone help?


73, Bill - AA4M





___
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] What's causing this?

[Bill Mullin]

That was it, I was using the notch during the ARRL SSB contest and 
forgot to turn it off!


Thank you Bill, George & Mike!

73, Bill - AA4M

On 2019-03-04 06:55:47, Bill Somerville wrote:

Hi Bill,

looks like you have the notch filter engaged on your receiver.

73
Bill
G4WJS.

On 04/03/2019 13:52, Bill Mullin wrote:

Like this:
*
**http://aa4m.com/links/Flatten_Off.jpg*

That's definitely not the fix!

73

On 2019-03-04 06:39:47, Black Michael via wsjt-devel wrote:

What does it look like with Flatten turned off?

de Mike W9MDB




On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin 
 wrote:



I have "dead space" running from about 1300 - 1700 on all bands:

*http://aa4m.com/links/Problem.jpg*

This screen capture shows that this dead space is in the same 
location on 80, 40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and 
have been since the day it came out.  This problem started 
yesterday, so I don't think it's a glitch in the program.  I've 
probably (accidentally) screwed up a parameter but I have no idea 
which one.  Can anyone help?


73, Bill - AA4M





___
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] What's causing this?

[Don AA5AU]

 Kind of looks like you might have the notch filter enabled on your radio?
Don AA5AU
On Monday, March 4, 2019, 7:33:55 AM CST, Bill Mullin  
wrote:  
 
   I have "dead space" running from about 1300 - 1700 on all bands:
 
 http://aa4m.com/links/Problem.jpg
 
 This screen capture shows that this dead space is in the same location on 80, 
40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and have been since the day it 
came out.  This problem started yesterday, so I don't think it's a glitch in 
the program.  I've probably (accidentally) screwed up a parameter but I have no 
idea which one.  Can anyone help?
 
 73, Bill - AA4M
 
  ___
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] What's causing this?

[Black Michael via wsjt-devel]

Flatten off just shows you what the "real" spectrum looks like.  Flatten tries 
to make it more user-friendly and works well with flat background noise.
But I agree that looks like a notch filter.
Mike

 

On Monday, March 4, 2019, 7:56:28 AM CST, Bill Mullin  
wrote:  
 
  Like this:
 
 http://aa4m.com/links/Flatten_Off.jpg
 
 That's definitely not the fix!
 
 73
 
 On 2019-03-04 06:39:47, Black Michael via wsjt-devel wrote:
  
 
  What does it look like with Flatten turned off? 
  de Mike W9MDB 
   

  
  On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin  
wrote:  
  
 I have "dead space" running from about 1300 - 1700 on all bands:
 
 http://aa4m.com/links/Problem.jpg
 
 This screen capture shows that this dead space is in the same location on 80, 
40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and have been since the day it 
came out.  This problem started yesterday, so I don't think it's a glitch in 
the program.  I've probably (accidentally) screwed up a parameter but I have no 
idea which one.  Can anyone help?
 
 73, Bill - AA4M
 
___
 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] What's causing this?

[Bill Somerville]

Hi Bill,

looks like you have the notch filter engaged on your receiver.

73
Bill
G4WJS.

On 04/03/2019 13:52, Bill Mullin wrote:

Like this:
*
**http://aa4m.com/links/Flatten_Off.jpg*

That's definitely not the fix!

73

On 2019-03-04 06:39:47, Black Michael via wsjt-devel wrote:

What does it look like with Flatten turned off?

de Mike W9MDB




On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin 
 wrote:



I have "dead space" running from about 1300 - 1700 on all bands:

*http://aa4m.com/links/Problem.jpg*

This screen capture shows that this dead space is in the same 
location on 80, 40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and 
have been since the day it came out.  This problem started yesterday, 
so I don't think it's a glitch in the program.  I've probably 
(accidentally) screwed up a parameter but I have no idea which one.  
Can anyone help?


73, Bill - AA4M



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

Re: [wsjt-devel] What's causing this?

[Bill Mullin]

Like this:
*
**http://aa4m.com/links/Flatten_Off.jpg*

That's definitely not the fix!

73

On 2019-03-04 06:39:47, Black Michael via wsjt-devel wrote:

What does it look like with Flatten turned off?

de Mike W9MDB




On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin 
 wrote:



I have "dead space" running from about 1300 - 1700 on all bands:

*http://aa4m.com/links/Problem.jpg*

This screen capture shows that this dead space is in the same location 
on 80, 40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and have been 
since the day it came out.  This problem started yesterday, so I don't 
think it's a glitch in the program.  I've probably (accidentally) 
screwed up a parameter but I have no idea which one.  Can anyone help?


73, Bill - AA4M

___
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] What's causing this?

[Black Michael via wsjt-devel]

What does it look like with Flatten turned off?
de Mike W9MDB

 

On Monday, March 4, 2019, 7:36:18 AM CST, Bill Mullin  
wrote:  
 
   I have "dead space" running from about 1300 - 1700 on all bands:
 
 http://aa4m.com/links/Problem.jpg
 
 This screen capture shows that this dead space is in the same location on 80, 
40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and have been since the day it 
came out.  This problem started yesterday, so I don't think it's a glitch in 
the program.  I've probably (accidentally) screwed up a parameter but I have no 
idea which one.  Can anyone help?
 
 73, Bill - AA4M
 
  ___
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] What's causing this?

[Bill Mullin]

I have "dead space" running from about 1300 - 1700 on all bands:

*http://aa4m.com/links/Problem.jpg*

This screen capture shows that this dead space is in the same location 
on 80, 40, 30, and 20 meters.  I'm running WSJT-X 2.0.1 and have been 
since the day it came out.  This problem started yesterday, so I don't 
think it's a glitch in the program.  I've probably (accidentally) 
screwed up a parameter but I have no idea which one.  Can anyone help?


73, Bill - AA4M

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