27-11-2018, 00:39
Answering with a though:
Should those checks be done at WeatherDuino level, by a microcontroller with limited memory resources and running at relatively low clock speed, or at weather software level which usually run on machines with lots of memory and much higher clock speeds?
By other side, datasets with a date in the past are absolutely normal in a logger, if they are more in the past than required by the weather software, then they should be rejected by the software (Cumulus 1 and CumulusMX does this). Datasets with a date on the future, can only happen due to something which will cause that the system clock isn't set properly. As much as we know, the only thing than can cause wrong timestamps is compiling the software with avr 1.6.22 or 1.6.23,
If you wish, you can try to write an weatherduino routine to do what you propose, but then give a look at the size of the resulting code, and the processing overhead that it will introduce (imagine a full logger download: 512 pages * 5 records).
Should those checks be done at WeatherDuino level, by a microcontroller with limited memory resources and running at relatively low clock speed, or at weather software level which usually run on machines with lots of memory and much higher clock speeds?
By other side, datasets with a date in the past are absolutely normal in a logger, if they are more in the past than required by the weather software, then they should be rejected by the software (Cumulus 1 and CumulusMX does this). Datasets with a date on the future, can only happen due to something which will cause that the system clock isn't set properly. As much as we know, the only thing than can cause wrong timestamps is compiling the software with avr 1.6.22 or 1.6.23,
If you wish, you can try to write an weatherduino routine to do what you propose, but then give a look at the size of the resulting code, and the processing overhead that it will introduce (imagine a full logger download: 512 pages * 5 records).