Steve,
I should have mentioned that I compile with Qt 5.8 on an iMac but ship the
result to my MacBook Pro which lives elsewhere in the house next to the
transmitters.Are you also using OSX 10.11?
> On the machine that shows the large DTs, if I decode using jt9 from the
> command line,
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
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
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
--
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
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
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
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
18 matches
Mail list logo
