Since all the chars in message are ASCII is it possible to add a parity bit? Or an 8-bit checksum or CRC to the message? I'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] 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 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
