Cycle Analyst V3 preview and first beta release

irq said:
...after ~2hr it suddenly started accelerating itself, noone was even near it :shock:
Whoa! You really seem to be the nexus of Bad CA Happenings!

So - was it sort of creeping away, or did it launch into an invisible rider PAS frenzy?
Also - are you on b8 or b9?

The PAS stuff really hasn't been fiddled for quite some time, so I'm somewhat comforted that it's probably not something recent that changed unless it was an unfortunate indirect effect of other beta code changes. My first thoughts went towards a possible hardware glitch, but that was almost certainly just biased wishful thinking... :)

If you can, PM me a settings file and I'll slap it on the bench rig for a protracted idle test.
 
irq said:
...i think that i have Seen threads where users reported strange things caused by the wire Route? Magnetical interferences, but since it was idle...

Maybe some ferrite rings wont hurt?
You have a simple PAS wheel and the firmware requires an ongoing series of pulse to activate PAS and keep it going. Random noise seems unlikely to fill the bill. The torque input can't initiate PAS by itself, so that's off the table as well. With the Throttle configured as 'off', the signal is ignored, so that can't be responsible either. It doesn't look like any of the input leads can be bringing in noise that could precipitate this behavior and so efforts to squelch noise there is unlikely to bear fruit.

I don't want to discourage shot-in-the-dark fix-it attempts, but it would be good to get a better handle on the failure mode first.

The first step is reproducing the issue. If you have a sensored controller, you might try unplugging the halls, setting the CA to the Diagnositics Screen and letting it stand. The OUT field will show if the CA is trying to apply throttle but the disconnected halls will thwart the attempt.

  • From there you can look at the IN field to see if the CA thinks there's throttle activity, and the HW screens will show if there are RPMs, HW, etc that are causing the output.
  • Button-pushing may cause the issue to go away as might entering Setup, but the SETUP TRQ screen would show the voltage and torque. The problem may or may not still be in force when you leave Setup, but that would be useful to know as well.
 
teklektik said:
irq said:
...after ~2hr it suddenly started accelerating itself, noone was even near it :shock:
Whoa! You really seem to be the nexus of Bad CA Happenings!

So - was it sort of creeping away, or did it launch into an invisible rider PAS frenzy?

it was a nearly 360° jump, luckily only a hp laserprinter (nothing of worth lost) was in its way and power wasnt set to maximum. i think i cant imagine what a 12t mac at full throttle and 2000 watts is going to do when it starts to get crazy.

Also - are you on b8 or b9?

its b8 currently

The PAS stuff really hasn't been fiddled for quite some time, so I'm somewhat comforted that it's probably not something recent that changed unless it was an unfortunate indirect effect of other beta code changes. My first thoughts went towards a possible hardware glitch, but that was almost certainly just biased wishful thinking... :)

If you can, PM me a settings file and I'll slap it on the bench rig for a protracted idle test.


sure, will extract it from the ca when back at home (wanted to upgrade to b9 anyway)
 
teklektik said:
irq said:
...i think that i have Seen threads where users reported strange things caused by the wire Route? Magnetical interferences, but since it was idle...

Maybe some ferrite rings wont hurt?
You have a simple PAS wheel and the firmware requires an ongoing series of pulse to activate PAS and keep it going. Random noise seems unlikely to fill the bill. The torque input can't initiate PAS by itself, so that's off the table as well. With the Throttle configured as 'off', the signal is ignored, so that can't be responsible either. It doesn't look like any of the input leads can be bringing in noise that could precipitate this behavior and so efforts to squelch noise there is unlikely to bear fruit.

its a 12 magnet ring, with the CA Forward/Backward Sensor

I don't want to discourage shot-in-the-dark fix-it attempts, but it would be good to get a better handle on the failure mode first.

The first step is reproducing the issue. If you have a sensored controller, you might try unplugging the halls, setting the CA to the Diagnositics Screen and letting it stand. The OUT field will show if the CA is trying to apply throttle but the disconnected halls will thwart the attempt.

