Quadrature decoder

[RogerH]

Hi All,

A number of my projects require the decoding of a quadrature position sensor.

As a total newb to the XMOS world can anybody suggest to me a way of implementing this on XMOS chips. I have implemented this on Atmel ATmega chips using interupts triggered by the level change on one of the two phases.

From my reading to date it appears that this would implemented on XMOS by having a thread waiting on the transition of a phase input then examine the other phase relationship. There may be a much better way of doing this?

I would welcome suggestions on this. Please note that I do not have XMOS hardware at this stage so would need to simulate any suggested code...any thoughts on how I would simulate the two input phases?

Cheers, Roger...

[Andy]

Hi,

From my reading to date it appears that this would implemented on XMOS by having a thread waiting on the transition of a phase input then examine the other phase relationship. There may be a much better way of doing this?

I don't know a great deal about implementing Quadrature decoders but his sounds like a very reasonable approach. You can implement your decoding process as a thread on the XCore waiting for an event, such as data from I/O or another thread. The big benefit is that you don't need an interrupt routine because it is running in parallel with other threads of execution. Have a look at the select{} statement to start...

If your core decoder routine is written in C, you should be able to port it quite easily and call it from XC.

Please note that I do not have XMOS hardware at this stage so would need to simulate any suggested code...any thoughts on how I would simulate the two input phases?

You can simulate your input phases on another thread and 'loopback' the output to the input of your decoder thread. There's a mechanism in the simulator to allow you to do this.

[bsmithyman]

I'm fairly sure there's an example of doing this in one of the university projects (the one with the orange tracked robot). The Traxster kit they used comes with motors with integrated encoders. This is also something I've thought about doing, and the nice thing is that it should be very easy with XMOS (no need for things like interrupts).

After a while searching, I also came across this, though I'm not on a system where I can easily check it at the moment.

[RogerH]

Hi Andy,

Many thanks for the reply.

Hi,
[I don't know a great deal about implementing Quadrature decoders but his sounds like a very reasonable approach. You can implement your decoding process as a thread on the XCore waiting for an event, such as data from I/O or another thread. The big benefit is that you don't need an interrupt routine because it is running in parallel with other threads of execution. Have a look at the select{} statement to start...
/quote]

I will indeed take a look athe select statement. I have only just started wading through the XC documentation so it's still all very new.

You can simulate your input phases on another thread and 'loopback' the output to the input of your decoder thread. There's a mechanism in the simulator to allow you to do this.

Excellent! That will be very usefull in simulating all sorts of inputs. I must read more on the simulator. I have had a small play with it but got a bit confused so I must RTFM.

Regards, Roger...

[RogerH]

Hi bsmithyman,

Thanks also for your reply.

I'm fairly sure there's an example of doing this in one of the university projects (the one with the orange tracked robot). The Traxster kit they used comes with motors with integrated encoders. This is also something I've thought about doing, and the nice thing is that it should be very easy with XMOS (no need for things like interrupts).

After a while searching, I also came across this, though I'm not on a system where I can easily check it at the moment.

Great link...Exactly what I was looking for. I am very new to XMOS so I am still discovering the resources available on the various sites. I have grabbed the source code and it compiles okay. Now I just need to create a thread to toggle the inputs and setup the loopback in the simulator as in Andy's message above.

Many thanks and regards, Roger...

[bearcat]

I just finished code for an low cost encoder (not in XC though). I am using a mechanical encoder so much switch noise. I found using a state machine was the approach that works. Using a low pass filter on the inputs then decoding did not.

I would assume with a motor you have an optical encoder. If you have an optical encoder, then I would still look at using state logic for noise protection. If your encoder is an incremental and has a marker pulse, then you may want to use that also. I have implemented simple decoding of a high quality encoder in the past with success, though.

Using a select and pinsneq statement on each encoder phase might save XMOS cycles. Encoder speed is something to look at.

[RogerH]

Hi Bearcat,

Yes, I am using an optical encoder attached to the motor. The motor will be PWM controlled and should not exceed 500 RPM so I think that a single thread on a core should be able to handle this. I will do some calculations before I go too much further with the XMOS device.

Thanks for the pointer on using a state machine for noise immunity.

Regards, Roger...

[bsmithyman]

Hi Bearcat,

Yes, I am using an optical encoder attached to the motor. The motor will be PWM controlled and should not exceed 500 RPM so I think that a single thread on a core should be able to handle this. I will do some calculations before I go too much further with the XMOS device.

Thanks for the pointer on using a state machine for noise immunity.

Regards, Roger...

It'll depend on the motor and the geartrain, where the encoder attaches, etc. but it seems like 500 RPM shouldn't be a big issue. I've got some motors with 30:1 gearboxes on them, rated at 200 RPM, which accept encoders on the motor shaft at 400 quadrature transitions per revolution. That works out to 40 kHz per motor, but that still leaves room for ~625 instructions per transition on a 50 MHz thread.

[RogerH]

[quote="bsmithymanIt'll depend on the motor and the geartrain, where the encoder attaches, etc. but it seems like 500 RPM shouldn't be a big issue. I've got some motors with 30:1 gearboxes on them, rated at 200 RPM, which accept encoders on the motor shaft at 400 quadrature transitions per revolution. That works out to 40 kHz per motor, but that still leaves room for ~625 instructions per transition on a 50 MHz thread.[/quote]

Yes, I had not got to specific re motor and encoder as I am looking at various projects with this and will need to do the math to suit each project.

I am looking at using the G4 and would likely be able to run just two instances on each core giving a bit more cycles to play with.

Many thanks for the help,

Roger...