Hi, im creating this thread for the MT6835, since there are folks working on support for it, and because its awesome (not yet tested).
For folk who dont know it. It is the latest Magnetic Angle Sensor from MagnTek. It features a really interesting auto-calibration routine, which should help increase performance. This basic calibration routine works by mowing the motor/shaft in open-loop at a set speed, whereby the calibration is started until done.
Anyways, I’m wondering where the Z point is (cero point in ABZ encoder config.) if not set by the MCU. Will it just be some random place and if so, what does it matter if it is in a random place?
I’m thinking a XY machine use case here, like a PNP machine, where one will home the machine every time it start a job. In that case, if the sensor is mounted and calibrated (as part of the installation on the machine). Is SPI then actually needed if the ABZ interface is working properly ?
Edit: If needing to customize the ABZ resolution, then naturally the SPI interface is needed. So maybe while calibrating it would be nice to have SPI available, but other then that, should ABZ work independently?
Lets say the ABZ is pre-configured to a resolution when buying the sensor (the vendor programs the ABZ resolution).
Its quite small, but actually significantly larger then other TVS diodes in the same range (3.3V working voltage - clamping voltage below 6V). Usually those are 0402 parts, like 0.6mm long, which is pretty hart to place by hand. Above footprint is 1.05mm long.
If you know any other TVS diode, with the same specs, but a bit larger eg. 0603 package, plz advice.
I think you got the answer already, but you can manually write the zero position. So you can do calibration, then move to endstop and write register over SPI to align the mechanical system and software.
The MT6835 looks like a hot candidate to solve my AS5147 noise and precision problem which seems to make closed angle loop with steppers impossible. I see that the chip even has an internal calibration LUT! For calibration LUT I currently need a STM32L432KC with 64K RAM.
Is there a MT6835 breakout board available which fits on a NEMA17 mounting holes?
Would you share the design files, including the magnet holder? By the way, which magnet are you using? specs recommend 10mmx2.5mm. I only find that on Aliexpress again like the sensor board itself (which I ordered already).
here my first results with MT6835 (courtesy @runger !) on NEMA17 stepper with a 6mm magnet.
First graph shows the error table of calibration.cpp. The error range is within the specs for factory calibration, which say ±0.5 degrees.
Velocity mode in closed loop is working fine. Next step is to try the chip’s user calibration which should bring down the error to ±0.07 degrees.
The ultimate step of using the chip’s internal LUT for NLC - Non-Linearity Compensation Calibration - is out of reach for me currently as that would need a 21bit high precision optical encoder.
and here are the results of the chip’s user calibration method (pull pin Calibration Enable to Vdd and rotate 64 times - check PWM output pin duty cycle for success).
For clarity: I abuse the SimpleFOC calibration routine to get a sensor angle deviation from the ideal line, as I don’t have an external 21bit reference.
First the CalibratedSensor.cpp error array before moving average filter:
And indeed you see that the chip’s calibration feature really reduces the error a lot - compare to my last post. And that means that you could live without the software sensor calibration and have a good average accuracy. And you don’t need MCUs with >=64kB RAM.
Now comes the master question: For velocity mode the accuracy of the MT6835 seems good enough on a stepper motor - limiting factor is more the PWM resolution now. You can address that with high resolution timers (GHz clock!!) on bigger STM32 MCUs like STM32G474.
But how about high precision angle mode? What you really get from the sensor/motor combination is what you see on my first plot - the signal is jumping around ±0.2degrees in a small angle interval.
I am unsure if using a filter really helps here - we talk about low RPM converging to zero when the motor approaches the target angle.
Any thoughts about that?
MA702 is also a good sensor, and these things are not so easy to compare. MA702 gives its max RPM at 60000, and has a filter function with 1000Hz cutoff. MT6835 gives its max RPM at 120000, and has configurable bandwidth (though the datasheet doesn’t say exactly what it is).
So maybe the additional bits of the MT6835 give it some extra headroom to handle higher speeds while still giving you meaningful results.
Either sensor will benefit from linearity calibration, but the MT6835 has it built-in while for the MA702 you’d have to add it afterwards in software…
MT6835 has many options and functions, really. On the other hand its SPI protocol needs 24bit exchanges - while MA702 runs with 16bits - so you can read it 33% faster.
There are lots of details to consider when picking a sensor, and unfortunately they have not yet made the perfect one
@husky thank you so much for your detailed and precise description, that is really cool!
Thanks runger, I was hoping for a higher resolution to achieve better position accuracy (as the best I could get with the MA702 is 0.3 degrees, the MA732 is unusable due to high latency). I don’t need the 120KRPM (this seems too fast even for the uController to handle the FOC at these speeds and close current loops). Right now I think the MA702 is the best one, and as you said, it is faster to read. Maybe I should try the AMS ones.
I have no final conclusion what my measurements are telling us. I zoomed in a little bit into the signal as it is recorded during software calibration, means one motor mech rotation takes several seconds. You see a lot of ticks oscillating around zero. Each tick is the delta between sensor measurement and theoretical electrical angle as forced by the D/Q current settings.
Maybe the sensor works perfect (0.07deg error) and what we see is coming from improper motor control? I have lousy L298 drivers… Or is the PWM resolution much too low?
I think about how I could move the stepper on a really constant speed by attaching a DC motor to it to make the stepper just turning passively. That would show if PWM is the problem or some mechanical/magnetical effect. In another topic I was told that a stepper can’t suffer from cogging by principle…
Another option would be to buy another Nucleo board(grr… #3) with STM32G474 which has a HighRes timer running with GHz clock giving much higher PWM resolution.