What is the proper name for this technique.

[ste2425]

First of all sorry for the really poor thread title.

Basically many years ago i did a small module in pic micro-controllers at uni. On this module i remember them teaching us of a technique of applying a curve to a signal range.

So instead of a straight line mapping from one value to the other it had a curve. Hope these poor paint images will help demonstrate what i mean.

What is the name for this technique? Essentially what im doing is reading a 10k potentiometer that has a fixed range. I currently read its value and as i turn it through its range i get its value. However id like to run it through some form of process to apply a curve like the above to that signal range.

The behavior im after is for the first third or so of the pots range the value i get doesn't change too much than for the last two thirds the value ramps up to the pots maximum value.

However my maths is failing me badly and i don't even know what the correct technique is called to start googling.

Thanks for your time everybody.

 

[Seba_82]

Hi!, how are you!, i am new over here, sorry for my very bad english... i supouse you mean Linear and LOGARITHM,

 

[truth teller]

the curve you mention is an exponential function, basically e^x (or some variant) in code form
you can archieve this effect in hardware using a capacitor and a transistor (and a resistor for pull-up/down) (similar curves can be archieved using only a capacitor, charging and decharging cycle produce similar curves, inverted y and inverted x respectively from the picture you mentioned)

 

[silentbogo]

The easiest way is to replace your linear potentiometer with logarithmic one. Scaling can be done with Pullup/pulldown resistors.

But it all depends on what you are actually trying to do. If you are making something trivial, you can use code to get the desired result with an existing circuit.

If program is small and performance is not an issue: reading an input from ADC and applying a simple math formula would suffice.

You can also make a map/array for I/O translation, but it needs to be stored in micro-controller memory. It works much faster, because you don't have to perform any complex calculations, but is not useful for applications where memory capacity is critical.

 

[ste2425]

Thanks for the replies guys. I'm away from laptop so will look up what you've said when I get home. However some of it rings a bell. What I've got set the moment is a pic that reads a GameCube joystick which is essentially two 10k pots. It then converts. That to a n64 joystick. This works great in banjo kazoooe style games but for b perfect dark etc where you have to aim it doesn't feel right. I've noticed on xbox and other consoles the movement of the analog stick didn't relate to a direct linear movement in game but has a curve like the image in sensitivity so wanted to b investigate that. Ps I'm using phone to type this so sorry for grammar etc

 

[ste2425]

Well ive looked a bit more into and i fear i may have wasted your time.

I was replaying the issue from memory when i asked. Since actually using the controller im afraid it isn't infact the responsiveness of the analog stick through the range but more 'twitchyness' of the stick when held at an angle. Say in perfect dark when aiming on a bad guy/girl/child/dog/cat/cow (got to be equal these days right?) the cross-hair will twitch. So i need to modify my logic to only register movement if the stick has moved over a certain threshold from its current position.

Thinking more about what i was asking you guys, logarithmic scaling of each joystick axis through its range, this isn't really something that the controller should be doing anyhow right? It would be upto the game itself to apply such filtering to the controller input and i guess me performing it whilst a game is also doing it could lead to some 'interesting' game play. I may however revisit it and make it an opt-in feature when i sort the twitchyness. But thanks for the help everybody.

 

[FordGT90Concept]

Might need to increase the deadzone.

All a joystick does is give you a value of -1000 to 1000 on each axis. It's up to the game how to interpret that into the game space.

 

[silentbogo]

Here's my old article on handling XBOX controller with xinput. It might not be 100% related to your situation, but if you scroll down a bit you'll see some samples on how to handle deadzones easily.

http://eprojects.xyz/2015/05/21/using-xbox360-controller-with-arduino-part-2/

XBOX controller uses 16-bit values for thumbstick positions, so if you have an 8-bit or 10-bit ADC on your PIC, you should adjust those values accordingly.

 

[ste2425]

Might need to increase the deadzone.

All a joystick does is give you a value of -1000 to 1000 on each axis. It's up to the game how to interpret that into the game space.

Thats exactly what i was thinking, its just the controllers job to tell the game what the user is doing. Its up to the game how to interpret that. There's a dead zone implemented around the analog sticks stop position (top dead center) but the issue is when the stick is held seemingly stationary at some angle.

There are minor movements that you don't realize your doing however its enough for the PIC to read and think it needs to tell the controller its moved. An idea of a tiny deadzone that follows the stick may work, so for it to acknowledge that the stick has moved from its current position, that movement has to exit the deadzone.

Here's my old article on handling XBOX controller with xinput. It might not be 100% related to your situation, but if you scroll down a bit you'll see some samples on how to handle deadzones easily.

http://eprojects.xyz/2015/05/21/using-xbox360-controller-with-arduino-part-2/

XBOX controller uses 16-bit values for thumbstick positions, so if you have an 8-bit or 10-bit ADC on your PIC, you should adjust those values accordingly.

Brilliant ill have a read through that tonight. At a glance it looks it'll be quite useful.

 

[FordGT90Concept]

The only thing I can think of is it is rounding between two numbers, you have it somewhere in between, and the rounding + slight adjustment causes a jump between the two is causing the twitching. For example, you have it held at about 450 and you're seeing the effect of it jumping between 400 and 500. Joystick states are supposed to be transmitted as floating point numbers but if, at any point, that floating point is forced to an integer, it can cause that rounding and thusly the twitching.

 

[silentbogo]

There are minor movements that you don't realize your doing however its enough for the PIC to read and think it needs to tell the controller its moved. An idea of a tiny deadzone that follows the stick may work, so for it to acknowledge that the stick has moved from its current position, that movement has to exit the deadzone.

There is nothing wrong with handling that on PIC beforehand. On my gamepad 1% wobble was enough to cover the deadzone, so in your case 1.5% of max ADC value should cover it.

Are you using interrupts or single conversion to do your ADC acquisition?