Cycle Analyst V3 preview and first beta release

[justin_le]

i wish justin would show up again, and give us a short update. it's more then 9 MONTH now that pre6 was released. that's the time a BABY needs to be born. should be enough time to go from beta to release.
and maybe update the community if this is still a supported product ... or do i ask for too much???

No you don't ask for too much Izeman! I called it a preliminary release just because as a complete official product, I wanted to also have both a complementary set of software and documentation to go along with it. Teklektic has done a fabulous job helping with the latter bit, and I've got good news about the other bit too. We're basically ready to release a software program that lets you connect the CA to a computer and then see and edit all of the setup menu settings in bulk. It's attached as a file to this post and also available to download here:
http://www.ebikes.ca/documents/CASetupUtility-1.0.2.exe

There have been a few people testing this over the past few weeks and I think most of the kinks have been ironed out. When you launch the program, it shows the default configuration of all the CA3 settings like this:


From the file menu or the buttons, you can read and write settings from a CA device, and you can also save and load configurations from a .hex file too. So if you have a bike that is particularly dialed in and want to save that configuration for later, you can create a .hex file with all those variables, then you can mess around with stuff and restore your favorite settings.


When you read or write data to the CA, you just need to select the serial port from a pop-up window and hit OK.
View attachment 3
Just keep in mind that the CA needs to be in operating mode. If it's in the setup menu and you try to read or write, then it won't connect and eventually the software will give a timeout error.

In the preferences menu, there is an option to show the protected settings. When you do this, some of the deeper calibration data is editable if you enable the associated checkbox, and I really don't recommend changing any of these since there is no way to restore what they were originally at. The one exception is the voltage scaling in case people are using an external voltage divider:


There is also at the end a table of OEM settings that aren't accessible via the button presses. The absolute max speed, power, and current limits set clamps to what you can input as an active speed, power, or current limit in the main setup menu. So if you were to set absolute max power to 1000 watts here, then if someone created a preset with a 2000 watt limit, it would still get clamped to 1000 watts. I can see this crowd not exactly jumping with excitement
But the other OEM feature is a set of masks for every item in the setup menu which could be of value to DIY types. If any of these items is unchecked, then the associated setup parameter is no longer accessible via the setup menu. So if you don't want any of these variables to appear, just uncheck the box and they'll no longer be present in the button menu.


The last thing to mention is that if you want to view and edit multiple setup files at once, or say compare to two setups side by side, the in the preferences you can enable multiple files, and each one shows up as it's own tab in the window. Every time you read from a CA, the settings appear in a new tab without overwriting the settings that were previously open:


One important thing to note. The software only works with the V3.0 Prelim6 firmware. If you connect to a CA with older firmware, the data you read will be increasinly nonsense depending on how far back the firmware release is. And if you try to write to a CA with older firmware using this program, then all kinds of funny behaviors could result. We are working on having a firmware version included in the code so that the software can automatically detect which FW is on the CA and then show the appropriate list of settings, but that is not currently implemented. This (getting back to the original thread topic) is one of the other reasons that the current firmware is still called prelim rather than V3.00, because I want the entire set of official firmware releases all to be compatible with one piece of user software. Hope that makes some sense.

Anyways we are actively working on this software right now, so any feedback and reports of bugs or glitches are greatly appreciated as we can fix things in a timely manner. Once that is done it's back to CA3 firmware coding again, and thanks tons to all those who have been patient for the last 9 months. -Justin

 

[izeman]

how cool is that? instant download thanks justin!
i will test this weekend, when back from my business trip and report ...

 

[hjns]

wow, Justin is back, and with a superduper update!!!!

Thanks again, Justin et al!

 

[electricwheels.de]

How cool that is ...
And to get playing with it before the Americans wake up :wink:

 

[zener]

THANKS JUSTIN!
That's what all CA3 owners have waiting for. (easy setup after new flash and maybe serial production of ebikes )
Now only the option to show the motor temperature all the time and its almost perfect.

 

[Supertux1]

Thanks teklektik. I don't want to use the 3 way switch to toggle presets. As the first one is the legal setting. In case I get stopped by the police I don't want a visible switch to enable full power mode. So maybe I can use the switch to cut the throttle voltage to let's say 30, 60, and 100%. This would be the same for all presets but would tame the throttle if needed?

Okay - I certainly see your point.

