jremington:
It does look like a Gray code, but the bit order is different than the example shown in post #15.If all allowed 1024 bit patterns show up, then it must be possible to remap the bits to follow the pattern shown in post #15. Just swap the wires around.
Thanks Jremington! I'll try to use a microstepper or something to move the shaft around to get the full map. Much appreciated.
Note that there are a number of different types of Gray codes. Perhaps if you look through the linked article, you will recognize yours.
On the other hand, if it is a "single track Gray code", common with rotary encoders, then not all 1024 positions will appear. In that case just use a lookup table to convert to standard binary.
jremington:
Note that there are a number of different types of Gray codes. Perhaps if you look through that article, you will recognize yours.
Very greatly appreciate Jremington. I will take a look at that article to see if I can use those details to get a match on my patterns, or generate a matching pattern. That would help heaps.
I'll see where that leads me. At the very least, I can see if I can get a map automatically..... and then run some kind of check, like a bitwise XOR bit difference check to see adjacent patterns change by 1 bit at a time. Or just run a scan to see if every pattern is unique.
Thanks again!
Just going to attach my measured TRD-NA1024NW bit pattern outputs here as well, in case somebody notices that their encoder doesn't have the typical 'gray code' pattern. The patterns I measured for my two encoders are identical. Not typical gray code, but at at least unique (1024 patterns), and they change by 1 bit at a time (ie...a gray code...but not the general pattern).
bit_patterns_TRD-NA1024NW.txt (12 KB)
Interesting! I couldn't see how to swap wires to convert those codes into reflected binary Gray codes, but I've attached some C code a start if you want to play with it. (Too long to post using code tags).
You can of course use the data table as a lookup for conversion.
main.c (15.2 KB)
jremington:
Interesting! I couldn't see how to swap wires to convert those codes into reflected binary Gray codes, but I've attached some C code a start if you want to play with it. (Too long to post using code tags).You can of course use the data table as a lookup for conversion.
Hi Jremington! Apologies - I didn't know that you replied to my post. I'll download your c-code. That will come in really handy. Thanks for that! Greatly appreciated.
Since that time I posted that text file containing the 'unorthodox' gray code pattern on both of my TRD-NA1024NW rotary encoders, I ended up thinking that it was weird that both of those encoder units (which came pre-connected with 12 pin connectors) would have such unorthodox set of bit patterns.
At first, I figured that mapping the pattern would immediately allow me to very quickly (with relatively minimal delay) use arduino coding to map the bit pattern back to a standard 0, 1, 2, 3, 4, 5, 6 etc binary bit pattern (from which I would quickly compute/obtain the corresponding encoder angle). However, I then figured that getting the arduino software to do a lookup could mean significant delay ...... I guess it depends on application or how quickly we need the angle values.
So, in the end, I decided to just use a truth table (case statement) FPGA method to do the conversion from unorthodox gray-code to typical binary pattern. The arduino has been able to read the decoded binary patterns from the FPGA board really well.
The FPGA board outputs 3.3V logic, and I decided to just skip the conversion to 5V logic... so the arduino is just reading 3.3V logic...... no issues. But I think I'll do things properly later, and use recommended (5V) logic levels.
Still can't understand why my encoders have that unorthodox pattern. I even tried to manipulate the columns to try figure out whether or not swapping appropriate columns would lead to the 'usual' gray code. But interchanging columns didn't help.
Hi,
Good to hear of your success and a bit of lateral thinking to get your code.
Your encoders must be made for a OEM project somewhere in space and time.
Thanks for replying... Tom.. 
TomGeorge:
Hi,
Good to hear of your success and a bit of lateral thinking to get your code.Your encoders must be made for a OEM project somewhere in space and time.
Thanks for replying... Tom..
Hi Tom! Thanks for your response as well, and kind words. Your mention of OEM project certainly makes sense. I didn't think of that before. I think you're right about that.
I still believe that one can swap the bits in some clever and trivial way, thereby interconverting the two codes, but have no particular motivation to do so.
jremington:
I still believe that one can swap the bits in some clever and trivial way, thereby interconverting the two codes, but have no particular motivation to do so.
I think so! Time plus motivation needed hehe.
