Cycle Analyst V3 preview and first beta release

MattyCiii said:
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?
Odd.
Your reported failure appears unique, which makes me think you may have a noise or button problem that has been exacerbated into visibility with some timing changes on the button logic. The business of ameliorating the issue with a reconfig is strange - I would have expected a complete cure or none at all - a partial remediation is hard to fathom. I'll open a ticket on this and snoop it a bit.

How often does it reoccur?
It would be good if you could please PM your settings file. You're an old hand at the V3 but but it might help us see if a particular gathering of settings is fomenting unrest...
 
teklektik said:
MattyCiii said:
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?
Odd.
Your reported failure appears unique, which makes me think you may have a noise or button problem that has been exacerbated into visibility with some timing changes on the button logic. The business of ameliorating the issue with a reconfig is strange - I would have expected a complete cure or none at all - a partial remediation is hard to fathom. I'll open a ticket on this and snoop it a bit.

How often does it reoccur?
It would be good if you could please PM your settings file. You're an old hand at the V3 but but it might help us see if a particular gathering of settings is fomenting unrest...


Thanks!

I'll try a few things and report back. I have an new "top case" for the CAv3, which I'll swap out. I actually have a full spare CAv3 so maybe I'll also swap the whole unit (to see if some strange signal wire feedback is the problem). I also have an Analogger I'll hook up and take logs from...
 
Got the CA V3 DP and not sure if I need to add a speed sensor for my mid drive. I don't plan on adding PAS or fooling with things like cruse control and don't need to know how fast I am going as I ride with my Garmin GPS most times. Am I missing some other program needs for speed sensing and if so can I wire in a conventional bike computer pickup for it?
 
There are a few features tied to detecting either if the bike is moving or the actual distance: selection of moving vs still display screen masks, display temperature averaging (Tavg) only when moving, computation of Wh/mi (obviously), etc. In general the CA will work okay without that input.

A cheapie bike computer pickup will work fine, as will hall-based pickups - see "Appendix B. Add/Remove Wheel Speed Pickup Sensor" of the Guide.

Alternatively, if you don't care about distance-related stuff, you can leave the CA-DP connector rigged to the controller to get speed data from the motor and set the wheel circumference to 1666 mm and the display units in Km. This will convert the 'Speed' display to 'motor rpm' in 10's of rpm (e.g. 35.6 kph = 356 rpm) -- a tach for your mid-drive...
 
Thanks Tek, was thinking the rpm display would be the sporty option. Shift points mapped with different color leds for up and down shifts based on performance or efficiency driving selections. :lol:

Looks like I will add one of the several speed pick up sensors lying around now that the garmin has replaced them on the pedal bikes.
 
MattyCiii said:
I'll try a few things and report back. I have an new "top case" for the CAv3, which I'll swap out. I actually have a full spare CAv3 so maybe I'll also swap the whole unit (to see if some strange signal wire feedback is the problem). I also have an Analogger I'll hook up and take logs from...

Turns out it was likely coincidence, not cause-and-effect. I swapped out the top of the CA case and it all works fine now!
 
Morning All,

Can anyone assist me with a question regarding "idle watts":

Earlier in thread Justin suggested a way to reduce transmission shock by adjusting the minimum throttle input to allow the motor continue spinning on a very low power when you are freewheeling. This was set with a watts throttle set up.

Does anyone know a way in which a similar situation could be created with a R/C pulse throttle set up?

Thank you

Ham
 
hi everyone,

i have some problems with my cycle analyst V3 :
at high current the controller jerks many times hard and my CA reboot automaticly. (most when the controller have many work) YGE 320HV
someone had similar problems ?

greetings from germany
 
I've (finally) updated to FW v3.1b10 the other day.
So far, so good. (pretty good actually!)

One slight issue, though:
I can't find the 'Set Assist Start Power' and 'Set Assist Power Factor' in the PAS settings if the CAv3 is in setup mode.
Checked out the 'OEM Features' settings of my (brand new) setup file in the Setup Utility and all entrys are set as available.

Am I missing something, or did I stumble over a bug?

In case this helps:
DigiAUX is disabled, AnalogAUX is set to control PAS level
 
When i use the AUX input or brake switch , i short the input pin to zero, and everything works fine but i notice the screen dims is this normal ? or do i need to put some resistor between ground and the input pin as its loading the internal 5v reg too much ?
 
