Hi Mike, WSPR message structure is way beyond simple things like adding parity bits. The protocol is described in a number of places. For example, see Appendix B in any of these:
http://physics.princeton.edu/pulsar/K1JT/WSPR_2.0_User.pdf (Appendix B) http://physics.princeton.edu/pulsar/K1JT/WSPR_3.0_User.pdf (Appendix B) http://physics.princeton.edu/pulsar/K1JT/WSPR_4.0_User.pdf -- Joe On 7/31/2015 10:20 AM, Michael Black wrote: > 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:[email protected]] > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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
