Cycle Analyst V3 preview and first beta release

Hi Tek. I have a question regarding regen braking. My older bike does not have a proportional regen capable controller. However I want to use the new TripWire e-brake switches through the CA. Is it possible to set up the CA so that it signals the controller to engage old style infinion regen braking? Or will I need to run my TripWire cables down to the controller? Thanks.
 
Obiwan007 said:
My older bike does not have a proportional regen capable controller. However I want to use the new TripWire e-brake switches through the CA. Is it possible to set up the CA so that it signals the controller to engage old style infinion regen braking? Or will I need to run my TripWire cables down to the controller?
Hey Obiwann!
I'm really liking the way your Tripwire product worked out! :D

As far as the CA is concerned, because of the controller you are pretty much strapped to the simple ON/OFF ebrake/regen feature w/o proportional control. Either of the schemes, case 2 or case 3, on page 35 of the Unofficial Guide are your two best options. The CA adapter (CA3_Adapter) uses nomenclature that suggests it's somehow related to CA2 legacy stuff, but it really just splits the throttle and ebrake signals out of the CA ThrottleOut signal. You can use the 'ebrake' signal (closure to Gnd) as an ebrake, regen, or both signal and can run the throttle signal into the throttle directly or into a CA-DP connector of a CA3 compatible controller.
 
Thanks Tek, I got it. Really I just wanted to confirm that none of the new regen features in the update covered this directly. It will be no problem running one wire so I'll try that first.
 
justin_le said:
Nope, it'll be fine. What you actually want to do is leave the white LED jumper soldered together, then hook up two wires to a simple toggle switch or button which will short out the red LED pads. When the switch is closed, both the red and the white LED's are in parallel, but the red LED's have a lower forwards voltage drop so they'll take all the current while the white LED's won't have anything flowing through them. When you short those two wires with a switch, the backlight will go red, and when you open the switch it will revert back to white.

That would actually be really cool to see a CA set up like this with a simple day/night selector switch so I encourage you to open it and perform the simple wiring mod. There is room inside the CA enclosure for the body of a small toggle switch so it would stay self contained.

Glad this info popped up because I've been wanting a dimmer screen for night use for a while.

Super easy hack to make.
My CA is mounted in a mini-console so i just ran a pair of wires from the led pads on the board, outside the case, to a slide switch mounted in the console.
Works just as Justin describes.

The red lights are bright enough to see during the day and at night they're just right.

Thx
 
Hey Tek, got this all hooked via case #2 like you suggested and it works perfect. The wiring was made extra simple due to the pig tail on my TripWire :wink: Thanks a million.
 
I bought my CA3 I'd say 2-3 yrs ago, I havent done anything with it. No updates or anything. I know I have to update it. Would the cable required to do it come with the CA when I bought it, or do I need to buy it? The reason I ask is because Im putting in an order to EM3EV and he sells it. I tried looking for it in my tote box reserved for my CA, couldnt find anything. I might have misplaced it.
 
Oh I wish I had the Satiator, creme$ de la creme$

Put on the list to order then.

Dont worry I will be studying this thread for the firm ware update, and 3 speed switch hookup.
 
updated to latest 3.1 b15

I am using a torque pas sensor (Thun BB) and with the AUX Pot the assist level is adjusted (no digi aux buttons yet).
Two presets are configured.
On the first i have set the maximum assist level to "6 x humen watts", while on the second preset i have set "12 x humen watts".

Now, if i switch to preset 2 and twist the pot to maximum assist, the display shows 6 x (or always the same as in preset 1) and not 12 x like programmed there.

Is this normal, or could this be a bug?

btw: wasn't there once more settings for the battery? Like that it shows 100-0% soc if the battery only is used within, lets say 10-90% for longer lifespan?
 
v3.1 Beta 16 Released (Repaired b15)

Hey madin88 - good catch! Here's a new release to fix up your bug.

There are two quick fixes in this release that relate to TorqPAS mode:

  1. 4222 - Aux Change 'PAS Power Factor' pop-up only shows data for preset #1
    When configured to control 'PAS Assist', the Aux Change pop-up screen always displays the Assist Power Factor for preset #1 regardless of the actual selected preset #1 to #3.

  2. 4224 - Setup Utility 'Assist Pwr Fctr' units do not vary with Assist Mode
    PAS Assist Mode controls the interpretation of values 'Assist Start Power' and 'Assist Power Factor'. In the Setup Utility the PAS Assist Mode selection should alter both displayed units and input value bounds checking for both settings. These features are broken in 3.1b15 due to shortening the PAS Mode menu.