Marc S. said:
I can't find the 'Set Assist Start Power' and 'Set Assist Power Factor' in the PAS settings if the CAv3 is in setup mode.
I suspect you have PAS->PASMode set to either 'PAS Off' or 'ThrotPAS' - neither of which use those parameters in which case they are not displayed...
If this is not the case, please post up or PM your settings file.
 
Alex07 said:
When i use the AUX input or brake switch , i short the input pin to zero, and everything works fine but i notice the screen dims is this normal ? or do i need to put some resistor between ground and the input pin as its loading the internal 5v reg too much ?
No external resistors are required and the internal pullups should cause no material current on short to Gnd.

That said, I'm a little surprised that you are seeing a dimming effect. The LED backlight actually gets brighter under increased current draw so it looks like you are reducing the current when you close the switches.
 
teklektik said:
Marc S. said:
I can't find the 'Set Assist Start Power' and 'Set Assist Power Factor' in the PAS settings if the CAv3 is in setup mode.
I suspect you have PAS->PASMode set to either 'PAS Off' or 'ThrotPAS' - neither of which use those parameters in which case they are not displayed...
If this is not the case, please post up or PM your settings file.

Nope, PAS->PASMode is set to 'Auto PAS',
'Assist Start Power' and 'Assist Power Factor' actually work as intended. I just have to tweak the settings a bit further...

I have an other issue since the FW update:
The 'Odometer distance' in Lifetime Statistics doesn't add up.
Compared to my trip distances since the update (88km) it was missing 22km.

I just pulled the setup file from the CA to make sure the file on my computer and the file from the CA have identical settings.
While at it, I've corrected the 'Odometer distance' (to 6,292km) and tweaked the 'Assist Power Factor'.

After writing the setup back to the CA, the 'Odometer distance' in the CA showed 6,348km!
Pulled the setup file from the CA again and it still was at 6,292km in the setup utility.

After power cycling the CA, restarting the Setup Utility and writing the setup file to the CA again it worked, though.

This is the setup file:
 

Attachments

  • Blue ICE v3.1b10 Setup.hex
    1.3 KB · Views: 23
Marc S. said:
teklektik said:
Marc S. said:
I can't find the 'Set Assist Start Power' and 'Set Assist Power Factor' in the PAS settings if the CAv3 is in setup mode.
I suspect you have PAS->PASMode set to either 'PAS Off' or 'ThrotPAS' - neither of which use those parameters in which case they are not displayed...
Nope, PAS->PASMode is set to 'Auto PAS',
'Assist Start Power' and 'Assist Power Factor' actually work as intended. I just have to tweak the settings a bit further...
Thanks for the file Marc.
Yep - my Bad - forgot about this one. It was fixed incidentally a bit ago while implementing b11 features and sort of fell in the cracks...

The difficulty can arise when using multiple presets - the preset indexing for presets 2 and 3 is incorrect which can result in the incorrect display behavior you noted; other PAS features may also operate improperly as the Torque/No-Torque mode condition can be misinterpreted. Testing your file showed proper display for presets 1 and 2 but not 3. However, since the firmware is actually looking at the wrong data, it might behave differently depending on the phase of the moon.

As mentioned above, this was already repaired for the next release, but that has gotten delayed a bit, so I back-ported the fix onto a new b11 release. See next post ;)

As always - thanks for the reviews and bug reports!
 
v3.1 Beta 11 Released (Repaired b10)

Thanks to Marc's bug report, we have a new 3.1b11 release.

This release specifically targets the b10 per-preset PAS Config error so this is really just a 'fixed b10' (See above). There are no other changes or new features.

This repairs faulty handling of internal parameters and so the xxxx_NoEeprom version can be loaded over an existing 3.1b10 installation to correct the behavior without affecting the existing configuration. See the Release Notes for installation on releases prior to 3.1b10.

So: "Have at it!" -- if you're in the States - just a little Black Friday goodie...

Download!
View attachment CA3-1b11.zip
(Previously implemented 3.1b10 beta features (part of this build) described here and in the Release Notes.)
(Newer 3.1b12 beta release available here!)
 
I'm always impressed by the quick support from teklektik or grin tech generally. Thumbs up!
I wish Adaptto support would be as good. Now, if there is a bug or problem with the firmware, they do it the easy way and REMOVE the whole feature instead of investing time for a fix or reprogramming.
They don't care much about strange problems/bug several end users have.
 
