On 29/09/2015 02:18, Dave Halbakken wrote:
Hi Dave,
> Thanks for your reply, Mike.
>
> I found that this problem can be reproduced by unplugging and re-plugging
> the USB cable to my soundcard. To get WSJT-X fully working again you have to
> swap the soundcard settings away and back on both input
Joe -
I’ve just committed sfrsd3.c. This uses the probability of error derived from
your fort.40 data to set the erasure probabilities. I modified extract2.f90 to
print the 8x8 array out and then imported it directly into sfrsd3.c I manually
edited the probabilities in the regions that had
Hi Hans,
Thanks for the report.
I am not aware of any problems that have been reported with spot uploading in
WSJT-X.
I do not know the answer to your question about why WSJT-X might transmit on a
slightly different frequency than WSPR-X, even when the TX settings are the
same. Very early
So the failures are a separate section? So a quad core should get
something approaching 3X barring cache contention.
Question would be how often in real life do failures occur?
And would you make the # of trials dependent on # of cores?
On Tue, Sep 29, 2015 at 3:50 PM, Joe Taylor
Mike --
On 9/29/2015 5:29 PM, Michael Black wrote:
> So the failures are a separate section?
No. Have you looked at what the decoder is doing?
If 25 or fewer of 63 received symbols are in error, the deterministic
Berlekamp_Massey (BM) algorithm is guaranteed to succeed. With more
than 25
