Hi Steve and all, As weak bursts of interference seems doing the same trick with r6080 I wonder if it is possible to consider a change in algorithm of choosing candidates to this one or something similar:
both, full correlation <and> onebit correlation functions are used to recognise candidates, if full correlation function gives more than 50 candidates then result from onebit correlation is used, if full correlation function gives less than 50 candidates then both function's combined result is used for decoding the signals. I have asked in Russian JT65 forum to assist with audio files collection for HF radar operation, it might be interesting to see if r.6058 deals better with periodic pulse interference vs r6080 under various band conditions. 73 Igor UA3DJY > >------------------------------ > >Message: 5 >Date: Sat, 14 Nov 2015 07:53:45 -0600 >From: Steven Franke < [email protected] > >Subject: Re: [wsjt-devel] weak signals decoding under r6058 vs r6080 >To: ????? ? < [email protected] >, Joe Taylor >< [email protected] > >Message-ID: < [email protected] > >Content-Type: text/plain; charset=utf-8 > >Igor, > >This is likely due to the very strong burst of interference at about 21 s into >the file. It looks like a chirpsounder swept through the band at that time. >This interference is about 40 dB larger than the noise floor. The 1-bit >correlation will be relatively immune to this spike, whereas the full >correlation will be strongly influenced by it. > >Steve > >> On Nov 14, 2015, at 6:54 AM, ????? ? < [email protected] > wrote: >> >> Hi Joe, Steve and all, >> >> There is audio file where JT65 weak signals are handled better by r6058 than >> by r6080 and I can not explain why is it happen: >> >> r6058: >> >> 0706 -23 0.6 2493 @ CQ PA3GUK JO32 >> >> 0706 -7 1.0 280 # CQ R9HAW NO26 >> >> 0706 -23 1.7 1087 # JH8JNF F5GPE 73 >> >> 0706 -25 1.2 1499 # CQ UA3LHA KO64 >> >> 0706 -2 0.9 2124 # SP2CDN YO8SEP -06 >> >> _____________________________ >> r6080: >> >> 0706 -23 0.6 2493 @ CQ PA3GUK JO32 >> >> 0706 -7 1.0 280 # CQ R9HAW NO26 >> >> 0706 -2 0.9 2124 # SP2CDN YO8SEP -06 >> >> __________________________________ >> >> File is recorded from DDS SDR ANAN-10, AGC is OFF, digital audio stream to >> CPU. >> >> The same WSJT-X ini file is used. Random erasure pattern set to 8, two pass >> enabled, agressive decoding level set to 5. >> >> May it be DT values range for weak signals that is handled differently by >> two mentioned releases? >> >> I have put audio file there: https://cloud.mail.ru/public/Hhpj/EgLDYNPK4 >> >> >> 73, >> >> Igor UA3DJY >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > >------------------------------ > >Message: 6 >Date: Sat, 14 Nov 2015 18:58:56 +0000 >From: Bill Somerville < [email protected] > >Subject: [wsjt-devel] WSJT-X: WSPR reported drift >To: WSJT software development < [email protected] > >Message-ID: < [email protected] > >Content-Type: text/plain; charset=utf-8; format=flowed > >FAO Steve K9AN, > >I notice that wsprd reports the integer value of DT in the drift column, >I assume this is a defect. If so I will apply the following patch: > >index 1aab50e..d70b71c 100644 >--- a/lib/wsprd/wsprd.c >+++ b/lib/wsprd/wsprd.c >@@ -1160,7 +1160,7 @@ int main(int argc, char *argv[]) > for (i=0; i<uniques; i++) { > printf("%4s %3.0f %4.1f %10.6f %2d %-s \n", > decodes[i].time, decodes[i].snr,decodes[i].dt, >decodes[i].freq, >- (int)decodes[i].dt, decodes[i].message); >+ (int)decodes[i].drift, decodes[i].message); > fprintf(fall_wspr, > "%6s %4s %3d %3.0f %4.1f %10.7f %-22s %2d %5u %4d\n", > decodes[i].date, decodes[i].time, >(int)(10*decodes[i].sync), > >73 >Bill >G4WJS. > > > >------------------------------ > >Message: 7 >Date: Sat, 14 Nov 2015 13:18:51 -0600 >From: Steven Franke < [email protected] > >Subject: Re: [wsjt-devel] WSJT-X: WSPR reported drift >To: Joe Taylor < [email protected] > >Message-ID: < [email protected] > >Content-Type: text/plain; charset=utf-8 > >Yikes! Yes, please fix it Bill. This?ll need to be fixed in both wsjtx and >wsjtx_exp I suppose. >Steve k9an > >> On Nov 14, 2015, at 12:58 PM, Bill Somerville < [email protected] > >> wrote: >> >> FAO Steve K9AN, >> >> I notice that wsprd reports the integer value of DT in the drift column, >> I assume this is a defect. If so I will apply the following patch: >> >> index 1aab50e..d70b71c 100644 >> --- a/lib/wsprd/wsprd.c >> +++ b/lib/wsprd/wsprd.c >> @@ -1160,7 +1160,7 @@ int main(int argc, char *argv[]) >> for (i=0; i<uniques; i++) { >> printf("%4s %3.0f %4.1f %10.6f %2d %-s \n", >> decodes[i].time, decodes[i].snr,decodes[i].dt, >> decodes[i].freq, >> - (int)decodes[i].dt, decodes[i].message); >> + (int)decodes[i].drift, decodes[i].message); >> fprintf(fall_wspr, >> "%6s %4s %3d %3.0f %4.1f %10.7f %-22s %2d %5u %4d\n", >> decodes[i].date, decodes[i].time, >> (int)(10*decodes[i].sync), >> >> 73 >> Bill >> G4WJS. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > >------------------------------ > >------------------------------------------------------------------------------ > > >------------------------------ > >_______________________________________________ >wsjt-devel mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > >End of wsjt-devel Digest, Vol 21, Issue 31 >******************************************
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
