Hi David, Thanks for your view of what the issues are.
The incorrect spot can waste a lot of time when the 6m band is "going" so minimisation of these false reports would be most helpful. I can also agree on the process, I have done that many times but it takes a few minutes. Sometimes a spot is correct yet it seems un-believable, thus happened to me when I was the only one to hear W9JN on Jun18 this year on 6m, and it took me a few precious minutes to find out that it was correct,,, maybe I should have just replied to the CQ straight up and that could have sorted the issue. Problem was there was a lot of QRM at his end, and that may have made things difficult, anyway, I did not complete the contact. Interesting thing is that a 6m contact to NA in June is very rare as it is our winter, so the value of accurate 6m reports is obvious. 73 Andrew, VK3OE/VK3OER -----Original Message----- From: David Tiller [mailto:[email protected]] Sent: Friday, 27 October 2017 11:39 To: WSJT software development <[email protected]> Subject: Re: [wsjt-devel] False Frequency reports Andrew, Thanks for the clear explanation of the problem. As I and others have said, CAT control is not a guarantee of perfect spots. Changing bands at the wrong instant can still generate bad info (even accidentally pressing the wrong button on your rig can do that). Similarly, impossible/wildly inaccurate decodes do happen, and those (AFAIK) also get reported. As I've said, relying on raw data to draw conclusions is not a good idea, and the pskreporter maps are representations of raw data. Here's an example of how PSKReporter could curate their data to make it more accurate. Here's a link to a randomly-chosen example of a bad report from your dataset that you mentioned. It involves LU5VV reporting AC9NJ on 6m at 2017-10-26 01:40:15Z at offset 496 Hz. --> https://drive.google.com/open?id=0B4DphHV_ItCZazNKUlI5aUN5WHc I then searched for reports of others hearing AC9NJ on any band(s), and found that at least one other station heard the same report as LU5VV, except on the correct band (and similar offset of 508 Hz). Here's the link --> https://drive.google.com/open?id=0B4DphHV_ItCZNU1sdTgzQmtVUkU When conflicting reports are received (note that they'd all be received in the same transmission 'slot'), the singleton report should be discarded. If there are many reports that conflict, throw them _all_ out. Simple data cleansing by pskreporter would yield better information for _all_ of the users, including those that may later access the historical database - it's better that bad spots never get into the database in the first place, regardless of their source. -- David Tiller Sr. Architect/Lead Consultant | CapTech (804) 304-0638 | [email protected] On Oct 26, 2017, at 6:52 PM, Andrew Martin <[email protected]> wrote: > Hi, > > To illustrate exactly what the problem is have a look at PSK reporter > for the last 24 hours, use 6m, LU5VV FT8 and 24 hours. > > This type of false reporting makes the 6M usage difficult because of > the rare propagation on 6m of long distance contacts. It only takes > one set of false reports like the above to make PSK reporter almost > useless for 6M long distance propagation surveilence. > > Maybe false reports do not matter so much for lower frequencies as > there are so many reports. > > All I was asking was for a click box to the right of the frequency box > to ckick when the CAT is not connected to confirm the frequency. > > Andrew > VK3OE. > > -----Original Message----- > From: David Tiller [mailto:[email protected]] > Sent: Friday, 27 October 2017 09:21 > To: WSJT software development <[email protected]> > Subject: Re: [wsjt-devel] False Frequency reports > > >> In passing one might note that CAT control is not a panacea against >> bad > reports. > > Exactly! The data is never going to be perfect - there are enough > intrinsic bad decodes even on the correct freq that get reported up. > > As any careful data consumer knows, you must clean and curate any > dataset you use. That includes weeding out spots that appear once on > band A but are matched by multiple simultaneous spots on band B. > >> On Oct 26, 2017, at 17:52, G8DQX (WSJT developers on SF) > <[email protected]> wrote: >> >> In passing one might note that CAT control is not a panacea against >> bad > reports. > > ---------------------------------------------------------------------- > ------ > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ---------------------------------------------------------------------- > -------- Check out the vibrant tech community on one of the world's > most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > wsjt-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ---------------------------------------------------------------------------- -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
