Thank you. I am slow on the uptake and will ask questions that seem obvious to anyone but me.
How did you arrive at the exact 1000 resolution number? Why not 100 or 10000?
Complete the conversion or complete the measurement acquisition of the signal? I mean the end point in time where the signal hits the wire, because that’s what’s important in the timing diagram, then you can take your time converting ADC and storing in the register, because the signal itself is already stored in the silicon and even though the outside signal had moved on, we can still keep processing the original signal which is “frozen in time” in a sampling “time capsule” by the silicon.
To me it seems you need to “acquire” the signal withing the 50ns, not “acquire/process/store” the result. Which relaxes the timing requirement as sample storage is nearly instantaneous and timing is negligible. So at 10MHz generic 32-bit MCU (like STM32) ADC Clock (which has nothing to do with the MCU clock speed itself which could be 100MHz or 200MHz for what we know), assuming sampling time of about one cycle (or 100ns) and conversion time of say 11 cycles, or 1100ns =~ 1us, the entire end to end until you “see” the value in the register cannot be under 1us, however, the acquisition time is only 100ns. Actually the real STM32 ADC processing time is 1.3us according to silicon specs, and sampling acquisition time is 80ns. So now you see why I am asking about the 1000 resolution number, the 50ns are extremely low as far as hitting the middle of the pulse, however, the MCU could produce a pulse with 10ns resolution, depending on the frequency and PWM resolution. So hitting the middle of a 10ns pulse with an 80ns sampling time will produce an incorrect sampling charge signal in the silicon when the MCU integrates the value for the subsequent ADC processing.
In other words, while theoretically the current sensing is straightforward on paper, the code and hardware implementation and actual motor and code setup decisions make the end combination so uncertain in my head when I construct my use case.
I am not sure I follow this, because I could hit an “off” period if I arbitrarily sample at any time period quite consistently. I need to trigger the sampling at the very beginning of the rising edge, high or low, and make sure sampling time is lined up with the actual current rising edge, and the sampling width is at least the duration of the MCU sampling cycle, which in our example is 80ns. So my timing must account for the delay in driver and gate, else I may hit the dead time at the beginning if I trigger on the PWM rising edge. Even if I interrupt at the middle of the PWM, at short pulses when a coil is at minimum I will miss the measurement window.
Which also leads to my first question, at what point the response time of the current sensors and opamps become so off that they are no longer applicable in this use case, since they introduce extra delay in the measurement, since you don’t measure the current directly, but using an intermediary.
Now you see my confusion.
If you could clarify, or may be point some obvious gaps in my reasoning, which are not obvious to me, it would be great.
Thanks!
Valentine
Edit: One very important point, the case is when the motor inductance does not “smooth out” the current. In case where the entire system is so well designed (PWM->driver->transistor->coils) that the motor behaves perfectly, I am in full agreement that the inline current sense timing could be done at any point of the PWM control signal as the resulting current profile is just a “gentle wave” and the offset error is minimal, then even a really cheap current sensor would suffice given it smooths out the transient spikes which could be done with a simple filter. Of course since SimpleFOC is aiming at a very generic approach and we combine random MCU with drivers and motors and sensing hardware I feel a much more rigorous approach to the inline current sensing timing is required.