Rotary Encoder Increment - GPIO Digital In too slow?

#1

Hello everyone!

I'm working on a project where we use this kind of rotary encoder connected to the axoloti:

The sensor has a Z pin that sends a pulse for every rotation. We use this pulse to trigger a musical note in axoloti. The value of the Z pin is captures using GPIO PA0 through the gpio/in/digital object.

This system works well when the rotation is relatively slow (0-5 Hz). But if the rotation gets faster (5+ Hz) , it seems that gpio/in/digital doesn't always catch the pulses. It randomly catches one in four pulses. My guess is that the pulses get too short for the k-rate. Am I wrong in thinking this?

Would any of you know how to make sure my axoloti patch catches the Z pulses up to 25 Hz or so? In another environment, I would add an interrupt function after the Z changes value, just to be sure it gets caught. Can I do this in axoloti?

Thank you for your help!

Best,
Dominic

#2

This encoder is very different to the ones I have mentioned in posts.
But looking at the specs, it says its maximum is 6000 rpm with 1024 pulses per rotation, I guess if I am doing this right, that comes out at about 102400 pulses per second.
But when you read the comments on the Item below, one comment is made about having to use an FPGA at much higher speeds than a normal Arduino etc to read 4 encoders at 50rpm.
Not sure if this is the problem though...
One thing you could try is the order of the objects in the patch, this can have interesting impacts, also do you have other rotary encoder types to test and see if the same thing happens ? :grin:

#3

Hi Gavin,

thanks for your help. Yes, the encoder also has A & B pins that spit out 1024 pulses per rotation. We use that to control LED strips with a Teensy board (it does wonderfully). For the music, we intended to only use the Z pin, which spits out a single pulse per rotation. Much easier to deal with....

It just seemed odd to me that past 5-10Hz, the axoloti couldn't catch those pulses. I tested and experienced the same problem on 2 rotary encoders of the same model. So I doubt it's a problem with the sensor.

I was hoping to maybe find a way of bettering the rate of the gpio digital in. Or, could I use the dc-coupled audio in on the axoloti and therefore sample the sensor at s-rate?

best,

Dom

#4

catching signals like this is tricky from such a high level programming environment. You can try to install your own interrupt for something like this, but it requires some serious hacking and a deeper understanding of the firmware source code to get it done. Though I can definitely see a wider use for a "high speed trigger catch" object.

#5

Are you able to set it up so the encoder can send a signal to an external scope as well as the scope in a patch, that way you could compare the differences ?
Or maybe instead of running the encoder at a certain speed, use it to set the speed and tell an LFO what speed to run at ?
I am sure there is a solution, maybe not in the way you originally intended ..:grin:

#6

Nice encoder!

That is odd indeed, gpio/in/digital reads them at 3000Hz. If you have access to a "real" oscilloscope, please verify the encoder output waveform. Maybe it needs a pullup resistor or something?

GPIO interrupts are not exposed in Axoloti. It could be done but not in an elegant way (far from...).
A more elegant way than using interrupts is programming a hardware timer, there is a mode to deal specifically with incremental encoders, refer to chapter "18.3.12 Encoder interface mode" in the "RM0090" STM32F427 reference manual. That should be able to handle 100000 pulses/s and maintain a position counter that does not skip a single step, without causing an interrupt storm.