Go Down

Topic: Hysteresis (Read 8947 times) previous topic - next topic


Ok, I should not have mentioned an enhancement that had a time element. The rest directly simplified a hysteresis procedure.


I am sure there are other ways of achieving the same thing. However you implement it, you are implicitly accepting a loss of precision. This loss of precision is explicit in the model I have used. Most applications of hysteresis here will require, in addition to boundary checking, a value range mapping, by some means or other. Hence the example of the potentiometer delivering N discrete values. These elements are combined in the solution I have proposed. By all means, use another solution if it better matches your needs especially if you want to introduce a timing element like an incremental change of precision based on the rate of change of the underlying value or similar.


I guess I am just quibbling over running efficiency vs code size/complexity. Maybe a print function running in the neighborhood of once a second makes efficiency an unimportant consideration.

I did not immediately understand the code you wrote because its syntax is a little above my skill level but it seemed complicated to me. I went back and concentrated on following what you wrote and it seems to me that you calculated the inverse conversion function for the current displayed value to find a range of values to test the new measurement against.

I suggest instead to add the margin to the new measurement and then test if the conversion function will give the same output as the current displayed output. If either adding or subtracting the margin gives you an unchanged output, then you do not need to go any further. The output must remain unchanged.

Best case your method will perform the inverse conversion function twice while my method will perform the conversion function once. Worst case, you perform the inverse conversion function twice and the conversion function once while I perform the conversion function three times. (obviously the efficiency of the conversion function relative to the inverse conversion function would be worth considering)

Perhaps add an initial test to see if the new measurement will give an unchanged output without margin consideration or if it will give an output more than one away from the current displayed value. Both instances would eliminate consideration for hysteresis.

Also, it seems to me that it would be good to have the conversion function (and the inverse conversion function) outside the hysteresis function. That would free up the hysteresis function to be used for nonlinear conversion functions. (an inverse conversion function for margin calculation would then be needed)


Defining it as a class has made it look somewhat clumsy, that is true, but if you strip out the class overhead and the comments, there is not really that much left. The class structure is ideal for the case that multiple data sources are used (e.g. potentiometers in an audio application) because of the requirement to store the previous state of each data source.

Of course, it would have been possible to define a single function, but then the user would have to take responsibility for storing the previous state of each data source and hand it over to the function at each call.

For time critical applications, obviously it is necessary to look at all possibilities for optimising the code. However, things dependent on changes to the environment (light levels etc.) or things which result from human intervention (potentiometer changing value etc.) don't have to be tested so often so some inefficiency there can be tolerated.

Anyway, thanks for your input and comments and I am pleased that the issue has aroused such interest. If I return to this theme, I'll look again carefully at the issues identified and suggestions made and attempt to incorporate these in any future development.


Apr 23, 2018, 07:55 pm Last Edit: Apr 23, 2018, 07:58 pm by GoForSmoke
How would my reply have anything to do with debouncing? My reply clearly has to do with changing output when the new value is close to a boundary, thus preventing unwanted flickering between two output values.
That is ADC DITHER and I made a reply about that leaving a long-known non-moving deadzone solution.

Since then it's been made it clear that the topic is not ADC dither. So why not spend a few pages retyping what is just too long to bother reading through before adding yet another off-topic post, it's so much easier than reading the ongoing context.

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.


Which brings up a completely different subject...  AVERAGING.
If one applies hysteresis to an average value over time, many of the needs for hysteresis are minimised.
Now we can fight over different methods of averaging!
Experienced responders have a nose for laziness, (they were beginners once)... Sure, there are trolls, chest-beaters, and pretenders - but the help you'll get here is about as good as it gets - if you try to help youself!.

Go Up