If you are running Current Throttle (ThrI->CntrlMode = Current), you could use the switch to change the current (eg 100%, 66% 33%) which should make things much more manageable. Since in this case the switch first scales PLim->MaxCurrent and then Current Throttle scales that result, you can try this out by just scaling back MaxCurrent to test if the switch will give you what you need. If it seems to do the job you can then install the switch to do it on the fly.

This is what I do on mine, I set the max amps to 30A so I know I'm getting a fraction of 10A, 20A or 30A when I twist the throttle.
I'm using the ebikes.ca 3 speed switch with resistor dividers. If you have the same I can get you the voltage values to make it %33, %66 and %99. (At work now.)

 

[mike.jarvis]

Great work and controller. I'm personally very interested in capturing data history on my cell phone to utilize in ride analyses projects. I have read through every post yet to find this, but if that is already in there or planned, it would be a great upgrade. The data I'm most interested in is the torque input for the ride, but all data points taken at a set intervals and saved on a ride per ride basis would be ideal. I envision a bluetooth connection to a smartphone that records the data at intervals you set and can be used by apps to combine with GPS, etc...

Much like garmin does here on my commute log...

http://connect.garmin.com/profile/mike.jarvis

I'm planning to build my own stealth commuter and would love to be able to profile the data from this controller. Honestly, I would rather keep the smartphone in my holster on my backpack strap and not have a cable connection to it either.

Mike

 

[teklektik]

I'm personally very interested in capturing data history on my cell phone to utilize in ride analyses projects.
I envision a bluetooth connection to a smartphone that records the data at intervals you set and can be used by apps to combine with GPS, etc...

Please see section 5.10 "Serial Data Port" of the Guide for available stream data, format, and interface.

 

[justin_le]

Great work and controller. I'm personally very interested in capturing data history on my cell phone to utilize in ride analyses projects. I have read through every post yet to find this, but if that is already in there or planned, it would be a great upgrade.

Hey Mike, there are a few other threads covering that topic but the short answer is that there isn't a straightforward off-the-shelf means to log data to a cell phone yet. However, it is possible with a serial to bluetooth wireless adapter, and Bartimus has come a long way towards getting an android app interface worked out:
http://endless-sphere.com/forums/viewtopic.php?f=2&t=45661

If any phones still had IrDA interfaces then it could be really easy, but it doesn't look like the infra-red serial standard really made it far into this millennium.

-Justin

 

[maττ]

When you posted this on April 1st I wasn't sure what to make of it... but it's real. I'm thrilled. Also, nice defaults!

 

[justin_le]

When you posted this on April 1st I wasn't sure what to make of it... but it's real. I'm thrilled.

Oh shoot, didn't even check the dates, that was missed opportunity

Anyways, there is now a V1.0.3 update with some very minor tweaks, one of which sorted an issue that was preventing Teklektic from running the program with an older processor. Has anybody else gotten error messages when trying to launch the V1.0.2 build? So far we haven't heard much one way or another, so hopefully no news was good news in this regards. The 1.0.3 version is here:

http://www.ebikes.ca/documents/CASetupUtility-1.0.3.exe

 

[Merlin]

i had no problems on 2 laptops.
one business new one and a 6 year old DELL Laptop.

works fine.

have you read it about chaning battery soc to wh?
maybe there comes enough space to make
for each preset individiual Gain settings.

 

[zener]

i had no problems on 2 laptops.
one business new one and a 6 year old DELL Laptop.

works fine.

have you read it about chaning battery soc to wh?
maybe there comes enough space to make
for each preset individiual Gain settings.

Yes its very confusing that the CA runs with (KW/KWh/Wh/W) and (A/Ah) simultan with gain's and limits and diplaying.
Thats what the German Forumscontroller made better.

It would be less confusing and cleaner if everything is only in (KW/KWh/Wh/W) and as Merlin say'd the SOC is calculated for the given max. battery Wh.

 

[teklektik]

have you read it about chaning battery soc to wh?

Yes its very confusing that the CA runs with (KW/KWh/Wh/W) and (A/Ah) simultan with gain's and limits and diplaying.
Thats what the German Forumscontroller made better.

It would be less confusing and cleaner if everything is only in (KW/KWh/Wh/W) and as Merlin say'd the SOC is calculated for the given max. battery Wh.

