Cycle Analyst V3 preview and first beta release

[john61ct]

Does activating the brake not failsafe-cut all power / assist, override every throttle signal?

 

[aum]

Gonna tell people cycling backwards charges the battery after updating to latest beta

yea, but this only works uphill, downhill not at all. though i have not really tested it

lol

have fun

aum

 

[aum]

olo

i am troubleshooting regen braking with my 2 pcs golden motor magic pie 5 edge e-motors
i surfed the web, only info i could find is:
- for regen braking to work, battery has to be somehow empty
- the speed has to be 10+ kmh (6.2 mph)
i have my throttle connected to ca3.1(4) wp (8 wire plug)
i have tried all possible combinations, yet i can feel no regen braking from e-motors

in un-official ca3 user manual, long version, page 35/77, there is case 2 description, and it says, that some controllers/e-motors also need e-brake signal (wire) connected, along with e-brake connected to ca3 (e-brake) input

question:
does golden motor, magic pie 5, edge e-motor controller(s) need to be connected to e-brake (signal) wire, along with ca3 being connected to e-brake (signal) wire ?
and, since i have 2 edge e-motors, and only one e-brake, will 1 e-brake signal suffice for both e-motors - meaning i will
1) re-purpose ca3 key return wire (both thermistor and speedo wires are already taken, and working fine), as e-brake signal wire, and
2) split this ca3 (key return) e-brake wire between both e-motors

in other words, what do i need to do for regen braking to work with my ca3.1 and 2 pcs gm mp5 edge e-motors ?

thank you for your cooperation

have fun

aum

 

[amberwolf]

The MP motors Iv'e seen generally have internal controllers. Some of those have programmable settings for some things; you would need to use whatever software and cabling (if any, might just be bluetooth to an android or ios app for your phone) Goldenmotor provides for your specific version of the MP motors to ensure regen is enabled and setup the way you want, if there are any options for this (there may not be), assuming they are even capable of regen at all (not all controllers are).


It is very likely that the MP does not use the throttle to control anything other than forward motor motion; they probably only have on/off regen braking controlled by an ebrake switch input, so to activate it you would need to directly connect your ebrake lever to that.

The CA cannot control that form of regen/braking. It can only proportionally control regen/braking if the controller uses part of the throttle range on the main throttle input to do this, like some of the Grin Tech controllers do (phaserunner, etc).

 

[mrbill]

Hi Folks:

I recently updated my CA3 firmware to the latest beta version 3.2b2. Oddly, I saw no announcement of either this beta or the prior on this thread. Most of the changes add different options and modes for regeneration (motor braking) implementation.

One of the changes I discovered was additional choices of temperature sensor, in particular two styles of directly connected 10K NTC sensor, one with b=3900, the other with b=3450. My prior firmware (v3.12) offered only one style of 10k NTC thermistor.

The thermistors in my motors were obtained from the same batch of surplus "10K NTC" thermistors I procured from a local surplus outlet. Although the price was right, no other specs were provided by the vendor.

With the new firmware set to use b=3900 I believe but am not certain that I am seeing lower temperature readings with the new firmware than with version 3.12, especially at the high end of the range (near 100C). But, perhaps these new readings are correct and my prior readings were inflated.

Can anyone check the data I collected from an experiment I conducted today that shows temperature vs sensor resistance and tell me which sensor type offered in the CA3 v3.2b2 firmware is going to give me the most accurate measurement?



Thanks.

 

[amberwolf]

If it helps, you can calculate the general beta of a particular NTC thermistor with this handy calculator
http://www.learningaboutelectronics.com/Articles/NTC-thermistor-beta-calculator.php
after doing some measurements.

NTC thermistor beta formula

(calculator stuff:
Enter the Resistance, R1:
Enter the Temperature, T1:
Enter the Resistor, R2:
Enter the Temperature, T2:
Beta, β: )

This NTC thermistor beta calculator calculates the beta (β) value of the NTC thermistor based on two points of resistances of the thermistor with their corresponding temperatures.

So this calculator needs 2 different, distinct resistance values along with their corresponding temperatures to be able to calculate the beta value of the thermistor.

The beta value is an indication of the shape of the curve representing the relationship between resistance and temperature of an NTC thermistor.

