ok, my mistake, these are using magnetic sensors rather than resistive pots. These may be affected by stray magnetic fields (I don’t know how sensitive they are)
but how long does it take you do do the A/D conversion and then doing the math compared to counting pulses like you do with an ABZ encoder.
I do know from people who have used the magnetic rotation sensors that they are frequently not as linear as you would think. You ask if the anti-cogging code could be modified to correct for this error, but the first issue you have to answer is what you are correcting against? the current anti-cogging code compares the position reported by the encoder with the expected position based on the drive power phases, what do you compare the sin/cos encoder against to correct it?
All the magnetic encoders do lots of processing on the chip: analog signal conditioning, ADC, angle computation (arctan), error compensation, AGC etc. For reference see the processing flow graph on page 8 of A1335 datasheet: https://www.allegromicro.com/-/media/Files/Datasheets/A1335-Datasheet.ashx
The ADC delay is only a small part of the overall delay. If money is no object you can spend $50 on a 16bit 100Msps ADC chip and the delay will be less than a few ns. In contrast the A1335 chip mentioned above at $2.00 price point has a response time of 60us. The popular AS5048A at $9.00 has response time around 100us.
The limitation of the low cost magnetic encoder chips is processing power. Most of them have very small die size to work with. I am speculating that by taking the signal in sin/cos format and moving the processing to STM32F4 on ODrive board we can get better faster response and better accuracy.
That 30ns in the datasheet is rise/fall time of the CMOS output, not the delay from taking sample to output. They put that number in the datasheet to specify their CMOS output characteristics. It has nothing to do with the delay. For example another product AMT11 (https://www.cuidevices.com/product/resource/amt11.pdf) has two different types of outputs and has two different rise/fall time in the datasheet. The rise/fall time for AMT11 is better because a line driver is used internally to boost the output to RS422 specs. Its delay might actually be slightly worse than AMT10 due to the additional line driver used.
Using their max rpm specs you can see their max sampling rate is around 266Ksps, which gives sampling period of 3-4us. Their delay is likely to be 8-10us since most of the encoders take at least 2 samples to compute an average before sending the output. 10us response time is still a very good number compared to others.
Hello everyone! Just for info - i use old soviet resolver - БСКТ-1065 трансформатор >> 2 шт от производителя недорого купить . As a driver i use AS2S1210. It works great. I tried magnetic encoder and cheap optical one. After a lot of tests i chose resolver, less errors and less problems. Resolver gives me 4096*5(5 pole pairs) = 20480 cpr. Additionally it is cheap and easy to mount.
Nice I used resolvers a lot in a previous job.
A resolver is not the same as a sin/cos encoder - What most people call a sin/cos encoder is simply an incremental optical encoder with analog quadrature outputs instead of digital (usually a direct output from the photodetector), which improves its resolution, but it does not give an absolute readout that is useful for commutation.
A resolver is a kind of 2-phase rotary transformer which needs an AC excitation signal, and the two outputs’ amplitude varies as a function of sin and cos of the rotor angle.
It is absolute to within one turn, so it is great for PMSM motors.
Did you write a driver for AS2S1210 for ODrive? It would be great if you could share it.
I spent a lot of time for creating evaluation board and writing some kind of software. But after all the tortures i realised that AD2S1210 don’t need any tuning or special config. It gives us perfect ABI signal “from the box”(“I” appears a lot of time during one rotation). So, i can recommend to read only datasheet for AD2S1210, there are a few pins need to be set.
Ah ok. The multiple index is a common EM noise problem with ODrive - you can solve it by using ferrite rings on the motor wires and/or adding 1-10k resistance to GND and 22nF capacitance to GND on the index pin
However, it would still be better if there were a way to use the SPI interface of that chip, because it avoids the need for the index search.
If the motor had a heavy load that cannot be easily detached, it might not be able to move for the index search.
Hi,Can your DJI motor drive effectively? I have the same motor. The motor is 7 pairs of poles. How to match the cycle of this encoder? The encoder is linear Hall and the output waveform is sincos waveform; Can you share how you set or adjust it?
I used resolvers a lot in a previous job.
hmm, all the ones I’ve seen were absolute magnetic encoders with sin/cos single-turn output. But either way, still not a resolver 