Skip to content
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

ReadData method delay bug correction, the 10ms were removed since they were just needed because of delay function limitations. #29

Closed
wants to merge 5 commits into from

Conversation

1DOTCODE1
Copy link

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]
image

@1DOTCODE1
Copy link
Author

Meanwhile a new method was also added to allow the obtention of the delay in ms for the current configurations, this will allow for the call of the method startSingleMeasurement, then this new method(getDelayForSingleMeasurment) can be called to validate the time that is needed to obtain the new values from the sensor, wait the obtained delay in some way, might be an interrupt or other logic running and then the readMeasurement can be called.

This allows a async logic to be built that is not based on the delay function.

@1DOTCODE1 1DOTCODE1 closed this Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant