Re: [wsjt-devel] Cannot find path

[charlie]

Hi Jim

The same happened to me just before the FT8 Dxpedition test, for the first
time.  In my case this was with 1.9 that has been installed and stable for
some time.

I was able to fix it by going to Settings-> Audio and pressing 'Select'
and browsing to the standard locations (in my case c:/Users/User/AppData/
Local/WSJT-X/save.

I don't know why the cannot find path specified warning appeared.

73

Charlie G3WDG


 > Hi:
>
> After the fun of about a thousand Qs and switching to 1.9, I started to
> get the "cannot find path specified" error message with every cycle.
>
> I have attempted to reset "Location" in the Audio Save Directory with no
> success.
>
> Can someone please give me a pointer on how establish the path to direct
> the wave file.
>
> Thanks 
>
> Jim W8CZN
> I have save set to "none"
>  Saku  wrote:
>> Hi!
>>
>> This small patch seems to stop duplicate decodes in
>> BandActivity/UDP/ALL.TEXT  and makes touching "CQ only" to take *effect
>> from next decode onwards*.
>>
>> Just what I tried to describe...
>>
>> --
>> Saku
>> OH1KH
>>
>>
>> Bill Somerville kirjoitti 06.04.2018 klo 19:43:
>> > On 06/04/2018 17:39, Bill Somerville wrote:
>> >> this is not really a defect. If you have "CQ Only" checked then
>> >> non-CQ decodes are discarded and cannot be recovered. Un-checking the
>> >> option causes the decoder to redo the decode on the sample buffer.
>> >> The same applies to checking the "CQ Only" option except that CQ
>> >> decodes are discarded. If you do not want duplicated UDP Decode
>> >> messages nor duplicates in the ALL.TXT file then all I can suggest is
>> >> that you do not use the "CQ Only" option. BTW it is possible that the
>> >> repeated decode passes may have different results if the Rx audio
>> >> offset, decode depth, waterfall width, or AP settings have been
>> changed.
>> >
>> > Fixing a critical typo:
>> >
>> > this is not really a defect. If you have "CQ Only" checked then non-CQ
>> > decodes are discarded and cannot be recovered. Un-checking the option
>> > causes the decoder to redo the decode on the sample buffer. The same
>> > applies to checking the "CQ Only" option except that *non-* CQ decodes
>> > are discarded. If you do not want duplicated UDP Decode messages nor
>> > duplicates in the ALL.TXT file then all I can suggest is that you do
>> > not use the "CQ Only" option. BTW it is possible that the repeated
>> > decode passes may have different results if the Rx audio offset,
>> > decode depth, waterfall width, or AP settings have been changed.
>> >
>> > 73
>> > Bill
>> > G4WJS.
>> >
>> >
>> > --
>> >
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > ___
>> > wsjt-devel mailing list
>> > wsjt-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>> >
>>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 1400-1600 UTC

[Tsutsumi Takehiko]

Hi Bill and Robin,

I think I do not need to further explain about my words in my previous memo to 
WSJT-X experts like you but I doublchedked my understanding about “TDM and FDM” 
fundamentals has the validity or not through google search.

You can see several cons for TDM about non-linearity from the analog age.

For example.

https://techdifferences.com/difference-between-tdm-and-fdm.html

As you know, 4G technology introduces Single-carrier FDMA for mobile terminal 
usage (cost of the power amplifier) to reduce lower-to-average power ratio 
(PARR) against OFDMA.

https://en.wikipedia.org/wiki/Single-carrier_FDMA

I interpret the principle is unchanged from the analog age to modern 4G and it 
can be sharable for us.

Regards,

take

de JA5AEA

Sent from Mail for Windows 10


From: Tsutsumi Takehiko 
Sent: Monday, April 9, 2018 11:07:24 AM
To: WSJT software development
Subject: Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 
1400-1600 UTC

Hi Bill and Robin,

So, we stay at single carrier architecture along with 5x clock for the purpose 
to maintain the encoder and decoder codes.

Regards,

take

de JA5AEA


Hi Take-san,



the output when NSlots >1 is not a simple distribution of the Tx power

between tones, the reason for this is that multiple tones will mix and

some filtering is necessary to minimize undesirable side-bands. The

result for NSlots=5 is a power reduction per signal of ~14dB with

respect to an NSlot=1 transmission using the same radio settings.



73

Bill

G4WJS.


Take-san,



for a small number of constant level carriers, such as 5, they should be

considered to add in phase when passed through a clipping amplifier,

rather than according to individual power. Thus the second term in the

formula quoted below would be -20log_10 (5), about -14dB, rather than -7dB.



If these constant carriers are not considered to add in phase, rather

than according to power, then the signal will clip, causing

intermodulation products and worse, depending on the degree of clipping.



Hope this helps,



Robin, G8DQX

Sent from Mail for Windows 10

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Cannot find path

[jtullis]

Hi:

After the fun of about a thousand Qs and switching to 1.9, I started to get the 
"cannot find path specified" error message with every cycle.

I have attempted to reset "Location" in the Audio Save Directory with no 
success.

Can someone please give me a pointer on how establish the path to direct the 
wave file.

Thanks 

Jim W8CZN
I have save set to "none" 
 Saku  wrote: 
> Hi!
> 
> This small patch seems to stop duplicate decodes in 
> BandActivity/UDP/ALL.TEXT  and makes touching "CQ only" to take *effect 
> from next decode onwards*.
> 
> Just what I tried to describe...
> 
> -- 
> Saku
> OH1KH
> 
> 
> Bill Somerville kirjoitti 06.04.2018 klo 19:43:
> > On 06/04/2018 17:39, Bill Somerville wrote:
> >> this is not really a defect. If you have "CQ Only" checked then 
> >> non-CQ decodes are discarded and cannot be recovered. Un-checking the 
> >> option causes the decoder to redo the decode on the sample buffer. 
> >> The same applies to checking the "CQ Only" option except that CQ 
> >> decodes are discarded. If you do not want duplicated UDP Decode 
> >> messages nor duplicates in the ALL.TXT file then all I can suggest is 
> >> that you do not use the "CQ Only" option. BTW it is possible that the 
> >> repeated decode passes may have different results if the Rx audio 
> >> offset, decode depth, waterfall width, or AP settings have been changed.
> >
> > Fixing a critical typo:
> >
> > this is not really a defect. If you have "CQ Only" checked then non-CQ 
> > decodes are discarded and cannot be recovered. Un-checking the option 
> > causes the decoder to redo the decode on the sample buffer. The same 
> > applies to checking the "CQ Only" option except that *non-* CQ decodes 
> > are discarded. If you do not want duplicated UDP Decode messages nor 
> > duplicates in the ALL.TXT file then all I can suggest is that you do 
> > not use the "CQ Only" option. BTW it is possible that the repeated 
> > decode passes may have different results if the Rx audio offset, 
> > decode depth, waterfall width, or AP settings have been changed.
> >
> > 73
> > Bill
> > G4WJS.
> >
> >
> > --
> >  
> >
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: early results

[Joe Taylor]

Hi John,

On 4/9/2018 12:00 PM, John Nelson G4KLA wrote:


Any reason why W1/KH7Z ceased transmissions at 143630?   Wasn’t in the plan...


Our announcements have included this advice:

"Real-time liaison will be available on the "Ping Jockey Relief" chat 
page (PJB), https://www.pingjockey.net/cgi-bin/pingtalkB .  Everyone 
should monitor this page for possible last-minute announcements of a 
frequency change, etc."


Don/N1DG, operator at W1/KH7Z,  worried that he might have a problem 
with his PC.  At ~1436 UTC We arranged on PJB that I would take over as Fox.

-- 73, Joe, K1JT

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: early results

[John Nelson]

Hi Joe,

Any reason why W1/KH7Z ceased transmissions at 143630?   Wasn’t in the plan...

— John G4KLA
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Second Public Test of FT8 DXpedition Mode: early results

[Joe Taylor]

Hi all,

Many people have asked for a list of stations heard and worked in the
Second Public Test of FT8 DXpedition Mode, held on April 7.  I have 
attached a brief summary.  It's a plain text file containing four lists 
of callsigns:


1. 61 logged by W1/KH7Z in 36 minutes: rate = 61*60/36 = 102/hour

2. 55 logged by K1JT in 21 minutes: rate = 55*60/21 = 157/hour

3. 174 logged by W7/KH7Z in 60 minutes: rate = 174/hour

4. 390 unique calls copied by one or more of the three Foxes

It's worth noting that Ned/AA7A, operator at W7/KH7Z, learned to manage 
his queues much more effectively as his hour progressed.  After a 
program restart at 1532 UTC he worked 105 additional stations, a rate of 
105*60/28 = 225/hour during the remaining part of the hour.


Slowly but surely, we are optimizing the software and improving our 
"FoxOp" skills.  Further progress will definitely be possible!


For this test the three Foxes were configured as follows:

Call GridPEP   PerSlot  Antenna

W1/KH7Z  FN42   500 W20 W   SteppIR at 15, az=50
K1JT FN20   100 W 4 W   Dipole at 17m
W7/KH7Z  DM43   500 W20 W   3 el at 22m, az=45

-- 73, Joe, K1JT
61 logged by W1/KH7Z in 36 minutes: rate = 61*60/36 = 102/hour
--
9A1CBK 9A2JK AA7A AA9A AC4MG AJ6T DF6SM DJ9KG DL5FU EA4EQD EA6VQ G6UW
GM0VRP GM4VGR I5NPH IZ0MIT K5CM K5FR K5RK K5RKS K5WE K6TD K6UM K7VZ
KA9CFD KD0Q KD6WW KE5XV KY7M M0GXM N0CWR N0TCA N7CW NA6L ND2T NX6D
NZ1Q OH1EB OH1MRR OH2BLD OH2MQ OK2PCL OM2WX ON7KEC OZ1GNN OZ7AMG R3OZ
SM4DHF SP9FKQ W0GJ W4BGH W4DXX WA1SXK WA2VNV WA7HQD WB0RPF WB6RSE
WD4CNO WR4K YL2UI ZF1EJ


55 logged by K1JT in 21 minutes: rate = 55*60/21 = 157/hour
--
AA7A AC6SL DJ9KG DM5EE G0DQS HH2AA IZ4GWE K0UA K5CM K5FR K5OA K5RK
K5RKS K5RPD K5WE K6EU K6GFJ K6ML K6SJT K7MTR K9AN KA1R KA5M KA6BIM
KA9CFD KB6C KC9H KD6X KJ3L KK5I N0AN N0CWR N0TB N3SL N5KW N5OK N5SD
N6EE N7BD N7BT ND2T OZ1GNN OZ7A W0SD W2HUV W4AS W5TKZ W6AMM W6CYX
W8LIG WA7HQD WB6EWM WB6RSE WB9MSM WQ5C


174 logged by W7/KH7Z in 60 minutes: rate = 174/hour
--
AA4VV AA5AM AA9A AB1J AB9V AD0FL AD0RW AE4CW AK9S DJ9KG DL3GA DL7VEE
G0DQS HH2AA IK1ADH IZ4GWE K0IR K0KT K0TLG K0TPP K0UA K0VM K1APJ K1GW
K1JT K1KA K1MIJ K2DRH K2QM K3AJ K3RH K4BYN K4DSP K4JJW K4SO K4SQC K4XD
K5CM K5EK K5ESW K5FR K5GZR K5RKS K5SUL K5TCJ K5VIP K5WE K6UM K7VZ
K8EUR K8MOM K8OM K8ST K9AN K9IMM K9MM K9SE KA1R KA5M KA6BIM KA9CFD
KB0MDQ KC2MBV KC9MEG KD0Q KD2OXE KD7PY KD9DXF KE5XV KE7B KF5KK KG4W
KJ3N KJ4Z KK5I KM4AF KM4H KU4V KV1E KW4VA KY7M N0AN N0CWR N0LNK N0TCA
N0UNL N1DG N1QMM N1RDN N1XK N2ADV N2RJ N4AU N4CC N4LDF N5BO N5KK N5KW
N5OK N5SD N5WA N7BD N8RR N9FN NA7TB NE1I NI5DX NN4X NO4J OZ1GNN PA0WRS
UB7K VA3OPP VA3PC VE1JF VE1SKY VE2EBK VE2QLH VE2RO VE2YTQ VE3ERX VE3KI
VE3KOI VE3MV VE6WQ VE7VZ W0FG W0GJ W0OE W0SD W1JA W1SPM W1SSN W1ZZ
W2HUV W2PU W3CCX W3DLQ W3GQ W3MR W4AS W4ATL W4DXX W4GHV W4LDP W5ADD
W5CW W5LDA W5TKZ W5VOM W6GX W6HGF W8BAR W8OI W8VA W9BZW W9MDB WA0RVK
WA3LAB WA4MIT WA7BRL WA8CLT WA9ONY WB2COY WB4HXE WB4OSS WB5LVI WB8GSD
WB9MSM WD9HSY WQ5C WQ5L WS7L WU1ITU


390 unique called copied by one or more of the three Foxes
--
9A1CBK 9A2JK AA4VV AA5AM AA7A AA9A AA9GR AB1J AB3CV AB9V AC2QH AC4MG
AC6SL AC8NP AD0FL AD0RW AD7KG AE0AL AE4CW AI4WL AJ6T AK9S DF6SM DJ9KG
DK2LO DK6SV DL1SGH DL3GA DL5FU DL5KAT DL6AST DL7TG DL7VEE DM5EE EA4EQD
EA6VQ EI2GLB EI6IL F1ABL F4HSU F5JNV F5POE G0DQS G0VXE G3SJX G3UEG
G3VGZ G4DYA G4KCM G4KLA G4WJS G6UW G7KHV GM0VRP GM4VGR GM8MJV HA6NN
HH2AA I0MOM I1JQJ I5NPH IK1ADH IK2RPE IU7GSN IZ0MIT IZ4GWE K0ARG K0IR
K0KT K0TLG K0TPP K0UA K0VM K1APJ K1GW K1JT K1KA K1MIJ K1NE K1TOL K2DRH
K2LYV K2QM K2TE K2TWI K2YG K3AJ K3KO K3RH K3WA K4BYN K4DET K4DSP K4JJW
K4PO K4SO K4SQC K4VBM K4XD K5CM K5EK K5ESW K5FR K5GZR K5OA K5RK K5RKS
K5RPD K5SUL K5TCJ K5TXT K5VIP K5WE K6AVP K6BZZ K6EU K6FW K6GFJ K6IA
K6ML K6QK K6SJT K6TD K6UFO K6UM K6XJ K7AR K7MTR K7TAB K7TN K7VZ K8EUR
K8MOM K8OM K8ST K8TLC K9AN K9EL K9HWL K9IMM K9MM K9NU K9RMP K9SE K9WWW
KA1R KA5M KA6BIM KA9CFD KB0MDQ KB1VUN KB6C KB7ME KB8GAE KC0GU KC2MBV
KC2WUF KC7V KC9H KC9MEG KC9YRA KD0Q KD2A KD2OXE KD4S KD6WW KD6X KD7PY
KD9DXF KE0HQZ KE5XV KE7B KF5KK KG4W KI0O KI4NGM KJ3L KJ3N KJ4Z KK4PHP
KK5I KM1D KM4AF KM4H KM4HQE KN3ILZ KQ6RS KU4PY KU4V KV1E KW4VA KX7YT
KY7M LA7XK LA8WRA LA9VFA LZ2HA M0GXM MM0LGS MM5AGM N0AN N0CWR N0LNK
N0TB N0TCA N0UNL N1DG N1JEZ N1QMM N1RDN N1XK N2ADV N2NS N2RJ N3SL N4AU
N4CC N4LDF N5BO N5KK N5KW N5OK N5OSK N5SD N5WA N6EE N6RW N7BD N7BT
N7CW N8RR N9FN N9LF N9VPV NA6L NA7TB NC4RY ND2O ND2T NE1I NF3R NG7M
NH6Y NI5DX NN4X NO4J NR3M NU7K NV0O NX6D NY3B NZ1Q OE6IWG OH1EB OH1KH
OH1MRR OH2BLD OH2MQ OK1AUO OK2PCL OM2WX ON7KEC OZ1GNN OZ4O OZ6GH
OZ7AMG PA0WRS PA9O PY5EJ R3OZ R6YY RA7M S58T 

Re: [wsjt-devel] "CQ only", UDP and ALL.TXT bug

[Saku]

Hi!

This small patch seems to stop duplicate decodes in 
BandActivity/UDP/ALL.TEXT  and makes touching "CQ only" to take *effect 
from next decode onwards*.


Just what I tried to describe...

--
Saku
OH1KH


Bill Somerville kirjoitti 06.04.2018 klo 19:43:

On 06/04/2018 17:39, Bill Somerville wrote:
this is not really a defect. If you have "CQ Only" checked then 
non-CQ decodes are discarded and cannot be recovered. Un-checking the 
option causes the decoder to redo the decode on the sample buffer. 
The same applies to checking the "CQ Only" option except that CQ 
decodes are discarded. If you do not want duplicated UDP Decode 
messages nor duplicates in the ALL.TXT file then all I can suggest is 
that you do not use the "CQ Only" option. BTW it is possible that the 
repeated decode passes may have different results if the Rx audio 
offset, decode depth, waterfall width, or AP settings have been changed.


Fixing a critical typo:

this is not really a defect. If you have "CQ Only" checked then non-CQ 
decodes are discarded and cannot be recovered. Un-checking the option 
causes the decoder to redo the decode on the sample buffer. The same 
applies to checking the "CQ Only" option except that *non-* CQ decodes 
are discarded. If you do not want duplicated UDP Decode messages nor 
duplicates in the ALL.TXT file then all I can suggest is that you do 
not use the "CQ Only" option. BTW it is possible that the repeated 
decode passes may have different results if the Rx audio offset, 
decode depth, waterfall width, or AP settings have been changed.


73
Bill
G4WJS.


-- 


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel



--- mainwindow.cpp	2018-04-09 17:53:39.226156093 +0300
+++ mainwindow_new.cpp	2018-04-09 17:58:28.793249750 +0300
@@ -7208,8 +7208,8 @@
 
 void MainWindow::on_cbCQonly_toggled(bool)
 {
-  QFile {m_config.temp_dir().absoluteFilePath(".lock")}.remove(); // Allow jt9 to start
-  decodeBusy(true);
+  //QFile {m_config.temp_dir().absoluteFilePath(".lock")}.remove(); // Allow jt9 to start
+  //decodeBusy(true);
 }
 
 void MainWindow::on_cbFirst_toggled(bool b)
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] CPU Usage Over Time

