开云体育

Fat-finger problem in Spot Collector

Earl Needham All Messages By This Member #229317 For MONTHS now, I've been having an on-again off-again problem.? If I let my spot database get too large (around 10,000 entries is when I start noticing it), it gets slower & slower processing spots, until it finally just stops doing ANYTHING and I usually have to use Task Manager to kill the program before staring over. Well, this morning, it happened again.? I had let it run overnight, and the database had around 20,000 entries, and when I first came into the radio room this morning, the Q said 842 and was just sitting there, not processing. Once I got it going again, I started going through ALL the config settings in Spot Collector, one-by-one like a checklist.? I had a hit on the first one!? Apparently, some time in the past, I meant to set "Maximum Separation in Time) to 60, which is reasonable, but I found it set to 600!!!? My finger must have bounced on the 0 key and I never noticed.? Spot \|Collector sure seems to run better now that it's changed to 60, with my current database at ~11,300 and all Telnet sources are turned on with skimmer turned on throughout.? Oops, now we're at ~11,350... A fat-fingered wrod ot teh wsie... Vy 7 3 Earl / KD5XB DM84 e e Sent with secure email.
Dave AA6YQ All Messages By This Member #229319 + AA6YQ comment sbelow Once I got it going again, I started going through ALL the config settings in Spot Collector, one-by-one like a checklist.? I had a hit on the first one!? Apparently, some time in the past, I meant to set "Maximum Separation in Time) to 60, which is reasonable, but I found it set to 600!!!? + With that setting, each time a new spot arrived that was not a duplicate of a recently-received spot (e.g. from another cluster), SpotCollector was searching through the last 600 minutes (10 hours) of Spot Database Entries looking for an existing Spot Database Entry matching that new spot. If your Spot Database contains only an hour's worth of spots, this would have no adverse impact, but with a larger Spot Database, a lot of CPU time would be spent needlessly searching. + When you have a DXLab application working they way you want it, terminate it and direct the Launcher to save its settings to a Workspace. Then if you experience an unexpected change in the future, you can direct the Launcher to restore those setting to quickly recover from an inadvertent setting change. ? ? ?73, ? ? ? ? ? ?Dave, AA6YQ
Earl Needham All Messages By This Member #229321 Good idea. I meant to include this in my original message, but forgot -- my checklist is at?? Vy 7 3 Earl / KD5XB e e Sent with secure email. On Wednesday, May 21st, 2025 at 2:23 PM, Dave AA6YQ <aa6yq@...> wrote: toggle quoted message Show quoted text + AA6YQ comment sbelow Once I got it going again, I started going through ALL the config settings in Spot Collector, one-by-one like a checklist.? I had a hit on the first one!? Apparently, some time in the past, I meant to set "Maximum Separation in Time) to 60, which is reasonable, but I found it set to 600!!!? + With that setting, each time a new spot arrived that was not a duplicate of a recently-received spot (e.g. from another cluster), SpotCollector was searching through the last 600 minutes (10 hours) of Spot Database Entries looking for an existing Spot Database Entry matching that new spot. If your Spot Database contains only an hour's worth of spots, this would have no adverse impact, but with a larger Spot Database, a lot of CPU time would be spent needlessly searching. + When you have a DXLab application working they way you want it, terminate it and direct the Launcher to save its settings to a Workspace. Then if you experience an unexpected change in the future, you can direct the Launcher to restore those setting to quickly recover from an inadvertent setting change. ? ? ?73, ? ? ? ? ? ?Dave, AA6YQ

Previous Topic Next Topic