Would using an anolog linear hall sensor be practical for position sensing?

[dekutree64]

I don’t think there’s any limit to how fast you can sample linear hall sensors, but if you want to try extrapolation, change the last line of loopFOC to this:
setPhaseVoltage(voltage.q, voltage.d, electrical_angle + shaft_velocity * pole_pairs * (_micros() - sensor->angle_prev_ts) * 1e-6);
You have to change prev_angle_ts from protected to public in Sensor.h.

Except instead of the angle timestamp I was playing around with measuring the time between that calculation and when driver->setPwm gets called at the end of setPhaseVoltage, to eliminate the small lag from the calculation time. It worked, but resulted in a little jitter when holding position. I expect extrapolating from the angle read time will too.

[Gloppy16]

The datasheet for the DRV5055 lists Fast 20-kHz Sensing Bandwidth.
I assume that the sample rate. I could be wrong though.

@dekutree64

if you want to try extrapolation, change the last line of loopFOC to this:

I’ll start with that. I’ll probably try other methods of extrapolation later.

[runger]

[Gloppy16]

That is indeed a chart.
If I didn’t drop out of engineering, I might understand what I am looking at.

On a slightly related note, I think I can brute force an approximation of efficiency with python if assuming efficiency and degrees of error have an inverse relationship. Basically assuming that a 90 degrees offset is 100% efficient, 135 and 45 degrees are 50% efficient, and 180 and zero degrees is 0% efficient.

[Gloppy16]

So I still don’t know what I am doing but I do have some probably meaningless numbers.

At a sample rate of 20kHz and an rpm of 60k, the average amount of rotation between each sample is 18 degrees. If simpleFoc sets the commutation angle (Q Axis?) at 9° ahead of 90°, the average error is 5%.

Here is the python code I used:

SampleRate = 20000 #Hz
MotorRPM = 60000 #rpm

# Calculated Values

samplesPerRevolution = SampleRate/(MotorRPM/60)
degreesPerSample = 360/samplesPerRevolution

# Main code

print(f'Total samples per rotation: {round(samplesPerRevolution,2)}')
print(f'Degrees per Sample: {round(degreesPerSample,2)}')

print(f'Average Error: {degreesPerSample/2}°')
print(f'Percent of Max Efficiency: {(round((90-degreesPerSample/4)/90,4)*100)}')

This is its output

Total samples per rotation: 20.0
Degrees per Sample: 18.0
Average Error: 9.0°
Percent of Max Efficiency: 95.0

[runger]

@Gloppy16

That is indeed a chart.
If I didn’t drop out of engineering, I might understand what I am looking at.

Sorry, it was getting late here and I didn’t have the energy for words…

I was trying to point out the relationship between bandwidth and sample rate in response to deku’s post.

In this case the sampling is also happening on the MCU side, since you read the linear hall with the ADC at discrete points in time.

The sensor itself also has a bandwidth though (as stated in the datasheet). As an analog sensor, I don’t think it has an internal “sample rate” - but it still has an analog bandwidth, which is typically related to the RC time constants of the analog circuit. To change the voltage it has to drive charge into the capacitance of the output line and switches through the resistance. So if you add an external RC-filter to the hall’s output, you would be changing (lowering) the analog bandwidth, but it also has internal capacitances and resistances which mean the bandwidth can’t be infinite.

As the motor speed approaches the sensor’s bandwidth, I think the output signal will be both phase shifted and attenuated. But with a 20kHz bandwidth you should be ok for quite some speed. To give you an idea:
Lets say your motor has 7 pole pairs, then the frequency of the sensor’s sine or cosine waves will be

F_s = \frac{v}{2\pi} \times pp

where v is rotor velocity in rad/s.

So 10000RPM = 1166Hz commutation frequency on a 7PP motor, which should be comfortably in the 20kHz bandwidth afforded by the sensor. And 10000 RPM is a lot!

Anyways, I would focus more on the sampling by the MCU, as I think this will more likely be the limiting factor:

As you can see, as the MCU sample rate per electrical revolution goes down, your MCU will see the curve less and less as a sine wave. This will affect the accuracy of your position estimation, and introduce errors.

@Gloppy16

So I still don’t know what I am doing but I do have some probably meaningless numbers.

I think this way of thinking about it may not be numerically accurate, but is intuitively correct. The relationship isn’t exactly linear, since the effective torque will be related to the cosine of the angle error, but the idea is the right one.

[Gloppy16]

Thank you for the detailed response.

@runger

Lets say your motor has 7 pole pairs, then the frequency of the sensor’s sine or cosine waves will be

The sensor or the commutation? I’d have a dedicated magnet for the sensor so I thought it wouldn’t care about the poles.

With simple foc, are the positions of commutation discrete and related to the pole of the motor or can it set an arbitrary angle?

@runger

The relationship isn’t exactly linear, since the effective torque will be related to the cosine of the angle error, but the idea is the right one.

I’ll implement that in Python if I can.

[runger]

@Gloppy16

The sensor or the commutation? I’d have a dedicated magnet for the sensor so I thought it wouldn’t care about the poles.

Ah sorry! I thought you were using the motor magnets…

If you have a dedicated magnet then the PP would be 1 in the calculations above.

