Cycle Analyst V3 preview and first beta release

I can't find in this topic.
Does CA3 support variable regen?
If so how do I have to hook up?

My Kelly controller does have this feature, but it needs a ebrake signal to activate variable regen brake. Do I have to hook up ebrakes signals to CA3 and Kelly?


Thanks!
 
teklektik said:
Nope - good plan. Section "5.8 Powering the CA / High Voltage Vehicle Support" of the Guide discusses this setup and also recommends a settings strategy to ensure that data is saved properly on shutdown.

No personal experience with that particular supply, though....

  • It looks like it will do the job nicely with a DC input voltage spec right in the target Vbatt range - unlike the usual trick of using an AC mains adapter running at lower DC input voltage.
  • I'm not too sure about physically squeezing it into the case - but that's going to be pretty black and white when you get it in hand.
  • The only other consideration is waste heat from regulation, but since it's a switcher there should be little and you should be good. You are planning to take over much of the voltage drop normally accomplished with linear regulation by the CA so this looks good with reduced dissipation from the CA proper. Justin suggested in earlier conversations that there was likely some thermal dissipation capacity in the case for this sort of thing but that it actually had not been rigorously tested. We do know that Kepler was successful using a small dropping resistor in the case to get a little regulation headroom. His power dissipation was very modest but I'm thinking your supply will be even lower - Go for it.
Good find on the part...

Hi teklektik:

Thanks for the encouragement.

Although the project looks interesting, I would prefer to leave the CAV3 in its stock configuration if there is little chance of running into problems with my planned use.

Here's what I've got running on both of my bikes today (and their nominal loads as given in Section 5.9 of the Unofficial User Guide):

2 eZee e-brake levers (2mA)
1 eZee potentiometer (1mA)
1 Hall throttle (5mA)
1 King PAS pickup (10mA)
1 front wheel speedometer sensor (1mA)

According to Section 5.9 of the Unofficial User Guide, these accessories impose a load of 19mA. Added to the 10mA of the CAV3 itself, the total load is 29mA. According to the table, this load can be supported by the stock CAV3 up to a supply voltage of 48 Volts, which is a bit too low for a freshly-charged 14s LiPo battery.

I wish to be able to use up to 14s LiPo.

After some email exchange with Justin, he concluded that I do not need an external regulator for my application. He wrote that the accessories I have listed above can be supported by a stock CAV3 up to 60 volts. Further, he suggested that even if I were using a Thun sensor instead of the PAS pickup and wheel, I would still be OK up to 60 volts and that problems only emerge at higher voltages for systems using a Thun.

We haven't had anyone experience regulator problems running thun sensor, throttle, and aux pots with 48V nominal packs. With 60V nominal packs (~70V off the charger) then this has crossed the threshold.

Perhaps the chart is too conservative or the internal regulator has a bit more headroom than we assume.
 
mrbill said:
Here's what I've got running on both of my bikes today (and their nominal loads as given in Section 5.9 of the Unofficial User Guide):

2 eZee e-brake levers (2mA)
1 eZee potentiometer (1mA)
1 Hall throttle (5mA)
1 King PAS pickup (10mA)
1 front wheel speedometer sensor (1mA)

According to Section 5.9 of the Unofficial User Guide, these accessories impose a load of 19mA. Added to the 10mA of the CAV3 itself, the total load is 29mA.
...
He wrote that the accessories I have listed above can be supported by a stock CAV3 up to 60 volts.
...
Perhaps the chart is too conservative or the internal regulator has a bit more headroom than we assume.
First - thanks for the heads-up - always good to get input to fix up shortfalls in the Guide.

In this case, though, I think you did a little math misstep before the chart look up - you added in the 10ma for the CA itself, which is excluded from the chart. This gave you the overly conservative result. Here's a shot of the Guide section with some stuff highlighted.

AccessoryCurrentSnippet.png
Here we can see that the chart result of about 61V to 62V for 19ma coincides with the 60V specification in Justin's email. The calculation from which the chart is constructed (see image above) was Justin-approved before inclusion in the Guide to ensure we got the best estimate possible for users.

Again, thanks for the effort to get this squared away. Appreciated.
 
