Reset the Hall Effect V2 counter with its periodic callback (uc bindings)

[cl-]

Hi,

I was wondering how to reset the Hall Effect V2 counter when using the periodic callback instead of the tf_hall_effect_v2_get_counter() function. I use the uc bindings.
tf_hall_effect_v2_get_counter() has an input parameter for that purpose, but the counter callback configuration does not.

I could not find out whether the callback resets the counter automatically by scanning through the uc bindings (I assume it does not though).

I like to always reset the counter when the periodic callback was triggered to measure the RPM of a wheel.

Any chance it can be done with the callback too?

Cheers,
Claudio

bearbeitet August 27, 2022 at 11:31 von cl-

[cl-]

I edited previous my post and wrote more details, but the forum kicked me out because it took "too long" to write. All my changes were lost somehow, which is strange.

bearbeitet August 29, 2022 at 11:55 von cl-

[cl-]

Once again (in short)

As it's not allowed to call tf_hall_effect_v2_get_counter() inside the callback handler, one possible approach would be to set a flag inside user_data to trigger a manual counter reset outside the callback handler. However, if the delay between the callback handler was triggered and the subsequent, manual counter reset outside the callback is too long, one might in theory miss counters when the counter frequency is very high (or am I wrong?). I doubt that might ever play a role in my special use case (20 counters per second), but if one would approximate the maximum of 10 kHz?

What's the right approach to reset the counter with the periodic callback? Or is it done automatically anyway, but it's just not "visible" in the source code?

bearbeitet August 29, 2022 at 11:54 von cl-

[photron]

On 8/27/2022 at 2:26 PM, cl- said:

What's the right approach to reset the counter with the periodic callback?

This is not possible in a robust way right now. Even if the uC bindings would allow you to call the getter to reset the count in the callback, you could still lose count.

The callback doesn't rseet the count, only the getter with reset_counter=true does it.

If you want to use the callback ou can emultate a reset in your code by remembering the counter value from the previous callback call and subtract that from the new value.

[cl-]

I have another problem that is related to my previous question:

In your documentation, you say that "If the measured magnetic flux density goes above the high threshold or below the low threshold, the count of the counter is increased by 1."

In the screenshot, I have a signal that ranges between 300 and 1200 uT (approx). This configuration works for the shown signal.

For some reason though, that does not work anymore, when I change the low threshold to -7000 uT, for instance. The counter should still be incremented by the high threshold. However, doing that causes the counter to stand still for as long as I keep the low threshold to -7000 uT. Changing back to 350 uT makes the counter increase again.

Now what's weird, the other way does work indeed, that is changing the high threshold to 7000 uT (instead of the 1150 uT). In this case, the counter works as expected, as the low threshold is still "active".

What am I doing wrong? Why does the low threshold causes this weird behaviour? Any ideas?

Cheers,
Claudio

bearbeitet October 25, 2022 at 13:42 von cl-

[borg]

That is indeed strange. I just looked at the code and there is nothing special with negative values or similar.

Does this behavior start happening with a specific threshold? If you start increasing the low threshold is there a specific point where it starts to work properly?

 

Internally the low threshold is converted into a voltage that is fed to an analog comperator.

int32_t mv_low  = (-drv5053.counter_threshold_high*90/1000) + DRV5053_ZERO_OFFSET_MV;

the offset is 1020, so mv_low = (-(-7000)*90/1000) + 1020 = 1650 in your case. This is not at all an edge case (the voltage can go from 0mV to 3300mV here).