so far, its still in the same corner like this morning - battery plugged, CA is on, power reduced to 50w - surprise: no more gremlins occoured. it does not seem to be reproducable, but i had no chance yet to try anything further. the controller is a 12 fet xie chang with pcb dated to 2016/01 sold by a german vendor (Ebike Solutions Heidelberg), dunno if it works without halls connected. will try

  • From there you can look at the IN field to see if the CA thinks there's throttle activity, and the HW screens will show if there are RPMs, HW, etc that are causing the output.
  • Button-pushing may cause the issue to go away as might entering Setup, but the SETUP TRQ screen would show the voltage and torque. The problem may or may not still be in force when you leave Setup, but that would be useful to know as well.

shouldnt i see such random instant happenings somehow in the serial log ? currently my openlog device is not connected, but it can be anytime.
 
irq said:
shouldnt i see such random instant happenings somehow in the serial log ? currently my openlog device is not connected, but it can be anytime.
That would be great!
Logging is not something a lot of people are doing, so not something I usually bring up. The OpenLog seems to be a nice way to go about it.

The log uses a mix of averaged and instantaneous data, but all but the briefest aberrant behavior will show up...
 
Alan B said:
A kill switch on the handlebars that removes battery power from the controller, CA, etc is prudent
I don't want to derail this thread into a general discussion of kill switches, but in so far as you specifically mention the CA:
I find it more useful for the kill switch to deactivate only the controller and leave CA and other accessories powered normally. This fulfills the primary emergency safety requirement of killing the drive system but allows the rest of the bike to remain operational (e.g. CA keeps running, lights are not extinguished, etc). This is handy for safety while standing or temporary dismounts, running with the motor disabled in pedal-only mode where various CA trip statistics are useful even in an unpowered mode, or pedaling home with a shorted controller that will trip a breaker if powered up. (Yep - I have experience in all these... :) )

The Guide examples involving external shunts outline this strategy as an option to get a little more flexibility out of the switch since custom wiring is required as a matter of course, but the behavior can be arranged with controllers utilizing a plug and play CA-DP connector by redirecting CA-DP pin 1 to switched Vbatt - typically from a keyswitch.

In irq's case above, this type of kill switch setup would have allowed the 'spontaneous runaway' test to be run via kill switch, leaving the CA alive and under test. (This is an observation, not a suggestion that 'CA testing' a compelling reason to adopt the strategy -- although this kill switch does afford my normal mode of flashing CA firmware or fiddling CA accessories like throttle, ebrakes, PAS, etc. without a stand.)

Anyhow, just an alternative view on the conventional 'kill everything' switch...
 
short update about my gremlins: surprise... they did not show up again. i hate "random voodoo you cant reproduce"

longer update:

since i dont know yet how to reproduce what happened i decided to keep everything turned on during workhours, to prevent another dead laserjet i kept power at lowest level and speed limit to 7kmh. nothing - absolutly nothing strange happened, also during riding everything works like it should be. currently i carefully tend to think that the bike started to slip away (its leaning against a wall, no side stand) which probably caused the crank to move enaugh to engage autopas. but probably i am totally wrong, time will tell.

openlog is connected again, so nothing will be lost if it´ll happen again.

regarding kill switch: since i dont see a real reason to disconnect the battery every time and theres one more switchbutton unused on my digiaux i grabbed on of those modules which i planned to place inside the controller

https://www.pololu.com/product/2809

sure, it whould be also possible to wire the controller switch to the handlebar but from an aesthetic point i prefer the microswitches
 
Thanks for the update - I'm hoping for the 'falling bike' more-auto-Pas-than-desired explanation instead of the voodoo hoodoo.


Hey - that's a neat little PCB. Thanks for the link.

I was thinking specifically about your extra pbutton the other day in a discussion with Justin where he pointed out that my old Phaserunner has switched 5V like other controllers to deactivate the controller logic, but the new models have a pushbutton that toggles power ON/OFF with a built-in soft-start no-spark circuit (!). That would fit in perfectly with a three pbutton module like yours so you'd get DigiAux, power ON/OFF, and no-spark battery hookup.
Really pretty tidy. :D
 
gremlins are back... but thank thanks to 10w / 6 kmh setting they did not hurt anything this time

and this time i was able to catch some info from the ca screen:

- throttle bar rises up for 1-2 secs (no throttle connected!)
- throttle out voltage also rises for 1-2 secs and goes back to baseline
 
teklektik said:
v3.1 Beta 9 Released