Ah, I see now that Iacc includes only the accessory currents, while I assumed it included the current draw of the CAV3 itself.

Thanks for the clarification. I feel even better now about saving myself the trouble of installing a third-party regulator. We'll have to leave this one as an exercise for someone running a high-voltage rig.

One niggle remains.

Justin wrote:
We haven't had anyone experience regulator problems running thun sensor, throttle, and aux pots with 48V nominal packs. With 60V nominal packs (~70V off the charger) then this has crossed the threshold.

His quote suggests that swapping out the King PAS sensor for the Thun sensor would still be acceptable with 48 volt nominal packs. That would put my Iacc up to 29mA and would according to the chart overload the regulator when supply voltage is over 48 volts actual.
 
Ya - quite right. Two or three things are in play there:

  • there IS extra headroom in the table - Justin estimated the 1500mw regulator capacity in the closed case with a bit of a safety margin. Specific examples that he knows work can lead to apparent inconsistencies
  • Some of the various accessory current contributions can be on the high side - in particular the devices that rely on a pull-up resistor in the controller or device (hall throttle, PAS wheel, ebrakes, etc). These resistors define the current draw. There is no way to know these actual resistor values so we use a conservative Wild Ass Guess for the current.
  • In particular, the table value for the Thun is from the official Thun spec. Justin's estimate is about 10ma less. I went with the spec. We discussed this in the context of the TDCM unit. Justin needs to do some tests and get values in which he has confidence - meanwhile, the Guide uses the published Thun value.
The best method is to do as the Guide suggests and verify the tabular estimates with an actual Iacc current reading for the desired suite of devices:

empiricalIaccTest.png
So - your observations are spot on. The Guide errs on the side of safety to ensure that no one has a mishap. The empirical test will certainly get you an accurate real world Iacc value to plug into the V+ vs Iacc table.

Documentation can be such a PITA.... :D
 
teklektik said:
The Guide errs on the side of safety to ensure that no one has a mishap. The empirical test will certainly get you an accurate real world Iacc value to plug into the V+ vs Iacc table.

And, that's as it should be. The table estimates should favor reliable operation rather than pushing the envelope of capability.

I was surprised that the apparent accessory limit when run at the rather common 48 volts nominal had not been raised before. So, I investigated further. And, as you point out I could have undertaken the minor hassle of measuring this myself.

I think one thing that would have prevented my error would have been to emphasize/repeat somewhere that the table of Iacc values does not include the current draw of the CAV3. A little repetition, perhaps in the table caption, would not be excessive:

Table of Maximum Total Accessory Current (Iacc) in mA vs Supply Voltage on PCB Pad +V
Note: Iacc does not include the 10mA current drawn by the CAV3 PCB.

teklektik said:
Documentation can be such a PITA.... :D

Yeah, but you do such a good job with the current documentation that we are motivated to improve it, even if only at the margins!
 
mrbill said:
I think one thing that would have prevented my error would have been to emphasize/repeat somewhere that the table of Iacc values does not include the current draw of the CAV3. A little repetition, perhaps in the table caption, would not be excessive...
I take your point. This particular section has led to questions in the past and has been re-worded more than once.... I'll have another go at it for the next release and review the accessory current estimates with Justin to get the table tuned up a bit.

mrbill said:
teklektik said:
Documentation can be such a PITA.... :D
Yeah, but you do such a good job with the current documentation that we are motivated to improve it, even if only at the margins!
Thanks!
Frankly, posts and problem resolutions by loyal customers have provided invaluable content and direction. Add a little secretarial duty and Voila!, The Guide.... :D
 
teklektik said:
mrbill said:
I think one thing that would have prevented my error would have been to emphasize/repeat somewhere that the table of Iacc values does not include the current draw of the CAV3. A little repetition, perhaps in the table caption, would not be excessive...
I take your point. This particular section has led to questions in the past and has been re-worded more than once.... I'll have another go at it for the next release and review the accessory current estimates with Justin to get the table tuned up a bit.

Maybe consider discussing the total current draw, including that of the CAV3. That's what I erroneously did when reading the table. It's also what one would measure directly at the plug.
 
BoomerChomsi said:
I can't find in this topic.
Does CA3 support variable regen?
If so how do I have to hook up?

My Kelly controller does have this feature, but it needs a ebrake signal to activate variable regen brake. Do I have to hook up ebrakes signals to CA3 and Kelly?


Thanks!


I dont know, but in a near future i will have the same problem :roll: lets see if someone can give you a bit of light :wink:
 
It has no variable braking function as far as I know, it is either brakes on / off. you send the brake lever signal in to the CA and it is sent to the controller to activate regen, or not. CA, when receing the brake signal, cuts throttle output too I believe.

So does the Kelly variable regen use a special a brake lever with a variable proportional signal output ?

Or how does the Kelly handle variable regen?
 
chucho said:
BoomerChomsi said:
I can't find in this topic.
Does CA3 support variable regen?
If so how do I have to hook up?

My Kelly controller does have this feature, but it needs a ebrake signal to activate variable regen brake. Do I have to hook up ebrakes signals to CA3 and Kelly?


Thanks!


I dont know, but in a near future i will have the same problem :roll: lets see if someone can give you a bit of light :wink:

The 'brake out' of the CA3 can currently be adjusted to whatever you want it to be (up to ~5V). This will then apply the set voltage to the throttle signal when you short the eBrake connection pin to ground on the 4-pin JST. So using a programmable controller, or one that enables variable regen over the throttle signal you can set regen set points via the CA3 brake out. At the moment there is no way to adjust the brake out voltage other than entering the setup. Adjustable brake out is on the list for new features.
 
Thanks for replies!

So I have connect E-brake sigals to CA3 and Kelly controller?
Kelly controller will also cut off throttle signal when it receive E-Brakes signals.

But I will connect variable regen (hall sensor throttle) to Kelly.

So it should be fine right? So this way it is redundant (CA3 and Kelly will cut off throttle when E-Brake is applied).
 

Attachments

  • ebrake.jpg
    ebrake.jpg
    65.5 KB · Views: 6,678
BoomerChomsi said:
So I have connect E-brake signals to CA3 and Kelly controller?
Kelly controller will also cut off throttle signal when it receive E-Brakes signals.

But I will connect variable regen (hall sensor throttle) to Kelly.
Yep - you need to connect the switched side of the ebrake (pin 4) to the Kelly as well as the CA. Without this connection, the Kelly will not energize regen. The other ebrake connection (pin 2 - Gnd) isn't necessary since the CA has a ground reference already from its primary power connection at the shunt. I'm not a fan of running multiple ground wires between similar points, but if you want to do so, you can run it to Kelly pin (20).

I haven't hooked up a Kelly, but I believe it should go like this for a V3 hookup (assuming you are using a larger external shunt). If you are using the smaller molded CA V3 External Shunt, it's pretty much the same except you pick up the Throttle and Speed connections from the shunt breakout cable instead of directly from the CA-DP connector.

CA-DP_V3Hookup2.png
I was sort of thinking that using one of gwhy!s cool hall throttle boxes with a brake lever would be a neat means to get variable regen instead of the second throttle. There's a few ways to go after this (dual cable lever for combined regular brake/regen, no regular rear brake, add ebrake microswitch inside throttle box to keep regular brake lever, stronger spring, etc) but it seems the core idea should work fine. Brake cable movement is much reduced over throttle action but since the Kelly has voltage (actually %) limits for the regen levels, so you should be able to compress the regen operating range to match the available lever throw - or if dual cable - to have the regen work before the real rear brake becomes effective. Just a thought... :)
 
Thank you soooooooo much!
I will follow your wiring layout. 8)

Yeah a good idea about the cool hall box, but for now I will use a normal thumb throttle. Due I have a lot of them in stock :mrgreen: :oops:
 
teklektik said:
BoomerChomsi said:
So I have connect E-brake signals to CA3 and Kelly controller?
Kelly controller will also cut off throttle signal when it receive E-Brakes signals.

But I will connect variable regen (hall sensor throttle) to Kelly.
Yep - you need to connect the switched side of the ebrake (pin 4) to the Kelly as well as the CA. Without this connection, the Kelly will not energize regen.


Is this the same for the Lyen 12FET controller? I still don't have regen working on my build....
 
