Maker Pro
Maker Pro

Can't identify a gray code

I'm using an Omron E6CP-A Rotary encoder which has a gray code that looks like this. Anyone know what the algorithm for it is?

0
1
5
4
6
7
23
22
20
21
..... and so on
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
looks odd that there are only 6 values that use 3 bits. What value precedes 0 (and what is the value prior to that)?

According to the datasheet I found, it's a standard grey code that goes: 0, 1, 3, 2, 6, 7, 5, 4, 12, ...)

Is it possible you have the outputs in the wrong order?
 
I confirmed, and verified, all 256 values of the 8-bit output the hardway (using a data logger through a complete rotation). The first 10 values are as listed. If you search this sequence on the internet it crops up in the odd gray-code-related conversation, but no where does anyone say what the algorithm is.

My first suspicion was that I'd connected the sensor up the wrong way, but the colours are correct as defined by the data sheet and, further, a detailed Excel analysis of this sequence to a standard gray code sequence (eg 0, 1, 3, 2 etc) shows that it's not possible to make them the same just by swapping the bits around to undo a possible misconnection.

I fell a little bit more confident that I'm not being a dufus as one of my colleagues used the same rotary encoder in one of his projects and ended up creating a truth table by hand because he couldn't work it out either - and he is a good electronic engineer.

So the mystery continues......

What get's me is that the Omron data sheet doesn't mention it at all - pretty crappy for a $250 sensor!
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
send me the complete sequence ant I'll try to work out an algorithm for you.

But a lookup table may be just as good :)
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
For others that may be interested, the sequence is:


0
1
5
4
6
7
23
22
20
21
17
16
18
19
27
26
24
25
29
28
30
31
95
94
92
93
89
88
90
91
83
82
80
81
85
84
86
87
71
70
68
69
65
64
66
67
75
74
72
73
77
76
78
79
111
110
108
109
105
104
106
107
99
98
96
97
101
100
102
103
119
118
116
117
113
112
114
115
123
122
120
121
125
124
126
127
255
254
252
253
249
248
250
251
243
242
240
241
245
244
246
247
231
230
228
229
225
224
226
227
235
234
232
233
237
236
238
239
207
206
204
205
201
200
202
203
195
194
192
193
197
196
198
199
215
214
212
213
209
208
210
211
219
218
216
217
221
220
222
223
159
158
156
157
153
152
154
155
147
146
144
145
149
148
150
151
135
134
132
133
129
128
130
131
139
138
136
137
141
140
142
143
175
174
172
173
169
168
170
171
163
162
160
161
165
164
166
167
183
182
180
181
177
176
178
179
187
186
184
185
189
188
190
191
63
62
60
61
57
56
58
59
51
50
48
49
53
52
54
55
39
38
36
37
33
32
34
35
43
42
40
41
45
44
46
47
15
14
12
13
9
8
10
11
3
2
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
The answer is almost trivial (well, not really)

Firstly, the order of the bits does not give a correct grey code sequence. In order to get that, you need to take them in this order:

bit 6 (inverted)
bit 7 (inverted)
bit 5
bit 4 (inverted)
bit 3 (inverted)
bit 2 (inverted)
bit 1 (inverted)
bit 0 (inverted)

Your first number (0 -> 00000000b) becomes 11011111b

Converting that using the standard conversion of Grey code to binary you get 10010101b (or 149)

The next number (1 -> 00000001b) gets translated to 148.

the sequence continues to decrement to 0 when it wraps around to 255.

Some simple maths can reverse the order and remove the offset if you require that.

If you arrange the bits in the right order, the inversion of the appropriate bits can be done easily in a uC and the conversion from grey to binary should be smaller than a lookup table -- although a lookup table would be faster.
 

(*steve*)

¡sǝpodᴉʇuɐ ǝɥʇ ɹɐǝɥd
Moderator
Just had to put it next to a normal grey code and play "spot the difference".

Sesame Street stuff really :D (once you know what you're looking for)

I guess it's a bit like paying an engineer $2000 to git something with a hammer -- $1 for hitting it with a hammer, $1999 for knowing *where* to hit it.
 
Just had to put it next to a normal grey code and play "spot the difference".

Sesame Street stuff really :D (once you know what you're looking for)

I guess it's a bit like paying an engineer $2000 to git something with a hammer -- $1 for hitting it with a hammer, $1999 for knowing *where* to hit it.

I charge $211.45 excl GST for each hammer hit otherwise I'd never make any money
 
Top