[*]A new 'Temp Statistics' screen has been added to the Status Screens and like the other status screens can be selected for display when still or moving in Preferences. The rightmost field alternates to show two different values as illustrated below. Importantly, the temperature stats are **NOT** saved to EEPROM and will disappear on a power cycle - they are considered transient trip-specific data that will be derived anew on the new trip.

I loaded up 3.1b9, and I like the changes and additions (and in general I have been pleased with the recent bug-fixes and changes). But, I have a problem with the implementation of the new Temperature Statistics screen.

This is the only peak stats screen for which data are not saved upon power-down. This is inconsistent with the interface with for the other peak statistics screens whose data are saved at power-down and that can be reset (and confirmed) by screen (per the changes in 3.1b7).

I like to reset my stats when I do a "trip reset" at the beginning of a trip or a per-screen peak stats reset upon command, not when the power is shut off, either on purpose or by accident. Sometimes during a trip I might park the bike and power-down the controller and CA3 to avoid possible meddling by passers-by. I did this recently, and when I powered back up I discovered my peak temperature stats had been reset. Grr. Then I remembered the warning above, and now I ask the question,

"Why does this particular peak stats screen receive a different treatment from the others?"

Are we hitting a memory limit in EEPROM already that we cannot save these data at power-down?
 
mrbill said:
I loaded up 3.1b9, and I like the changes and additions (and in general I have been pleased with the recent bug-fixes and changes).
Thanks. Good to hear.

mrbill said:
... But, I have a problem with the implementation of the new Temperature Statistics screen.
"Why does this particular peak stats screen receive a different treatment from the others?"

Are we hitting a memory limit in EEPROM already that we cannot save these data at power-down?
Yep - you nailed it.
Both configuration parameters and stored statistics occupy EEPROM. This has been mentioned in the past in the context of choosing new features that would have the widest appeal (biggest bang-for-the-buck memory-wise). Along this line, some parameters in the 3.1 beta firmware have been converted from per-preset to global - largely to recover memory...

We thought the temp screen was valuable and the difficulty with losing parameters on power down was deemed annoying but an acceptable penalty vs omitting the screen altogether. In this case the dwindling memory led to a decision to not use extra EEPROM to preserve the temp data as a trade-off for adding other new configurable features.

Anyhow - I hope you find the temp screen useful in spite of this shortfall...
...wishing for a bigger processor... :)
 
Does anyone know what type the conformal coating of he CA's board is? I need to redo it after some modifications I did.
 
I have a cav3 with the throttle hooked through the TH In and Th out of the CA, and it stutters every time under hard load ?

i had a look and none of the limit flats go capitals, awvst etc but i see on the main screen the throttle indicator flashes at exactly the same time , also i can see on the throttle in and out voltages when this happens the Vout fluctuates and in is solid.

what could this be ?
 
Looking to possibly add a CA v3 to my GNG mid drive bike which is running 18s lipo and a Sunwin 72v 1500watt controller. Hoping to tame the throttle response a bit as well as add a bunch of features to my bare bones build such as thermal roll back and battery - current features. I am a bit lost in all the thread searches and wondering if anyone is up to speed with it in a similar setup and can share some basic info I should know before jumping in.
 
CA works well with the GNG mid drive.
I didn't have any trouble just following the manual directions and setting up.

Taming the throttle was a bit of trial and error - it will take some time because you'll want to adjust and test, adjust and test, adjust and test until you're happy.

A lower ramp up will save your drive train and you'll be able to map out all the dead spots in your throttle. I found a three-position switch to be highly useful - having a low-speed, high-speed and eco-mode.
 
Alex07 said:
I have a cav3 with the throttle hooked through the TH In and Th out of the CA, and it stutters every time under hard load ?

i had a look and none of the limit flats go capitals, awvst etc but i see on the main screen the throttle indicator flashes at exactly the same time , also i can see on the throttle in and out voltages when this happens the Vout fluctuates and in is solid.
Hmmm - This is strange.
  • Normally the Throttle indicator flashes on a throttle fault - but that requires closing the throttle to clear the fault.
  • The other Main screen indicator is a flashing voltage reading which indicates LVC limiting is in effect - which might make sense in your scenario - but you are not reporting that failure.
  • The remaining limiting indicator is DSGain-induced speed limiting which does not cause an 'S' flag. This can happen under hard acceleration as described in the Guide - but not under simple hard load. In any case, it does not affect the throttle indicator.