Earlier explanation of Ah as true SOC measurement vs Wh that varies according to rate of discharge here.

 

[zener]

have you read it about chaning battery soc to wh?

Yes its very confusing that the CA runs with (KW/KWh/Wh/W) and (A/Ah) simultan with gain's and limits and diplaying.
Thats what the German Forumscontroller made better.

It would be less confusing and cleaner if everything is only in (KW/KWh/Wh/W) and as Merlin say'd the SOC is calculated for the given max. battery Wh.

Earlier explanation of Ah as true SOC measurement vs Wh that varies according to rate of discharge here.

Ok i understand that.
But it would be better to display %% of the left Ah as SOC. Better to read.

Why there is gain and limits for both A and KW thats for me confusing.

 

[teklektik]

Why there is gain and limits for both A and KW thats for me confusing.

Please see section 4.9 'Adjust Gain...' of the Guide.

In short, AGain and WGain are gain parameters for two different PI controllers - one that limits current and the other that limits power. The Power PI controller is also used for the PAS system so having two different PI controllers with separate gain settings turns out to be handy - AGain can be adjusted for desired response for Current Throttle and WGain can be adjusted to give smooth PAS operation - the former is generally set for brisk response and the latter for a much more heavily damped response.

If you don't wish to be concerned about both, there is no reason to use both.
For instance if you wish to use MaxCurrent as your defining limit, then leave MaxPower at the 9900W default and WGain will never come into play (and therefore need not be adjusted from the default).

 

[zener]

Why there is gain and limits for both A and KW thats for me confusing.

Please see section 4.9 'Adjust Gain...' of the Guide.

In short, AGain and WGain are gain parameters for two different PI controllers - one that limits current and the other that limits power. The Power PI controller is also used for the PAS system so having two different PI controllers with separate gain settings turns out to be handy - AGain can be adjusted for desired response for Current Throttle and WGain can be adjusted to give smooth PAS operation - the former is generally set for brisk response and the latter for a much more heavily damped response.

If you don't wish to be concerned about both, there is no reason to use both.
For instance if you wish to use MaxCurrent as your defining limit, then leave MaxPower at the 9900W default and WGain will never come into play (and therefore need not be adjusted from the default).

But i must have PAS (EU) can i only use the power PI controller ?

 

[teklektik]

But i must have PAS (EU) can i only use the power PI controller ?

Sure. That's actually what I do. I use a Power Throttle and AutoTorqPAS so only WGain is in play. I have gear motors so the low WGain setting works both for PAS and keeps me from smoking the clutches when using throttle. But there really is no issue with using both gain settings...

I use Power Throttle only because I'm running kind of a high voltage for the motors and the batteries have a high Ri and so are a bit saggy. Power throttle keeps the applied watts the same relative to the throttle for the duration of the ride by automagically jacking up the amps towards the end of the ride to compensate for the drop in battery voltage. This, though, is not a usual situation - Current Throttle is much more common.

 

[justin_le]

It would be less confusing and cleaner if everything is only in (KW/KWh/Wh/W) and as Merlin say'd the SOC is calculated for the given max. battery Wh.

Yeah I've struggled a bit with this. It's a conflict between cleanliness and correctness. You want current limit and not a wattage limit if say you need to use the CA to keep from tripping a battery BMS overcurrent protection, since that is based on the amperage not the watts. And since almost all battery packs are sold with a claimed Amp-hours, it makes more sense to show total Ah rather than total Wh on the main screen, so that people will see how their battery is living up to the nominal specs. But then it requires a bit of mental math to relate the wh/km mileage stat to the amp-hours in their battery. We could show Ah/km instead, but then it's not universal and relevant when comparing the energy use of different systems.

The point I also made that watt-hours is not a good SOC indicator is also very true, especially with higher impedance batteries which are commonly used on ebikes. However, given that the CA3 knows the internal resistance of the battery pack, it's possible in principle for it to compute an effective watt hours that IS independant of the rate of discharge, by using:
delta watts-hrs = (Volts + RBatt*Amps) * Amps * deltaT

It's a little academic maybe, but that would be an approach I could live with. Then there is the question of whether you use this inflated watt-hours or the actual measured watt-hours in the wh/km calculation for mileage. In once case you are including the internal battery losses in the Wh/km figure, while in the other case you are only looking at motor and controller energy. You could make an argument for both.

 