Know that the curve of the resistance vs temperature of an NTC thermistor is not linear unless the NTC thermistor is specifically a linear thermistor; otherwise, the relationship is logarithmic and it varies according to the specific type of NTC thermistor being used.

The beta value helps to paint the curve for the specific thermistor in use .

As stated before, this calculator needs 2 pairs of resistance-temperature values, and then it can compute the beta value. To use this calculator, simply enter in resistance R1 with its corresponding temperature value, T1, and resistance R2 with its corresponding temperature value, T2, and then press 'Calculate'. The resultant beta value will then be calculated and displayed.

The beta value is in unit K (or Kelvin).

 

[mrbill]

If it helps, you can calculate the general beta of a particular NTC thermistor with this handy calculator
http://www.learningaboutelectronics.com/Articles/NTC-thermistor-beta-calculator.php
after doing some measurements.

Hi amberwolf:

Thanks for the reference.

I plugged in a bunch of different value off my worksheet, and I get a beta between 2600 and 2800--my data are a bit noisy. Unfortunately these figures are a ways off the two available parameters in the 3.2b2 firmware: beta = 3450 or 3900. I suppose 3450 is the closest. Perhaps Grin could allow the user to set the beta for whatever 10k NTC thermistor is being used.

 

[amberwolf]

Somewhere around here is the method you can use to tweak the CA settings to better match the actual thermistor in use (assumign the new version has the same settings available). It's probably by Justin_LE, so searching his posts for "thermistor" or similar words might find it. I'm heading out for work so dont' have time ATM to check.

I expect the reason there aren't a bunch of presets is lack of memory space--that's what comes up as the reason many times a feature suggestion cant' be implemented.

 

[lightrush]

Just tried the 3.2b2 today with my Erider-based PAS setup and I have to say - after so many years we finally instant torque from standstill! I first used a CA to control my system in 2016 coupled with a Thun BB. New torque sensing BBs like the Sempu T2, then T4 improved responsiveness. So did added features in the CA. I had managed to dial-in the current iteration of my system to have a near-instant torque by carefully adjusting various thresholds in the system to trim delays. The result was decent but it still required some 5-20 degrees of rotation before engagement. NO MORE! I almost teared up. :lol:

 

[john61ct]

Yaay Justin!

 

[amberwolf]

Sounds like I can drop the idea of the first Nano Tidbit here:
https://endless-sphere.com/forums/viewtopic.php?f=2&t=110497
unless people would find it useful for non-PAS controllers to give them that.

 

[lightrush]

Sounds like I can drop the idea of the first Nano Tidbit here:
https://endless-sphere.com/forums/viewtopic.php?f=2&t=110497
unless people would find it useful for non-PAS controllers to give them that.

Really nice idea! I've independently almost resorted to doing exactly that - getting an Arduino or a small Pi to convert signal from a peripheral to force the CA to do something I wanted. But yes, finally **that particular one** is no longer needed. I've also had another much more blasphemous thought - creating an open-source, clean-room CA implementation in a high level programming language, using one of the widely available controller/computer ecosystems of today. Those things didn't exist when the CA was created and the barrier to entry to creating a device like that for a software guy and an electronics noob was huge. Today with tons of off-the-shelf components, not so much. There's still however a large amount of math in the CA that will require a significant amount of work to re-create without crashing people into things. In general I think we're all worse-off (Grin included) for not having an open-source project that implements a generic, extendable, high-level bike computer. Grin's stuff is as close as we can get to that. Even though they're incredibly transparent and tinkerer-friendly for a proprietary vendor, I would have been able to fix at least a few bugs I've encountered over the years if the firmware was open-source. With all that said, the CA as of 3.2b2 is pretty much *perfect* for my use case so my motivation is at an all time low. :lol:

 

[amberwolf]

Over the years, several people have created "CA-like" computers, but I don't know of any of them that have publicly available repositories of documented code or schematics that would let someone else reproduce one, or customize it.

I don't know programming to be able to do it myself, which is why I made that thread about the tidbits because I thought it would be relatively easy to just alter some of the input and let the CA handle the stuff it does do "right" but I'm always tired and it gets harder and harder for me to self-motivate to do things except what has to get done right now (or else not be able to do some daily required task, etc without it). Working with other people that are doing the same project(s) and not always waiting for me to decide everything and define everything and "do" everything, but would take my input when I do have it, would be motivating. I just haven't found that yet (don't expect to).