liamcaff said:
teklektik said:
Yep - you need to connect the switched side of the ebrake (pin 4) to the Kelly as well as the CA.
Is this the same for the Lyen 12FET controller? I still don't have regen working on my build....
Yep - same deal. This requirement is discussed in the Guide in section "3.4 Important Conflicts with Controller Features" and the wiring is detailed in section "5.3 eBrakes".

You will also need to make some connections and perhaps re-program the controller.

  • Normally the controller BK/Gnd PCB pads are brought out of the controller as a pair of white wires that can be permanently plugged together or run to a button on the bars. If there are no white wires, jumper BK to Gnd on the PCB.
    When these are connected, both 'Throttle Regen' and 'Ebrake Regen' are activated. These two regen modes operate independently of each other.
  • "Ebrake Regen" is applied by jumpering the controller PCB EBS- pad to Gnd (or the EBS+ pad to more than 3V).
    EBS- and Gnd are brought out to the ebrake connector (yellow and black respectively).
  • "Throttle Regen" is disabled by setting 'Slip Charge Mode' to "Only Fake Indicate" (default).
    When enabled, zeroing the throttle will apply regen until speed drops to about 15% of full speed.
  • "EBS Level" sets one of three fixed regen levels (0:low, 1:med, and 2:high = default for 26" wheels) .
    Regen level is only adjustable by this programming - not by an external control.
  • "Regen Voltage" sets the maximum regen voltage to prevent battery overcharge. This should be adjusted according to your battery voltage.

 
There's no question how great the CA is, however, I wonder if this is the right place to add suggestions or is there thread else where for wish list of future features?

1. Same as the temperature control for the motor, it would be logical to have one for controllers too. So alternating the display between the too with
M 100
C100

would be amazing.

2. Instead of just total voltage, have a connector to allow various cell level display. Somehow in Justin magic code be able to display the lowest cell at all times. This would be way more important than showing overall voltage. It could alternate between the two?

T 86v
C 3.4

flashing and limiting would be amazing.


Just tell me if these are stupid ideas, and yes I know there are other products to do this stuff, but I just think having one display for everything an ebiker needs is better than 100.
 
I broke my cycle analyst version 3 a few weeks ago trying to externally measure a motors RPM by plugging a speedo sensor into the pedal assist plug. I wasn't getting results (needed to use 2 magnets instead of 1, why can I set it to 1 pole) so I decided to foolishly try a few other combinations in the plug, this shorted the linear regulator and broke a diode. I don't know which diode that is, any chance someone here can pinpoint where this broken diode it is and tell me which one to purchase on digikey so I might replace it? I e-mailed ebikes.ca a few weeks ago about this but I think they are on vacation.

Thanks
 
bowlofsalad said:
I broke my cycle analyst version 3 a few weeks ago trying to externally measure a motors RPM by plugging a speedo sensor into the pedal assist plug. I wasn't getting results (needed to use 2 magnets instead of 1, why can I set it to 1 pole) so I decided to foolishly try a few other combinations in the plug, this shorted the linear regulator and broke a diode. I don't know which diode that is, any chance someone here can pinpoint where this broken diode it is and tell me which one to purchase on digikey so I might replace it? I e-mailed ebikes.ca a few weeks ago about this but I think they are on vacation.
Thanks

Hey sorry about that. This happens often enough (people shorting out the 10V supply on the PAS plug) that I should really add it to the troubleshooting page. Unlike the 5V power for throttle etc., the 10V isn't really protected against overloads and usually the first thing to fail is just the reverse protection diode that is inline with the V+ input lead.
Linear Reg Schematic.gif

You can replace this with just about any surface mount diode, the ratings don't matter much but it will only have reverse voltage protection up to the diode's voltage rating. If you don't have a diode handy, then it's also possible to just bypass it with a short circuit. The CA will power up and work fine, but then if you were later on to connect the CA with reverse battery polarity it would no longer be protected and other things would fry.
Reverse Protection Diode Location.gif

It's probably not worth digikey ordering a single SMT diode worth about 10 cents, so if you have any conventional leaded diodes handed or can pull them from any old circuitboards you have around then you can see from the layout diagram above that it is easy to solder it to the large Vf pad and the main body tab of the D2Pak transistor Q1. You don't need to find something that fits on the smaller surface mount pads intended for D3.
 
John Bozi said:
There's no question how great the CA is, however, I wonder if this is the right place to add suggestions or is there thread else where for wish list of future features?

Yes, this is the right place, and you can also put in a feature request on the google docs here:
http://www.ebikes.ca/product-info/grin-products/cycle-analyst-3.html
down in the "features request and bug report" section at the end.

1. Same as the temperature control for the motor, it would be logical to have one for controllers too. So alternating the display between the too with
M 100
C100 would be amazing.

Unfortunately there is only one input signal available for the temperature sensor. It's quite possible to hookup a toggle switch to select between to different thermistors while riding, so you can choose which temperature you want to see, but the CA3 would of course only be able to do thermal rollback on one of them at a time. Usually controllers will have their own internal temperature sensor and rollback/cutout, while motors have no such protection, so sensing and reacting to the motor temp is more prudent.

2. Instead of just total voltage, have a connector to allow various cell level display. Somehow in Justin magic code be able to display the lowest cell at all times. This would be way more important than showing overall voltage. It could alternate between the two?

It's on the V3.1 release plan to show what the average cell voltage is like instead of just the net pack voltage. To actually sense the individual cell voltages would require the CA3 to be communicating with the BMS as the BMS circuit is the only item on the ebike aware of per-cell voltages, and as there is no standard at all for BMS communications it's a tall order to offer this feature in any universal capacity. Plus, when you have a BMS, you don't really care about individual cell voltages as a) they are almost always exactly the same anyways, and b) the BMS will already look after protection and pack cutout if there is a low cell.

I imagine most people wanting per-cell display are riding DIY packs without a BMS circuit, and the real answer to that is "get a BMS circuit!". Perhaps it's not the ES way, but its definitely the right way.

Just tell me if these are stupid ideas, and yes I know there are other products to do this stuff, but I just think having one display for everything an ebiker needs is better than 100.

Not stupid at all, the dual temperature could and likely would be done if there were more available IO pads, but the per-cell readout would involve designing and making a separate product (level shifting cell monitor that communicates with the CA3), which isn't in the cards in the near future. We came close to going down that path 3-4 years ago, but I'm convinced that all packs should simply have a BMS in the first place.
 
justin_le said:
Unfortunately there is only one input signal available for the temperature sensor. It's quite possible to hookup a toggle switch to select between to different thermistors while riding, so you can choose which temperature you want to see, but the CA3 would of course only be able to do thermal rollback on one of them at a time.
Assuming the only reason for having the CA monitor the temperature is for thermal rollback, then a small external module could be made (op-amps?) that compares the signals and feeds only the highest one to the CA, with an LED (or pair of them) on it to indicate which one it's feeding thru.

This would let teh CA be able to control based on two (or more) separate thermal sources, albeit only the highest one at any moment.
 
amberwolf said:
This would let teh CA be able to control based on two (or more) separate thermal sources, albeit only the highest one at any moment.
but this would only make sense if the two temp limits were the same. if your controller limit is 90°C and your motor is 120°C you will never be informed about a cooking controller. :(
 
OK, back on the train again.

I've got the CA3 Prelim7 firmware available for download here:
http://www.ebikes.ca/downloads/CA3_Prelim7_NoEeprom.hex

This firmware has no eeprom parameters defined in it, so you can reflash your existing CA with the above code and all of your settings, calibrations, and stats will be preserved unchanged. I've got at least 85% of the bug fixes and minor feature enhancements implemented which were on the agenda to say it's the final 3.00 release.
CA3P7 Fixes.jpg

Most of the changes you won't really notice since they are special cases, but there are 3 that are of some note:

1) Implementation of a temporary Aux Display readout

When you have an Auxilliary input enabled for limiting, then whenever the Aux voltage changes more than a small amount it shows this on the screen so you know what the new limit setting is at. Then after a few moments it goes back to showing whatever screen you were just on. This makes it a lot more clear where things are at, especially if you have a proper potentiometer knob which doesn't have an accurate indicator dial.
AuxAdjustPreview1.jpg
AuxAdjustPreview2.jpg

2) Re-enabling of Quadrature Mode
At one point in the development the I disabled quadrature detection because I assumed it was part of the problem causing occasional PAS assist cutouts. However, it meant that with a quadrature style PAS sensor (like the THUN, TDCM, or the CA3 compatible KingMeter pickups and 12 pole magnet rings) then there were a few locations where you could rock the pedals back and forth ever slightly and the CA wouldn't be able to distinguish that from actual pedalling, and in some cases it could cause a brief burst of power in PAS mode when your feet are dangling and not turning the cranks.
With the quadrature signal detection enabled (renamed to the 2-wire option), then no amount of shaking the pedals anywhere can cause a false PAS reading and this glitch is fully removed.
Quadrature re-enabled.jpg

