Cycle Analyst cuts out the motor for no reason

[Fastolfe]

The e-assist installation in my velomobile is a Cyclone motor (with the internal Headline controller), a Cycle Analyst v3 driving the motor's throttle-in line, and a 24V battery.

The CA receives its inputs from a regular 5V hall effect throttle, a speedo pickup (reed switch) on the rear wheel, and a shunt on the power line. There's also a Cycle Analogger connected to the CA.

Up to now it was all working fine. But I've been having this weird problem for the past few days: every now and then, my motor cuts out for a split second. For instance, I'm at full throttle, the motor stops for half a second, then restarts. It restarts on its own, I don't have let go of the throttle or anything.

It seems to happen more when I'm accelerating, and/or at low speed, but not always: sometimes it cuts out in the middle of a long ride at full throttle.

At first, I thought it was the motor's internal thermal protection, but it can also happen when the motor is cold. So I took a look at the data log in my Cycle Analogger, and it turns out the culprit is the CA: when the problem occurs, the CA seems to drop the ThO signal temporarily. Additionally, while the motor is off, the CA seems to be totally confused with the bike's speed. When the motor restarts, everything goes back to normal.

Check out this video, in which I display the Analogger's data in real time. The problem occurs at 00:29:

http://www.dailymotion.com/video/x4cfkhz

Anybody knows what might be going on with my CA?

 

[cal3thousand]

It seemed to happen just as you crossed below 24V. Is there an LVC setting?

What version of CA? CAV3 will flash the area that is causing the cut out. If your battery voltage is flashing, that would mean LVC cutoff

 

[teklektik]

Take a look at the Diagnostic Screen when you get these 'limiting' effects.