Marc S. said:
I have an other issue since the FW update:
The 'Odometer distance' in Lifetime Statistics doesn't add up.
Compared to my trip distances since the update (88km) it was missing 22km.

I just pulled the setup file from the CA to make sure the file on my computer and the file from the CA have identical settings.
While at it, I've corrected the 'Odometer distance' (to 6,292km) and tweaked the 'Assist Power Factor'.

After writing the setup back to the CA, the 'Odometer distance' in the CA showed 6,348km!
Pulled the setup file from the CA again and it still was at 6,292km in the setup utility.

After power cycling the CA, restarting the Setup Utility and writing the setup file to the CA again it worked, though.
Yep - there is a known issue with Lifetime mileage.

The Lifetime mileage (EEPROM) is maintained separately from the Trip mileage (RAM+EEPROM) and is only updated with the accrued Trip mileage on a Trip Reset. So - in order to make the displayed Lifetime Stats in the CA appear correctly, the Trip mileage is added to the Lifetime mileage to show how things -should- look, even though the EEPROM Lifetime mileage is still not updated. The Lifetime mileage in the Setup Utility lacks the Trip mileage component and so may differ from the CA display.

Importantly: Without going into annoying details, when a computer accesses the CA via the serial port to read or write data, the EEPROM Lifetime mileage is not updated and the Trip mileage is lost. In short - simply looking at the CA with the Setup Utility will erase Trip data.

This is an original design issue and isn't new with the 3.1 beta code - it's just a little hard to notice... (good pickup on your part!)

The workaround is to do a Trip Reset to force EEPROM update before using the Setup Utility.
Anyhow, this is on the 'fix' list, but other stuff just got higher priority so far... ;)
 
teklektik said:
Hey madin88!
Thanks for the kind words.
Appreciated! :)

Totally agree with madin88.

I don't wish to embarrass you teklektik but honestly, I've been baffled for a very long time why this forum doesn't recognize you with guru (blue) font? Maybe you don't want it but if it were left up to me it would've happened a long time ago.
 
Hi teklektik:

Justin discussed offering a technique of applying variable regenerative braking by sensing backwards crank spinning, where faster spinning commanded more regen, and slower spinning commanded less. I see this listed without an ID in the "planned features" list on Grin's CA3 page.

http://www.ebikes.ca/product-info/cycle-analyst-3.html

With the current system of throttle-mediated regen intensity I need two hands or good finger dexterity on one hand to effect variable regen, one hand (or finger) holding down a button or partially engaging a brake lever while using the thumb or opposite thumb to vary the throttle. It's a slightly awkward arrangement that I can manage ok, but my fingers get fatigued on long descents when I use regen. In this case, "long" is 15 minutes or longer.

I'm not sure how workable backward-pedaling regen is on some drivetrains as fast backward pedaling can throw a chain if the return chain run is long or the chain becomes stiff. But, I'd like to try it some day.

Can you give us some idea when this feature might be available?
 
Hi teklektik and others:

I have converted both of my e-bikes to use direct-drive hub motors with ASI's 12-FET controller, using many of the CA3's features to improve the power train's ergonomics and usability. I have been mostly pleased with the conversion to direct-drive hubs overall. But, the availability of high torque at low speed is a feature of the crank-drive motor I have missed. I think this calls for a software solution that does not appear to be addressed by the current CA3 feature set.

I often find myself in a situation where I need to apply a burst of high torque when starting from a stop or at very low speed (<6kph), especially on uphill grades. While some of the smaller DD hub motors cannot generate sufficient torque even when driven by a controller capable of high output current, some of the medium or larger sized DD hub motors are capable of supplying sufficient torque even at zero speed when driven momentarily by high current.

Although I program my CA3 to limit power drawn from the battery to 750 or 1000 watts, even 1000 watts (20 Amps at 50 volts) is occasionally insufficient to get the bike moving. And, I should note, that when the power and current gain parameters are properly set, I get very little power/current overshoot. I don't believe that relaxing these to allow a broad power/current overshoot is a good solution to the problem.

I have on these occasions put my CA3 in "unlimited" mode so that I could power out of the rut, so to speak. So, I know that the motor and controller are capable. They just need to have their power/current restrictions relaxed briefly.

I would like to have low-speed Power EQ available, a mode that relaxes the power and current limits when vehicle speed falls below a certain set speed (e.g. 6 kph). Since DD hub motor efficiency falls off significantly below some RPM, say below 100 rpm, the actual power getting to the road at low speed is significantly less than the power drawn from the battery and may, depending on the amount of boost, remain within legal power requirements.