These are not show-stopper issues, but this release will get the firmware and Setup Utility working as advertised. Previous CA settings and settings files are unaffected so you can just flash the NoEeprom version over your existing installation. There are no other changes so if you're not a TorqPAS user there's no particular reason to advance to this release.

Thanks for the bug report!

Download!
View attachment CA3-1b16.zip
(Previously implemented 3.1b15 beta features (part of this build) described here and in the Release Notes.)

ALL NEW RELEASES ARE AVAILABLE DIRECTLY THROUGH THE SETUP UTILITY AND ANNOUNCEMENTS ARE NO LONGER CHAINED IN THIS THREAD.
 
madin88 said:
wasn't there once more settings for the battery?
Like that it shows 100-0% soc if the battery only is used within, lets say 10-90% for longer lifespan?
No, not yet - but it's been a planned enhancement for a while and is slowly floating up towards the top of the list... :D
 
wow that was a quick fix
thumbs up!
 
I installed v3.1 beta 15 a few days ago (just before beta 16 was released). Overall it seems to be a very good improvement over 3.01, which I had before. I also installed DIY digiaux buttons in addition to analog aux.

I noticed a small bug in PAS assist power factor setting in CA menus. When I adjusted the numbers and pressed left button long a few times to return to edit +/- sign, the sign turned into numbers and the only way to get out of the menu was rebooting CA.

If presets are controlled by analog aux, then preset cannot be changed by CA buttons. But if digiaux controls presets, then also CA buttons can change the preset. In my use it would be better, if changing preset by CA buttons was disabled when digiaux controls presets. This would allow using digiaux presets for an offroad mode, that could only be activated by some additional hardware (e.g. removable buttons). That way the bike would still be legal on road as CA could not be turned into offroad mode during ride. I have a good analog pot for power adjustment. That’s why I don’t want to use analog aux for presets.

PAS assist power factor (W/rpm) was a good addition. However, it would be much more flexible, if the rpm after which more power is applied, could be changed from 55.
 
radix said:
I installed v3.1 beta 15 a few days ago....
I noticed a small bug in PAS assist power factor setting in CA menus. When I adjusted the numbers and pressed left button long a few times to return to edit +/- sign, the sign turned into numbers and the only way to get out of the menu was rebooting CA.
Verified. Actually, this appears to be happening with other +/- entry values as well so we may have a common UI entry field bug.
Good catch.

EDIT: Actually, it turns out this bug is in the 3.0x release as well....

radix said:
If presets are controlled by analog aux, then preset cannot be changed by CA buttons. But if digiaux controls presets, then also CA buttons can change the preset. In my use it would be better, if changing preset by CA buttons was disabled when digiaux controls presets.
Verified. Interestingly, this wasn't intentional - it's an unexpected side effect of the AuxD implementation. I see the point of your request, but frankly the ability to alter presets from either button set may be considered a useful feature. This one will get a little internal discussion, I'm sure. Thanks for pointing this out.

radix said:
PAS assist power factor (W/rpm) was a good addition. However, it would be much more flexible, if the rpm after which more power is applied, could be changed from 55.
Yep - this has been discussed - primarily in the context of hand cycles where crank speed is lower that foot pedaling and requiring 55rpm really postones scaling to a relatively high percentage of achievable max rpm. As a workaround, if you want to lower the base rpm speed, you can halve the number of PAS poles which will double the apparent crank rpm (e.g. the CA will see 55rpm at only 27rpm, etc). The other PAS parms will need to be adjusted appropriately. This messes up the displayed and logged human stats a bit, but if that's not important to you, this hack will initiate scaling at a much lower rpm.
 
Over the last few days I have installed and tested the AuxD 2-button accessory from Grin and updated my CA3's to firmware version 3.1b16 on both of my bikes.

After spending considerable time tuning the speed gain parameters on an empty road with an even downgrade and then descending over varying terrain, I am mostly happy with the new feature. Thanks, teklektik and Grin, for supporting this. Having a speed control on long descents frees me to concentrate on riding the bike and to enjoy the scenery. It also allows me to capture the maximum energy* possible on downhills. The system works as I expected it would.

