RS422 encoder on Raspberry Pi

[niekb]

Hi all,

I was hoping if you could help me with the following.

I would like to use a Gurley RS119 quadrature incremental encoder and connect it to Raspberry Pi. The data sheet for this encoder can be found here:
http://www.gpi-encoders.com/PDF/R119.pdf.

So have two questions, hardware and software related (I hope they are clear enough).

This encoder uses an RS422 interface to output the signals (channel A, B, /A, /B, N, /N).
My hardware-related question is: would using a RS422 to USB adapter work to get the encoder channels to the Pi? I found this one from FDTI:
http://www.ftdichip.com/Products/Cables/USBRS422.htm
I noticed that on the forum, it is also possible to connect RS422 to the pins directly, right? What would you advise?

Software question:
How can I read the A and B and /A and /B channels from the encoder via USB and translate that to the encoder angle? I am not a code-expert (i.e. new to the scene), so I would like to use py-gaugette for getting the encoder angle. Is this possible?

Any help would be greatly appreciated.

Thanks!

Niek

[joan]

Do you still plan to do up to two rotations per second? If so I'd rate the chances of py-gaugette working as zero unless you can cut down the resolution. I scanned the pdf. Does it allow you to do an effective divide by 16 internal to the device?

[niekb]

No, I am aiming for less than that - maybe half a rotation per second (max).

Am I even being realistic? I am new to this, and I am trying to learn as much as I can. How difficult would it be to get this working?

I am not sure what you mean with an effective divide by 16 (I don't think so by the way)? The problem is that I need the high resolution.

Thanks!

[FLYFISH TECHNOLOGIES]

Hi Niek,

This encoder uses an RS422 interface to output the signals (channel A, B, /A, /B, N, /N).

This encoder uses just electrical levels which are RS422-compliant. This fact doesn't mean that this encoder is RS422 serial (UART) device, because it is not... If it would be, then the datasheet would list also communication parameters like supported speed (9600, 19200,... baud) format (8N0, 7E1, ...)., etc.

would using a RS422 to USB adapter work to get the encoder channels to the Pi?

No.

I noticed that on the forum, it is also possible to connect RS422 to the pins directly, right?

Wrong. Voltage converter is required.

What would you advise?

Depends on maximum rotation speed.
This rotator outputs ticks related to rotation speed and direction. You have to interpret these ticks "manually".

Maybe dedicated chips exist, but I don't know of any.
Similar principle of these ticks pattern use old computer mouses, the ones with a ball. So this might be the direction to search a bit... Maybe this kind USB mouse could be re-used here... It sounds silly, but this is not impossible. The electrical level would need to be aligned, but if your rotation speed is low enough, this might even be feasible.

How can I read the A and B and /A and /B channels from the encoder via USB

With a dedicated chip. A custom-programmed microcontroller might also perfectly fit here.
RasPi GPIO port (with proper electrical conversion) might also be the answer (if USB is not a must).
But the crucial question is max rotation speed....

and translate that to the encoder angle?

Relative angles data is available by interpretting the pattern of received signal (you count ticks number and check at each signal transition the pattern - to find out the direction).
Additionally, you have Index signal available to (re)align relative position with a known position.

so I would like to use py-gaugette for getting the encoder angle. Is this possible?

Sorry, I don't know much about this code...


Best wishes, Ivan Zilic.

[joan]

Half a rotation a second should be OK.

I'd just connect A, B, GND, and +5V. A and B to gpios through a voltage divider preferably (to convert the 5V to Pi tolerant 3V3) and see if it works.

[niekb]

Thanks for your posts, Ivan and Joan, I understand everything a bit better now.

So using the GPIOs and proper 5V to 3V3 conversion and reading out channels A and B might do the trick.

Indeed, the max rotational speed is crucial (half a rotation per second max), and with the high resolution, I guess it is easy to miss a couple of ticks, leading to false data.
So, what do you think of the following: instead of using an incremental encoder, I could also use an absolute encoder, and use the SPI interface instead. Would this be easier (relatively, heavier on the 'software side')?

Thanks

[FLYFISH TECHNOLOGIES]

Hi,

I could also use an absolute encoder, and use the SPI interface instead. Would this be easier (relatively, heavier on the 'software side')?

If you have a related datasheet link, feel free to post it and I can verify my statements... but I believe that with the absolute SPI encoder everything would be much easier.
First of all, on the software side, the SPI communication is supported well, with many communication code examples available.
You also don't need to count ticks all the time, the position data can be read just when needed, so the processor load is lower. You could also "trust" that your data is correct all the time, since ticks loss case is not applicable here.

Furthermore, if this encoder is 3.3V, then you can connect its SPI bus to RasPi GPIO port directly, without any additional hardware required. But even if the encoder is 5V, just some "dumb" elements are needed for voltage conversion (converters are widely available).

Well, I cannot find any disadvantage of this option... The only one I can think of right now could be if the distance between the encoder and RasPi is significant (measured in meters), especially in "noisy" environment.


Best wishes, Ivan Zilic.

[joan]

Hi,

I could also use an absolute encoder, and use the SPI interface instead. Would this be easier (relatively, heavier on the 'software side')?

If you have a related datasheet link, feel free to post it and I can verify my statements... but I believe that with the absolute SPI encoder everything would be much easier.
...

The disadvantage appears to be the resolution seems to be much less (say 4096 steps rather than 64K). I did a quick web-search and they don't seem to be immune from reading problems.

[niekb]

I found a 14bit absolute encoder with a native SPI or/and I2C interface:

http://www.ams.com/eng/Magnetic-Encoders/AS5048

One disadvantage of this type of encoder is that it is the chip only, so I need to make a housing for it.
Other absolute encoders are available as well, but they have interfaces such as SSI (this one for instance:
http://www.gpi-encoders.com/PDF/R119.pdf).
I read that it might be possible to connect SSI devices using the SPI interface (it seems some people did this using an Arduino)

Thanks for your help!