-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow fetching data even when using setWaitForConversion(false) #254
Comments
Interesting question, |
bool DallasTemperature::readScratchPad(const uint8_t * deviceAddress, uint8_t * scratchPad) Somewhere in the getTempC() call stack the above call will appear. This would reduce IO and thus time needed. Did a similar trick in my https://github.com/RobTillaart/DS18B20_RT library - using a flag DS18B20_CRC to disable the CRC check - however my library only supports one sensor per pin. |
Measurements with my library with an UNO, timing for getTempC only if fetching 9 bytes it takes ~28 millis, if fetching 2 bytes it takes ~24 millis. don't know how this gain ports to another processor. |
I am reading 12+ sensors. I use
setWaitForConversion(false)
sorequestTemperatures()
returns instantly and as I understand it the conversions are done in the background. Then when I want the temps I usegetTempC(address)
which takes 13ms to return. This is much faster than waiting for conversion but still when reading 10 sensors this is 130ms which I cant afford to block for, and we are wanting to add more sensors...I refactor my code to read only one 13ms block per loop witch spreads out the blocking rather than having it all at once but I would still like to investigate the reason for the delay. Is it purely the unavoidable transfer time of the converted data from sensor to processor? Or are there other ways to optimise this?
Since conversion has already been done at this point I assume lowering resolution will not have any impact so have not tested this. Is this correct?
By my (cough, ChatGPT) calculations:
So I'm guessing the additional 8ms are overheads and unavoidable? Or can we shave them off somehow?
Any tips or tricks or optimisations appreciated? Thanks
The text was updated successfully, but these errors were encountered: