60 degree hall sensors

[humble800]

Variant

USART

Control type

FOC

Control mode

Torque

Description

Hi @Candas1, Thank you and @EFeru for developing and maintaining the FOC software. It has been working perfectly on my 6” hoverboard motor that has 120 degree hall sensors with exact internal wiring as here: https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/docs/pictures/motor_inside.jpg. I am working on an 8” hub motor with 60 degree hall sensor and will appreciate some tips to make the software work with that motor.

I got an 8” motor from an old Halo hoverboard. This 8” wheel has 60 degree hall sensors. It also has different hall sensor spacing and placement (1.5 poles in between) vs. the 6” wheel that has hall sensor spacing of 3 poles. In addition, the sensor wire orders are also different. This 8” wheel has green hall sensor goes first, followed by the yellow hall sensor wire (which is reversed to produce 60 degree), and lastly the blue hall sensor wire. This is different from the Yellow->Blue->Green order of the working 6” wheel. I believe both wheels use WYE wiring. Please see pictures below.

I have tried inverting the hall value as @Candas1 noted here and here. I also connected the 8” hall sensor wire in different orders to match with the order of the working 6” wheel. In particular I connected the green hall wire to yellow (Hall C as shown here https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/docs/pictures/mainboard_pinout.png), yellow to blue (Hall A), and Blue to Green (Hall B). I haven’t been able to make it work so far. I have tried many combinations of matching different hall sensor wires, inverting one of the three hall values, and even tried different combinations of phase wires.

The next step I am thinking to try is to adjust the Hall to Position table here as @Candas1 suggested. I couldn’t figure out the meaning of sector and angle: https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/386#issuecomment-1450640574. Could you give me some suggestions please? Given that the physical placement of the hall sensor spacing on the 8” wheel differs from the working 6” wheel, would it even possible to make the FOC software work this 8” wheel with 60 degree hall sensors?

Thank you very much!

[Candas1]

Hi,

It's the first time I see that, it doesn't look like the middle hall sensor is inverted. What do you mean by not working?

I have a very experimental firmware with some kind of autodetect. It's not finished yet but I will check if I can publish a version that can at least give the values for the hall to position table.

[Candas1]

I also see there are 7 coil wires in parallel? There is an extra white wire for temperature, you have seen that you sure use the alternative board variant?

Can you share pictures of the other side of the wheel and the hoverboard? I want to check if I have anything like this

[humble800]

Thank you very much again for your help, @Candas1. I have tried a few things today, but still have no luck so far and will appreciate your suggestions.

To answer your questions first:

1. Yes, it has 7 coil wires in parallel.
2. Yes, the white wire is believed to be used for temperature.
3. Yes, I am using the alternative board variant, which I have set BOARD_VARIANT=1 and works perfectly with the 6” wheel that has the same internal wiring as here https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/docs/pictures/mainboard_pinout.png.
4. Pictures of the other side of the wheel is attached.
5. Is the middle hall sensor inverted? I do not know for sure, but looking at the picture of the hall sensor board, it looks to be the inverted. I labeled which sensor goes to which color of hall sensor wire on the picture. The middle sensor has a different orientation (which is labeled Y and connected to yellow hall sensor wire) than the other two (labeled as B and G). I have labeled the positive and negative pins as well.

I did a very cruel bldc hall sensor tester board and verified that the yellow color hall sensor and blue color hall sensor are swapped on the not-working 8” wheel, and compared compared with the working 6” wheel. I made a short video to demonstrate the halls sensor result on the 8" wheel after swapping the Y and B hall sensor wire. I have the same reading from the hall sensors on both the 8” and 6” wheels when rotating the wheel forward (clockwise) and starting with the green hall reading.

Next, I tried two different ways of connecting motor hall sensor wires to the HB; and 6 permutations of phase wire connections. The results are shown below. There was no beep sound from the HB, so the hall sensors are operating normally. Unfortunately, I haven’t been able to get the motor working. Very strange indeed. Your advice is very much appreciated!

https://github.com/EFeru/hoverboard-firmware-hack-FOC/assets/88641966/2036eac6-f272-4f62-9b30-7e9be7b33a26

[Candas1]

Can you try this fork ? It will make the wheels turn and output some information on right USART.

It's set to work with this for my test. Use it only for diagnostics, I made a lot more changes that I still need to test.

[humble800]

Many thanks, @Candas1. Sorry it took me a while to set up the test environment. I believe I got the output message you are looking for.

I built VARIANT_USART variant (platformio.ini); changed BOARD_VARIANT to 1 (config.h), changed #define VBAT_PIN GPIO_PIN_1 (define.h to fix the compile error for VBAT_PIN).

I only connected the left motor.

I did three tests below: Test 1. Left phase and hall sensor wires unchanged (matching the same color between HB and the motor) Test 2. I left the phase wire unchanged (meaning matching the same phase wire color from the HB with the motor); but swap the blue and yellow hall sensor wire between HB and motor. Test 2. Swapped the Blue and Yellow phase wire between the HB mainboard and the motor. Also swapped the blue and yellow hall sensor wires.

The output message from UART3 are listed below. Thank you again!!