In this case you should see the 'S' speed limiting kicking in which is a dead giveaway as to the cause. Similarly, check the flags in the Analogger data. (The speed limiting flag doesn't show up if the limiting is due to hard acceleration, but it should be asserted in this case where simple max speed limiting is likely in play...)

The Grin sensors are typically very reliable, but you can replace it with a magnetic reed pickup from any cheapo bicycle computer or a pickup using a hall sensor. In the latter case you can steal 5V from the throttle or Aux Pot connectors. Although they may require some slightly inventive mounting, you can also use just about any normally open hall effect magnetic proximity sensor - many can be had on eBay for a few bucks (search eBay for sensor examples). King Meter also makes a 3-wire hall effect speed sensor specifically for ebike use. At last look these were available from BmsBattery.

 

[Fastolfe]

Thanks Teklektic. Yes I did see that bit in the manual. There's only one problem: my CA isn't setup to do speed limiting. So even if the reed switch was bouncy, it shouldn't affect anything.

 

[teklektik]

There's only one problem: my CA isn't setup to do speed limiting.

No setup is required to get speed limiting - actually there isn't any means to disable speed limiting except to set an unachievable limit. The max configurable speed is 199mph/kph. Contact bounce typically yields speeds in the 600mph/kph range - way above the 199 limit.

What does your MaxSpeed Statistic read?
Are you getting a speed limiting flag? If not, what limiting flag are you getting?

 

[Fastolfe]

In my CA3, I could set MaxSpeed at 500 kph, and I also set IntSGain at 100, PSGain at 0 and DSGain at 0. That's what I meant by "it doesn't do speed limiting".

Looking at my Analogger log file, I can see 5 or 6 lines at 110+ kph in the middle of 6 kph speeds - and the resulting calculated acceleration on these lines is over 400 m/s2. Those lines have ThO dropping to the minimum instantly, and the timestamps match exactly the moment the motor stops.

Clearly it is due to the reed switch contact bouncing, as you suggest. Yet there's no S flag on these lines, and with 0 gain, the speed limiter should remain entirely unconcerned by the crazy calculated acceleration. That's what puzzles me.

 

[teklektik]

In my CA3, I could set MaxSpeed at 500 kph, and I also set IntSGain at 100, PSGain at 0 and DSGain at 0. That's what I meant by "it doesn't do speed limiting".

My mistake - you are quite right, the max speed is 500mph/kph by default. The other settings will effectively disable the PI controller as well - good move.

The serial log simply dumps the present speed, so it's possible that a transient speed limiting incident is simply not coincident with the logged sample. Rather than pursuing analysis at this time of possible means by which the CA might not properly log a speed limiting incident, I suggest that you simply displace the magnet or sensor and see if the problem is eliminated. In the end, the goal is to remedy your symptom and I am fairly certain that contact bounce is the cause - particularly since you have mentioned no other limit flags in play.

I will discuss with Justin and take a look at the code to see about stretching transient limit flags to ensure logging or display.

 

[Fastolfe]

I think you're right: it does come from the speedo pickup bouncing. I see the same thing in other log files too (crazy speed increase and the governor slamming ThO to 1V at the same time). Why the CA does this when it's setup not to? I'm not sure. But clearly the solution is to redo the speedo pickup.

Trouble is, in my bike, it ain't that easy You can see what it looks like here: http://www.dailymotion.com/video/x3hz95o

I presume the problem comes from the fact that the reed switch in my setup is installed in a horizontal position, so the blades probably vibrate with the rear wheel arm, and possibly resonate and touch each other on certain road surfaces. On a regular bike with the speedo pickup mounted on a front fork leg, the blades are vertical, so up-and-down movements don't affect them.

Incidentally, it would be nice to have a setting in the CA's speedometer menu to specify the minimum time between pulses manually: that way, it would ignore spurious pulses coming from a bouncy switch more easily for folks like me who run single pole pickups.

Anyhow, thanks a lot for your help. I appreciate it!

 

[teklektik]

Why the CA does this when it's setup not to?

Again - contact bounce incidents typically yield speeds in excess of 600mph - way above the configurable 500mph limit. This is not a case of the CA being set up 'not to'. Whether or not the reported speed happened to reveal the actual transient 'contact bounce' maximum speed is another issue. The displays and logging were designed to report relatively constant speeds, not to capture transient maximums from defective sensors.

I presume the problem comes from the fact that the reed switch in my setup is installed in a horizontal position...

This may be a factor, but these sensors just go bad so I wouldn't make too much of this on this first failure. If this re-occurs after replacement, then you may be on to something. Alternatively, just do as mentioned above and stick a hall sensor on it.

Anyhow - I think the issue is identified. Hope a replacement sensor gets you rolling again....

 

[Fastolfe]

I tried something and it seems to have cleared the problem: I set MaxSpeed at 500 kph, IntSGain at 100, PSGain at 0 and DSGain at 0 in my "legal" profile (I have this profile, with a hidden reed switch to quickly enable it, in case of a roadside police check).

Then I went for a ride with the "unlimited" profile, and the problem was gone. I took a look at the logs, and I could see episodes of crazy speed increases, but the with CA leaving ThO alone - as it should.

Then I reinstated the settings back in the "legal" profile for a 25 kph speed limit, and the CA continues to work as expected with the "unlimited" profile.

Strange, it seems the CA got confused between the "legal" and "unlimited" profile data, and merely editing the former seems to have removed the confusion. Now it all works good, even with the flaky speedo pickup.

 

[teklektik]

Good - but Odd.
(The gain settings a global - not per-preset -- only the speed limit should be in play and that doesn't seem to make sense...)

What software version are you running? (Splash Screen)

 

[Fastolfe]

Firmware version 3.0p13.

Anyway, I installed a hall-effect sensor this afternoon. So... problem solved - twice And as a bonus, I can do away with my script that filters out bad lines from my log files.

 

[teklektik]

Firmware version 3.0p13.

Okay - that's a pretty good version - the known issues would not account for the wonky behavior you experienced.

That said, you might like to take 3.1b3 for a spin - it has some display options (instantaneous Wh/mi, etc) that you might find interesting in your vehicle... It got a pretty good going-over by beta testers and has no reported issues (so - fewer than 3.0p13).

Good to hear you upgraded the sensor - I think going with the hall was a good choice for a high reliability solution.

 

[Fastolfe]

[...]That said, you might like to take 3.1b3 for a spin - it has some display options (instantaneous Wh/mi, etc) that you might find interesting in your vehicle... It got a pretty good going-over by beta testers and has no reported issues (so - fewer than 3.0p13).[...]

Mmmweeell, I might. But if I've learned anything in 25 years as a computer engineer, it's that working systems should be left alone. My CA works fine, and I'd rather be ready for my next tour in a month than risk bricking the CA - even if the risk is low. So... yeah, I might.

 

[teklektik]

aka "If it ain't broke, don't fix it."

If you're happy with p13, then by all means, keep on the steady path of no surprises...

I ride with 3.1b3 every day, and do like it, but the upgrades are to the display, proportional regen with a Grin controller, and some misaligned setup menu exclusion flags accessible in the Setup Utility - so - perhaps not compelling if p13 is filling the bill. CAs are very hard to brick, but in the case of b3 you would need to enter the whole config from scratch since the EEPROM format is different - PITA.

BTW - It does make a minor mod to the log format as well, so that would be an added small hiccup since you are collecting the serial data stream.

 

[Fastolfe]

I have to say, the Wh/mi display interests me: I'm a hypermiler when I drive the car, and I tend to do the same with my velo. That'd provide me with an additional display to gawk at instead of looking at the road when I ride But I suppose it doesn't interest me enough to go crawl under the velo and free up the serial port to do the upgrade.

I'd definitely do it if a firmware revision allowed me to integrate charging from an external source - such as a solar panel, in my case - and work out the actual SoC of the battery. I've already talked to Justin about that, but apparently it's not trivial, for hardware reasons. So in the meantime, I'll stick to what works I guess.

 

[teklektik]

...integrate charging from an external source - such as a solar panel, in my case - and work out the actual SoC of the battery. I've already talked to Justin about that, but apparently it's not trivial, for hardware reasons...

Sounds like you are looking to adjust the CA SOC/Ah to reflect opportunity charging (not full pack charge) - this is addressed in [strike]Un[/strike]official Guide: "6.10 Monitoring Charge Current".

BTW - For other readers - I added a link in the post above for a hall effect ebike speed sensor made by King Meter - available from BmsBattery. Should work fine and requires no finagling to mount, etc.

 

[Fastolfe]

aka "If it ain't broke, don't fix it."

If you're happy with p13, then by all means, keep on the steady path of no surprises...

I ride with 3.1b3 every day, and do like it, but the upgrades are to the display, proportional regen with a Grin controller, and some misaligned setup menu exclusion flags accessible in the Setup Utility - so - perhaps not compelling if p13 is filling the bill. CAs are very hard to brick, but in the case of b3 you would need to enter the whole config from scratch since the EEPROM format is different - PITA.

BTW - It does make a minor mod to the log format as well, so that would be an added small hiccup since you are collecting the serial data stream.

I upgraded to 3.1b6 today. Yep, re-entering the config was a PITA, but not as much as I expected.
It seems to work dandy, and the Wh/km display seems accurate. I like it!

The only small downside is, there was a bug in p13 that I liked, that has been fixed: in the second preset, it used to skip the splash screen entirely. That was useful to power up and get going in a hurry. Now I have to wait a couple seconds for the splash screen to go away. Oh well...

 

[teklektik]

The only small downside is, there was a bug in p13 that I liked, that has been fixed: in the second preset, it used to skip the splash screen entirely. That was useful to power up and get going in a hurry. Now I have to wait a couple seconds for the splash screen to go away. Oh well...

Glad 3.1 is working out for you. It has a bunch of user Interface stuff that folks requested from the gitgo, but that got postponed to get additional core functionality in place.

Gee - we weren't aware of the p13/preset2 splash screen hiccup. Interesting.

It's funny that you mention the absent Splash Screen display - we actually made changes fairly recently so that special versions of the CA could boot without it and still have a proper display (there was originally a bunch of initialization stuff being hidden by that display). I'll add an option for this behavior to the 'would be nice' list for discussion for the standard CA version. We are frankly running out of configuration room so triaging features can send good ideas to the undertaker simply as a matter of resource management...

 

[Fastolfe]

I'll add an option for this behavior to the 'would be nice' list for discussion for the standard CA version. We are frankly running out of configuration room so triaging features can send good ideas to the undertaker simply as a matter of resource management...

Don't sweat it, it really doesn't matter. The only times I appreciated the "instant boot" thing was when I hit a steep slope at high speed, thinking I could crest it on momentum alone, and then as I decelerated and realized I wouldn't make it, I'd quickly throw the motor's clutch, the power switch and slammed the throttle forward before stalling completely on the slope. It really doesn't happen that often.