If you can PM a settings file and indicate what firmware you are using, I can take a look.

(I'm off this week, so it will take 'til next week, but I'll get to it...)
(You can also email Grin direct to see if Justin or one of the Support guys can assist sooner.)
 
r3volved said:
CA works well with the GNG mid drive.
I didn't have any trouble just following the manual directions and setting up.
Good to hear. :)

speedmd said:
Looking to possibly add a CA v3 to my GNG mid drive bike which is running 18s lipo and a Sunwin 72v 1500watt controller. Hoping to tame the throttle response a bit as well as add a bunch of features to my bare bones build such as thermal roll back and battery - current features. I am a bit lost in all the thread searches and wondering if anyone is up to speed with it in a similar setup and can share some basic info I should know before jumping in.
As r3volved indicated, the Guide should give you what you need.

The primary obstacle in your case is hooking up the CA to your controller. The Guide describes a simple method using an external shunt that doesn't require cracking the case - see: "Appendix D. Adding a CA-DP Connector to a Generic Controller". There are ES threads for hooking the connector into the controller internals and sharing the controller internal shunt (for instance this thread) - both techniques yield identical capabilities. If you use this second technique and don't know the controller shunt value, you can use one of the techniques in the Guide section "Appendix A. Calibrating the Cycle Analyst RShunt Value" to calibrate your CA.

Once the CA-DP connector situation is addressed, the installation should go by the book.

Ramping Hints:

Since you have a freewheel in the drive, you will be setting this up like a gearmotor. The FastRate setting determines the ramp rate until enough load is detected to switch to the slower UpRate. You should tune using ThrO->FastThrsh=0 to start to get the ramping the way you like. Then you can run up your drive unloaded on a stand and note the current. Try setting ThrO->FastThrsh to about 150% of that value to start. When you are at speed, this will let the motor run up to speed pretty quickly and then back off the rate as soon as the freewheel engages. This is a little fussy to set up but improves response quite a bit.

To simplify the ramping adjustments, I recommend you download the 3.1 beta firmware which has visual 'ramping flags' on the Diagnostics screen. These are very helpful in figuring out what the heck the CA is really doing... In any case - you want to order a programming cable with your CA.
 
teklektik said:
r3volved said:
CA works well with the GNG mid drive.
I didn't have any trouble just following the manual directions and setting up.
Good to hear. :)

speedmd said:
Looking to possibly add a CA v3 to my GNG mid drive bike which is running 18s lipo and a Sunwin 72v 1500watt controller. Hoping to tame the throttle response a bit as well as add a bunch of features to my bare bones build such as thermal roll back and battery - current features. I am a bit lost in all the thread searches and wondering if anyone is up to speed with it in a similar setup and can share some basic info I should know before jumping in.
As r3volved indicated, the Guide should give you what you need.

The primary obstacle in your case is hooking up the CA to your controller. The Guide describes a simple method using an external shunt that doesn't require cracking the case - see: "Appendix D. Adding a CA-DP Connector to a Generic Controller". There are ES threads for hooking the connector into the controller internals and sharing the controller internal shunt (for instance this thread) - both techniques yield identical capabilities. If you use this second technique and don't know the controller shunt value, you can use one of the techniques in the Guide section "Appendix A. Calibrating the Cycle Analyst RShunt Value" to calibrate your CA.

Once the CA-DP connector situation is addressed, the installation should go by the book.

Ramping Hints:

Since you have a freewheel in the drive, you will be setting this up like a gearmotor. The FastRate setting determines the ramp rate until enough load is detected to switch to the slower UpRate. You should tune using ThrO->FastThrsh=0 to start to get the ramping the way you like. Then you can run up your drive unloaded on a stand and note the current. Try setting ThrO->FastThrsh to about 150% of that value to start. When you are at speed, this will let the motor run up to speed pretty quickly and then back off the rate as soon as the freewheel engages. This is a little fussy to set up but improves response quite a bit.

To simplify the ramping adjustments, I recommend you download the 3.1 beta firmware which has visual 'ramping flags' on the Diagnostics screen. These are very helpful in figuring out what the heck the CA is really doing... In any case - you want to order a programming cable with your CA.


Thanks Guys! I feel exited about the upgrade now more than thinking I was making trouble for myself. Will look forward to getting into the weeds on it! :D
 
speedmd said:
Hoping to tame the throttle response a bit as well as add a bunch of features to my bare bones build such as thermal roll back and battery - current features.
A couple of additional quick thoughts to shortcut additional reading and get all the goodies in the order the first time:

After setting up the CA so it's working 'pretty well' by following the Guide and using the throtlle in 'PassThru' mode, switch over to 'Current Throttle' to finish up your tuning. This will get you improved throttle control at the cost of a bit of lag.

You will be looking at a CA3_DPS (speed pickup) if you are going to do the 'internal' connection method for the CA-DP connector, or a CA3-SA if you are doing the external shunt. In either case the yellow 'Speed' wire in the CA-DP cable is unused, so you can attach it in the CA case to the 'NTC' PCB input and use the yellow SPD (pin 5) + black Gnd (pin 2) connections on the CA-DP connector to tie in your thermistor instead of routing additional wires to the bars - just re-purpose the unused one.

Also - recommend you get a CA 3-spd switch instead of the controller 3-speed you may already have installed.
 
v3.1 Beta 10 Released

Hey folks-
3.1b10 is appears to be ready -- It looks great on the bench and in limited road testing, but is not as thoroughly tested as we might like. Things are a little jammed up at this end and will be for a bit, so instead of delaying release to squeeze in another feature or two and dotting all the i's, I'm throwing this out there so you can give it a whirl. In the northern hemisphere Fall is upon us and frankly galloping toward cooler temperatures, so hopefully this will get a neat PAS feature in your hands for some of the warmer riding.

Unfortunately, this release reorganizes the EEPROM map, so a full manual from-scratch config is required....

3.1b10 implements two PAS-related items:
  • A reorganization of the PAS/TRQ configuration to simplify setup and
  • A new 'rpm-scaled' assist extension to AutoPAS that provides the same functionality as the 'AutoTrqPAS' hack in the Guide.

  • The old PAS and TRQ Setup menus looked like this:

    PasMenu3-01.png
    Configuring a device generally required tinkering in both menus both for initial setup as well as for subsequent tuning efforts.

    The reorganized menus 'Device' and 'Config' look like this:

    PasMenuReorg-2.png
    Here the parameters for the underlying device hardware and user-oriented tuning configuration are separated into different menus. The first menu is used for the initial device installation, while the second is used for user config. If desired, the OEM menu flags can be used to hide the device menu to keep busy non-techie fingers away from the hardware setup.

    Importantly, operation of the 'Device Sensor Type' menu has changed significantly. Previously, selecting a predefined type like 'Thun' hid other parameter items and caused operation from fixed values specific to the device. In the new scheme, selecting a 'canned' or 'predefined' device copies preset versions of *ALL* device parameters into place where they are available for user modification. If device parameters remain unmodified, the device type remains as the predefined type. However, editing any device parameter automagically changes the device type to 'custom'. Re-selecting the pre-defined type erases the customization and restores the default canned settings. The Release Notes detail some other aspects of this change and how it relates to the Software Setup utility (see below).

    You will also find a few new pre-defined torque device setups available. The TDCM and CycleStoker require scaling adjustment, but the canned setup ensures the annoying details are correct. More on the NCTE ISIS BB coming soon...

  • AutoPAS has been upgraded to optionally increase power with increasing cadence over 55rpm. This is configured using the 'Assist Power Factor' parameter - which in AutoPAS mode specifies the W/rpm increase. This same parameter in TorqPAS mode determines the Watts/HumanWatts assist factor. The Assist Start Power parameter is similarly used in both AutoPAS and TorqPAS modes to respectively set the baseline assist power when pedaling and to set the Human Watts offset before assist kicks in. Configuration of the two modes now looks very similar and both critical parameters are per-preset.

    For flat terrain or lowish rolling hills, this feature can be helpful by proportionately boosting assist with cadence or to provide a boost when downshifting. This is certainly not a substitute for a torque sensor but it can reduce the incidence of Assist Level adjustments necessary in some common riding situations. The trick here is to adjust the Power Factor high enough to give useful assist without running away at higher rpms. Even modest assist increases can improve the riding experience. Setting the Power Factor to 0 restores the original v3.0 fixed assist operation.

Here's an excerpt of the included Release Notes

Code:
Release: 3.1b10                                                      2016-10-12


Note: V3.1b10 Setup files are **incompatible** with firmware or Setup files
      of **ALL** prior releases including any earlier 3.1 version.

      ------------------------------------------------------------------------
      IMPORTANT:                               __________________
      Please install this package according to README_install.txt.
      Failure to do so may result in improper operation of the Setup Utility.
      ------------------------------------------------------------------------
      
      ------------------------------------------------------------------------
      IMPORTANT:
      After installing this zip package on a PC, the Setup utility will no
      longer be able to properly utilize 3.1 Setup files prepared for prior
      3.1 versions.  3.1 settings files prior to 3.1b10 will not display or edit
      properly and will download to the CA incorrectly resulting in improper
      CA operation. Similarly, setup files prepared with this release cannot be
      used with earlier CA 3.1 firmware versions. 3.0 Setup files are unaffected.
      ------------------------------------------------------------------------

      >> Any incompatible existing CA setup must be recorded and manually
         reconfigured over a fresh 'CA3-1b10_firmware.hex' installation.

      >> All existing CA Setups must either be:
	    1. exported manually from the CA console (at least the statistics)
	    2. OR read by the Setup Utility and preserved in screen snapshots
	       PRIOR to installing this package. Saving to a 3.1 Setup file and
	       reading the file after installing the zip package will not work.

      ------------------------------------------------------------------------
      IMPORTANT:
      Because a CA3-1b10_firmware.hex flash will load default settings, throttle
      voltage configuration may be incorrect. Treat this as an initial CA
      installation and place the bike on a stand or otherwise elevate the drive
      wheel to prevent a runaway when the flash completes and before a proper
      configuration can be restored.
      ------------------------------------------------------------------------


(1) 2566 - Reorganize PAS/TRQ categories to separte hardware and config features

    The classic PAS and TRQ categories have parameter overlap that can require
    modification to both groups to initially configure basic operation for certain
    devices. Subsequent PAS tuning also requires using parameters in both the
    PAS and Torque groups.

    Menu parameters have been reorganized to replace the PAS/TRQ grouping in
    favor of a group addressing basic hardware device features and a second
    group used only for tuning the assist. Simple PAS as well as Torque related
    parameters appear in each group as appropriate. This also allows using the
    OEM menu mask to hide the device configuration and leave only the tuning
    configuration parameters exposed.

    Device Menu:    -Device Sensor Type (pulldown menu)
			Disabled
			PAS noTrq ...... (simple cadence wheel)
			Custom Trq ..... (custom torque sensor device)
			Thun BB ........ (predefined device)
			TDCM BB ........ (predefined device)
			NCTE BB ........ (predefined device)
			Cycle Stoker ... (predefined device)

		    -PAS Poles
		    -PAS Signal Type (pulldown Menu)
			1-wire
			2-wire
		    -PAS Direction Polarity  (pulldown Menu)
			5V = FWD
			5V = REV
		    -Torque Scale
		    -Zero Torque Offset
		    -Torque Assist Averaging

    Config Menu:    -PAS Assist Mode (pulldown Menu)
			PAS Off
			Auto PAS
			Throt PAS
			Torq PAS
		    -Start RPM Threshold
		    -Stop RPM Threshold
		    -Assist Start Power
			(units = W  in Auto PAS mode)
			(units = HW in Torq PAS mode)
		    -Assist Power Factor
			(units = W/rpm in Auto PAS mode)
			(units = HW    in Torq PAS mode)
		    -Max Throttle-Only Speed
    
    As before, parameters are hidden if not relevant based on configuration of
    device or PAS/TRQ mode.
    _________
    IMPORTANT:
    Operation of the 'Device Sensor Type' menu has changed significantly.
    Previously, selecting a predefined type like 'Thun' hid other parameter
    items and caused operation from fixed values specific to the device. In the
    new scheme, selecting a 'canned' or 'predefined' device copies preset
    versions of *ALL* device parameters into place where they are available for
    user modification. If device parameters remain unmodified, the device type
    remains as the predefined type. However, editing any device parameter
    changes the device type to 'custom'.
    _________
    IMPORTANT:
    The Software Setup Utility is not capable of this more complicated parameter
    preset behavior so selection of a predefined type there does not affect
    displayed device parameters and changing them does not automatically switch
    to a 'custom' device type.
    
    However, setting a canned device type in the Setup Utility will force the CA
    to establish *ALL* preset device parameter values when the settings are
    downloaded.  In such cases, all downloaded device parameters are ignored by
    the CA in favor of the preset versions. If a device parameter is modified in
    the CA, the resulting 'custom Trq' device type will be uploaded to the Setup
    utility so that a subsequent download will no longer be a predefined type
    and all downloaded device parameters will be used by the CA. This allows the
    CA and Setup Utility to operate consistently as before but with the added
    ability to force preset device setups into place as needed.

    Several new predefined devices are now supported. Future devices will be
    added to the device menu with the same configuration behavior.

    This revision affects EEPROM configuration, existing Setup files, and the
    Setup Utility.

    >> A fresh configuration must be instated after flashing the new firmware
      (use 'CA3-1b10_firmware.hex').


(2) 1716 - Add RPM-proportional AutoPAS Support

    AutoPAS mode previous supported a fixed Power Assist level when pedaling was
    detected.  However, in some riding conditions, it can be useful to get
    increased power with increased cadence from either direct rider effort to
    achieve higher speed or from downshifting for inclines.
    
    AutoPAS has been revised to provide configuration of a power factor in
    'W/rpm' that is applied to crank rpm over 55rpm. For instance: at 75 rpm and
    4W/rpm then (75rpm-55rpm)*4W/rpm = 80W extra is applied to the configured
    Start Power.
    
    Setting this Power Factor to zero disables the feature and restores earlier
    V3.0 AutoPAS operation.  The Power Factor may be negative so that power
    declines with rpm. This may be useful for fixie riders who need extra
    assistance on getaway, but desire reduced assistance when underway.

    The AutoPAS Start Power and Power Factor are configured in the new 'PAS
    Config' category using the same parameters employed for Torque mode
    operation.
    
    This revision affects EEPROM configuration, existing Setup files, and the
    Setup Utility.

    >> A fresh configuration must be instated after flashing the new firmware
      (use 'CA3-1b10_firmware.hex').

So, take it for a spin and post up any issues! :D

Download!
< CA3-1b10.zip - withdrawn - see 3.1b11 >

(Previously implemented 3.1b9 beta features (part of this build) described here and in the Release Notes.)
(Newer 3.1b11 beta release available here!)
 
well, as master of all CA Gremlins and incurable early adapter of bleeding edge things: i cant resist, - must - upgrade - firmware - now.

i´m totally excited about the pas improvements, cant wait to test it out :mrgreen:


edit: Feature Request :mrgreen:

give us 2 more digi aux buttons :D
 
Strange behavior...

I upgraded my firmware to 3.1b9 (from... I think 3.1b3?) recently. Before the firmware upgrade, the CAv3 worked fine. I wrote down all my settings, and flashed the CA3-1b9_firmware.hex file...

After the upgrade, my CAv3 randomly started switching screens while in motion. A lot.

I thought maybe I accidentally flashed the CA3-1b9_firmware_NoEeprom.hex file and had some corrupt old settings... or maybe I restored some old settings with the upgrade utility (rather than entering them manually), so a few days later I re-flashed the CA3-1b9_firmware.hex and hand-entered my settings... just to be sure. Interestingly, most of the random switching has gone away. It still happens though.

If I were a true scientist I'd flash back to 3.1b3, but I have not tried that yet. Any thoughts on what's happening?
 
irq said:
back in the game, with an ca replacement unit. so far so good, first ride was absolutly fine. arrived at work, placed it in a corner where it was waiting until 5pm. after ~2hr it suddenly started accelerating itself, noone was even near it :shock:

Pulled the Battery Plug, plugged in again -> everything back normal. what the heck... ?!
irq said:
gremlins are back... but thank thanks to 10w / 6 kmh setting they did not hurt anything this time

and this time i was able to catch some info from the ca screen:

- throttle bar rises up for 1-2 secs (no throttle connected!)
- throttle out voltage also rises for 1-2 secs and goes back to baseline
teklektik said:
Okay, please fwd your settings file to me, and I'll run it overnight on the bench rig with data capture to look for gremlin footprints...
irq-
Apologies for the delay in getting back on this.

Footprints found.
I was able to reproduce this on the bench rig running 3.1b8 loaded with the settings file you forwarded.
I cut a high priority ticket for the problem and work is afoot to track this down.

Thanks for the settings file and posts describing the issue...
 
Back
Top