Stutter at startup

[wingye1988]

When accelerating from a stop there is a jerky/ stuttering vibration from the motor. Im using a G63 1000w Bafang geared hub motor. I upgraded from a KT 35a controller and screen combo to a V6 Phaserunner L10 Controller and a CA3. Ive done auto tuning and changed what setting I thought would solve the issues, the stutter still occurs. Going back to my old controller does not have the same issue. I will note that when I would use the auto tuning it would put, "Motor position sensor type" to [1] Hall sensor start sensorless run. This would cause the motor to stutter and then stop. I would have to let off the throttle and wait or reset the bike before the bike would move again. Placing that setting to [0] Hall sensor fixed the stalling issue, but the stuttering still occurs.

Any ideas on what could be causing this and can it be fixed? Other then the stuttering on start up the bike runs with no issues.

 

[E-HP]

What happens if you run auto tune with the position sensor type set to Sensorless? Seems like the motor needs the halls to run, but will only start sensorless. How did you wire up the hall sensor connector interface between the motor a controller?

 

[wingye1988]

The auto tune does its own thing and will not let you choose. It just always chooses [1] Hall sensor start sensorless run after the tune and I switch it back to [0] Hall sensor. The motor is a Julet Z916 and the contoller is a HiGo L10 so i use a HiGo to a julet connector.

 

[amberwolf]

When accelerating from a stop there is a jerky/ stuttering vibration from the motor. Im using a G63 1000w Bafang geared hub motor. I upgraded from a KT 35a controller and screen combo to a V6 Phaserunner L10 Controller and a CA3. Ive done auto tuning and changed what setting I thought would solve the issues, the stutter still occurs.

What specific settings did you change, from what value to what value?

What does the autotune come up with, including the hall results? (does it say anything unusual about the hall configuration, etc)

Going back to my old controller does not have the same issue. I will note that when I would use the auto tuning it would put, "Motor position sensor type" to [1] Hall sensor start sensorless run. This would cause the motor to stutter and then stop. I would have to let off the throttle and wait or reset the bike before the bike would move again. Placing that setting to [0] Hall sensor fixed the stalling issue, but the stuttering still occurs.

Any ideas on what could be causing this and can it be fixed? Other then the stuttering on start up the bike runs with no issues.

Are any limit flags in the CA diag screen capitalizing during the problems?

Have you tried setting the CA throttle mode to BYPASS to eliminate all CA operation and send the throttle directly to the PR unaltered, to ensure no CA limiting is causing the issue?

How much battery current is the PR setup to draw, and how much does it actually draw under the problematic conditions?

How much battery current is the KT setup to draw, and how much does it actually draw under the same conditions?

How much voltage sag is there under these conditions on each controller?

What are the PR voltage limits setup at?

If the PR is drawing higher current than the KT, the battery voltage will sag more under those conditions.

If the battery voltage under startup load (probably higher than at any other moment) is sagging below a threshold in the PR's settings, the PR may cease driving the motor until it rises again, then cease, then drive, etc., and that could cause a stutter if it happens fast enough.



