Thanks for those thoughts, and confirming the internal name of the signal quality Let me go back and analyse the bad data and confirm that there really is nothing worth saving when rxCheckPercent is not 1 I agree, it would be cleaner to not have the driver insert the bad data in the first place if possible.
Tks Derek On Thursday, May 18, 2017 at 11:19:28 AM UTC+1, mwall wrote: > > > > On Thursday, May 18, 2017 at 5:39:27 AM UTC-4, drder66 wrote: >> >> >> Unless there is some neat trick to use sqlite to remove table entries >> when ISS is not 1 (and I'm not sure the signal quality is saved, and it it >> is, what it would be called), would it make sense to consider a >> wee_database option to remove all data where the signal quality was suspect >> ? >> > > since a value for rxCheckPercent not equal to one is perfectly valid, and > the behavior you describe is specific to fine offset hardware, it might be > better to simply do the database cleanup using a sql command. something > like: > > update archive set windSpeed = NULL, outTemp = NULL, ... where > rxCheckPercent <> 1; > > however, if the correlation you describe is consistent, then it might be > useful to put the logic in the fine offset driver. that would prevent bad > data from getting into the database in the first place. > > m > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