[George Molnar]

Thanks, Joe.

Will check my build environment.


George J Molnar
Washington, DC, USA
KF2T   -   @GJMolnar









> On Apr 9, 2018, at 5:52 AM, Joe Taylor  wrote:
> 
> Hi George,
> 
> Evidently you are building the program yourself.
> 
> It seems that you should look carefully into why you are having this issue 
> with your home-built executable.  I do not think our builds show any problem 
> of this kind.
> 
>   -- 73, Joe, K1JT
> 
> On 4/9/2018 8:33 AM, George Molnar wrote:
>> Using 1.9 (8603) under MacOS 10.13.4.
>> Upon launch, program operates smoothly. As Band Activity window fills, CPU 
>> usage rises slowly, until the program becomes unresponsive. At that point, 
>> only a forced quit recovers the app. It does keep receiving and decoding, 
>> however.
>> If I catch it early enough, double-clicking “Erase” drops the CPU usage and 
>> allows continued operation. Left running overnight, I can count on an 
>> unresponsive GUI in the morning.
>> Have only tested using the FT8 decoder. Did not have this problem with the 
>> initial rc3 release.
>> *George J Molnar*
>> Washington, DC, USA
>> KF2T   -   @GJMolnar
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> wsjt-devel mailing list
>> wsjt-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> wsjt-devel mailing list
> wsjt-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] CPU Usage Over Time

