The above sensors are read via SPI and they have an internal delay between measurement and SPI response (100µs see datasheet). So for higher speed this must be taken into account, but I looked into the sources and did not find any kind of compensation.
Is this an issue?
If you read carefully the sensor documentation, the sensor algorithm is predictive. the result you receive is already adjusted by the silicon. you can program the sensor to turn the prediction on or off depending on your use case because at low rpm the predictive algo will make the systemic error larger than expected by emf interferance and thermal\quantun noise in the silicon. thats why these sensors cost $10. you pay for a tiny mcu inside the sensor with hardwired code.
What about the SPI transfer itself? Clock speed is 1MHz, and a measurement is 2*16 Bits. If rpm is about 12K rpm, you get 5 ms per revolution, and a measurement time of 32µs.
There is SPI and SPI with DMA (Direct Memory Acces) + FIFO. Unfortunately I think DMA is somewhat MCU specific and need setup by writing to the registers. DMA let’s the SPI transfer exist outside the main loop.
Here is a writeup explaining SPI and DMA. SPI+DMA Tutorial
you are confusing sampling rate with spi propagation rate. sampling rate is in the nanoseconds. the read signal is already daec adjusted. i believe we are reaching a point where i used to tell my students trust me it works.
What I mean is, that the SPI transfer itself consumes some time, the time to transport the 16 address bits MOSI and the 16 data bits MISO. So, this is a imanent latency due to the SPI transfer. If the SPI-Clock is 1MHz this latency is 32µs just for the bit-transport from the AS5047 to the µC. At first here it does not matter, how the µC itsef transfers these 4 bytes further. But yes, this also adds time.
So the question is, if this latency does harm the computation of the electrical angle? Or did you find that this is neglectable up to say 10k rpm or so?
Actually the SPI read time for this sensor is 100us, not 32us. However the SPI refresh rate is 200ns, and when you request the data the SPI will serve you the predicted data 100us in the future so by the time you complete the SPI read you will have the position where the angle should be. It is true, for example, the AS5047P can detect 28000RPM which is about 466rps, and by the time you finish reading at 1MHz the rotor had already turned over couple degrees but you don’t care because the read data is already predicted +few degrees. Since the rotor angular inertia is >> than the delta read time the prediction is pretty good unless you shoot the motor with a bullet and stop it (and i mean this literally because at 28000 rpm the angular velocity of a small motor is about 50m/s) because this is the only condition you can exceed the nyquist sampling frequency of the four hall sensors. The AS5047P sampling frequency is 2250,000,000 sps, or 2250 Msps, which is vastly higher than the 466 rps (of the fastest 28000RPM motor). You are reading with 1MHz speed, which is 10,000 reads per second and will give you about 20 reads per rotation. You can do a lot better if you read at 10MHz which will give you 200 reads per rotation but I don’t know if the sensor supports 10MHz, perhaps someone on this board can speak for that.
So, you are rest assured at the maximum RPM the sensor will serve 20 times per rotation the predicted positional bits at the end of the read. Unless you are Wyatt Earp .
Thanks.
I overlooked the value of t_delay_daec which is 1,5…1,9µs.
Because the SPI-clock is externally provided to the sensor, the SPI-transfertime adds to this.