False Decode Progress
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
For example, I am the only one who decodes N3AGE many times per day, on many bands.
On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
The other thing I noticed was that a single transmitter - a balloon in the North Atlantic, which I believe was real - was the apparent source of many bad decodes, bad callsign and power but oddly not location. Many more bad decodes than all the other ones put together. In that case I wondered if there was not something up with the transmitter itself.
Anyway, I'm going to turn it back down to the default, or about that. Mainly because I don't like the false decodes messing up my pretty map.
Edward
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
- I suggest -C 1000 and -o 4 on wsprd cmds
- running FST4W means that the jt9 decoder runs and it is prone to falsing
I beg to differ on decoding N3AGE, but I did experimentally turn up W3ENR's decoding intensity to 5000. What I noticed was a modest increase in obviously false decodes (e.g. African callsign deep in Antarctica, a UK callsign in far north Russia, etc).
The other thing I noticed was that a single transmitter - a balloon in the North Atlantic, which I believe was real - was the apparent source of many bad decodes, bad callsign and power but oddly not location. Many more bad decodes than all the other ones put together. In that case I wondered if there was not something up with the transmitter itself.
Anyway, I'm going to turn it back down to the default, or about that. Mainly because I don't like the false decodes messing up my pretty map.
Edward
On 8/13/22 09:59, WA2TP - Tom wrote:
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.
On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
On Aug 13, 2022, at 7:50 PM, Jim Lill <jim@...> wrote:
-Jim
- I suggest -C 1000 and -o 4 on wsprd cmds
- running FST4W means that the jt9 decoder runs and it is prone to falsing
On 8/13/22 11:41, Edward (W3ENR / K3WRG) wrote:
I beg to differ on decoding N3AGE, but I did experimentally turn up W3ENR's decoding intensity to 5000. What I noticed was a modest increase in obviously false decodes (e.g. African callsign deep in Antarctica, a UK callsign in far north Russia, etc).
The other thing I noticed was that a single transmitter - a balloon in the North Atlantic, which I believe was real - was the apparent source of many bad decodes, bad callsign and power but oddly not location. Many more bad decodes than all the other ones put together. In that case I wondered if there was not something up with the transmitter itself.
Anyway, I'm going to turn it back down to the default, or about that. Mainly because I don't like the false decodes messing up my pretty map.
Edward
On 8/13/22 09:59, WA2TP - Tom wrote:
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.
On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
Also, if Jim's data is coming from our wsprdaemon.org scrape of wsprnet.org, then there is no way to distinguish between WSPR-2 and FST4W-120 spots.
So the FST4W spot count is probably higher.
Rank Reporter Rep_Grid Con wUnqs 2200 630m 160m 80m 80eu 60m 60eu 40m 30m 20m 17m 15m 12m 10m 6m 2m fst4 fUnqs Fls Spots
|___ wspr only
uniques total valid
fst4w spots ___| | | |___ all reported
spots++
fst4w unique for all bands/modes __| |____ trapped falses for all wspr/fst4w bands/mode**
** does not include balloons.
So are these false decodes primary with 4w only?
Are you counting 4w decodes in your daily raw and unique totals?
I see a separate column on your page just for 4w.
On Aug 13, 2022, at 7:50 PM, Jim Lill <jim@...> wrote:
-Jim
- I suggest -C 1000 and -o 4 on wsprd cmds
- running FST4W means that the jt9 decoder runs and it is prone to falsing
On 8/13/22 11:41, Edward (W3ENR / K3WRG) wrote:
I beg to differ on decoding N3AGE, but I did experimentally turn up W3ENR's decoding intensity to 5000. What I noticed was a modest increase in obviously false decodes (e.g. African callsign deep in Antarctica, a UK callsign in far north Russia, etc).
The other thing I noticed was that a single transmitter - a balloon in the North Atlantic, which I believe was real - was the apparent source of many bad decodes, bad callsign and power but oddly not location. Many more bad decodes than all the other ones put together. In that case I wondered if there was not something up with the transmitter itself.
Anyway, I'm going to turn it back down to the default, or about that. Mainly because I don't like the false decodes messing up my pretty map.
Edward
On 8/13/22 09:59, WA2TP - Tom wrote:
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.
On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim
One error below, Spots is only valid wspr spots, no fst4w, falses, or balloons
Rank Reporter Rep_Grid Con wUnqs 2200 630m 160m 80m 80eu 60m 60eu 40m 30m 20m 17m 15m 12m 10m 6m 2m fst4 fUnqs Fls Spots|___ wspr only uniques total valid fst4w spots ___| | | |___ all reported spots++
fst4w unique for all bands/modes __| |____ trapped falses for all wspr/fst4w bands/mode**
** does not include balloons.
On 8/13/22 20:33, WA2TP - Tom wrote:
So are these false decodes primary with 4w only?
Are you counting 4w decodes in your daily raw and unique totals?
I see a separate column on your page just for 4w.
On Aug 13, 2022, at 7:50 PM, Jim Lill <jim@...> wrote:
-Jim
- I suggest -C 1000 and -o 4 on wsprd cmds
- running FST4W means that the jt9 decoder runs and it is prone to falsing
On 8/13/22 11:41, Edward (W3ENR / K3WRG) wrote:
I beg to differ on decoding N3AGE, but I did experimentally turn up W3ENR's decoding intensity to 5000. What I noticed was a modest increase in obviously false decodes (e.g. African callsign deep in Antarctica, a UK callsign in far north Russia, etc).
The other thing I noticed was that a single transmitter - a balloon in the North Atlantic, which I believe was real - was the apparent source of many bad decodes, bad callsign and power but oddly not location. Many more bad decodes than all the other ones put together. In that case I wondered if there was not something up with the transmitter itself.
Anyway, I'm going to turn it back down to the default, or about that. Mainly because I don't like the false decodes messing up my pretty map.
Edward
On 8/13/22 09:59, WA2TP - Tom wrote:
I think the only person reporting variable may become an issue and become source of false elimination of valid data.
For example, I am the only one who decodes N3AGE many times per day, on many bands.
On Aug 13, 2022, at 7:06 AM, Jim Lill <jim@...> wrote:
I've made some progress on the false decodes situation. In addition to the refinement of the filters I use, I have changed the "err" column on my 8088 page to be "fls". That column is the number of False Decodes that were trapped and there not counted as unique. Most of those are caught by being a bad non-existent prefix or callsign format. Still under development is a valid callsign trap which will either use a whitelist or only-spot technique. The latter is if the person reporting it is the only person.
Large number of false decodes can be the result of aggressive values of -C and -o on the wsprd cmd line value. Also, multiple receivers on the same band simply multiply the chances.
-Jim