MultiGeiger
MultiGeiger copied to clipboard
ecocurious2
separate CPM calculation from displaying / sending
Currently, displayGMC and transmit functions in multigeiger.ino both calculate their own count_rate, CPM etc. Current BLE dev uses displayGMC to avoid yet another separate CPM calculation and timestamp storage. Maybe we could have a minimum time granularity to calculate CPM in main loop and use that calculated value for displaying, BLE, Wifi and LoRa transmissions?
Yeah, I also thought about decoupling calculation and display.
But depending on the update interval, we have to compute different values:
- display update interval
- bt transmission interval
- internet server transmission interval
- ...
Not sure how to deal with that.
Hmm, maybe we could use a ring buffer that has fine-granular (e.g. per-second) pulse counts for the last 10 minutes or so. That could be managed by some ISR to make it rather precise.
Then, there could be one function that gets 2 same-granularity (e.g. 1s) timestamps and computes:
- counts in that interval
- radiation in nSv/h for that interval
One needs to be careful of course to not lose counts that way and deal with the intervals correctly.
Yes, good idea - although the count rate typically isn't changing a lot. But maybe we're could store different time scales, too - that could be interesting, e.g. one all-time (since reboot?) rate, one weekly, one daily, and one hourly rate.
I don't think we should target longer timeframes (like a week) because we have stuff in RAM and if power goes away, it is lost. So longer term storage and display should be done by some server (or maybe a smartphone in future?).
But all that makes sense for shorter experiments, ad-hoc and mobile usage could be within the multigeiger.
Are we monitoring typical uptimes somehow at the moment? Stability here does not look too good... 1.13.0-dev-ble had few days until reboot, now it's at a few hours... so indeed no long time values available...