3) Better Throttle Fault Detection
The CA3 now treats it as a throttle fault condition if it sees the throttle higher than the MinThrottle when first turned on, or if exiting a setup menu. This is cleared the moment the throttle is brought down below the MinThrottle value. Similarly, if the throttle ever exceeds the Throttle Fault voltage, then it will only be cleared when the voltage is brought down to the MinThrottle again, wheras before once it fell below the FaultVoltage it would engage again. And finally, if the fault throttle is set lower than the max throttle, then the max throttle voltage detection is ignored. So this means that people using a potentiometer throttle that goes all the way to 5V don't have to worry about it causing a throttle fault error right when they hit the full throttle. Also, in the diagnostics screen, the actual input voltage flashes when it is in a throttle fault condition so that you can see what's going on, in addition to the throttle bar on the main screen flashing too.
View attachment 2

4) Throttle Noise Immunity
One of the main unexpected sources of troubleshooting has been people setting their throttle input minimum voltage very close to the actual voltage when the throttle is off. In principle this would be fine to eliminate any dead zone in the throttle action, but in practice there was often enough electrical noise on the throttle signal when the bike was powered some signal glitches would bring level above the minimum voltage. If the ebike was being ridden in a PAS assist mode, then the CA would think momentarily that the user was pressing the throttle at a very slight level, resulting in the PAS assist cutting out (since it's now in throttle control mode) and then having to ramp up from zero again. This has been totally fixed in the current firmware so that small throttle noise events won't cause a PAS cutout. I still recommend having the minimum throttle input at least 0.1V higher than the actual throttle off voltage just to have some margin, but if you do push it tight (even within 0.02V) it doesn't seem to affect the PAS operation anymore.

If it's possible for beta users to flash this latest firmware and possibly find any new bugs or glitches it could have introduced that'd be great, i've done more than a few trips around the block with it but haven't explored all the edge cases. I'm going to be tackling the last two remaining things (occasional power surge on releasing ebrakes, and software immunity against speedometer sensor glitches) in the next couple days and could integrate any other small fixes too.
 
Hey Justin:

Thanks for releasing a new firmware.

With regard to ticket #10001, the throttle burst upon reapplication of power occurs most often when pedaling continues (e.g. "soft-pedaling") while braking briefly for more than 1 second but for less than 3 seconds. Likewise when pedaling and under power mediated by PAS, if one stops pedaling, power continues for another half second or so, then stops. If pedaling is resumed within 3 seconds, a throttle burst occurs.

It feels like the CAV3 is ignoring the prior assist factor (set by aux pot) or throttle ramping when power is re-applied after a 3-second break in pedaling or after a 3-second application of the e-brake.

This problem is particularly noticeable since I use PAS with a mid-drive, often at low power (e.g. <400 watts). The power surge slams the clutch in my mid-drive and over time this mangles the tiny springs behind the rollers that lock the clutch. I am really hoping you can observe and correct this as it is the "roughest edge" remaining in the firmware from my perspective.

(The other rough edge, a minor nuisance, is the wide hysteresis of the speed limit when approached from above the max speed. If decelerating through the max speed, resumption of power is delayed unless one is decelerating very slowly. E.g. if max speed=20mph and bicycle decelerates quickly from 25 mph through 20 mph as when a downhill is following by an uphill, power might not be applied until speed is down to 15 or 16 mph and momentum lost. PSGain=0.85v/mph, IntSGain=200, and DSGain=200. The parameters were tweaked for approaching the speed limit from below.)

It would be nice if PAS-mediated throttle signal observed the throttle ramping parameters. I'm using up-ramp of 3.5v/sec, fast-ramp of 5v/sec and down-ramp of 40v/sec. Amps feedback gain and Power feedback gain are both "50". When using the throttle, I don't get any surges or slamming of clutches, while throttle and power application are still subjectively quick.

Lastly, I should note that my throttle is connected through the CAV3, and that my controller is a Lyen MKII controller, compatible with the CA V2. To allow the throttle signal on the CA DP (direct-plug) to control the throttle signal on the controller without modifying the wiring of either, I set the controller's throttle "high" (5v) to invoke a fault condition on the controller using a shorting plug. The CA overrides the fault condition by pulling the controller's throttle signal down through the ThO on the CA DP. This is described in method #2 in the following post:

http://endless-sphere.com/forums/viewtopic.php?f=4&t=37964&p=608858#p608858
 
Hi Bill and thanks for the quite detailed diagnostics information.

mrbill said:
Hey Justin:
With regard to ticket #10001, the throttle burst upon reapplication of power occurs most often when pedaling continues (e.g. "soft-pedaling") while braking briefly for more than 1 second but for less than 3 seconds.

This behavior should be somewhat better in the P7, but I know what to do to make it work perfectly.

It feels like the CAV3 is ignoring the prior assist factor (set by aux pot) or throttle ramping when power is re-applied after a 3-second break in pedaling or after a 3-second application of the e-brake.

What's actually happening is that the power feedback loop is still attempting to output a higher and higher signal if you pedal during the ebrakes (which separately forces the output low) and then on releasing the ebrakes there is a built in "wind-up" in the feedback term. The up-and down ramp rates are always being followed, but you have them set so high that it's not having much effect. I think that's why I haven't noticed this since I've typically had a much more subdued up-ramp, and with hub motors I don't think an overshoot is felt with quite as much kick.

(The other rough edge, a minor nuisance, is the wide hysteresis of the speed limit when approached from above the max speed. If decelerating through the max speed, resumption of power is delayed unless one is decelerating very slowly. E.g. if max speed=20mph and bicycle decelerates quickly from 25 mph through 20 mph as when a downhill is following by an uphill, power might not be applied until speed is down to 15 or 16 mph and momentum lost. PSGain=0.85v/mph, IntSGain=200, and DSGain=200. The parameters were tweaked for approaching the speed limit from below.)

Ha yes, this is part of the asymmetric control problem (CA can apply power to speed up the bike, but has no ability to control the deceleration rates) and I'm glad you reminded me of it since there may be some room for algorithm changes to better cope with that. If you do increase the DSGain to a higher value though you should find that the situation is improved, as then it will sense your rapid deceleration and attempt to increase the throttle output accordingly.

It would be nice if PAS-mediated throttle signal observed the throttle ramping parameters. I'm using up-ramp of 3.5v/sec, fast-ramp of 5v/sec and down-ramp of 40v/sec.

Try in this case having your standard up ramp at 1V/sec, and if you find that it is switching from the fast to the standard up ramp too soon then either increase the fast ramp current threshold from 3A to more like 5 or 6A, OR reduce the fast ramp rate a bit so that the current draw of the motor as it is ramping up to an RPM that engages the drive chain is less than the current threshold. You want the throttle to quickly reach the voltage where the motor RPM is now matched to the drivechain RPM, and then take a slower path from that point on. 3.5 V/sec may not seem too fast, but given that at a given RPM the controller goes from no current to max current over about a 0.3-0.5V span (depending mostly on the motor's winding resistance), it means that the effective time to go from zero to full power is on the order of 0.1 seconds. That's not a whole lot of time for the CA to respond in.

Lastly, I should note that my throttle is connected through the CAV3, and that my controller is a Lyen MKII controller, compatible with the CA V2. To allow the throttle signal on the CA DP (direct-plug) to control the throttle signal on the controller without modifying the wiring of either, I set the controller's throttle "high" (5v) to invoke a fault condition on the controller using a shorting plug. The CA overrides the fault condition by pulling the controller's throttle signal down through the ThO on the CA DP.

This should all be OK and ought not have any effect on the control scheme or performance. Let me know if subjectively things improve with the suggestions posted above and I'll work on addressing some of the key algorithm issues to optimize things further.
 
Back
Top