RoboteQ GB Project

[Williamclark77]

Efficiency differences and overall power won’t be noticeable. I've been using trapezoidal just fine for years on my W1 and W2. However, they both have gear reduction. The GB motors do not. Very low speed, below 5 rpm or so, might be "stuttery" and hunt.

Trapezoidal uses only three sensors with one reference each. Sinusoidal (except sinusoidal using hall sensors) uses encoders with 1000 or positions to reference. I can't say how trapezoidal will do on those GB motors. I can barely feel the cogging/stuttering on my W1 and W2, but the gear reduction helps hide it.

The main downside to trapezoidal is the noise I talked about above. There's no way around it. I don't notice it unless I'm somewhere very quiet trying to stay out of view. Then it sounds like a big dog growling. The slower and heavier the load the louder it is. Sinusoidal is not silent, but much quieter. Planetary gears and helical gears are louder.

[stevelawiw]

Thanks Will. I've got one motor working on the bench, it's loud! I guess I'm just going to have to live with more noise than I'm used too.
Reffering back to a previous post you made, I wanted to try the new features of the V2 software, but the diagnostic tab in Roborun is missing from any older firmware.
I did see it when I had the V2 firmware installed, but of course couldn't use it because of the false Overvolt fault warning which must have been an error in the V2 firmware that they have now pulled from thier download page.
Hopefully they are working on a fix.

[LROBBINS]

Trapezoidal requires 3 sensors equally-spaced around the motor. Are the GB's sensors arranged that way? At the very low RPM of the GB motors there will also be a much larger hit on efficiency than WIll has found, and the noise he hears will likely to be massive cogging instead. Given that the GB motors have sin/cos output (which gives absolute angle information) and the newer Roboteq brushless controller can use that for both sinusoidal commutation and field-oriented-control (which can yield a noticeable efficiency gain, but won't work at low speed with just Hall sensors) - see https://www.roboteq.com/index.php/applications/100-how-to/359-field-oriented-control-foc-made-ultra-simple, my advice would be to read the Roboteq manuals and other downloads for as much information about that as you can take in and plan on going that route.

[stevelawiw]

Thanks Lenny. The original sensors in the GB Motors are on the pcb in the picture above, there are onlt two of them. The 3 Hall sensors I've installed are 120 degrees apart . I've read that article you linked to twice now.
I'll read it again tomorrow and see if it sinks in

[shirley_hkg]

I would not hesitate to get a new controller , if I were up to this mod.
Glad to know someone is still after the great GB motors.

PS. You have to run that internal calibration to get smooth operation, whenever a motor or controller were replaced .

[Burgerman]

Not with roboteq.

[stevelawiw]

Actually I believe you do with sinusoidal commutation, it's in the user manual for the newest Roboteq controllers

[Burgerman]

Is it? I dont have one of those. I stand corrected.

I know I did it on the Dynamic controller. Not that it changed anything as far as I could tell. What does it actually do?

[Irving]

Is it? I dont have one of those. I stand corrected.

I know I did it on the Dynamic controller. Not that it changed anything as far as I could tell. What does it actually do?

If I understood it correctly, some motors have calibration data in an eeprom (or otherwise) that characterises torque v angle to manage variation in coil/magnet relationship. The controller can use this to improve running efficiency, reduce torque variation, esp at low speeds.

[stevelawiw]

Yes what he said! It's nice to talk to people that know stuff. This site is bloody marvelous

[Burgerman]

If I understood it correctly, some motors have calibration data in an eeprom (or otherwise)

Oh. Maybe it stores some values in the PM or some place. I swapped power module, worked as normal. I did the calibration, (you need HHP emulation) and couldnt detect any changes.

[Irving]

Is it? I dont have one of those. I stand corrected.

I know I did it on the Dynamic controller. Not that it changed anything as far as I could tell. What does it actually do?

If I understood it correctly, some motors have calibration data in an eeprom (or otherwise) that characterises torque v angle to manage variation in coil/magnet relationship. The controller can use this to improve running efficiency, reduce torque variation, esp at low speeds.

A little more digging suggests that the controller can work it out itself - this is the 'calibration routine' previously mentioned and it works like this: you run the motor unloaded (wheels off ground) then the controller increases current until the rotor starts turning against the detent torque (the cogging feeling you get when turning by hand) - it does this for each pole in turn until it's built up a map of current v torque for each rotor step. It can then use this map to minimise torque fluctuation across each revolution and improve slow speed running. That's why you need to run the calibration if you change either motor or controller. A significant mismatch could be damaging to either component and would potentially give a rubbish ride.

[Irving]

I suspect there's a secondary purpose to this calibration routine: to check for open or shorted stator coils before applying full power and potentially damaging something.

[Burgerman]

A little more digging suggests that the controller can work it out itself - this is the 'calibration routine' previously mentioned and it works like this: you run the motor unloaded (wheels off ground) then the controller increases current until the rotor starts turning against the detent torque (the cogging feeling you get when turning by hand) - it does this for each pole in turn until it's built up a map of current v torque for each rotor step. It can then use this map to minimise torque fluctuation across each revolution and improve slow speed running. That's why you need to run the calibration if you change either motor or controller.

I suspect in the case of dynamic/invacare it is stored on the controller. Or why would swapping a controller need to recalibrate. If stored in the motor then it would just use that stored data. And I saw no chips in the motor that could store dats. Just op-amps? and basic looking non active components. So is this data on the new roboteq?

[Irving]