Low-Speed Power EQ or Boost is typically not sustained since once one gets started the bike will almost always accelerate to a speed at which the motor can operate efficiently, so I don't have a concern about too much heat being generated or of wasting too much energy. This capability is needed only occasionally to get started or perhaps to climb an unusually steep but short grade.

The old Xie Chang controller software offered a "Block Time" parameter that attempted to do something similar by relaxing the controller's current limit for a certain number of seconds (rather than below a certain speed), but the effect is similar.

Low-Speed EQ might require the following new parameters:

transition speed below which EQ is operative
maximum power/current at zero speed
time limit in EQ speed range

The power/current limit would be scaled linearly from the normal Max Power or Max Current at the transition speed, increasing to the maximum power/current at zero speed. The time limit can be optional, but if offered, give an option for unlimited time. I'm also thinking that this should only be available through throttle control, since the application of fixed PAS power during low-speed EQ or Boost could be dangerous or disconcerting.

I look forward to hearing your and the community's thoughts.
 
I wrote earlier an inquiry re: the progress of backward-pedaling mediated variable regeneration:

mrbill said:
Justin discussed offering a technique of applying variable regenerative braking by sensing backwards crank spinning, where faster spinning commanded more regen, and slower spinning commanded less. I see this listed without an ID in the "planned features" list on Grin's CA3 page.

http://www.ebikes.ca/product-info/cycle-analyst-3.html

With the current system of throttle-mediated regen intensity I need two hands or good finger dexterity on one hand to effect variable regen, one hand (or finger) holding down a button or partially engaging a brake lever while using the thumb or opposite thumb to vary the throttle. It's a slightly awkward arrangement that I can manage ok, but my fingers get fatigued on long descents when I use regen. In this case, "long" is 15 minutes or longer.

I'm not sure how workable backward-pedaling regen is on some drivetrains as fast backward pedaling can throw a chain if the return chain run is long or the chain becomes stiff. But, I'd like to try it some day.

Can you give us some idea when this feature might be available?

After riding again yesterday and descending two 500+ meter descents, using regeneration to recover significant energy, I thought of another way to relieve some hand/finger fatigue during long regeneration sessions like this, that may work more smoothly and not suffer the downsides of backward pedaling (thrown chains, pedal clearance issues in corners, etc.).

Would it be possible to add variable regeneration control to the AuxPot function?

The way I visualize this is that when one is in regeneration mode (i.e. eBrake circuit closed), one could adjust the AuxPot to adjust the amount of regeneration. What would be particularly useful is to adjust the AuxPot to set the vehicle speed the CA3 attempts to hold, while varying the amount of applied regeneration.

I've found that using a speed cruise control or AuxPot to set driving (powered) speed to give somewhat uneven, jerky behavior over slightly varying terrain, causing the bike speed to drift about the set speed. I much prefer when driving to have AuxPot adjust current or power (when power is applied by PAS activity). But, for regeneration I think vehicle speed may be more useful parameter to adjust than power.

Downhills vary their grade over short distances, and a constant power/constant current approach to regeneration will result in speed that varies too much, to the point of stopping the vehicle if the grade levels out for a short distance. When descending one is generally moving faster than when climbing, at least on a low-powered e-bike.

I find that when I use regeneration on descents, I'm aiming to hold a moderate descending speed that is a compromise between being too fast to recover significant energy that is otherwise lost to wind resistance and so slow as to be tedious. My usual descending speed when in regeneration is usually between 25-40 kph.

So the added functionality I visualize would allow one to optionally set a MaxRegenSpeed and adjust the RegenSpeed between MaxRegenSpeed and 0* using AuxPot, when the CA3 eBrake circuit is closed. The CA3 will then vary throttle output in accordance with the eBrake protocol (0.85 down to 0.0 volts) to maintain a vehicle speed no greater than the RegenSpeed. The throttle itself would continue to function as it does currently, allowing the user to apply more or less regeneration on demand, overriding the RegenSpeed setting.

*It may be more intuitive for RegenSpeed setting to be lowered with advancing AuxPot position, the full-CCW position of a higher RegenSpeed resulting in the least amount of regenerative braking applied, and a full-CW position of a lower RegenSpeed resulting in the highest amount of regenerative braking applied. The AuxPot would adjust the speed downward with advancing position.
 
Back
Top