`/***** Test #1 **/

Using the configuration from config.h a mid-resting potLimits Input1: TYP:0 MIN:-1000 MID:0 MAX:1000 Limits Input2: TYP:2 MIN:-1000 MID:0 MAX:1000 -- Motors enabled -- Warning, Serial Timeout repeat timeout msg Warning, Serial Timeout

Right Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01962|002014|002004||| |Phase A|-0004|000012|000003|_OK|___| |Phase B|00000|000011|000009|NOK|__OK| |Phase C|-0001|000010|000003|OK|__NOK|

Hall Positions 3,2,0,1,4,3,5,0, Hall Angles 179,0,0,0,0,0,0,0,

Hall A B C Min- 0 0 0 Max- 0 0 0 OK?- 0 0 0

Left Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01964|002020|002025||| |Phase A|-0007|000024|-00041|OK|OK| |Phase B|-0001|-00016|000025|OK|OK| |Phase C|-0004|-00029|-00040|_OK|___|

Hall Positions 0,5,3,4,1,0,2,0, Hall Angles 0,287,166,182,31,307,83,0,

Hall A B C Min- 0 0 0 Max- 1 1 1 OK?- 1 1 1 Warning, motor right error code 3

/ Test #2 / Using the configuration from config.h a mid-resting potLimits Input1: TYP:0 MIN:-1000 MID:0 MAX:1000 Limits Input2: TYP:2 MIN:-1000 MID:0 MAX:1000 -- Motors enabled -- Warning, Serial Timeout repeat timeout msg Warning, Serial Timeout

Right Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01966|002015|002006||| |Phase A|-0003|000017|000009|_OK|___| |Phase B|-0003|000012|000009|OK|OK| |Phase C|-0002|000007|000004|_OK|NOK|

Hall Positions 3,:,0,1,4,3,5,0, Hall Angles 179,0,0,0,0,0,0,0,

Hall A B C Min- 0 0 0 Max- 0 0 0 OK?- 0 0 0

Left Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01965|002019|002027||| |Phase A|-0008|000035|000010|OK|OK| |Phase B|00000|000016|000041|NOK|_OK| |Phase C|00001|000000|-00014|_NOK||

Hall Positions 0,1,3,2,5,0,4,0, Ha�l Angles 0,33,139,102,277,310,193,0,

Hall A B C Min- 0 0 0 Max- 1 1 1 OK?- 1 1 1 Warning, motos right error code 3 Warning, motor right error code 3 Warning, motor right error code 3 Warning, motor right error code 3 Warning, motor right error code 3

/ Test #3 / Right Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01964|002014|002004||| |Phase A|-0003|000012|000003|_OK|___| |Phase B|00000|000011|000008|__NOK|_OK| |Phase C|00004|000015|000008|NOK|__NOK|

Hall Positions 3,2,0,1,4,3,5,0, Hall Angles 179,0,0,0,0,0,0,0,

Hall A B C Min- 0 0 0 Max- 0 0 0 OK?- 0 0 0

Left Motor +-------+-----+------+------+-----+-----+ |-------|DCCUR|PHA-AB|PHA-BC|DCCUR|PHASE| +-------+-----+------+------+-----+-----+ |Offsets|01965|002019|002025||| |Phase A|-0005|000029|-00048|OK|OK| |Phase B|00000|-00017|000025|NOK|__OK| |Phase C|-0002|-00023|-00048|OK|_____|

Hall Positions 0,3,1,2,5,4,0,0, Hall Angles 0,127,57,91,284,202,330,0,

Hall A B C Min- 0 0 0 Max- 1 1 1 OK?- 1 1 1 Warning, motor right error code 3

`

[Candas1]

ok there are some weird values but it's probably my code that is buggy. So what if you use now the hall positions from debug output here with the main firmware ? 0,1,3,2,5,0,4,0, or 0,3,1,2,5,4,0,0, depending on how it's wired now. If the hall sensors were really spaced at 60 degrees I would expect the 1 or last value to be non zero based on the theory. Unfortunately I don't own sure motor.

[humble800]

Thank you again, @Candas1. I tried to overwrite the hall positions from debug output with the main firmware as you suggested; unfortunately no luck yet. For what it is worth, I did notice changing the phase wire would change the hall position readings from the debug window using your code. So, I updated the code with the new hall positions and test again without changing the phase wire connection until the hall position readings remains the same. I did that for all the 6 permutations of the phase wire connections. So far no luck.

1. Could you tell me if the hall labels on this picture (https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/docs/pictures/mainboard_pinout.png) matches with the phase wire color scheme here?
2. Does it also match the A, B, C label noted on the hall position table here: https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/386#issuecomment-1450640574?
3. Additionally, does A mean u, B mean v, and C mean w in the main firmware?

Thank you again!

[humble800]

I take it back! I did the following it seems working except the wheel is not going the correct direction. Meaning, the left wheel rotates backwards (counterclockwise instead of clockwise).

Here are what I did:

1. swap the yellow and blue hall sensor wires as I showed on the video before.
2. change the hall positions as { 0,1,3,2,5,0,4,0 } based on the debug output using @Candas1's code
3. no change in the phase wire connections.

Right now the wheel is rotating the opposite direction as expected. So I suspect changing the hall position array could solve this problem; but I don't know how. Some guidance will be appreciated!

[Candas1]

You can invert a motor in config.ini. It's described in the wiki. But wouldn't this have worked by swapping phases and finding the right combination ?

But it's good news, this autodetect works. I just need to run it on demand and save the results to eeprom

[humble800]

Thank you, @Candas1. I will give it a try next weekend. Could you please confirm if the statements listed here are all true? https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/408#issuecomment-1556065209 I am thinking eventually after I find the correct wire mapping, I may be able to modify the firmware by redefining the pins on define.h and make it work.

[humble800]

Closing the issue. The last solution was the best solution I have. Just wanted to say thanks again for @Candas1's help!