[Joe Taylor]

Hi George,

Evidently you are building the program yourself.

It seems that you should look carefully into why you are having this 
issue with your home-built executable.  I do not think our builds show 
any problem of this kind.


-- 73, Joe, K1JT

On 4/9/2018 8:33 AM, George Molnar wrote:

Using 1.9 (8603) under MacOS 10.13.4.

Upon launch, program operates smoothly. As Band Activity window fills, 
CPU usage rises slowly, until the program becomes unresponsive. At that 
point, only a forced quit recovers the app. It does keep receiving and 
decoding, however.


If I catch it early enough, double-clicking “Erase” drops the CPU usage 
and allows continued operation. Left running overnight, I can count on 
an unresponsive GUI in the morning.


Have only tested using the FT8 decoder. Did not have this problem with 
the initial rc3 release.



*George J Molnar*
Washington, DC, USA
KF2T   -   @GJMolnar











--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot



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



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] CPU Usage Over Time

[George Molnar]

Using 1.9 (8603) under MacOS 10.13.4.

Upon launch, program operates smoothly. As Band Activity window fills, CPU 
usage rises slowly, until the program becomes unresponsive. At that point, only 
a forced quit recovers the app. It does keep receiving and decoding, however.

If I catch it early enough, double-clicking “Erase” drops the CPU usage and 
allows continued operation. Left running overnight, I can count on an 
unresponsive GUI in the morning.