I have a lot of ideas about how stuff could or should work, and some of how to implement it, but not enough knowledge/time/skills/money/etc to actually do most things I can think of. Just hacking stuff together out of existing stuff is pretty much my limit to most projects.

But if you wanted to try doing an OSFW CA-type device, that's a project I could get behind.

 

[justin_le]

I recently updated my CA3 firmware to the latest beta version 3.2b2. Oddly, I saw no announcement of either this beta or the prior on this thread. Most of the changes add different options and modes for regeneration (motor braking) implementation.

Hey everyone and sorry indeed that I haven't posted anything on this thread to keep people updated about CA development and I'm encouraged to see that there is still quite a substantial interest and following and that the CA3.2 features have been quite well received. We did a short video summary of the key 3.2 updates here:

[youtube]6v-_HECwBAQ[/youtube]

To try this out, you just need to click the "Get New Firmware" button in the CA setup utility and select Beta firmwares, and then you'll get the CA3.2 beta builds as well as the CA3.15 betas


Then expand the "Beta" tab when selecting firmware releases to flash and you'll see the 3.2 releases there, currently at 3.2b3.



We'll be keen to get any further feedback and bug reports from a wider pool of beta testers here, so if you've been on the testing side of CA stuff in the past feel free to give this a go. There is also a 3.15b6 that should (afaik) address every known minor bug or issue that came up over the years of CA3.14 being the primary release FW.

 

[justin_le]

Just tried the 3.2b2 today with my Erider-based PAS setup and I have to say - after so many years we finally instant torque from standstill! I first used a CA to control my system in 2016 coupled with a Thun BB. New torque sensing BBs like the Sempu T2, then T4 improved responsiveness. So did added features in the CA. I had managed to dial-in the current iteration of my system to have a near-instant torque by carefully adjusting various thresholds in the system to trim delays. The result was decent but it still required some 5-20 degrees of rotation before engagement. NO MORE! I almost teared up. :lol:

Ha ha sweet, and glad to hear that this has found it's some happy users and I really apologize for how long it took to get this particular behavior released. We had a branch on it back in ~2015 or so when THUN sensors were the most popular model with their single side torque sensing, and back then struggled to get a good behavior we felt was release worthy. But there was no excuse for it to lapse for so long.

The 3.2b2 will always power the motor without cadence if the torque is higher than the start threshold setting, and in some cases if you are standing on the cranks while coasting that will produce sufficient torque signal to power the motor even though you aren't actually pedaling. On the CA3.2b3 the start threshold torque only applies if the vehicle is at a standstill to address this.

One thing that was added to the firmware release process some years ago is a thorough set of release notes that are visible in the extracted folder as a .txt file and also visible if you just go help -> help when you have the firmware file of interest loaded in the setup utility. This makes it easy to get a quick view of what's been either updated or fixed. I see some people have found this which is great but it's worth me calling it out explicitly:




So for instance, the discussion about the new thermistor modes is mentioned under the CA3.15b1 release notes



In general every change since the first CA3.1 release has been cataloged this way

With the new firmware set to use b=3900 I believe but am not certain that I am seeing lower temperature readings with the new firmware than with version 3.12, especially at the high end of the range (near 100C).

That original "10K NTC" lookup table hasn't been changed, just renamed to b=3900, so the displayed temperatures are the same. What we found is that Bafang and other geared hub motor manufacturers started supporting 10K NTC thermistors in their geared hub motors but they tended to have beta constants of around 3400-3500. The lower Beta is somewhat advantageous since it means the resistance doesn't drop off as much at elevated temps and you continue to get decent resolution up at really high temps like 120-150 oC. And in the case of Bafang, they included a 10K pull-up resistor to 5V hall power already inside the hub itself which further changes the shape of the curve.

Here is how the 3 different CA options relate the measured voltage to the computed temperature

Can anyone check the data I collected from an experiment I conducted today that shows temperature vs sensor resistance and tell me which sensor type offered in the CA3 v3.2b2 firmware is going to give me the most accurate measurement?

1710 ohms at 100oC would mean you have a beta of about 2600, so none of the 3 options is particularly good for accurate motor temperature reporting, but you can easily make a translation table.

 

