More accurate control of integration time #40
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Allow setting any ATIME value 0-255 - Add mathod for setting integration time in msec - Add setRawData option to delay by integration time before reading
|
thanks, it may be a bit till we get back to this library. till then can you check the CI failure report above? there some non-compiling example code - clieck Details on the CI build report :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The changes here are all related to my attempts to achieve more reliable readings from the TCS43725, particularly when dealing with changes in integration time. The initial problem I ran into is that getRawData was returning values that were not consistent with the configured integration time (also reported in #15). After digging into that issue, I found that the implementation of
setIntegrationTimewasn't consistent with the model described in the datasheet (also reported in #37). These two issues are addressed across several changes:waitargument togetRawData, allowing to delay until integration has finished. (fixes Issues with accuracy and speed #15).reset()and calls this whenever changing integration time in order to begin the new integration immediately. This ensures that the delay in getRawData is sufficiently long to guarantee integration has completed.enable(); this is no longer necessary due to the above changes.setIntegrationTimethat accepts auint8argument rather thantcs34725IntegrationTime_t. The datasheet specifies that any value 0-255 is acceptable here, whereastcs34725IntegrationTime_tonly provides access to a few specific values.setIntegrationTimeMsec, which selects the closest ATIME value to the requested duration and returns the actual integration time.getRawDataMax(), which returns the maximum possible raw data value given the current integration time, making it possible to detect saturation.calculateIntegrationTimeand calculateIntegrationConstant`, which map back and forth between ATIME and integration time in msec. Note--the values I use here are based on my own measurements from my device, which did not match the values in the datasheet. I don't know whether these values will be universally accurate.I believe these changes are backward compatible, with the exception of some timing differences and the addition of a reset() when setting integration time. I have tested both
examples/tcs34725andexamples/tcs34725autorange; everything seems ok there. The other two examples would have required some hardware modifications, though, so I haven't tried those.