[Allex]

Can someone please point me to an instruction on how to make this USB-TTL cable?

 

[zener]

It would be less confusing and cleaner if everything is only in (KW/KWh/Wh/W) and as Merlin say'd the SOC is calculated for the given max. battery Wh.

Yeah I've struggled a bit with this. It's a conflict between cleanliness and correctness. You want current limit and not a wattage limit if say you need to use the CA to keep from tripping a battery BMS overcurrent protection, since that is based on the amperage not the watts. And since almost all battery packs are sold with a claimed Amp-hours, it makes more sense to show total Ah rather than total Wh on the main screen, so that people will see how their battery is living up to the nominal specs. But then it requires a bit of mental math to relate the wh/km mileage stat to the amp-hours in their battery. We could show Ah/km instead, but then it's not universal and relevant when comparing the energy use of different systems.

The point I also made that watt-hours is not a good SOC indicator is also very true, especially with higher impedance batteries which are commonly used on ebikes. However, given that the CA3 knows the internal resistance of the battery pack, it's possible in principle for it to compute an effective watt hours that IS independant of the rate of discharge, by using:
delta watts-hrs = (Volts + RBatt*Amps) * Amps * deltaT

It's a little academic maybe, but that would be an approach I could live with. Then there is the question of whether you use this inflated watt-hours or the actual measured watt-hours in the wh/km calculation for mileage. In once case you are including the internal battery losses in the Wh/km figure, while in the other case you are only looking at motor and controller energy. You could make an argument for both.

@teklektik I will try this soon.

Thats good to go the path of universal useness for all ebikers.
Preventing a BMS to trip should be doable in the settings from most controllers.
Computing the losses from the battery to get the real Wh is genius.
Showing both Wh/km would be good to see how (un)efficient the batterie is. (could be a good indicator for buying new battery)

Ideas for CAv3.x are:
%% of SOC from the Ah or real Wh would be ideal to read.
Motor-temperature constant displaying or only with maybe SOC alternating.
Comparsion of the real deltaWh with the Wh

 

[maττ]

Zero issues to report on two Windows 8.1 machines, other than the obligatory Windows SmartScreen refusing to let it run initially.

The only thing leaving me a little confused is how the battery indicator on the CA shows almost empty. It's a 48V LiFePO4 from BMSBattery and entered as 48V/10AH/16S/Cutoff@43V... displays 50-53V but the battery indicator still looks empty. Perhaps it's expecting that col to be cell voltage, not overall. I'll have to do some more reading.

 

[justin_le]

Zero issues to report on two Windows 8.1 machines, other than the obligatory Windows SmartScreen refusing to let it run initially.

Hey thanks for the confirm. One thing we don't have anywhere in our lab is a windows 8 system, so good to know.

The only thing leaving me a little confused is how the battery indicator on the CA shows almost empty. It's a 48V LiFePO4 from BMSBattery and entered as 48V/10AH/16S/Cutoff@43V... displays 50-53V but the battery indicator still looks empty. Perhaps it's expecting that col to be cell voltage, not overall. I'll have to do some more reading.

With a a 16S LiFePO4 pack, you'll only get a full SOC indication when the pack is above about 55V. At 50-53V, you are in the 3.3 V/cell regime and there is no way for the CA (or anything else for that matter) to know if the cells are 90% charged or 30% charged, it all looks the same. So once you have a fully charged battery then the SOC indicator will go all the way up, and it will go down after that based on your Ah consumption. In pinch, if you know your pack is mostly charged up then you could temporarily set the #cells to 15S rather than 16S, then the CA will show a full SOC status, then go back to the setup menu and revert it to 16S. The SOC icon will then show mostly full.

-Justin

 

[shorza]

I know it's been mentioned here before but my CA turns on and lights up while the bike is moving when I don't have a battery connected.

Can this damage the CA/controller?

 

[Arlo1]

I know it's been mentioned here before but my CA turns on and lights up while the bike is moving when I don't have a battery connected.

Can this damage the CA/controller?

You have it powered from the power inside the controller? The wheel is working as a generator to charge up the caps inside the controller but you will need to generate above 150v dc to hurt the CA how fast is your unloaded wheel speed when powered from the battery? And what is your fully charged voltage? And how fast are you able to peddle the bike with no assist?

If you look at those numbers or post them we can work the math to show you why its no problem.