~ AK1P CT1GVN IM67
1927 Transmitting 14.079 MHz FT8: A92AA G4KLA 73
192730 2 0.3 1055 ~ G4KLA A92AA 73
Extract from wsjtx.log
2017-07-02,19:27,2017-07-02,19:27,A92AA,LL56,14.080055,FT8,+02,-17,20W,v1.7.1-dev
r 10.11,Fawaz
Extract from wsjtx_log.adi
A92AA LL56 FT8 +02
Thanks, Greg. I think we all agree that we don't want to see the beta
updates no longer made available.
May I suggest to all the group users that if we see folks requesting install
packages, we offer to help them set up the JTSDK environment on their
machines, in the "teach a man to fish" spirit.
Hello All,
Appropriate Use
==
JTSDK exists to help users build and "test" Joe's software, not distribute
it. We all want these fantastic applications, but, we "users" must respect
the developers requests.
I've received several reports of WSJTX packages built with JTSDK being
distrib
Thanks John,
> I get the same as Joe for the decoding of Tamás’s files. Running r and
> Mac OSX 10.11.6
Here’s a summary of what I’ve found so far.
I have three machines. Two run OS X and one is a linux box. One of the Macs and
the linux box show the smaller DT values that others are seei
Hi Everyone,
I’m grateful to Bill (G4WJS) for helping me resolve the issue. I’m posting the
solution in case anyone else makes the same mistake as I did.
The issue was that I downloaded the latest release candidate of CMake, rather
than the current release version. After installing 3.8.2 (rat
> On 2 jul 2017, at 20:34, Lloyd Kirk wrote:
>
> I noticed that pskreporter is displaying the exact RX freq for jt65/9 signals
> but not for FT8. Is this by design?
>
> It seems to be displaying the frequency that is configured in the
> settings->frequencies for that mode in WSJT-X.
>
> Was
-07-02,19:27,A92AA,LL56,14.080055,FT8,+02,-17,20W,v1.7.1-dev
r 10.11,Fawaz
Extract from wsjtx_log.adi
A92AA LL56 FT8 +02 -17
20170702 1927 20170702 1927
20m 14.080055 G4KLA IO92ak
20W v1.7.1-dev r 10.11 Fawaz
— John G4KLA
I noticed that pskreporter is displaying the exact RX freq for jt65/9
signals but not for FT8. Is this by design?
It seems to be displaying the frequency that is configured in the
settings->frequencies for that mode in WSJT-X.
Was just curious. Using r currently.
Lloyd Kirk
WB5HUP
-
Steve,
I get the same as Joe for the decoding of Tamás’s files. Running r and Mac
OSX 10.11.6
— John G4KLA
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! htt
Hi Joe
Seems to be working fine, learning how to use it now.
Charlie
-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: 02 July 2017 19:01
To: WSJT software development
Subject: Re: [wsjt-devel] Colors - FT8
Hi Kari,
> The 'worked before' feature is also not working
Hi Kari,
The 'worked before' feature is also not working with FT8.
I think this could be fixed by adding test for
FT8 on line 105 of "logbook/adif.cpp"
Thanks! I believe it's fixed in r.
-- Joe, K1JT
--
tnx
-Original Message-
From: Joe Taylor [mailto:j...@princeton.edu]
Sent: 02 July 2017 18:45
To: WSJT software development
Subject: Re: [wsjt-devel] Minimum transmission length for FT8
Hi Charlie,
> What fraction of the transmission is needed for a successful decode
> given 'good' S/N?
Hi Charlie,
What fraction of the transmission is needed for a successful decode
given ‘good’ S/N?
I’ve seen some “short” messages decode just now (using r7776).
The code rate is 1/2, so without AP decoding the bare minimum must be
about half a transmission. I've seen done good decodes with
Is it possible to change the “Disable Tx after sending 73” function to “Disable
Tx after logging QSO”?
With it checked, we get one 73, which is sometimes not enough. Usually it is.
But whenever a QSO is logged, we are -for sure- done with Tx5 and can go on
from there, either with a CQ or stop.
Hi Joe/Steve
What fraction of the transmission is needed for a successful decode given
'good' S/N?
I've seen some "short" messages decode just now (using r7776).
73
Charlie
--
Check out the vibrant tech com
Does the new FT8 have any sort of built in AFC compensation? Every
so often I see a station slowly creeping up the band while in QSO. It
looks very much like the way PSK acts when both stations have their AFC
control checked and they "chase" each other up or down the band.
It will only
On 07/02/2017 06:14 PM, James Shaver (N2ADV) wrote:
Running r7775 (Win 7) I've noticed and others have brought to my attention that
the colors for new DXCC and new call aren't showing up in the RX window. CQ in
Message and My Call in message are working.
73,
Jim S.
N2ADV
The 'worked before
Hi Dan,
you've got it now, hi hi.
73
Bill
G4WJS.
On 02/07/2017 18:02, Dan Malcolm wrote:
Bill,
At the moment it’s 1636. Perhaps the light is dawning. Would split
mode only shift the Tx frequency in order to keep the audio frequency
in bounds, and not to shift if Tx frequency is already in
I just tested my last reply to you, and it appears I understand "split mode"
better. Thanks.
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, July 02, 2017 11:33 AM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] r7776 Split problem
On 02/07/2017 17:29, Da
Bill,
At the moment it's 1636. Perhaps the light is dawning. Would split mode
only shift the Tx frequency in order to keep the audio frequency in bounds,
and not to shift if Tx frequency is already in bounds?
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Sunday, July 02, 2017 1
On 02/07/2017 17:29, Dan Malcolm wrote:
I think I understand, but perhaps I didn’t communicate well. Prior to
r7776 the B BFO did the Tx (and A BFO does the Rx) and shifted
frequency to 14.078.500 as I expected, in compliance with the
recommend split mode setting. Now, Tx still occurs on the B
Bill,
I think I understand, but perhaps I didn't communicate well. Prior to r7776
the B BFO did the Tx (and A BFO does the Rx) and shifted frequency to
14.078.500 as I expected, in compliance with the recommend split mode
setting. Now, Tx still occurs on the B VFO, but does not shift to
14.078.5
Dear Steve and everyone,
r7776 decodes the files as Joe described previously, and seems to
successfully decode current on-air signals.
(I'm using Ubuntu Linux 17.04 "zesty".)
Cheers,
Tamas HA5FTL
2017-07-02 18:02 GMT+02:00 Steven Franke :
> Ah - I should have RTFM. I am not used to using the
Now that Bill has fixed the memory issue, it would be interesting to see if we
get the same DT values from Tamas’ files when running on Windows and OS X. The
decodes that I get from r7776 on my OS X machine are the same as I had before:
130800 -7 0.9 1097 ~ EI4KF ES6DO KO27
--
On 02/07/2017 17:13, Dan Malcolm wrote:
I just compiled r7776 and found that there is a “split” problem. In
Settings under the Radio tab I have enabled Rig for Split Operation.
I am running Kenwood TS-2000 for the Rig model. That setting has been
working well until I compiled the new WSJT-
I just compiled r7776 and found that there is a "split" problem. In
Settings under the Radio tab I have enabled Rig for Split Operation. I am
running Kenwood TS-2000 for the Rig model. That setting has been working
well until I compiled the new WSJT-X 1.7.1-devel r7776. Prior to this Tx
occurre
Ah - I should have RTFM. I am not used to using the FFTW library with
real-valued input vectors. Thanks!
Steve
> On Jul 2, 2017, at 10:54 AM, Bill Somerville wrote:
>
> On 02/07/2017 16:47, Steven Franke wrote:
>> So why did you need to add the extra element at the end of cx?
>
> The real inpu
On 02/07/2017 16:47, Steven Franke wrote:
So why did you need to add the extra element at the end of cx?
The real input generates a complex DFT with one extra element
sizeof(input)/2 + 1.
http://www.fftw.org/fftw3_doc/Real_002ddata-DFT-Array-Format.html#Real_002ddata-DFT-Array-Format
73
Bil
Bill -
Thank you for finding this!
But I still don’t understand what was wrong with the way that the cx array was
sized.
Surely the size of the original x array (NMAX real elements) is equivalent to
the size of the original cx array 2*(NMAX/2) complex elements...
I just did this test (using
Running r7775 (Win 7) I've noticed and others have brought to my attention that
the colors for new DXCC and new call aren't showing up in the RX window. CQ in
Message and My Call in message are working.
73,
Jim S.
N2ADV
--
On 02/07/2017 16:06, Bill Somerville wrote:
Steve, I didn't fully analyse the issue. Does the c1 vector in
ft8_downsample() need to be one longer as well?
Hi Steve,
ok, I see not as it is complex to complex for the return to time domain.
73
Bill
G4WJS.
--
On 02/07/2017 15:41, Bill Somerville wrote:
On 02/07/2017 14:28, Tamás Fábián wrote:
Dear Steve,
I get no decodes with FT8 and r7775.
I tried to call CQ and I got an answer, but could not decode that
either. (The CQ was heard by multiple stations according to
pskreporter.)
Five sample reco
On 02/07/2017 14:28, Tamás Fábián wrote:
Dear Steve,
I get no decodes with FT8 and r7775.
I tried to call CQ and I got an answer, but could not decode that
either. (The CQ was heard by multiple stations according to pskreporter.)
Five sample recordings are in a .zip under the following url:
Hi Tamas,
I decoded the same 6 decodes as Steve with build 7774 on Windows.
Hope this helps,
ON4PB,
Erik.
--
Message: 3
Date: Sun, 02 Jul 2017 13:37:21 +
From: Steven Franke
To: Joe Taylor
Subject: Re: [wsjt-devel] r7775 FT8 decoding
Message-ID:
Content-Typ
Another observation. Watching you CQ on 20m now, I am seeing your DT jump
between 0.1 and 0.6….
> On Jul 2, 2017, at 2:07 PM, Steven Franke wrote:
>
> Hi Joe -
> The DTs that you got from Tamas’ files on Windows are different than what I
> got on OS X. Did you change anything that could expl
Hi Joe -
The DTs that you got from Tamas’ files on Windows are different than what I got
on OS X. Did you change anything that could explain this? If not - this could
be connected with the problem that I was having yesterday...
Steve
> On Jul 2, 2017, at 2:03 PM, Joe Taylor wrote:
>
> Hi Tama
Hi Tamas,
Your files decode OK here in WSJT-X r7775 (running on Windows).
20m
130800 -7 0.6 1097 ~ EI4KF ES6DO KO27
20m
130815 -12 0.2 1098 ~ ES6DO EI4KF -13
20m
130830 -7 0.6 10
Hi Tamas,
Your files produce the following decodes on r7775 here:
- 6m
130800 -7 0.9 1097 ~ EI4KF ES6DO KO27
- 6m
130815 -12 0.5 1098 ~ ES6DO EI4KF -13
- 6m
130830 -7 0.9 1097 ~ EI4
Dear Steve,
I get no decodes with FT8 and r7775.
I tried to call CQ and I got an answer, but could not decode that either.
(The CQ was heard by multiple stations according to pskreporter.)
Five sample recordings are in a .zip under the following url:
https://www.dropbox.com/s/sgcfehcdwfrp7th/wsj
Hi,
Can I make a few very ** minor ** GUI suggestions ?
1. Shouldn't we rename the TX even/1st label in JT8 mode to something
that explicitly refers to the quarter/kwadrant inside the minute into which
we will transmit ?
Something like "Start at 0 or 30 secs" ?
2. In the main
For future reference, I’ve attached a plot summarizing the performance of the
FT8 decoder in r7775. The 50% decoding threshold is at about -21 dB. These
results pertain to an AWGN channel (no fading) and were obtained using .wav
files generated by ft8sim. Each .wav file contains 25 signals. A to
On 02/07/2017 04:41, Tim Carlson wrote:
Also, here’s my configuration results:
$ FC=gfortran-mp-5 cmake -D
CMAKE_PREFIX_PATH="~/Qt3/5.9.1/clang_64;~/hamlib-prefix;/opt/local"
-D CMAKE_INSTALL_PREFIX=~/wsjtx-prefix -D
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/P
42 matches
Mail list logo