It's definitely stored in the controller. It seems, reading around, that factory calibration of motors and provision of data was quite common in the early days of bldc motors but now 'active' or 'dynamic' calibration as discussed is the norm. It only really applies to motors that need to be run at low speed where clogging & torque variation is an issue, most bldc motors don't need calibrating as they generally are run at fixed speeds or a relatively small range of speeds (think of a drone motor, the lowest speed is still quite fast).

[stevelawiw]

Not sure but I think on the Dynamic it could be stored on that little pcb in my first post on this thread, one of the wires to it is for eeprom data on that picture that Hank kindly posted

[Irving]

Not sure but I think on the Dynamic it could be stored on that little pcb in my first post on this thread, one of the wires to it is for eeprom data on that picture that Hank kindly posted

Good point Steve - yes there's data/clock to read (not write) the eeprom in the motor, so that strongly suggests they are factory calibrated and the Dynamic/Invacare calibration procedure loads the data from the motor to the controller (the eeprom is too slow to be used directly).

After a quick read of the Roboteq manual my guess is that it's highly unlikely that the Roboteq could use that data (no industry interface standard AFAIK), indeed I can find no reference to torque calibration of this type. The Roboteq calibration routine is to characterise the hall sensor min/max v angle values.

[shirley_hkg]

That's bad ! ! !

[Williamclark77]

The Roboteq doesn't need that calibration information stored in the EEPROM (if it even has anything stored). The version 2.0 firmware can be calibrated to it and permanently stored in the Roboteq.

Trapezoidal requires 3 sensors equally-spaced around the motor. Are the GB's sensors arranged that way? At the very low RPM of the GB motors there will also be a much larger hit on efficiency than WIll has found, and the noise he hears will likely to be massive cogging instead. .

The sheer number of poles in the GB motors SHOULD help mitigate that by reducing the amount of rotation required to make a full ELECTRICAL revolution. I don't know exactly how many poles they have but I saw the guts of one years ago (they are NOT easy to separate!) and it appeared to have over 20. That could reduce the amount of cogging down to just a few degrees of mechanical revolution between when each sensor registers.

Anyway, that's why I won't say whether trapezoidal with halls will be tolerable or not. It could be about like my W1 and W2 with less poles but gear reduction. But then again, as Lenny says, it could be like riding on square tires.

My suggestion is to just try it since you already have the hardware to. FYI - it’s very sensitive to hall sensor position. Just being 2 degrees off will increase the noise and cogging substantially along with reducing efficiency. I believe firmware 2.0 on the HBL23XXA models can even calibrate for correcting slight variances in hall spacing when using certain sinusoidal modes.

[stevelawiw]

15 poles in the GB Motors. I think with the wireing of the small pcb known I may keep the original sensors in as well as my new ones installed to try when/if I get one of the new 'A' controllers
Edit: That's the Mk2 motors. don't know about the originals that Shirley uses, or the newest version used on the brushless chair the Burgerman had for a while

[Irving]

15 poles in the GB Motors.

I thought it more...

Found these pics, first is external rotor as on later Storm 3 & 4 & TDX2, second is internal rotor & hub which I believe is earlier version?

images.jpeg (2.98 KiB) Viewed 5023 times

images (1).jpeg (8.71 KiB) Viewed 5023 times

[Irving]

I just realised we had 90% of this same conversation in June/July 2014!

[stevelawiw]

We did? I can't remember last week.
Did we come to a decision on the number of poles? I just counted them definately 15.
But if I change the number of poles to any other number in Roborun it's not making any difference

[Williamclark77]

The number of poles in Roboteq doesn't matter on the older controllers except for rpm measurement. It SHOULD change the rpm value on the run screen if you have it enables. Possibly the hall counter also. If the motors are 15 pole, put 30 poles and it should show double the rpm value of what the motor is actually turning.

[Irving]

We did? I can't remember last week.
Did we come to a decision on the number of poles? I just counted them definately 15.
But if I change the number of poles to any other number in Roborun it's not making any difference

How are you counting them? Do u have a pic?

[hank]

We did? I can't remember last week.
Did we come to a decision on the number of poles? I just counted them definately 15.
But if I change the number of poles to any other number in Roborun it's not making any difference

How are you counting them? Do u have a pic?

Irving does this help

[stevelawiw]

Same as Hanks pic just a bit more side-on, this is my second motor I've just opened up, no mods yet.

The count of poles is 45 in total, So split that into 3 is 15.
When I first started this I used a thread on endless sphere to give me the correct location for the Halls.
To make sure I had it right I put a total of nine hall sensors in, one each side of what I thought was the correct location, and it proved to be right as the amps weren't equal when running the motor using the halls not in the middle.

[Irving]

Same as Hanks pic just a bit more side-on, this is my second motor I've just opened up, no mods yet.

coil.jpg

The count of poles is 45 in total, So split that into 3 is 15.
When I first started this I used a thread on endless sphere to give me the correct location for the Halls.
To make sure I had it right I put a total of nine hall sensors in, one each side of what I thought was the correct location, and it proved to be right as the amps weren't equal when running the motor using the halls not in the middle.

OK that works. I'm sure I read somewhere that there were 54 or 57 coils which is 18 or 19 poles. Obviously the more poles the smoother the ride.

[stevelawiw]

I wonder if there are more in the latest version that are installed on the chair John had for a while, the last time I looked I couldn't find a part number for them to find out how much they would rush you for a pair I bet they'd be pricey.

[Irving]

I wonder if there are more in the latest version that are installed on the chair John had for a while, the last time I looked I couldn't find a part number for them to find out how much they would rush you for a pair I bet they'd be pricey.

Unlikely. It's pretty busy in there already, adding more poles would increase torque but would have to reduce # of turns on each coil as there's no more space - the rim is fixed at 8". Reduced turns = more current, more heat.