And you can manage very high speeds in that case probably much more than you need.

[Gloppy16]

@runger

I thought you were using the motor magnets

You know, that something I should probably try.
It would be a bit cheaper overall if it works.

Thanks for the help!

[Gloppy16]

Just a few updates.

When I first ordered the drv5055 breakout boards, I didn’t realize that the were DRV5055A4. I literally had to press my magnets against them to get any sort of output. Not good.

I manually replaced them with DRV5055A1s and actually got decent reading. With a hacked together mount and the magnet from an as5600, I was able to get an ADC reading of 300 on the low end and 700 on the high end. I can get better with some better mounts but it was good enough from some initial tests.

Then I fried 3 Qvadrans, 2 esp32s, and 1 STLink because I am a silly goose.

[Gloppy16]

The first casualty was a qvadrans. I soldered to to the pins on top which then snapped off. I think it just had a bad header.
I then accidentally scrapped away the ground mask next to the 3.3v and ended up with an unremovable solder short.

The second whas when I was setting up my esp32 as a UART converter. I tried to probe pins on my esp32 to see why I couldn’t detect a pin set to high on my qvadrans. I then shorted ground to 5v, killing the board.

The stlink was because I decided to fix a solder joint without unplugging the st-link. It wasn’t even directly connected to the wire I was going for. Angy.

The next two were my qvadrans and the second esp32. The Quadrans was the one connected during the st-link fiasco. It was behaving oddly and not spinning my motor smoothly. While staring at it in confusion, both it and the esp32 decided they’ve enough and shut off for good. The esp32 had some form of internal short and got real toasty.

Then the last qvadrans was working Ok and seemed to show promise. The motor didn’t have quite enough kick to spin reliably on open loop at 0.05v. So the natural reaction is to set the motor voltage to 2v on my 27mOhm motor and witness the MOSFETs literally catch fire. Whoops.

Eventually I will run out of new ways to break thing and end up with a functional test platform for my linear halls.

[Valentine]

@Gloppy16

run out of new ways to break thing and end up with a functional test platform

Anything I could do to help?

Cheers,
Valentine

[Gloppy16]

@Valentine

Anything I could do to help?

At the moment, unfortunately there isn’t much to help with. I do appreciate the offer.

Right now I need to spend the hour or so it takes to solder a new qvadrans into my setup. After that, I’ll test the boiler plate linear hall code found on SimpleFOCs github.

If I can’t get that to work, I’ll be posting in the forums again.

If it does work, I’ll post my quick and dirty freecad models as well as a write up on my github.

[Gloppy16]

@Valentine

Anything I could do to help?

What values do I need to set to use to the current sensing on the qvadrans?

[Gloppy16]

So I had everything working pretty reliably on a 2s lipo. It was getting low so I switched to my 20v power supply.

Apparently, it I plug the power supply, the st-link, and the esp32 in all at the same time, it fries the Qvadrans and the Esp32. Absolutely no idea why or how.

The esp32 is only connected to the qvadrans via the TX and RX pins so how that is getting killed from this is beyond confusing.

[dekutree64]

Maybe the USB ground and power supply ground are not the same, and unable to equalize to eachother when connected?

Is your st-link able to supply 3.3v power? I have a cheap st-link v2 that does, and an official v3minie that does not. If you need external power while programming, try adding a USB isolator (this kind of thing ADUM3160 1500V USB Isolation Board Module Signal Audio Power Isolator Module | eBay) between the computer and st-link. If the st-link can provide power, then just disconnect the other power supply while programming (what I normally do).

[Gloppy16]

@dekutree64

Is your st-link able to supply 3.3v power?

Yeah. It claims to have 3.3v and 5v. Haven’t check it with a meter though.

@dekutree64

If you need external power while programming

What real weird is that is just started doing this. This set up was also fine when on a lipo battery.

My esp32 could not read any values from UART without that plugged in so I guess it was a grounding thing.

I’ll be switching to an arduino nano or whatever else I find for the UART converter as I am now out of Esp32 C3 Super minis. Edit: I was apparently able to res one of my the C3s that was DOA. It had a short across the resistor in the crystal oscillator circuit.

I have one working qvadrans board left. Hopefully I don’t blow that one up too.

[dekutree64]

Yeah, the lipo’s ground will equalize to the USB ground voltage, whereas a wall-powered supply may not.

But now that I think about it, I have connected a wall-powered supply’s ground with USB ground before without issue when I was running a hoverboard motor on a 24V supply. I use an FTDI adapter for UART communication to Arduino serial monitor, and it has a ground pin that connects to the motor driver, which was connected to the power supply (which was plugged into a different outlet than the computer, but both outlets are on the same circuit in the house wiring). My house is very old, with two-slot outlets (no ground), but they are polarized (one slot wider than the other) so I was able to ensure that the power supply had its wires the right way around. I expect it would have blown up if I plugged it in the other way.

[Gloppy16]

Welp. Immediate fireball from my last qvadran board.

I guess I got soldering debris across a mosfet or something because one immediately popped when I hooked up the battery.

That’s going to put an end to my attempts for a bit.

[runger]

Oh wow, it sounds like there’s been many dramatic moments in your workspace recently

Will you order more quadrans boards?