[justin_le]

I will try to catch up and reply to many older posts from the last few pages of this thread this week. However, I first wanted to mention with an extremely sad heart that the former ES user Teklektik passed away earlier this month after a battle with cancer. People on this forum will know him from his helpful and rigorously detailed technical posts over ES, and especially in this CA3 thread.

What you may not know is that he also took the entire Cycle Analyst firmware development off my plate back when it was still in a "prelim" release phase. Over the course of ~8 years he brought it to a formal 3.0 release, then implemented all the features for CA3.1, then all the custom Solar and GPS firmware branches. In the course of that he took what was a single file 4000 lines of assembly code and created a comprehensive development environment with all kinds of custom scripts to automate the release process, bug tracking, documentation, and integration with our CA setup utility software. We would have a ~1 hour scheduled skype meeting once a week to review the plans and he just ran with them and applied a much needed rigor that only a retired software engineer would bring to the table.

While he could sometimes seem to have a "cranky old man" behavior and fell out with the ES forum in his later years, he continued working away on the CA roadmap. From 2019-2020 this effort was focused almost entirely on porting the code to a more modern microchip platform. But unfortunately a terminal cancer diagnosis in late 2020 abruptly ended that and instead great effort went into detailing and documenting the development process such that it could be handed off to a successor. After some false starts that in turn came round full circle back to me, and in early 2021 I was effectively re-onboarded to this project I had started quite naively back in 2004, only now with Alan showing me how to do things the 'right' way! And it's been a trip, and I'm confident we're on the right track now.

Anyways Alan Fortier AKA Teklektik, we will miss you and the ebike community will be forever appreciative of your contributions.

And for those wondering:

Yes I think it unlikely CA will see further development. I bet there is only one, that being Justin, and
indeed higher priorities occupy his time.

Luckily it wasn't going to end at CA3.14 Of course it's a bit silly to keep plugging away on such a dated platform, but it's also oddly rewarding to eek out more and more features and CA3.2 is getting us much closer to what could be the 'final' vision.

 

[justin_le]

What I like to know... Justin or or someone else!

(8) 8235 - (New) Wheel Torque Sensor PAS Option

This change affects the eeprom configuration with the addition of new
parameters and removal of the 'Absolute Max Current Limit' OEM setting. Firmware
updates will set these parameters to defaults.

How much is default Absolute Max Current Limit???

One trick is that you can see the default for any setting with the setup utility software just be creating a "New Setup" and choose the appropriate firmware version then scroll down to the setting of interest. The values in the SU software are the same as what is flashed by default on the CA

In this case you can see that it was defaulted at 99.99A (for standard range mode, or 999.9A for higher range mode.)

 

[lightrush]

@justin, think about whether open sourcing the existing or a future codebase for a new platform might be a net benefit for you. Even if that's under a restrictive license that gives you copyright over all source contributions, giving you the ability to re-license the complete codebase at any point in time.

RIP @Teklektik

 

[john61ct]

RIP

And kudos to Justin, thanks for updating here, and for all you've done, and do for the community

 

[justin_le]

@justin, think about whether open sourcing the existing or a future codebase for a new platform might be a net benefit for you.

Yeah I follow OS hardware / software projects with some interest to see when and where this approach makes sense. But the current CA3 codebase and architecture just isn't suitable for that model. It's all highly optimized 8-bit assembly and takes even a seasoned low-level firmware guy a few months just to have a handle on things to make even a modest change. There are so many more ways to inadvertently break the code and introduce bugs than there are to make improvements and the learning curve isn't really worth it to for a casual pursual.

But I've always heartily encouraged anyone else wanting to pursue a CA like device on an more modern platform to go ahead. The standard CA controller interface (original 6 pin JST and now 8pin HiGo) is a great plug standard that doesn't rely on any special controller communications making it quite universal and non-proprietary. And there are so many advantages to decoupling the controls (ie PAS, regen, throttle, ebrake etc. behavior) from the motor controller.

 

[justin_le]

Gonna tell people cycling backwards charges the battery after updating to latest beta

Ha ha I hadn't thought of that angle but what a great reply to "does it recharge when you pedal??" ! :lol:

Also glad there's an auto regen speed limit seperate from the speed regen setting