I say "mostly happy" because the best speed gain settings are an acceptable but imperfect compromise between too much initial overshoot, more than 3 excursions about the set speed, and perceptible higher frequency motor surging while the system attempts to hold the set speed. I can live with 2 overshoots and barely perceptible surging at the set speed, but I may try to fine tune the gain parameters further. I do have the odd sensation that if I pedal while engine braking, I can feel the motor attempt to compensate for the slight variation of speed with each pedal stroke in syncopation with my pedaling.

My bikes weigh about 140kg loaded, and I'm using DD hub motors with 30-35mm stator. CA3 is set for 1000 watts maximum (at 52 volts nominal) when driving normally, and -1500 watts in regeneration or up to the controller limit (up to about +3000 watts) when plugging, controlled by ASI BAC2000s. I set up 18 discrete speeds between 12 and 80 kph to be selected with the AuxD buttons. Speed gain parameters on the Gold Rush running the Edge1500 motor are PSGain=1.8, IntSGain=250, and DSGain=250. On the Pursuit running the Nine Continents M3006RC, the parameters are: PSGain=2.0, IntSGain=300, DSGain=300.

One bug or glitch: On one of my test rides, the CA3 recorded a MaxS of 87.9 kph, while my GPS track recorded a maximum speed of 65.3 kph. My speedometer signal is coming from one of the motor's Hall sensors, so there can be no faulty reed switch. And, "natural" regeneration occurs somewhere between 65 and 70 kph with these motors.

*The ASI controller's "engine braking" uses a combination of regeneration and plugging. Regeneration converts mechanical energy into stored battery energy and is desirable when it can be used. Plugging consumes battery energy to impart a reverse torque on the wheel. The two modes on the ASI controller have considerable overlap depending on speed and commanded braking force. The transition between regeneration and plugging varies depending on speed and braking force, lower speed or greater braking force increasing the likelihood of plugging.

When a speed limit lower than the current speed is set, it is possible for some braking to fall briefly into the plugging domain as the CA3 attempts to reduce quickly the vehicle's speed. Plugging may also occur even if net negative battery current is flowing, such as on steep descents where speed is moderate (25-30kph) but braking force is high. When some component of engine braking is plugging the motor core temperature will rise quickly, evidence of wasted energy. It is for this reason that I am looking for a way to disable plugging on my ASI controller.
 
mrbill-
Great feedback - as always. The whole issue of tuning the Speed PID can certainly be an annoying undertaking... My knee jerk reaction is that your IntGain is too high causing the PID to rapidly accumulate a large error term resulting in a lot of overshoot as the bike takes a while to physically respond to the throttle correction. Reducing that term should help the overshoot and you might increase the PGain to get a faster response without the lasting integration effect of IntGain.

I'm not sure about the funky speed issue. It's possible that it's related to a memory corruption issue that we are tracking down. I'll cut a 'watch' ticket on it.

Temp-limiting regen would indirectly go to one of your plugging concerns, but although planned, that feature is not on the immediate horizon. Justin is on the road for a bit, but your regen and plugging remarks will certainly get discussion on his return. So - those observations are in the pipe as it were, but there are some travel delays in there ahead of them... ;)
 
teklektik said:
mrbill-
Great feedback - as always. The whole issue of tuning the Speed PID can certainly be an annoying undertaking... My knee jerk reaction is that your IntGain is too high causing the PID to rapidly accumulate a large error term resulting in a lot of overshoot as the bike takes a while to physically respond to the throttle correction. Reducing that term should help the overshoot and you might increase the PGain to get a faster response without the lasting integration effect of IntGain.

I will try decreasing IntSGain on its own--I had been moving IntSGain and DSGain in tandem--to see if that improves the behavior. Thanks for the suggestion.

I'm not sure about the funky speed issue. It's possible that it's related to a memory corruption issue that we are tracking down. I'll cut a 'watch' ticket on it.

I've only seen this once. But then I've only ridden with 3.1b16 twice.

Temp-limiting regen would indirectly go to one of your plugging concerns, but although planned, that feature is not on the immediate horizon. Justin is on the road for a bit, but your regen and plugging remarks will certainly get discussion on his return. So - those observations are in the pipe as it were, but there are some travel delays in there ahead of them... ;)

Having regen, or more accurately in my case, engine braking observe temp limits and the other limits on the CA3 would be a good idea and would constitute consistent behavior. Although I favor adding observance of these limits during engine braking to the CA3 firmware, I believe a better solution to prevent wasteful plugging is to disable it directly in the controller, while retaining regenerative braking. In spite of ASI's apparent lack of interest in providing end-user "engineering" support I pressed on and submitted an inquiry directly with ASI.
 
