Hi Steve, Edson, and all,
I'm happy with setting bias = 0.42, given that several quite different
tests show that it results in a rate of false decodes smaller than 1 in
1000.
As for reporting to WSPRnet: my preference is to report all decodes to
the database site. It's not so very unusual for
>
> First I ran tests using wsprsim-generated files with -31 dB snr to test the
> effect of the change in the fano decoder. For each simulation run I generated
> and decoded 1 .c2 files. Since all simulated files have the message “K9AN
> EN50 33”, it was easy to find and count all frames wi
Joe,
> I'm thinking about the possible implications of our choice of values for
> bias and maxcycles, and also about Edson's suggestion to not send
> reception reports to WSPRnet until the second decode of a given
> callsign. I might have more to say about it in a day or so.
>
I think that Jo
> On Aug 2, 2015, at 12:49 PM, Joe Taylor wrote:
>
> Hi Steve, Edson, and all,
>
> I had forgotten that wsprd_exp is currently using a different sync
> algorithm. Thanks for the explanations. I, too, am happy with the way
> the modified fano.c is behaving. By all means, go ahead and commit
Hi Steve, Edson, and all,
I had forgotten that wsprd_exp is currently using a different sync
algorithm. Thanks for the explanations. I, too, am happy with the way
the modified fano.c is behaving. By all means, go ahead and commit the
necessary changes.
I'm thinking about the possible implic
Hi Joe,
> On Aug 1, 2015, at 1:02 PM, Joe Taylor wrote:
>
> Hi Steve,
>
> Visiting family are arriving later than expected, so I found some
> unexpected time to play with wsprd and wsprd_exp. To make the KA9Q fano
> decoder work with your change, I had to increase the size of the node[]
> s
Hi Steve,
Visiting family are arriving later than expected, so I found some
unexpected time to play with wsprd and wsprd_exp. To make the KA9Q fano
decoder work with your change, I had to increase the size of the node[]
structure by one bit:
###
Hi Steve,
Thanks for putting some thorough and very worthwhile effort into
apparent performance differences between our Fano and Jelinek decoders.
You have made some excellent progress!
I'm tied up most of today and early tomorrow, but should be able to put
some time into it by tomorrow afte
Joe,
> On these files I ran test cases like yours, plus two more, with the
> following results:
>
>Command T B G time
> ---
> 1. wsprd 125 2 123 25 s
> 2. wsprd_exp
Hi Joe,
Thanks. I saw your last data run report and the options used, that's
what I needed.
I would think, using consistent parameters between testers ( or at least
for those of us that don't really know what is going on ), would be
important in order to help achieve consistent results . That,
Hi Greg,
I did my tests using batch files. For example, the ones for the tests I
reported an hour or so ago, based on the 15 files that had produced a
false decode, look something like this:
#
rm ALL_WSPR.TXT
wsprd 150426_0114.wav
wsprd 150426_0148.wav
wsprd 150426_0342
Steve --
Some follow-up on the rare (but annoying) false WSPR decodes...
I decided to look especially at the 15 files in the wspr_data.tgz
package that produced a false decode (one containing "/") in *any* of
your test cases. The files are:
150426_0114.wav
150426_0148.wav
150426_0342.wav
1504
Hi Steve, Joe,
Can you post the invocations and options you used for the three cases below?
Case 1. wsprd
Case 2. wsprd_exp Fano
Case 3. wsprd_exp Jelink
I realize the source file <-Input locations will be different.
I want to play with this a bit and try to come up with a way to use
GnuPlot to
Hello Joe, Steve, and all,
With the experiments I have been doing with WSPR on the Raspberry-Pi, I
have implemented a simple spot feeder to wsprnet and have been thinking
about adding a mechanism to check if a spot just received is in the
ALL_WSPR.TXT before sending the spot to wsprnet. This would
m not familiar enough with the protocol to know if that is possible.
>
> 73
> Mike W9MDB
>
> -Original Message-
> From: Joe Taylor [mailto:j...@princeton.edu]
> Sent: Friday, July 31, 2015 9:12 AM
> To: WSJT software development
> Subject: Re: [wsjt-devel] W
riday, July 31, 2015 9:12 AM
To: WSJT software development
Subject: Re: [wsjt-devel] WSPR decoder: Jelinek vs Fano
Hi Steve,
Interesting results. We should definitely pay a bit more attention to the
false decodes. Maybe setting "bias" as low as 0.42 is not a good idea?
-- Joe
On
Hi Steve,
Interesting results. We should definitely pay a bit more attention to
the false decodes. Maybe setting "bias" as low as 0.42 is not a good idea?
-- Joe
On 7/30/2015 11:25 PM, Steven Franke wrote:
> Joe,
> Here are my results for your data set. I ran 3 cases. The execution ti
Joe,
Here are my results for your data set. I ran 3 cases. The execution times are
the average of two runs.
Cases
1. wsprd
2. wsprd_exp (Fano, 1 cycles)
3. wsprd_exp (Jelinek, 5000 cycles)
Results
1. 2657 (2) decodes in 359s
2. 2760 (13) decodes in 359s
3. 2749 (3) decodes in 346s
The inte
Hi Joe,
Thanks. I'm downloading the data now and will do some test runs later
this evening.
73's
Greg, KI7MT
On 07/30/2015 07:01 AM, Joe Taylor wrote:
> Hi Greg,
>
> I have updated Makefile.win32 in ^/branches/wsjtx so that it builds
> Steve's new wsprd_exp.exe correctly.
>
> I have made a t
Hi Greg,
I have updated Makefile.win32 in ^/branches/wsjtx so that it builds
Steve's new wsprd_exp.exe correctly.
I have made a tarfile with the set of WSPR *.wav files I used most
recently. It is now posted at
http://physics.princeton.edu/pulsar/K1JT/wspr_data.tgz
It's about 1 GB in size.
Greg -
I don’t see any need to do anything more with wsprd_exp beyond just compiling
it. There is certainly no need to over-write the wsprd binary.
Steve k9an
> On Jul 28, 2015, at 3:00 PM, Greg Beam wrote:
>
> Hi Steve,
>
> To be honest, I think particular testing is best left to those of y
Hi Steve,
To be honest, I think particular testing is best left to those of you
that know exactly what's going on and how best to test it. I would
probably just add confusion to the subject at this point.
Presently, the WSJT-X build script on Linux compiles wsprd_exp, but it
is not copying too
Hi Greg and Joe,
As Joe said, the stack decoder is only in wsprd_exp and it requires a
command-line argument (-J) to activate it, as the default algorithm in
wsprd_exp is the Fano algorithm.
The tests conducted by me and Joe show that my implementation of Jelinek’s
stack-bucket algorithm doesn
Hi Greg,
The experimental ("Jelinek") decoder is currently being built only as
wsprd_exp.
-- Joe
On 7/28/2015 3:08 PM, Greg Beam wrote:
> Hi Joe, Steve,
>
> Are these updates in the main wsprd binary, or do we still need to build
> the wsprd_exp binary and copy it over to wsprd t
Hi Joe, Steve,
Are these updates in the main wsprd binary, or do we still need to build
the wsprd_exp binary and copy it over to wsprd to test the changes?
73's
Greg, KI7MT
On 7/28/2015 12:22 PM, Joe Taylor wrote:
> Hi Steve,
>
> Nice job with implementation of a sequential decoder using the Je
Hi Steve,
Nice job with implementation of a sequential decoder using the Jelinek
Stack Algorithm!
I have now run some reasonably thorough tests of it, comparing results
with the default Fano decoder in wsprd. I confirm essentially all of
your basic conclusions. Jelinek with maxcycles=5000 pro
26 matches
Mail list logo
