Hot damn.
This looks like the halls are rattling inside. Some algorithms use only one hall so may be that’s why some algos work.
Try open velocity loop, that should be really quiet, then it’s definitely the hall sensors are loose inside.
Can you open the motor and pull the rotor out?
Valentine
Its so bizarre! I’ve never seen anything like it.
I think you’re correct about the hall sensors rattling, that would absolutely explain the inconsistency between the timings of the hall state changes. I’m going to see if I can get this thing open without breaking it… although it’ll be scary as it did cost quite a bit of money
I’ve ran some open loop velocity tests and it is essentially silent, so I think everything is pointing towards dodgy halls
Hey @Candas1
I tried out the MXLEMMING flux observer and wow it works fantastically. Luckily I had the motor parameters from my experimentation with VESC and it fired up straight away, I’m pretty mind blown that sensorless FOC was this easy to add.
I added a start up boost where it applies higher currents below a certain RPM so it can get started reliably and it works every time.
I’m going to definitely try this on my 15kW mobility scooter’s sensorless motor in the near future
EDIT: It’s got me thinking how incredibly useful motor parameter extraction would be. If SimpleFOC had the ability to profile the motor then we would essentially have a library that is as capable as VESC, but is much more modular and flexible
Thanks a lot for the feedback.
I wanted to get feedback before publishing this in the dev branch and then in main branch of simplefoc.
Please let me know if anything is unclear about the docs or the code to use the “sensor”.
There are people on the discord discussing HFI, some of this code could be used to characterize motor parameters like inductance. It will take some time but it will be a good addition to the library.
So sensorless runs better on this motor than with the weird hall sensors ?
The example code was all I needed to get it working in under 15 minutes. I think its absolutely ready to be added to the dev branch, and probably even main tbh. Some supplementary docs online could maybe be good to express the need for good motor parameters, but in its current state it was essentially plug and play.
Ive tried it on my 15 pp hoverboard motor, 10pp inrunner motor, and will be trying it soon on a 3pp inrunner soon.
The difference between the flux observer and the dodgy hall sensors was night and day. With halls it barely ran, drew loads of current and sounded horrific. As soon as i fired it up with the FO it span up great, was very smooth and sounded identical to using the vesc
Hello again @Candas1,
I’ve been doing more testing and have found a bug in the mxlemming sensor (and maybe many more sensors?) which causes it to go crazy after running for a while. Consistently at ~35:30 minutes since boot, the motor makes a sudden very loud noise before my overcurrent protection kicks in, this happens repeatedly until power off, despite my target current being 0.
I was thinking that 35:30 mins is suspiciously half of 71 mins, which is the time to overflow for a 32 bit unsigned integer when incrementing in the microseconds. That’s when I noticed that angle_prev_ts is a signed long datatype and stores the timestamp in microseconds, which therefore will overflow at exactly 35:30 mins. I inspected these variables using a debugger and indeed the angle_prev_ts & vel_angle_prev_ts get clamped to 2,147,483,647.
So essentially these timestamps become stuck at their maximum value after ~35mins, and this causes havoc for the FOC.
However, this is rather interesting because these variables are defined in the sensor base class, so surely this would also be an issue for many other sensor types as well?
Found the bug. Arduino-FOC-drivers/src/encoders/MXLEMMING_observer/MXLEMMINGObserverSensor.cpp at flux_observer · Candas1/Arduino-FOC-drivers · GitHub line 49, float now = _micros(); should be int32_t, not float. Those timestamp values are always used for deltas so wraparound will cancel out, but it only works with integer subtraction.
Thanks for sharing this. Need to check if I handle it in the right way.
Ah thanks. I will fix it.
I thought I need to find 36 minutes this evening to fix and test 
So it’s just int32_t now = _micros();
Out of curiosity why not uint64_t ?
Cheers,
Valentine
Yep I did long now = _micros(); but i believe a long is just an int32_t so its exactly the same
I think its because the _micros function returns a 32 bit integer, and if there is an overflow event when subtracting two of the same integer datatype it essentially cancels out the overflow
Right keep forgetting the _micros was internal to sfoc.
Still, uint64 would be cool, a motor running at 10k rpm would overflow it after 58 years. Talk about a long-running motor test, eh?
Cheers. Valentine
PS Imagine sending a probe to deep space, and the gyros are running sfoc, and after 58 years the probe goes coo-coo.
I keep an optical rotation sensor with AB outputs aroubd to use as a debugging tool. This kind of sensor is very reliable and has a “how to screw up” interface. I like to get the motor running with this sensor first. Then go with less bulky and cheap sensor. The iidea is to NOT jump to the target solution as a first step. Do what is known to work first, open-loop and take thre next baby step and so on.
