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 perhaps filter off most false spots. The draw back is that the first reception of a valid spot would no be forwarded. But since the likelihood of receiving only a single spot is unlikely, once the fist spot is received for a call, all subsequent spots would be sent to wsprnet.
73, Edson PY2SDR --- - We humans have the capability to do amazing things if we work together. - Nós seres humanos temos a capacidade de fazer coisas incríveis se trabalharmos juntos. On Fri, Jul 31, 2015 at 11:11 AM, Joe Taylor <j...@princeton.edu> wrote: > 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 > times are the average of two runs. > > > > Cases > > 1. wsprd > > 2. wsprd_exp (Fano, 10000 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 interesting part is the number in parentheses. This time, I paid > attention to the number of obviously bad decodes. It’s not easy to find the > bad decodes that show up as type 1 callsigns - but it is easy to find and > count the ones that show up as type 2 or 3 callsigns with a forward slash > “/“. The number in parentheses is the number of bad decodes with a slash in > the callsign. It needs to be said that we see only the bad decodes that > aren’t trapped by a sanity check in the unpacking routines. > > > > There is something funny going on with the Fano decoder in case 2. Here > is the result of doing a grep for “/“ in the ALL_WSPR results from the > three cases: > > > > Case 1. wsprd > > $ grep / Results_wsprd > > 0342 -28 0.5 0.001523 0 PH6/OK1SCE 10 > > 0630 -14 -0.8 0.001518 0 M0N/BX6IJG 30 > > > > Case 2. wsprd_exp Fano > > $ grep / Results_Fano.txt > > 0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33 > > 0148 -22 -0.9 0.001523 0 C4S/U23 27 > > 0512 -12 -1.4 0.001544 -1 EYJ/BD3OWF 43 > > 0526 -5 -1.1 0.001515 -1 J28/JH9VOA 10 > > 0530 -10 -1.3 0.001527 -1 XIR/L12IRI 57 > > 0534 -21 0.1 0.001451 0 5EY/588TIB 53 > > 0540 -9 -1.3 0.001498 -1 286/CI7RCI 13 > > 0614 -8 -1.2 0.001523 -1 W64/CZ9IYO 13 > > 0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13 > > 0704 -10 -1.3 0.001550 -1 KN4OHP/44 53 > > 0746 -8 -1.4 0.001525 -1 ATD/012KCR 27 > > 0856 -19 -0.8 0.001523 0 I02/VK3PNP 20 > > 1400 -17 -0.5 0.001459 0 P2INE/2 53 > > > > Case 3. wsprd_exp Jelinek > > $ grep / Results_Jelinek5000.txt > > 0114 -16 -0.3 0.001524 0 88Y/9E3XMR 33 > > 0616 -31 -1.0 0.001491 0 M2Q/ZG4VPX 13 > > 0654 -12 -1.3 0.001523 -1 1LY/GH4 40 > > > > Note the large number of bad decodes coming out of the Fano decoder in > case 2. There is only one bad decode that is common to cases 2 and 3. If > you look at the times, it appears that the bad decodes in case 2 are coming > in bursts. I have to wonder if this corresponds to special noise > conditions, e.g. lightning storm. > > > > It’s hard to reconcile the large difference in bad decodes between pairs > 1-2 and 2-3. In 1-2 the decoding algorithm is the same and in 2-3 the > candidates are the same. Strange, eh? > > > > I’ve just gone back and looked at bad decodes using the same > “forward-slash” criterion on two groups of my own wav files and in each > case I see either 2 or 3 bad decodes out of about 2000 for Fano and > Jelinek. There are no big differences between the number of bad decodes in > cases 1-3 for my test data. Still strange. > > > > Steve k9an > > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel >
------------------------------------------------------------------------------
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
