Grin Bafang G311 motor cutting out

[ErnieLehman]

Hello,

I have a brand new Bafang G311 kit that I purchased from Grin. I got it installed with their 10AH 36v bottle battery, standalone Baserunner contoller, and Cycle Analyst.

As soon as I got everything installed, with wheel circumference, poles, and PAS information set, the bike gets intermittent motor cutout, both with pedal assist and throttle. The CA does not power down, the motor just kind of blips off for an instant.

The speedometer is very erratic, moving so fast that it's hard to even register what speed is displayed. When I went to the "max speed" screen, I saw readings that would vary from 75-300mph. On the diagnostic screen the speed limiter was almost always capitalized, though I would estimate that I never got over 18mph. I've been through the settings several times and have tried the following hardware and software diagnostics:

-Tried second motor (I have another brand new G311 kit on hand)
-Tried second CA
-Tried second controller/battery (Reention downtube battery). This made it slightly better, but cutout still happened
-Adjusted Max Speed and DS gain values up and down. With the DS gain set to zero the diagnostic screen no longer popped a speed limiter, instead the power (W) began popping
-Adjusted Max Current, gain, Max power, gain settings up and down
-Confirmed integrity of Anderson connections to battery cradle

All these have been unsuccessful. I am concerned that this is somehow an ultra-noisy signal issue that I frankly am unsure how to rectify. I've done lots of ebike conversions but this is the first time venturing into the complexity level that the CA/Grin offers. I had hoped that their ready to roll kit would be a bit more...ready to roll but this has turned into a real head scratcher.

Thank you!

 

[amberwolf]

The symptoms indicate a speed sensing issue, and the speed limiter is triggered and so cuts the throttle signal to the controller which would cut off motor power during the event.

None of the settings should be a cause for a highly-variable signal like you are seeing--that's a hardware problem.

Usually this is a connection fault between the motor and the controller or the controller and the CA.

Were all the connections changed along with the parts that were swapped to test things?

It could be an electrical noise issue on the hall signal; there are two possible speed sensors that can be used in a geared hubmotor; it can be the separate speed sensor that reads a magnet on the shell (usually a six-pole sensor), or it can be one of the hall sensors in the motor itself. if it's presently using the motor hall, changing over to the shell sensor could fix a noise issue if it's induced noise into the sensor itself from stator fields.

Noise like this usually only happen during high currents, so often goes away in an off-ground test. But both sensors (all the non-phase signals) should be inside a shielded portion of the cable to minimize this, for the cables i've seen on Grin-supplied motors so far. If they're not, then induced-current noise is more possible.

Also, some motors have multiplexed temperature/speedsensor signals, which could cause problems reading a speed sensor in some cases (though the BR should be capable of reading that and demultiplexing it correctly; I don't recall if the CA can).

Does the speed sensor pass thru the BR on the way to the CA? (usually it would)



if it's an RTR kit from Grin directly, then it should have correct settings for everything, so you should be able to leave all of the built-in settings as they are, if it was correctly programmed in boht BR and CA from Grin. They do provide support for the RTR kits, so I'd also ask them about this issue in case they have suggestions based on experience with the entire kit.

 

[ErnieLehman]

Thanks so much for the detailed reply. I did get the kit directly from Grin. I've got a request in with them, from my experience thus far their support is good but can be a bit slow (I'm sure they get a ton of requests) and I was hoping to get this rolling as soon as possible as it's been a bit of a process to get to this stage. To reply to your points:

Each component was disconnected/reconnected using the fittings that were installed from Grin, I did not rewire any with brand new connectors (I assume that Grin's connections are probably better than what I could do on my own). Not sure if using a dielectric grease on any of them would make a difference?

From what I understand the G311 uses a shell mounted speed sensor, which is wired alongside a temperature sensor. From Grin: All the G31x motors at Grin now have a dual speed/temperature signal on the extra white wire, rather than just a simple speed sensor. Our Baserunner_Z9 motor controllers decouple this signal so that you can now see motor temperature on the Cycle Analyst display and use thermal rollback to prevent the motors from overheating even when used well beyond their nominal power.

The speed sensing issue does occur in both real-world riding situations AND "off ground" tests, so the high-load characteristic is not one I'm seeing. If I read your reply correctly it seems that would point more toward a connection issue?

 

[amberwolf]

It sounds more like a connection problem (which can be within the wiring itself, not just at the connectors) if it happens the same under loaded and unloaded connections.

But if all the connections were swapped out with the parts themselves, meaning there aren't any connectors or cables that remained the same between the various testing setups, then this is also unlikely.

Dielectric grease should not change a connection, but it will keep water out of a connector; it's unlikely to fix this problem if is actually a contact-to-contact issue.


Is it possible that either the BR is not decoding the signals and sending them completely separated to the CA, or that the wiring of the BR or harness is incorrect such that the still-multiplexed signal is being sent to the CA?

Is the problem consistent in it's intermittentness, or random, etc?

If it's consistent, then finding hte specific conditions that cause it to happen will help find the actual root cause.

For instance, if it happens only at low motor temperatures, or only at high, then it's more likley to have something to do with the multiplexed signal.

Or if it only happens when above or below a certain wheelspeed, etc.

There is also the extremely unlikely possiblity of a bug in the CA firmware. This can be tested by backing up the settings you have already (I recommend saving as a file via the CA setup software, *and* taking pictures of every screen in the onboard setup menus), and downgrading or upgrading the FW to the prior or next version, and re-inputting your settings back into the CA. (the main reason for the pictures, since you may not be able to load the file and upload into the CA with a different FW version tahn they were saved from).



If it's truly randomly intermittent, it's much harder to narrow down, but that also makes it much more likley to be a connection fault.


Side note: with a wheelspeed sensor that's mounted on a frame or fork, and a magnet on a spoke, the distance between them and even the angle of the sensor can sometimes cause this type of problem--but unless there's a batch of badly built motors I don't imagine this should be true of the internal speed sensor, since two separate motors have shown the same fault.

 

[ErnieLehman]

Copy that. I would describe the problem as random, I haven't been able to tie it to a specific set of conditions. It's most noticeable when using the throttle, but I think that's just because there is not pedaling input to "smooth" out the power dropoff (it definitely still happens on PAS modes) I haven't ridden the bike long enough to really get the temperatures up; my procedure for conversions is generally to mount things temporarily to get bugs worked out/allow easy component swapping before getting everything really tied down, so it hasn't been out for a longer ride.

Re: the Cycle Analyst firmware being wrong, I did not get the programming cable so I can't do a ton of "under the hood" tweaking on that (again, thinking this would be ready to roll). With that said, I DID try two CA's, so unless both were bad that wouldn't be it.

I'm going to go over my connections again this morning, thinking back one potential area for issue may be the 9-pin motor extension cable. I did try two different cables but the one I've been using most recently is not a Grin-supplied cable. Perhaps the shielding on it is not up to par for the multiplexed cable. I think I'll see if I can mount the controller in a place where it can be plugged directly into the motor and try from there.

 

[ErnieLehman]

One other piece of information to note: my plan was to stow the baserunner in a small frame bag along with some of the excess cabling. I've mostly been riding with the baserunner zip tied to the frame (again, to ease troubleshooting) but have had it in the bag once or twice. It appears as though the speed numbers got particularly erratic in that arrangement, that is when I started seeing maximum speeds in the 250-300 mph range. Not sure if that indicates the noise is indeed coming from a bad cable connection, made worse when the excess cable is coiled up in the bag?

 

[ErnieLehman]

Okay, working on this thing some more this morning: I've eliminated the motor extension cable and done some more testing.

With that out of the system the motor gives stable speed readings when doing "off the ground" runs, it pegs it right at 28mph and stays there. But, when riding the bike, the erratic speed readings and motor cutout return. So definitely higher current exacerbates the issue.

 

[ErnieLehman]

At the risk of sounding like I'm shouting into an empty room, more points of interest (typing them up it helps organize my thoughts):

On the diagnostics screen the CA was throwing a speed limiter signal. I think that was due to the erratic speed readings, I found on another thread here reducing the DSGain setting would eliminate that. It did.

From there, the CA no longer threw a speed limiter, but it began showing a power (W) limit. The CA was set to a 700W limit. I adjusted that up to 1700.

Now, the bike doesn't show any limiters, but it still gets motor cutout, especially when using the throttle. At this point I'm willing to live with the signal noise in the speed sensor if I can just get it working smoothly. Is there a chance the cutout issue could be related to a battery connection somewhere? Like when the system asks for more power there's some sort of bottleneck that says "no"? I assumed if it were a power supply issue the CA would likely power down, but that hasn't been the case..

 

[tnoller5972]

In my case the fix for me was disabling the speed limiting function of the cycle analyst. If you look in the unofficial user guide this is done by putting I gain to 100 D gain to 0 and P gain to 0. This will get rid of cutout when high speed readings occur but it won't fix the high speed readings under acceleration.

 

[amberwolf]

If there's no limiters in the CA that are engaging, even briefly (too brief to see on screen), but the motor is still cutting out, then it's probably a limit in the BR. Does it have any speed limits, etc., set in it?

A voltage drop sufficient to cause motor cutout should be logged by the CA in it's Vmin field. Compare the Vmin to the CA's LVC, and to the BR's preset voltage limits; if the Vmin is higher than those limits, it's not that.


FWIW, the CA outputs a continuous stream of data (which you can choose what data is sent), so you could theoretically log all that in a terminal program on a laptop, tablet, or phone (if they have a serial port), and examine it for glitches, etc. in the throttle output the CA says it's sending. If the throttle drops when you know it shouldn't have, and was at the same time as a motor cutout, the the CA is indeed still limiting even if it's too brief to see.


Another method to ensure the CA is not causing the limiting is to directly connect your throttle to the BR, either physically or by setting the CA to BYPASS mode, which directly sends the throttle signal from input to output, unaltered. (note that if the CA was scaling the throttle for the BR you'd need to change the BR's settings to match the new actual throttle scale).

 

[ErnieLehman]

OK, back at it (still awaiting a reply from Grin) but this is what I've gotten:

-Eliminating the speed gain restrictions seemed to clear up or at least greatly reduce speed limit flagging, in spite of the speed readings still behaving poorly
-Similarly eliminating the power restrictions also cleared up or greatly reduced the power limits

In spite of this the motor is still cutting out. Thinking about amberwolf's last post it seems more and more likely that the issue is coming from the BR than the CA. I tried the bypass throttle mode and the issue persisted, so it sure seems like the BR is the problem.

It occurs when accelerating from low speeds to medium speeds. From a dead stop the motor pulls you up to 3-5mph smoothly, then jolts once or twice, then once you're cruising it feels very smooth and natural. It's most pronounced when just using the throttle, but on the higher PAS settings it will do it too.

My thought is the Baserunner came configured to with some sort of limiter - maybe even like a max 5-second current figure (hence the delay in cutting off until I'm up to medium speed). That limit seems to be pretty unrefined, like it hits the limit and just cuts the power altogether for a moment before resuming.



The CA's limits seem to be much more...reasonable in how they operate, like it allows the system to reach the limit then plateau instead of jolting the motor off then back on again. I'm hopeful Grin has some information for me today, one piece of advice for anyone looking at this thread down the line is to get the programming cables, even if the kit has been touted as "ready to roll".

 

[ErnieLehman]

Does the Baserunner have any limits built in based off of the speed signal from the motor? I've slowly stepped the current and power limits down on the CA to see if I can hit a limit on the CA prior to whatever is cutting out at the BR level but haven't found anything that works..I'm wondering if that erratic speed sensor is triggering something?

 

[tnoller5972]

Sounds like the next thing for you to do is to take a day to adjust the current regulator bandwidth settings. If everything has been set and it is still acting up it's most likely those settings aren't proper. You can have settings there that will work but trying to pull power with a load will cog and maybe throw a fault.

Try adjusting ppl bandwidth, ppl damping and current bandwidth.

This is what I had to do even with a motor I got from grin as it was relatively new to their line up and I guess the values weren't as good as they could have been. This gave me hiccups where the motor would cut out and ramp back up all while holding WOT. After they updated the parameters it runs much smoother and no more cutouts. Even though I'm running it well above it's ratings. The motor is shengyi sx2 btw.

 

[amberwolf]

Does the Baserunner have any limits built in based off of the speed signal from the motor?

You'd need to run the Phaserunner setup software, connect via USB-serial to the BR, and read it's settings to see what it actually has setup for limiting. Then before you change anything, save the entire setup as a file, choosing to save all settings (not just motor, etc).

I've slowly stepped the current and power limits down on the CA to see if I can hit a limit on the CA prior to whatever is cutting out at the BR level but haven't found anything that works.

Since youve already established there is an issue with the system cutting out when the CA is not in the control loop, you need to leave it out of the loop and resolve all of the other issues first, and *then* tune the CA as a last step once the rest of the system works the way you need it to via throttle-only.

If you try to do the CA tuning in parallel with other tunings, it is probably going to take you a VERY long and frustrating time to do this.

.I'm wondering if that erratic speed sensor is triggering something?

If you have any sensors not working correctly, then before you can tune the system you have to either fix the sensors, or bypass them by using a different version of sensor to get the same data.

Or disconnect the sensor entirely to remove all of it's spurious data, and turn off any control loops based on that data.

Otherwise you may have things you are tuning out that are actually data problems, and once the sensor is fixed the system may not work correctly (and/or once tuned around the problem, it may not do what you need it to do).


For the speed sensor, you can try using one of the motor halls instead of the combined temperature/speed sensor, disconnecting the combined sensor, and changing the BR setting for which speed sensor port it uses so it reads a hall instead. Or use an external frame-mounted sensor with magnet(s) on the wheel. That signal can go right to the CA and not pass thru the BR at all.

 

[ErnieLehman]

Copy that. I think until I get a programming cable or a compatible external speed sensor I'm just pounding smoke, as my old man would say. I did hear back from Grin, we're working through some of the same things outlined here.

For now I think I'm going to get this thing on the road as it does ride quite well with in pedal assist mode, which was the main aim for this machine. Once the cable is procured/plugged in I'll circle back with any enlightening findings!

 

[ErnieLehman]

FYI, from Justin @ Grin:

"Hey Ernie

This situation was just brought to my attention. From reading the ES thread it certainly appears like you have a situation where the 6 pulse speedometer signal is mostly behaving just fine but that occasionally it is susceptible to electrical noise or an intermittent connection or something that is resulting in a much higher than proper pulse frequency. There is a known EMI noise issue with the GMAC motors specifically where a similar thing can occur at full throttle and very low bike speeds, but we've not yet seen that in the G31X or other motors that use an internal speedometer so this is highly interesting for us to dig deeper into.

In general the effect of a speedometer glitch can be nullified by setting DSGain and PSGain to 0, but the controllers also have by default a max speed limit (set to 99 kph) and if that is exceeded even briefly then it would result in a brief controller cutout too. We can easily disable this behavior with an update to the baserunner parameter settings and get a USB->TTL cable in your hands to do that and the power will then always be smooth, but it won't solve the fact that you will still see occasional glitches of high max speed on the CA3."

The full throttle/low speed characteristic is fairly accurate in describing the most common circumstances my issue was occurring under. After much faffing I got the bike out in the field using the settings in the CA. The person who owns the bike (not me) gave me a big smiley hug after the first test ride - while we all want everything to be perfect sometimes good enough is good enough. Once I get a cable here I'll remove the controller speed limiter and we should be all set.

Moral of the story? If you're thinking about getting one of these kits, GET THE CABLE TOO! Also from Grin after several emails back and forth:

"I wish that bloody cable were a mandatory purchase."