MT6835 performances

modo · April 30, 2026, 1:57pm

Hi, I am running a project with a iFlight GM6208 equipped with a AS5048A (using the SPI bus). As controller I am using at the moment a ST G431RB (the plan is to switch to this board later). I am quite happy with the results: I’d like to improve the system by increasing the accuracy of the sensor (the current one shows a deviation fluctuating around 0.3/0.5degrees). The MT6835 seems promising but I would like some feedback about people that have used it: what is the precision that you guys experience (of course the resolution is namely much better than the AS5048A but I wonder about the “actual” noise), has the calibration process suggested in the datasheet (the second one which consists in driving the motor at constant speed) helped, are there any reliable sellers (the major sellers seem on AliExpress)?
Thanks

dekutree64 · April 30, 2026, 7:09pm

My CNC’s DRO gives stable micrometer position on 4mm ballscrew, so sensor noise is better than ±0.05°. Probably much better, but I don’t think I ever checked exactly what it was since I only have 14-bit sensors for the other axes (their readings fluctuate by a micrometer or two).

It does have significant nonlinearity throughout the rotation (±0.5° according to the datasheet), so try CalibratedSensor with LUT size 168 (the number of cogging steps for your motor). But I would change this line to n_pos = 6

github.com/simplefoc/Arduino-FOC-drivers

src/encoders/calibrated/CalibratedSensor.cpp

ed05aa164


      
              float theta_actual = 0.0;
              float avg_elec_angle = 0.0;
          	// set the inital electric angle to 0
              float elec_angle = 0.0;
          
          	// Calibration parameters
          	// The motor will take a n_pos samples per electrical cycle
          	// which amounts to n_ticks (n_pos * motor.pole_pairs) samples per mechanical rotation
          	// Additionally, the motor will take n2_ticks steps to reach any of the n_ticks posiitons
          	// incrementing the electrical angle by deltaElectricalAngle each time
          	int n_pos = 5;
          	int _NPP = motor.pole_pairs;								      // number of pole pairs which is user input
          	const int n_ticks = n_pos * _NPP;							      // number of positions to be sampled per mechanical rotation.  Multiple of NPP for filtering reasons (see later)
          	const int n2_ticks = 5;										      // increments between saved samples (for smoothing motion)
          	float deltaElectricalAngle = _2PI * _NPP / (n_ticks * n2_ticks);  // Electrical Angle increments for calibration steps
          	float error[n_ticks];	         						  		  // pointer to error array (average of forward & backward)
          	memset(error, 0, n_ticks*sizeof(float));
          	// The fileter window size is set to n_pos - one electrical cycle 
          	// important for cogging filtering !!!
          	const int window = n_pos; // window size for moving average filter of raw error

I don’t know why 5 was chosen there. 4 would make sense for steppers and 6 for BLDC since those are their natural step sizes which should give the most evenly spaced stopping positions. 5 will give inferior positioning on both.

I haven’t tried MT6835’s built-in calibration. I expect its effectiveness will depend on the smoothness of the motor’s open loop rotation, which is often not good at low speed, but is assisted by inertia at higher speed, and a gimbal motor should be smoother than most. The SimpleFOC calibration methods depend on evenness of its open loop stepping positions. Both methods are worth a try. In my case, I was able to judge the linearity by how much my NEMA23’s velocity varies throughout the revolution, since it’s super sensitive to any variation in electrical angle. Not sure how to judge it on a BLDC.

I can’t find my notes (if I took any), but I think I was getting better than ±0.05° position holding using angle_nocascade and voltage control mode. Regular angle mode adds a small delay in response to disturbance, and foc_current adds another small delay, so that may have been as much as ±0.5° or something if I really harrassed it. I’ll try it again once I get my stepstick’s firmware finished so I can just plug it into the GRBL board rather than redoing all the electronics (which ended in failure when I tried before, so I’m currently only using the sensors for position display, not closed-loop control).