What blink code does the PR give during or after the problem? (if it has to be reset, there should be a blink code on it's LED)

If it's possible to test this way, what error codes come up in the PR setup software during or after the problem, if you leave it connected while trying to startup (without actually going anywhere so you can leave the computer connected)?

 

[E-HP]

…and I switch it back to [0] Hall sensor.

So you can only switch it to [0] Hall sensor, but not to [2] Sensorless ?

I would verify voltage and check continuity of the 5v conductor going from the controller to motor at the Julet connector to the motor.

 

[neptronix]

Are the motor poles set correctly?

 

[amberwolf]

Some analysis:

So you can only switch it to [0] Hall sensor, but not to [2] Sensorless ?

I would verify voltage and check continuity of the 5v conductor going from the controller to motor at the Julet connector to the motor.

Side note: there is also a checkbox for "fault tolerant hall (fallback to sensorless)", which if unchecked, prevents the system from ever using sensorless mode if the halls aren't working as expected. If it's checked, then if any hall has a problem for any reason, the PR will automatically transition to mode 2 (even if you've set a different mode).

If the system operates correctly set to mode 0, *and* that box is *not* checked, the sensors have to be operating correctly, as the PR will not fallback to sensorless in this mode (saw this in my testing with the v6 and the GMAC, and the v1 and v6 and the different Ultramotors).

If the box *is* checked, then a fault in the sensors of any kind will make the PR switch to mode 2 (sensorless).

BUT: If setting the system to mode 0 changes the behavior in a positive way, it means that the hall sensors *do* work, and the PR is not switching to mode 2 at least while that positive behavior is happening.

They might malfunction during the stutter problem, and that could be caused by connections, etc., and cause transition to mode 2 then, but a hall malfunction only under these startup conditions is more likely to be interference from high phase currents inducing noise on the hall signal, ground, or power lines that interfere either with their operation or with the controller's reading of the signals.

Are the motor poles set correctly?

If the motor poles werent' correct, it's fairly likely it wouldn't operate normally under any conditions, but it is reported to work normally except for these startup issues.

 

[E-HP]

Some analysis:


Side note: there is also a checkbox for "fault tolerant hall (fallback to sensorless)", which if unchecked, prevents the system from ever using sensorless mode if the halls aren't working as expected. If it's checked, then if any hall has a problem for any reason, the PR will automatically transition to mode 2 (even if you've set a different mode).

Question on the fallback; does it apply to running and startup, or just running? In other words, does the PR always fallback to sensorless startup when there is a hall issue, or will it not start the motor at all?

[0] appears to prevent running sensorless, but still appears to start sensorless. [1] appears to start sensorless and run sensorless. It appears that the PR is starting sensorless regardless of the settings, but wont run sensored, hence my question regarding the JST to HiGo adapter, since it appears that the halls are not working, but due to wiring (since the old controller works, and any mismatch, besides power, would be addressed through the learning function).

[0] Hall sensor: stutters then stops (appears to indicate sensorless start; run may be sensored or sensorless; mode 2 transition flag not set?
[1] Hall sensor start sensorless: stutters then runs (appears to indicate sensorless start; run may be sensored or sensorless; mode 2 transition flag may or may not be set.
[2] Sensorless: ??

 

[wingye1988]

Sorry all, Im a noob at this. I need a min to take this all in. What I do is set defaults to a Bafang g62 and then do auto tune, this is what it spits out.

 

[amberwolf]

I don't see any settings in the screenshots that jump out at me as specific issues that would definitely cause the problem.

I see a pole setting for the motor of 50. For a geared motor that number should be the number of magnet pairs x the gearing ratio. How many magnets does your G63 motor have, and what is it's gearing ratio? (might be available from Bafang) If it's different from the G62 (I don't know what that one is either), then the preset for the G62 wouldn't apply, and you'd need to manually set that prior to autotune. I suspect its correct simply because the system is working normally once you get past startup, but it's safer to verify and be sure.

Your PR battery current limit is lower (30A) than the KT (35A), so the PR will probably not have as much startup torque. I don't know what hte KT's phase current would be (it's not directly measured by the KT, so you can only guesstimate by whatever ratio the KT uses for that, if that info is available anywhere). The PR's phase current is set to 60A; I suspect you could leave it at the full current, but that probably depends on the gears in the motor and what torque they can handle; I don't know what that limit is.

I see that the fallback to sensorless is checked. If you disable this, and use mode 0 (hall sensors only) it will force the PR to use the sensors, and if it can't for any reason, to stop and provide a fault code (thru the PR software if you're connected to it, or blink codes with the onboard power LED if not). That might tell you if there's a sensor issue causing it to fallback to sensorless and try to start that way (see my next post for some info about sensorless startup issues that can happen).

The Autotune shows the halls should be working ok, but it's only testing them without any load, at low phase currents.


Can you reply with the other requested info as well? (or do testing that eliminates the need for it)

The screenshots help show us some of the settings, but don't tell us what you've tried to change so far or to what, or if you have setup the battery, throttle, etc. to match what your system is, whether you are getting voltage sag, or have a CA limit engaging, any blink codes, etc.

If the CA has any limiting setup, it could also be lowering any of the capabilities setup in the PR, as it won't send the full throttle signal thru to it if any of it's limits engage.

 

[amberwolf]

Question on the fallback; does it apply to running and startup, or just running? In other words, does the PR always fallback to sensorless startup when there is a hall issue, or will it not start the motor at all?

AFAICT it applies to any situation, but sensorless startup for many controllers (not just the PR) doesn't work very well under a number of situations, such as:

--geared hubmotors with freewheeling clutch; the motor may start and spin the wrong direction, the controller detects this and tries to spin it the ohter way which slams it into a loaded mode which may overcurrent the controller and shut it off, or cause it to

--high load situations (like on my SB Cruiser trike) with nonfreewheeling geared hubs, or with DD hubs, can cause stuttering startups as the controller tries to figure out the position of the motor, and wiggles it back and forth with various phase current timings and amounts, so it can know where the rotor magnets are relative to the stator windings and which direction it moves whenever it sends a pattern of currents. Because it can't ever know the position without moving the rotor, it has to do this every time when there's no sensors to tell it, and sometimes it's going to have a much harder time, when the magnets are in certain positions relative to windings, vs others.

[0] appears to prevent running sensorless, but still appears to start sensorless. [1] appears to start sensorless and run sensorless. It appears that the PR is starting sensorless regardless of the settings, but wont run sensored, hence my question regarding the JST to HiGo adapter, since it appears that the halls are not working, but due to wiring (since the old controller works, and any mismatch, besides power, would be addressed through the learning function).

The halls are getting power at least, and "working" or the autotune wouldn't leave it in mode 1***, it would only allow mode 2 (sensorless). (had this problem with the GMAC). (the screenshot the OP posted after your post also shows they're working). It doesn't mean they're working under all conditions...but they work with no load during autotune.


***(the default if sensors work is sensored start and sensorless run, since it's often smoother operation for a system; IIRC its' the default for Lebowski's brain chip too, but it's been too long since I was working on those so I'm not sure--but it is an available mode).

 

[wingye1988]

Im reading over all your input and Im going to tweak setting and test ride, ill see if I notice anything else.

I really appreciate all the knowledge being provided

Im using (2) 52V, 24Ah, LG4800 Cell in parallel and the RM G062.1000D to be exact has 20 magnets so 10 polar pairs and has a 5:1 gear ratio. (I said G63 on my original post, that was a mistake)

Are any limit flags in the CA diag screen capitalizing during the problems? I just took a look and noticed the throttle up ramp "F" and "D" flashing.

Have you tried setting the CA throttle mode to BYPASS to eliminate all CA operation and send the throttle directly to the PR unaltered, to ensure no CA limiting is causing the issue? Yes. its always ran on BYPASS mode.

How much battery current is the KT setup to draw, and how much does it actually draw under the same conditions?
My KT setup has no way of measuring current.

What blink code does the PR give during or after the problem? (if it has to be reset, there should be a blink code on it's LED)
The PR does not give any code and the red LED stays solid.

 

[amberwolf]

Im using (2) 52V, 24Ah, LG4800 Cell in parallel and the RM G062.1000D to be exact has 20 magnets so 10 polar pairs and has a 5:1 gear ratio. (I said G63 on my original post, that was a mistake)

Then it's not a pole issue, and highly unlikely to be a battery voltage sag issue.

Are any limit flags in the CA diag screen capitalizing during the problems? I just took a look and noticed the throttle up ramp "F" and "D" flashing.

The diag screen doesnt have an F or D limit flag, so you'll have to show me which screen you're looking at. (but see the next question's response before you worry about that).
https://ebikes.ca/product-info/grin-products/cycle-analyst-3.html#DisplayScreens
This is the diag screen, showing the AWSVT (amps watts speed volts temperature) flags, with watts shown as the limiting flag.

Have you tried setting the CA throttle mode to BYPASS to eliminate all CA operation and send the throttle directly to the PR unaltered, to ensure no CA limiting is causing the issue? Yes. its always ran on BYPASS mode.

OK, then the limiting flag stuff I noted above would never affect anything, and it doesn't matter what anything else in the CA is set to or setup as.

BYPASS mode on the CA throttle input means the CA doesn't do anything at all except act as a wattmeter/voltmeter/ammeter/speedo/odo. It doesn't do any throttle-related operations, so it passes the throttle from your actual throttle directly to the controller unmodified in any way (as if you had it plugged right into the controller instead of the CA).

Just to be sure, that's in this menu
https://ebikes.ca/product-info/grin-products/cycle-analyst-3.html#SetupThrotIn

How much battery current is the KT setup to draw, and how much does it actually draw under the same conditions?
My KT setup has no way of measuring current.

The KT does measure battery current, even if it doesn't display it on screen; there will also be a menu setting for what that current limit is, either directly or as a ratio of the max possible limit of that model.

Do you mean you don't have the CA setup so that it can measure the battery current on it's own with a standalone shunt (plugs only into the PR and uses the PR shunt for this)?

Either way, given the battery size/etc it's unlikely that the current draw is an issue (but knowing how much is drawn by each in the same conditions gives you a reasonably direct way to compare their performance, if you need or want that info).

What blink code does the PR give during or after the problem? (if it has to be reset, there should be a blink code on it's LED)
The PR does not give any code and the red LED stays solid.

Then there's probably nothing actually going "wrong" during startup causing the issue, just something that isn't setup the way it needs to be. At least, its' nothing that hte controller itself can detect, and nothing the controller itself is doing that it doesn't intend to do.

 

[wingye1988]

The F and D come up where it is labeled "throttle up ramp active". But you mentioned it should not matter because it's in bypass mode.

This is the previous setup I had made by KT, Upgrade Kit.

It's a separate screen and controller. The setup I have now is the motor and CA connected to the PA.

Like you said it may not be a "problem". I'm just used to a smooth acceleration and the stuttering is just annoying. It keeps me awake at night trying to figure it out. I preorderd the Grin 45mm Fat All-Axle Motor, so I'm hoping I won't have the same issue

I'll be messing with it tomorrow so I will let you know how that goes.

 

[amberwolf]

The F and D come up where it is labeled "throttle up ramp active". But you mentioned it should not matter because it's in bypass mode.

Right--in bypass mode it's a direct feed of throttle in to throttle out with no modification at all.

Passthru mode still applies limiting/ramping/etc, and allows PAS or torque sensors to work, but bypass doesn't.

Bypass is usually only used for testing, since most of the reasons for having a CA are to use it's throttle modification / limiting to customize a system's response to a rider's needs, or using PAS or Torque sensors, and bypass mode prevents any of that.

This is the previous setup I had made by KT, Upgrade Kit.

It's a separate screen and controller. The setup I have now is the motor and CA connected to the PA.

Yeah, we see a lot of KTs here (there's even OpenSource Firmware OSF available for versions of them, allowing for other options than the factory FW).

Like you said it may not be a "problem". I'm just used to a smooth acceleration and the stuttering is just annoying. It keeps me awake at night trying to figure it out. I preorderd the Grin 45mm Fat All-Axle Motor, so I'm hoping I won't have the same issue

As long as you tune the system to your specific parts, battery voltages, etc., then it should work with "any" motor on there (any that works with the KT should be able to be made to work "just as well" with the PR, at least hypothetically.

We already know your motor works, and your batteries, with the KT.

If you want to make the PR work like the KT, you can simply test to see what differences in behavior / supply / etc there are between the two under the same conditions. For instance, if the KT draws more battery current than the PR, then you'd need to figure out how to cause the PR to do that (or to stop limiting the current at that time, etc). But you'd have to measure that current, preferably with the same meter (the CA can be used for this with an external shunt, or there are cheap dedicated wattmeters, etc). And so on for other differences in properties between the controllers, vs differences in behavior.

You'd also want to explore what all the settings in the KT are set to, and what those settings mean in terms of system behavior under the conditions you're having issues with the PR. Then see if there are things in the PR equivalent to any of those specific settings that relate to the problem conditions, and set them incrementally in ways that vary the behavior under those conditions until it gets worse or better, until you tune out the problem.


I'm still working on understanding all of what the PR settings do, relative to physical motor behavior, so I don't have specific suggestions.


For instance, on my system, with the old Grinfineon (sort of like a KT with no settings) pulls harder at startup than the PRv1 settings maxed out on phase amps (but not battery amps). Even though the PR settings are actually higher than the GF's hardware limits, the PR doesn't actually draw that full current at startup the same way. I can probably make it do so but i have yet to get time/etc to experiment with it. I have a thread here for all that stuff, if you're interested in the eventual results:

Phaserunner startup issues (v6 and v1, each running an Ultramotor)

So...this is probably going to be complicated, and requires some explanation of the setup, both as it is now where it doesn't work right, and as it was before when it did work fine. So...apologies for the length. I'm very tired after working on this for the last 12+ hours, so I'll probably...

endless-sphere.com

Unfortunately because the GF doesn't have any settings to see or change, I can't even do what you can do with your setup to analyze the differences, I can only compare the external symptoms and behaviors (like battery current vs motor torque, etc).