the encoder itself is from an Audi TT, but from what i understand its a generic part used in Audis, VWs and some other cars.
i am just downloading the excel spreadsheet and i will take a look at it in a sec,
i am trying to re-purpose the sensor, and i don't want to use its original data output (angle in degrees is sent after a can bus message is received) because as far as i can tell, to zero the system (if the steering wheel has been realigned for example) requires some overpriced diagnostic tool, i feel it would be simpler if i took full control and then i can decide how the data is managed and transmitted.
here is a video i found that someone has made of the sensor:
thanks again for all your help guys, i am glad it is not so straight forward otherwise i would have felt pretty stupid for not figuring it out.
the reason that using math to get a higher bit number isn't working because there are only 16 possible numbers every time
That is not a valid argument against the approach. There are 256 unique values associated with two independent 4 bit numbers, and so forth for large bit combinations.
dougp:
I suspect this wheel, in addition to providing direction (although that may not be its primary function), is also part of the code generated by turning the wheel. The MSB part, if you will.
thanks for the reply,
i am not sure how it would add to give an absolute position though because it is totally stationary (locked by the encoder wheel) until a full rotation is done. it rotates at the same point on the encoder wheel every time so it is the same sequence of numbers coming from the encoder wheel each time the smaller wheel is turned.
check out the video i linked to get an idea of how it looks. (thats the same kind of unit that i have in front of me)
jremington:
That is not a valid argument against the approach. There are 256 unique values associated with two independent 4 bit numbers, and so forth for large bit combinations.
thanks for the reply,
sorry i don't quite understand, if there is a 4 bit number, that gives us 0 to 15,? i think i am confusing myself here sorry
Okay, there are two types of measurement in rotary encoders. They are amount of linear displacement and amount of rotation. And, these two depends upon the encoding type used. Please refer this link, I don't have much experience in this but I learned this in my class. http://www.ni.com/tutorial/7109/en/
NeX:
it rotates at the same point on the encoder wheel every time so it is the same sequence of numbers coming from the encoder wheel each time the smaller wheel is turned
The same way a single digit rolls over from 9 to 10. The tens columns increments and the ones digit starts all over again. The small wheel is analogous to the tens column
thanks for clarifying guys, i understand now, you are talking about compounding multiple readings.
anyway, i think i have an idea which i have loosely written down, does anyone want to have a look and see if they can spot a flaw?
this is what i was thinking of doing:
have an array with all the numbers in a single rotation. array[481]
on boot up, take the first 3 readings from the encoder wheel and store them in variables:
reading0 = 0000;
reading1 = 1000;
reading2 = 1010;
do a loop starting with 0, and check does reading0 == array[0]
if yes, does array[0] +1 or -1 == reading1?
if no, keep checking the array until array == reading0 again. if array[0] + 1 == reading1, does array[0] + 2 == reading2? if yes, then current position = i, set flag that position is known. then each new reading, check against what we expect from the array, eg does latest reading == array[known position] + or - 1 if the numbers are +, then we are moving to the right, if they are - we are moving to the left. set the flag for direction, if position known flag is false, re run the routine for syncing position. do some clever traps that stops searching outside the array index, and also that the code checks the begining of the array if the current position is at the end of the array etc,
Grumpy_Mike:
OK I took another approach, I noted a number and then how many steps were made before that number was encountered again. I then counted that number. However I have not got too many done. It might be that for any given number the number of steps before a repeat gives some clue to the angle.
The attached excel spread sheet is a start, scroll down to the bottom to see the count. Some one might like to complete it and see if a pattern emerges but so far I can't see one.
What car is it and have you tried looking for the information on this encoder. It is likely it is sitting in a patent somewhere if the encoder is marked with a patent number.
If there is no pattern then how big is the full turn data set? How quickly from any one number (which does get repeated) can the position of that number be determined in terms of steps to left or right? One step and position is known?
full turn data set is 480, 4 bit numbers, i think (just randomly looking over the data set) that orientation can be achieved after 4 or 5 readings, then it has one reading accuracy to stay in sync,
it would have to be 4 or 5 readings in the same direction, but given the resolution of the encoder, that could be a minor twitch in the wheel to get 4 readings
480 / 16 = 30 .... do all possible 4 bit values occur 30 times each?
Anyway, once the controller knows where in the dataset the steering wheel points it should know what to expect next either way the wheel turns.
480 divisions stop to stop. Steering wheel turns through 120 degrees by any chance? Then 4 values is 1 degree.
If the dataset was 120 uint16_t's and you read a random nybble then read more until by the repeating nybbles of the high bits of the uint16_t sequence be able to determine start and end of the current 16-bit word the last read nybble is in.
0x0000
0x1000
0x2000
...
0xFF00
...
etc, alway the low level bits fill first to change 1 high level bit. The upper bits change slower, changes of low bits compared to higher let the pattern be known to the read through 4 bits window. In the dataset it would stick out like a sore thumb.
ok thanks for the reply, maybe it will have to be 4 or 5 readings just to orientate and then it can keep in sync with one reading after that,
That is exactly what I did in reply #15 (for up to six successive readings) and it does not work.
In an attempt to explain a little more clearly: if a1, a2, a3, a4 is a unique sequence of 4 bit numbers, then 16*(16*(16*a1+a2)+a2)+a3 is a unique 16 bit number.
My tests showed that this in not the case for your data, even for sequences as long as six successive readings, a1..a6. I did not go beyond six.
I just noticed that there is something wrong with the data, or at least my assumptions about them.
The first 16 numbers are 0,8,10,14,15,11,9,8,12,14,6,7,3,1,5,4
"2" and "13" do not appear while "8" and "14" appear twice, so you do not get 16 unique numbers in 16 successive encoder positions. That explains why my method did not work.
Please check your wiring and the program that interprets the encoder bits.
jremington:
That is exactly what I did in reply #15 (for up to six successive readings) and it does not work.
In an attempt to explain a little more clearly: if a1, a2, a3, a4 is a unique sequence of 4 bit numbers, then 16*(16*(16*a1+a2)+a2)+a3 is a unique 16 bit number.
My tests showed that this in not the case for your data, even for sequences as long as six successive readings, a1..a6. I did not go beyond six.
This is known used automotive industry raw steering sensor data, supposed to be the full set, not the set of all 65535 other possible sequences.
So you have a set of 480 4-bit values and you start with one with value zero, knowing that there are many others and you have a map of all ACTUAL reads stop to stop. There was a day or more ago a post about the data set not repeating and I have seen none that show any pattern so that indicates it's not an ordered set but does appear random at the 4-bit level. The data sorts itself.
If you list the position of every 4-bit read = 0000 and the next 10 4-bit reads just to see how many match how far.
Wotchasay Grumpy Mike? I should get the data? Izzit Ubuntu-app friendly?
