Nice!
On 3/30/2016 8:34 PM, Greg Beam wrote:
> Not a WSJT Dev issue per say, but, interesting nonetheless.
>
> http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash
>
>
> 73's
> Greg, KI7MT
>
>
>
>
> -
Hi Pavel and all,
I’ll echo what Joe said. The Fano and Jelinek algorithms each implement a
search over the same tree (using the same branch metrics). They will visit
almost the same nodes on the tree during their search, and they will converge
to the same result in almost all cases. The stack
Not a WSJT Dev issue per say, but, interesting nonetheless.
http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash
73's
Greg, KI7MT
--
Transform Data into Opportunity.
Accelerate data analysis
Hi Joe
Thanks for these test results. I note that your conclusion that JT65c is no
better than JT4 with spreading greater than 10 to 20 Hz is based on non-DS
decoding. Based on my tests with r6536 I am inclined to agree that your
conclusion also applies to DS decoding although I would like to do
Hi Alberto,
On 3/30/2016 6:32 PM, Alberto I2PHD wrote:
> all clear, thanks. Well, with k=32, the use of Viterbi is out of question, for
> sure ! A state machine with more than 4 billion states is just...
> impractical... :-)
Agreed. Note that although sequential decoding with the Fano algorith
On 3/30/2016 11:37 PM, Joe Taylor
wrote:
Yes, JT4 uses a convolutional code with K=32, r=1/2.
Hi Joe,
all clear, thanks. Well, with k=32, the use of Viterbi is out of
question, for sure !
A state machine with more than 4 billi
Hi Alberto,
> please pardon my truly naif question, but, isn't Fano a decoding algorithm for
> sequential
> convolutional coding, while your FT decoder is meant for block RS coding ?
> Do you mean that JT4F doesn't use RS, while JT65C does ?
Yes, JT4 uses a convolutional code with K=32, r=1/2.
F
On 3/30/2016 8:38 PM, Joe Taylor wrote:
However, as shown in the attached graph JT4F with the Fano decoder is
about 1 dB better than JT65C with the FT decoder at Doppler spread 32
Hz, and by even more at larger spreads.
Joe,
please pardo
Hi Pavel,
Thanks for the additional information. Your choices make good sense.
Do keep in mind that the sequential decoders in wsprd and wsprd_exp have
an easy-to-use tuning parameter, "maxcycles". In wsprd_exp.c it's
defined on line 628:
unsigned int maxcycles=1; //Deco
Hi Joe,
Thank you for confirming that switching to floats should be relatively safe.
I started to use wsprd_exp after reading the following threads on this
mailing list:
https://sourceforge.net/p/wsjt/mailman/message/34326507/
https://sourceforge.net/p/wsjt/mailman/message/34334059/
Looks like
Hi all,
Lots of work has been going on (off list) on optimizations of the JT65
decoder for cases where Doppler spreading is significant. A summary
graph of my most recent simulation results is attached.
I've come to believe that using any JT65 submode (including C or even a
"D" submode) is
Hi Pavel and all,
Thanks for your effort on optimizations in wsprd. The change from
doubles to floats has been on our "To Do" list for many weeks. We
didn't get around to it because the potential gains (though desirable)
were not likely to be huge. Floats have enough precision for use in all
On 30/03/2016 18:02, Pavel Demin wrote:
> Thanks for your suggestion to switch to the single precision FFTW3.
>
> I've replaced 'fftw_' with 'fftwf_' in wsprd_exp.c and tested
> 'wsprd_exp -J -w' with 410 .wav files. This modification does not
> affect the number of decoded messages and improves
Hi Alberto,
On 3/30/2016 1:16 PM, Alberto I2PHD wrote:
> On 3/30/2016 7:08 PM, Joe Taylor wrote:
>
>> /More recently, Steve (K9AN) and I developed an open-source Reed Solomon
>> decoder for the (63,12). Many messages about this work are in the
>> wsjt-devel Archives, and the code is now part o
On 3/30/2016 7:08 PM, Joe Taylor wrote:
More recently, Steve (K9AN) and I developed an open-source Reed Solomon
decoder for the (63,12). Many messages about this work are in the
wsjt-devel Archives, and the code is now part of WAJT-X, WSJT, and
MAP65. The Koet
Hi Alberto,
On 3/30/2016 12:45 PM, Alberto I2PHD wrote:
> I am new to this list, so if question was asked before, please bear with me,
> as
> I don't know how to browse the archive copy of this group, supposing one
> does exist.
Click on the link at the bottom of every message to this group to f
Hi Bill,
Thanks for your suggestion to switch to the single precision FFTW3.
I've replaced 'fftw_' with 'fftwf_' in wsprd_exp.c and tested 'wsprd_exp
-J -w' with 410 .wav files. This modification does not affect the number
of decoded messages and improves the decoding speed by a couple of perc
I am new to this list, so if question was asked before, please bear
with me, as I don't know
how to browse the archive copy of this group, supposing one does
exist.
In past versions of his code Joe Taylor used the closed-source
Koetter-Vardy soft decoder
for
Has anybody any ideas yet as to what the problem is in my original message
stopping me running WSJT-X QT 5.5 on one of my PCs?
I am doing things very simply and most of the things mentioned in this
thread goes over my head. I am compiling and running WSJT-X as I was advised
when I started out usin
On 30/03/2016 09:07, Pavel Demin wrote:
>- NEON coprocessor supports only single-precision floating-point
> values and replacing double with float in some calculation intensive
> parts could improve the performance.
Hi Pavel & all,
if this is so then switching to using the single precision FFT
Dear wsjt developers,
Out of curiosity, I've played with the wsprd/wsprd_exp.c optimization
for ARMv7-A. Currently, on a dual core ARM Cortex-A9 CPU, it takes
'wsprd_exp -J -w' up to 70 seconds to decode 8 WSPR bands with several
wsprd_exp processes running in parallel. It's still within the av
21 matches
Mail list logo