mrbill said:
Having regen, or more accurately in my case, engine braking observe temp limits and the other limits on the CA3 would be a good idea and would constitute consistent behavior.
I've been thinking about this very issue and have come to the conclusion that regen shouldn't observe temperature limits. As braking is a critical safety function, I want to know that when I enable regen, it will give me full regen exactly when I ask for it. I certainly don't want to have to take into account any other factor at the very moment I want to engage regen, as I can imagine what might happen if one doesn't get the level of braking that one expects to recieve in a given situation
 
danielrlee said:
mrbill said:
Having regen, or more accurately in my case, engine braking observe temp limits and the other limits on the CA3 would be a good idea and would constitute consistent behavior.
I've been thinking about this very issue and have come to the conclusion that regen shouldn't observe temperature limits. As braking is a critical safety function, I want to know that when I enable regen, it will give me full regen exactly when I ask for it. I certainly don't want to have to take into account any other factor at the very moment I want to engage regen, as I can imagine what might happen if one doesn't get the level of braking that one expects to recieve in a given situation

Different users may have different goals in mind.

I use engine braking to recover energy with the goal being to maximize my bike's overall efficiency. I have perfectly good friction brakes on my bikes to handle stopping chores where engine braking would otherwise consume precious battery energy or risk overheating the motor. Right now I have to make a judgment call, based on speed and braking force, when to use my friction brake or to continue using the engine brake into the plugging regime. Anyone using an engine brake as their primary brake should also have good old-fashioned friction brakes on both wheels.

That said, if the Grin development team decide to allow users the option of whether or not to constrain engine braking to CA3 limits, I would be satisfied.
 
Thanks for your answer teklektik!

teklektik said:
Verified. Interestingly, this wasn't intentional - it's an unexpected side effect of the AuxD implementation. I see the point of your request, but frankly the ability to alter presets from either button set may be considered a useful feature. This one will get a little internal discussion, I'm sure. Thanks for pointing this out.

Ok, I understand if you decide to leave it as a feature. But it could be useful, it changing presets by CA buttons could be disabled in menus or CA Utility. E.g. in OEM features by unchecking select preset in presets menu.

teklektik said:
Yep - this has been discussed - primarily in the context of hand cycles where crank speed is lower that foot pedaling and requiring 55rpm really postones scaling to a relatively high percentage of achievable max rpm. As a workaround, if you want to lower the base rpm speed, you can halve the number of PAS poles which will double the apparent crank rpm (e.g. the CA will see 55rpm at only 27rpm, etc). The other PAS parms will need to be adjusted appropriately. This messes up the displayed and logged human stats a bit, but if that's not important to you, this hack will initiate scaling at a much lower rpm.

That is a good enough solution for me, as I don’t use human stats screen.

I think I found some new bugs from v3.1 beta 15. I have set speed limit to 26.5 kph. I had no problems when PSGain was 1.00, IntSGain 150 and DSGain 30. But since I changed IntSGain and DSGain to 0, speed limiting starts sometimes at lower speeds than 26.5 kph. Diagnostics screen shows S and in main screen km/h is blinking. I haven’t figured out what is causing it. It just happens sometimes when I first cycle at more than 26.5 kph, slow down to about 15-20 kph and accelerate again. I have to almost stop to make the speed limiting return to 26.5 kph.

I also discovered, that with PSGain 1.00, IntSGain 0 and DSGain 0 throttle output does not drop by 1.00 V/kph over speed limit of 26.5 kph. In unofficial CA V3 User Guide p. 30 it says ”So if it is set to 0.5V/kph, then for each km/hr you go above the speed limit, the throttle output will immediately drop by 0.5V.”. My throttle output range is 1.20 - 3.64 V. At 26.5 kph throttle is about 2.70 V. I accelerated by pedalling to 35 kph and throttle output was still about 1.60 and motor power was about 20 W. When speed limit is 26.5 kph and PSGain 1.00, throttle output should have been 1.20 by 29 kph.
 
radix said:
I think I found some new bugs from v3.1 beta 15. I have set speed limit to 26.5 kph. I had no problems when PSGain was 1.00, IntSGain 150 and DSGain 30. But since I changed IntSGain and DSGain to 0, speed limiting starts sometimes at lower speeds than 26.5 kph. ... when I first cycle at more than 26.5 kph, slow down to about 15-20 kph and accelerate again. I have to almost stop to make the speed limiting return to 26.5 kph.
Setting IntSGain to 0 is not a good idea - there is almost no error correction generated so the throttle adjustments for speed can be super slow. This is probably the cause of your slow recovery. This is part of the black art of PID tuning and that particular rule of thumb and consequence is not called out in the Guide...