Have only tested using the FT8 decoder. Did not have this problem with the 
initial rc3 release.


George J Molnar
Washington, DC, USA
KF2T   -   @GJMolnar









--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Re: [wsjt-devel] Second Public Test of FT8 DXpedition Mode: April 7, 1400-1600 UTC

[Bill Somerville]

On 08/04/2018 23:14, David Tiller wrote:
The W1/KH7Z fox was barely audible in FM17 - I only got a few decodes. 
K1JT was a bit louder, but still not loud enough to warrant calling him.


Hi David,

unless the Fox is QRO (Joe wasn't) then you should call if you copy them 
at all, if they are running 5 x Tx signals then you have a 14dB 
advantage against their signal to you.


73

Bill
G4WJS.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

[wsjt-devel] Test

[jarmo]

First hour signal was +3 and I got -24
I started with 20 watts and ended to 200 watts,
when I got that -24dB report.
Second hour hear best -8dB and started again from 20 watts
went up to 1K and didn't get w7/kh7z :(. Tried several
places, no lucky.
At the end of test last decoded signal was -15dB. Actually
all NA stations was between -5 to -18 dB.
Hounds were between +17 to -24dB, that +17 was one RY station :)

So, now the most important thing is to find suitable freq. and
operators learning course :)

Quite fine test anyway...

Jarmo

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel