ReadData method delay bug correction, the 10ms were removed since they were just needed because of delay function limitations. #29
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.
This change makes some small modifications to the MLX90393 library to enable it to achieve a higher Hz performance that the part claims in its spec sheet.
The only change was to the readData method, which was altered to use delayMicrosenconds instead of delay.
It seems delay was not able to handle the float vaues such as 1.28 and so on, since it is only ready to receive long.
Only needing this small change means that no change to the actual behavior of the class was needed, all methods work as they did with the addition of better poll rates.
The value of the table is obtained and multiplied by 1000 to convert from milliseconds to microseconds, converting float to long to be utilized in the delayMicroseconds function.
Although delayMicroseconds also has limitations, max 16383 and min 3 microseconds, these can be worked around by spliting the delay into multiple delayMicroseconds taking into consideration the max allowed.
After this change a test for each of the modes was done making sure all worked with this change, where it was detected that the mode [DIF_FILT][OSR] = [7],[3] was not working properly in which the value was just incremented in 1ms in the table which corrected the issue for that mode too.
The test for the Hz(Only poll rate was tested) were done in the folloing way, in the loop it was incremented per cycle the number of polls and in each run of the loop a request is done to the sensor, the values are not written to the console to not consume CPU time, only if there is an issue, the actual poll rate is printed each second to minimize time printing to console.
The 500Hz were not obtainable, although in the fastest speed [DIF_FILT][OSR] = [0],[0] it was possible to obtain 369Hz poll Rate.
Code below:
`long lastSecond = millis();
int pollRate = 0;
float x, y, z;
void loop(void) {
if(millis() - lastSecond > 1000) {
Serial.print("Poll Rate: ");
Serial.print(pollRate);
Serial.println("Hz");
pollRate = 0;
lastSecond = millis();
}
// get X Y and Z data at once
if (sensor.readData(&x, &y, &z)) pollRate++;
else Serial.println("Unable to read XYZ data from the sensor.");
}`
The following teste was done for the [DIF_FILT][OSR] = [0],[0]