Are controllers inconsistent in sampling stick input as angles?

This question comes to me as I have an issue detecting if a joystick is rotating clock wise or counter clock wise. I’m basically getting the axis of the joystick and using Atan2 to output an angle and transforming it into degrees. I than store a previous and current angle every frame as a means of comparing them, similar to what is described here:

Detect circular movement with joystick

Which works fairly well, except for that every few frames while rotating counter clock wise I get the values of actually having rotated clock wise, even though I did not. At this point I just want to know if this might be a thing or if I have to keep thinking of different solutions, as I already spend some time with this issue.

I would guess this is maybe caused by the transition from the high numbers around 350-360 to the low numbers around 0-10?

For that one frame it will look like the angle decreased because it went “down” from 350 to 10.

although StarManta’s code should be compensating for that.

The only thing to do is detect when your code things it’s going the wrong way and just print out all the values involved.

Thanks for your reply PraetorBlue. But yeah I’m compensating for the big change in angle on moving over 360°.
I’ve gone back to the roots already, so to say, which lead me to ask this question. I was purely taking in the input, transforming it into degrees and than printing it to the console in addition to storing the input angle of the previous frame so I can compare them. And most of the time, while moving counter clock wise the change was as expected since the current angle was smaller than the previous one hinting on a clounter clock wise rotation (accounting for the change of values at 360°), but once in a while, even though (I would say) I moved the stick correctly all the time, the current angle would be bigger than the previous one, causing a false value to be output.

Makes me kind of belive that I might want to tinker with the controller settings a bit, i.e. dead zone, or test it with another controller, but I’ve no leads otherwise.

€: Here’s a screenshot of some of those “faulty” values, interestingly enough the previous and current angle are always very close to each other value wise. Using a threshold of some sort in this case wouldn’t help though as it would also apply to the clock wise rotation blocking changes by small angles, which makes me belive that I might just want to round the input values before in some way. These values were not output in succession but rather over several circular motions. Maybe @StarManta knows something about this, as I used their code as orientation?