at least the MT6835 has a feature to store a calibration table based on comparing its readings with an optical 21+ bits encoder. This is described in the manual. But without having that encoder you can only do the more basic user calibration - I commented about that aleady.
Regarding the noisy signal: if there is no solution to this by e.g. filtering, we indeed talk about 11bit usable resolution and I am back on square one - getting beyond microstepping resolutionā¦
yes and no: when the stepper drives my two-motor setup, I am still on L298. Not so easy to get something else. I made a hardware design with TI chips which I canāt buy for two years nowā¦
When the Maxon motor drives my setup, it uses a separate Maxon controller which for sure has high quality output - my belief in Swiss engineering is rock solid.
On both setups I donāt get clean signals from the encoder, which takes out the poor L298 from the equation currently :-0
You can get 256 microstep drivers for like 8 bucks, though. The actual resolution is swamped by other error sources in almost all practical contextsā¦
Another bug-fix to the MT6835 driver now fixes setting the ABZ resolution.
Iāve tested this a bit, and setting ABZ resolution, ABZ on and AB-swap via the driver works nicely.
Code is still on dev branch but will be the next release:
Iāve pushed another update. I made good on m threat and radically simplified the STM32HWEncoderā¦
Now it just runs the timer to capture the encoder pulses, and leaves everything else (velocity, full rotations) to the base class Sensorā¦
It should now work like all the other sensors and the bugs should be solved
As usual you can find this code on the dev branch for now, but I will release a proper version soonā¦
Oh, and it now supports the MT6835ās full resolution on ABI
Hi, sorry for replying directly here, Iām new and a little lost right here, i have a question about the MT6835 driver, i see that you are able to change the ABZ resolution, but i have a question, is that change permanent?, like will it be saved after power cycles and being disconnected from the spi?, thanks in advance
The change is not permanent unless you write it to EEPROM. See section 7.6.6 of the MT6835 data sheet about EEPROM programming.
You can use the writeEEPROM() method of our driver class to do so. Pay attention to the fact that you have to wait 6 seconds (!) before talking to the sensor again after programming the EEPROM.
Got it, thank you so much for your answer, i have never done anything like that but i will research about spi programming on my own, that info deffinetly helps me getting started, only one last question, is there any problem if i do the programming with the ic already soldered in a pcb (with all the complementary components ofc)?, as i will be buying it that way?
Well, the SPI part is done for you in the driver already. You just need to configure your settings using the driverās methods, and then call the writeEEPROM() method to make them permanent.
It should work with any MT6835 board that has the SPI bus exposed.
Thank you for all the information here. I am not sure, that I read and understood all of it. I have read the datasheet of the MT6835 and got two issues with questions:
It seems that the sensor got some moving average filter function, and it is set by a programable BW parameter (see page 37 in datasheet). The factory default setting is 5.
How do the sensor actually do this filtering in more specific terms?
How is the filter changed by the BW parameter?
I read this other thread with some MT6835 information:
It seems that BW=5 cause a 2 ms latency, but it is not specific.
Another question is about how the sensor work. The AMS sensor like AS5047 got an internal clock with a cycle time between 90 and 110 us. So in a cycle the internal hall sensors output are sampled, ADC takes place, and calculations take place. When you issue the SPI command, the latest calculated angle or filtered angle can be read.
I guess that the MT6835 works in a similar way - do you agree?
What is the cycle time of the MT6835?
Are you able to synchronize your SPI-reading to its internal cycle?
Just a correction: setting BW to 5 results in a latency of 100 us, as described in the datasheet. The problem I was facing was that I bought a module with the chip configured to BW=0, resulting in an approximately 2 ms of delay relative to the real angle. You can achieve even lower propagation delays by using BW=7, but due to the 21-bit resolution, you may experience some noise in the lower bits. Iām working with BW=5 and itās running pretty well.
Yes, the Z point is usually random unless set through SPI. But in XY/PNP machines it normally doesnāt matter because the machine homes itself at startup.
If ABZ is already configured correctly, the sensor can run fully without SPI. SPI is mainly needed for calibration, setup, or changing resolution.
Thank you Digitalmonk for your answer, and welcome to the forum. And thank you cSandrini for your clarification.
Latency can have many forms, and I should like to see a typical response for a step angle change. You may be able to do a test setup by making a small coil of copper wire around the sensor and make a step current in it. When you use such a sensor in a closed loop system, you like to know more detail here.
When I look the specifications, the sensor can work with magnetic fields in the range 30 mT to 1000 mT. But it seems, that you cannot read what field, that it got. But with this large range, the sensor likely adapt by changing the amplifications of the amplifiers before the AD converters. If you got a too low field (likely below 30 mT) a status bit will issue a warning in the status register. But I think, that the noise level in resulting angle from the sensor will depend on the field strength from the magnet, so a larger field will reduce noise.
You are able to set a hysteresis (page 36 in datasheet). How would you interpret how this setting work?