Per @Zhouzhou377 suggestion:
The FPGA can easily compute the omega from the encoder to much higher resolution than the C code can since it can count FPGA clock cycles between encoder line edges. Therefore, we should extend the encoder FPGA IP block to also keep track of ticks between edges. Then, the C code can use this to compute omega
This will be an average omega across the encoder pulses, but will be much higher resolution.
For example, consider a 1024 line encoder. @Zhouzhou377 is running her control code at Fs = 10kHz. She is only getting delta_theta values of either 0 or 0.00613. This is due to the encoder quantization interacting with the fast control period. This makes it very hard to infer omega. If she could ask the FPGA how many clock cycles elapsed between encoder edges, that would be much higher resolution.
Per @Zhouzhou377 suggestion:
The FPGA can easily compute the omega from the encoder to much higher resolution than the C code can since it can count FPGA clock cycles between encoder line edges. Therefore, we should extend the encoder FPGA IP block to also keep track of ticks between edges. Then, the C code can use this to compute omega
This will be an average omega across the encoder pulses, but will be much higher resolution.
For example, consider a 1024 line encoder. @Zhouzhou377 is running her control code at Fs = 10kHz. She is only getting
delta_thetavalues of either 0 or 0.00613. This is due to the encoder quantization interacting with the fast control period. This makes it very hard to infer omega. If she could ask the FPGA how many clock cycles elapsed between encoder edges, that would be much higher resolution.