The DSGain term is the cause of the speed limit tripping lower than the speed setpoint. This gain controls the CA 'future sense' as it sees a rapid rate of speed change and throttles back to avoid an 'anticipated' speed limit overshoot. This only happens on hard acceleration - which is exactly the symptom you describe.

  • Think of DSGain as driving with your white-knuckled mother in the car screaming 'SLOW DOWN!' because you burned out but actually were going less than 20mph at the time - it's the acceleration that freaked her out.
If you want to deactivate speed limiting, the settings in the Guide on the bottom of page 30 will do the trick:

Guide said:
If Speed Throttle and maximum speed limit enforcement are not required, disable the speed control logic:set SLim->MaxSpeed to the maximum value, IntSGain = 100, PSGain = 0, DSGain = 0.
 
mrbill said:
On the Pursuit running the Nine Continents M3006RC, the parameters are: PSGain=2.0, IntSGain=300, DSGain=300.
teklektik said:
My knee jerk reaction is that your IntGain is too high causing the PID to rapidly accumulate a large error term resulting in a lot of overshoot as the bike takes a while to physically respond to the throttle correction. Reducing that term should help the overshoot and you might increase the PGain to get a faster response without the lasting integration effect of IntGain.

I reduced IntSGain to 100, and there is now a bit more overshoot when approaching the set speed either from above or below, but slightly less surging as the CA3 attempts to hold the vehicle at the set speed. I will continue to try to tweak these to see if I can get rid of the surging sensation without the speed wandering too much around the set speed. I think the optimal solution is rather insensitive to slight changes in these parameters. I discovered that much of the surging is due to undulations or bumps in the road causing the wheel to speed or slow ever so slightly. I know that my pedaling can cause surging.

I found another possible bug: Sometimes when clicking one button or the other when riding along, the temporary AuxA Pot screen pops up. It occasionally stays up for several seconds, longer than the usual one second or so after making an adjustment to the pot. It does not seem to be related to road vibration but rather to my clicking one of the mode buttons on the CA3. Usually doesn't occur, but for a while on today's ride it occurred frequently when I was clicking through the diagnotics screen and the battery IR screen, one and two screens to the "left" of the main screen.
 
JeffH said:
Glad this info popped up because I've been wanting a dimmer screen for night use for a while.

Super easy hack to make.
My CA is mounted in a mini-console so i just ran a pair of wires from the led pads on the board, outside the case, to a slide switch mounted in the console.
Works just as Justin describes.
The red lights are bright enough to see during the day and at night they're just right.

Hey and glad to hear that worked out, since I hadn't actually tested it out in practice, just looked right on paper.
Do you have any photos by chance? And do you find that you now only leave it in the red LED mode or do you sometimes switch back and forth?
 
mrbill said:
I found another possible bug: Sometimes when clicking one button or the other when riding along, the temporary AuxA Pot screen pops up. It occasionally stays up for several seconds, longer than the usual one second or so after making an adjustment to the pot. It does not seem to be related to road vibration but rather to my clicking one of the mode buttons on the CA3. Usually doesn't occur, but for a while on today's ride it occurred frequently when I was clicking through the diagnotics screen and the battery IR screen, one and two screens to the "left" of the main screen.
Okay - this is a certainly a genuine bug - and a weird one at that.
Thanks for the feedback - this one moves to the top of the list...
 
teklektik said:
mrbill said:
I found another possible bug: Sometimes when clicking one button or the other when riding along, the temporary AuxA Pot screen pops up. It occasionally stays up for several seconds, longer than the usual one second or so after making an adjustment to the pot. It does not seem to be related to road vibration but rather to my clicking one of the mode buttons on the CA3. Usually doesn't occur, but for a while on today's ride it occurred frequently when I was clicking through the diagnotics screen and the battery IR screen, one and two screens to the "left" of the main screen.
Okay - this is a certainly a genuine bug - and a weird one at that.
Thanks for the feedback - this one moves to the top of the list...

Make sure its not a wire broken off the Grin poti contacts.

The wires are unfortunately soldered to the very end of the contacts, hence the contacts break-off rather easily (as I had to find out).
 
Back
Top