Cool, I'm interested to hear more firsthand user feedback on this and what your use case is. One important update for the regen speed limiting is a new global "Gain Adjustment" for all the PID parameters when you are in regen mode vs forward power mode, as that lets you separately tweak the control loop during regen from power.



Generally this should be set so that the slope of the (motor amps) / (throttle volt) ratio is the same in the regen throttle region as the forward throttle region. Example suppose you have a baserunner or phaserunner that has say 80 amps of max phase current and 40 amps max regen current. And a signal range from 1.2-3.6 V for power and 0.3-0.9V for regen.

The forwards throttle response is scaled at 80A / (3.6-1.2V) = 33A/V.
Meanwhile the regen throttle response is scaled at 40A / (0.9-0.3V) = 66 A/V

ie, every mV of throttle motion during regen causes double the torque change in the motor, making the output controls more sensitive. So in that case, you would want to set the Regen Gain Adjust value to 50% to have exactly the same PID control loop response during regen speed limiting as you have during acceleration. If you were to increase the max regen of the controller to be 80A instead of 40A for higher peak braking force, then you should similarly reduce the Gain Adjust value to 25%.

 

[lightrush]

It's all highly optimized 8-bit assembly and takes even a seasoned low-level firmware guy a few months just to have a handle on things to make even a modest change.

Yes if it's all assembly, you're probably right. C is as low as one could go that allows for decent collaboration while providing damage control.

 

[justin_le]

Zero start from above specific crank torque (40nm in my case) works perfectly...however once I am pedalling I assumed that if the crank torque drops below threshold torque then PAs would cease but mine carries on no matter what I set torque threshold to...I have tried up to 50nm which seems to be the max and down to 10nm...it stays adding pas no matter it is set to even with the lightest of pressure well below the threshold value...albeit less but it does mean I basically have to stop crank movement to change gear without crunching the cassette...any ideas?

Hey Ham, yeah as long as there is pedal cadence detected then the CA3 will continue outputting PAS power. But you can definitely set it up so that below a certain pedal effort the computed PAS output power falls down to zero watts.

In the CA3.15 and earlier firmware, the setting

PAS -> Strt Level was the minimum amount of human watts that must be present on the pedals for the power assist to engage, so if you set this to 60 watts then light pedaling resulting in <60W of human power would mean zero output power.

The formula was basically:

Output Watts = (Human Watts - Strt Level)*(Scale Fctr)

With the CA3.2, we changed this around completely, so now Strt Level is the amount of power present with zero torque on the cranks, and then it increases from here based on your human watts:

Output Watts = Strt Level + (Human Watts)*(Scale Fctr)

In this case, if you wanted the behavior where you need a minimum amount of force on the cranks to get any output power, you need to set Strt Level to a negative value. If your scale factor is 2 W/hW, then a start level of -100 watts means that the motor power will drop off whenever there is less than 50 watts on the cranks.

Output Watts = 50W * 2 W/HW = (-100W) = 0W

So give that a try and let me know if has the behavior you are seeking. If you want the cutoff to be fast, it's good to make sure your WGain setting in the Power Limits setup menu is as high possible without being jittery, and the TrqAverage term corresponds to half the PAS poles of a full crank rotation.

 

[mrbill]

1710 ohms at 100oC would mean you have a beta of about 2600, so none of the 3 options is particularly good for accurate motor temperature reporting, but you can easily make a translation table.

Any chance you could in some future release parameter-ize the NTC temperature sensor data by allowing the user to enter the resistance at 20C, beta, and optionally, the pull-up resistor value? This would allow for most or all varieties of NTC sensors.

 

[Cowardlyduck]

Thank you Justin for jumping back on and letting us all know what's going on.

While were on the topic of the future of the product, have you considered investing in creating a replacement?

I definitely think there is a market for something like a Cycle Analyst, but build with a more modern screen and interface. I don't know of any existing display that can integrate with so many controllers like the CA can. IMO a modern equivalent would probably be moderately successful and should make back the investment costs if not make a small profit.

I do hope the CA will continue to exist in one form or another for some time yet...I don't know what I would use on all my builds for myself and others were it not for the CA.
The only other display that comes close atm is the Nucular, but you have to buy a Nucular controller to get that and the wait time and price is undesirable.

Cheers