Cycle Analyst V3 preview and first beta release

[johnrobholmes]

It is a big hardware upgrade, not just updates on the firmware. I would suggest you sell the units on the forum, I bet they would get snatched up pretty dang fast. V1 and V2 units will still be extremely valuable kit.

[justin_le]

Fantastic work Justin. Great list of new features. Especially like the automatic battery gauge, and the whole concept of making the CA the central brain that can work with any controller.

Hey Adrian, nice work on completing the tidy Brainbox too btw! It's no small feat to go from a concept/prototype into a first small scale production run like that,,, i would know

1) Torque Limit
If you have a constant power limit, torque drops as speed increases. Some systems may benefit from being able to set a maximum "torque" based on Volts*Current / Speed. This makes sense to me as most drive trains are torque rather than power limit.

Yes, I think this might have come up in the RC-CA thread as well. Torque limit also works best from the perspective of protecting controller mosfets and motor phase wires and connectors. IF the throttle output of the CA is mapped properly and the controller takes the throttle signal as a direct control of the PWM duty cycle, then the CA should be able to estimate the motor current from
Motor Current ~= Battery Current / (Act Throttle Output / Full Throttle Output)
And hence could set up a limit accordingly. Doing it as Volts*Current / Speed is an interesting approach but it wouldn't reflect the torque at lower speeds well where the efficiency of the motor is poor. It's looking at input power / speed, while what we'd want to be looking at (for motor torque / phase current) is output power / speed.

2) Throttle Rate Limit
I am a bit of a special case, but I actually use a separate rate limit for throttle down. It smooths the disengagement of my friction drive. Would be nice if this option was possible on the CA.

Duly noted!

3) Large Screen vs Small Screen
Are you only offering the large screen CA in the future? Has the smaller screen version been permanently discontinued?

We still keep the small screen LCD's and membrane overlays on hands for OEMs (like the stealth bomber), and if anyone wants to take on doing a small form factor enclosure for these and offering it that would be great. The actual footprint of the small LCD PCB is just 80mm x 36mm, and we made sure that the V3 CA boards would fit within this boundary. So in principle you could make a fairly small box around it. The old hammond enclosures we used to machine for the application were 100mm x 50mm.

4) Temp Limit
Have you decided on how you will be implementing any limitting features baseed on the temperature sensor input?

Right now you set a threshold temp and a maximum temp:

ThreshTempm.jpg (10.57 KiB) Viewed 935 times

MaxTemp.jpg (10.41 KiB) Viewed 935 times

The current limit automatically starts to scale linearly downwards when you hit the thresh temp, until it reaches 0 amps when you reach MaxTemp. I don't think anything more than this is really needed for effective overtemp protection, but if you have other ideas I'd be curious. I don't personally push many items to their thermal limit in my own ebike usage.

-Justin

[justin_le]

It is a big hardware upgrade, not just updates on the firmware. I would suggest you sell the units on the forum, I bet they would get snatched up pretty dang fast. V1 and V2 units will still be extremely valuable kit.

Ha, spoken like a true businessman JRH! Indeed this is a complete hardware change and has an especially more tedious set of wiring and connector harnesses to make up and solder. So the plan is that we will be keeping the V2 CA's in full production as they are still perfectly suitable for tons of users who don't need these new features, and also for people who don't want any additional wiring clutter on their ebikes. It's a bit early to say for sure since we haven't started production in quantity, but the V3 CA's will probably be in at the ~$160 price range, versus $120 for the CA V2's. So the CA V2's aren't going to become obsolete, we're just making a more 'deluxe' model for those who want it.

-Justin

[johnrobholmes]

Mmm, deluxe model


I just call it like I see it, but you have me pegged If you stopped v2 production I bet there would be a mad scramble on the forum of people swapping out units!

[justin_le]

Just a note that I'm about to take off my first distance trip using a CA V3 with torque sensing pedalec mode and so may be absent for this thread for a couple days though I haven't finished writing about all the V3 details yet. I'm travelling from the eZee factory to visit Cell_Man in another part of Shanghai. So far all the testing has been of the around-the-block variety so it'll be fun to take this on a real distance run which is where the pedalec mode should really shine.

Here's the rig that I put together. It has two hub motors installed for a dual drive, but I'm only connected to the front motor at the moment:

Test Ebike.jpg (37.62 KiB) Viewed 919 times

Cell_Man, if you don't here from me by sunset, I've emailed you my cell number which hopefully will work. China roads and traffic are a little crazy. Trusting that the google maps "pedestrian" route is a safe one!

-Justin

[adrian_sm]

Hey Adrian, nice work on completing the tidy Brainbox too btw! It's no small feat to go from a concept/prototype into a first small scale production run like that,,, i would know

Thanks. If CA v3 was available back then, I doubt I would have bothered. But still very glad I did it.

IF the throttle output of the CA is mapped properly and the controller takes the throttle signal as a direct control of the PWM duty cycle, then the CA should be able to estimate the motor current from
Motor Current ~= Battery Current / (Act Throttle Output / Full Throttle Output)

I like it.

The actual footprint of the small LCD PCB is just 80mm x 36mm, and we made sure that the V3 CA boards would fit within this boundary. So in principle you could make a fairly small box around it. The old hammond enclosures we used to machine for the application were 100mm x 50mm.

Interesting. A tight enclosure around the smaller 16x2 would be pretty neat, and the new v3 CA hardware has everything an ebike could want... Hmmm that has got me thinking.

The current limit automatically starts to scale linearly downwards when you hit the thresh temp, until it reaches 0 amps when you reach MaxTemp. I don't think anything more than this is really needed for effective overtemp protection, but if you have other ideas I'd be curious.

Sounds perfect to me.

Good luck with your ride. Stay safe.

- Adrian

P.S. Will Grin Tech be at Interbike? I was thinking of dropping by.

[www.recumbents.com]

Hi Justin,

Very cool new features. When you get a chance can you list what is being logged? I'd be interested in the usual time / motor parameters plus the human power. Maybe your firmware allows choice of parameters to log?

Thanks,

-Warren.

[chroot]

PLEASE add the flasher function for instance I am deaf or someone is also deaf dependent on light warning such light or LED flasher technology. Maybe flashing the LCD display such SoC act like warning LVC is near.

Did you ever thought about including a programmable BEEP piezo alarm option we could setup for ex low SOC alarm etc?

I think we need to be careful making sound noises. Certainly my tendency is to want to smash electronic devices that beep at me, so it's unlikely that the idea of a piezo buzzer would make it into the design!

However, I think we could do a compromise Stéphane where parts of the display would then flash when a hard limit is hit? so for instance if LVC is reached then the battery indicator blinks, if overtemp is reached then the temperature readout flashes etc. That would also be useful to tell people what is going on when the CA starts to throttle back the power output, and it shouldn't be too difficult to implement.

[nicobie]

That's pretty darn cool.

More than every feature than I was looking for.

Clever that the unit can use more custom input for each specific user's system. Kenny did have one good idea with his weak sauce display.

[teklektik]

Just wondering if there will be a firmware upgrade for the current Analogger to dump other (new) input data as well - minimally Temp data but the Aux Pot would be nice as well since it would reveal (usually) a changable operator control setting (limiting of one sort or another).

A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.

[justin_le]

Just wondering if there will be a firmware upgrade for the current Analogger to dump other (new) input data as well - minimally Temp data but the Aux Pot would be nice as well since it would reveal (usually) a changable operator control setting (limiting of one sort or another).

No need to update the analogger, since it already records to the SD card exactly the text that is output by the CA (or in fact, any other device with a 9600 baud ascii stream). At present, in addition to streaming the Volts, Amps, Speed, Distance, and Ah, the V3 also adds to the mix:

Throttle Input Voltage
Throttle Output Voltage
Aux Voltage
Temperature
Pedal Power
Pedal Cadence

A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.

That's a great idea for sure. It wouldn't be the Analogger doing this but I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.

-Justin

[justin_le]

Really nice improvements there!
In Europe we have the legal possibility to have a "push/start-help" 'til 6Km/h (without the PAS signal) after this speed a PAS signal is needed to reach "full" speed. Any infos If this could be inplemented or if it eventually already the case? ^^

Yes, at present I have almost the opposite. There is a "Start Speed" setting which gives a minimum speed that you need to attain before there is any output power to the motor.

Start Speed.jpg (8.78 KiB) Viewed 819 times

This is there mostly for sensorless RC type setups that have issues with starting from a dead stop. There's no reason not to have a "PAS Threshold Speed" that requires pedalling above a certain speed but allows throttle only power below that. I'll probably fit this setting in with the PAS setup menu, but haven't implemented it yet.

Is it only germany that has this legislation passed or is it europe wide?

-Justin

[adrian_sm]

A handy feature for the Analogger might also be to dump a short ascii file on startup named CAsetup_XXXX where XXXX is the same as the CAlog_XXXX file. The file would just contain a dump of the setup and advanced setup for the CA - one parm per line in 'name = value' format. Tweaking settings and recording data for test runs would then leave each data log with a corresponding file of the exact setup in use at the time. Although not always useful, the files would be of inconsequential size and easily deleted en mass if unwanted.

That's a great idea for sure. It wouldn't be the Analogger doing this but I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.

-Justin

I implemented something very similar. With the header containing software version, filename, settings, log rate and finally the header row for the data to follow. It was really useful for testing, and meant I didn't have to separately record what I was tuning as it was all in the log file.

The other file I created was a trip summary file. Basically whenever the bike came to rest it wrote or overwrote out to a different file that contained the same "trip number" as the datalog file. It included basically all the summary stats you would see on the display. Trip times, dist, wh, wh/km, average power, max amps, min volts, etc. It was great to automatically record the summary stats for each ride. The downside was that they were each in a separate file, making it a pain to review all the trips. A better method would be to have one file that has a line per trip for all the stats. But this requires different logic on how the file is written, or how you access the file to update the trip stats. Anyway, that would be another killer feature for the CA if you can be bothered doing it.

- Adrian

[hillzofvalp]

Is it possible to have two temperature inputs and the ability to display BOTH of them on the main display window? maybe one of the other pins could have multiple functions as setup in the settings...for those that intend on monitoring multiple temperature points

[teklektik]

At present, in addition to streaming the Volts, Amps, Speed, Distance, and Ah, the V3 also adds to the mix: ...[list of cool things]

... I could have a small header that the CA itself outputs during the bootup sequence. At the moment it just sends a line that says "V, A, Ah, Sp.. "etc, but it could instead be a header block with a more detailed breakdown of the parameter settings.

-- I *like* it! -- Thanks!

[justin_le]

I'm interested in the Torque Sensors. Would be nice if i could build pedal and go ebikes for my parents. Not sure if there is going to be anything decent available from ebikes.ca torque sensor wise to go with the CA.

For sure, we have a small number THUN torque sensors on hand (like maybe 6 or 7 left for beta testers) and will be ordering them in some quantity very soon so that we can offer a CA V3+THUN bundle, with pre-made wiring harnesses to simplify the assembly. The input settings for the torque and PAS sensor in the CA itself are pretty flexible, so it's not tied to any specific device and should accomodate anything on the market that has a linear voltage/torque relationship. You indicate the scaling factor in Nm/V (the thun is 100, but we set this to 200 so that it doubles the torque to account for the single sided torque sensing nature of the device):

TrqScale.jpg (9.96 KiB) Viewed 1493 times

Plus you can zero the torque offset, much like the zero amps routing for the current offset:

Trq Offset.jpg (10.48 KiB) Viewed 1493 times

For the pedal cadence sensing, you set the number of pulses per pedal rotation:

PAS Poles.jpg (9.73 KiB) Viewed 1493 times

And if the cadence sensing has a quadrature encoder, then there is a polarity selection to indicate which is direction is forwards and which is reverse pedalling:

Dir Polarity.jpg (9.78 KiB) Viewed 1493 times

All of my testing so far has been done with the THUN X-Cell sensor, for the most part it is pretty good but there are a few slight shortcomings that came up:

1) Magnetic Field Sensitivity: My demo bench was welded up from steel frame bike parts and a lot of the tools in my garage are slightly magnetized, and as a result the test jig has some residual magnetism too. It turns out that the sensing technology is extremely sensitive to external fields, so on my demo setup even with no torque on the bottom bracket, I would see a variation in about +- 10Nm in the signal output just by changing the spindle angle. When I touched my slightly magnetized wrench to the THUN spindle to remove the crank say, then the signal would jump off the scale. On an alloy frame bike this is all of minimal consequence, but I can envision situations with steel frames that have had magnets stuck on them in the past where a degaussing of the bottom bracket area might be necessary.

2) Offset hysterisis, The specified accuracy error of the THUN sensor is 2%, which looks really good at first. However, that is not the linearity error but 2% of full scale. Since it reads up to +- 200Nm, then the output can be off by +- 4Nm, which is a lot if you are only doing light pedalling. If you are averaging like 15-20 Nm which is pretty typical for casual effort, then the accuracy error can reach 20-30%. You can see this first hand by measuring the voltage from the THUN sensor with no torque, then standing and hoping on the pedals, and then looking at the zero torque reading again. If it was 2.49V the first time, it might read 2.52V or so afterwords. Spin the pedals 180 and hop on them again, and the zero torque reading might be 2.47V. That means that for very accurate reading of the human power, it will be important to periodically check and re-zero the thun's torque offset. For just PAS mode it's no issue, but for someone using it as a training aid it's not quite as suited as I had hoped.

3) Spindle length options Thun offers 120, 127, and 136mm spindles which is fine for the large majority of bikes. We thought it would be fun to install one on the Dogati bike after the Taipei show and have maybe the worlds first multi kW pedalec! But the Dogati needs a >150mm spindle for the cranks to clear the motor drive assembly, and lots of other mid-drive ebikes (like the Cycleone-USA stuff) require speciality long spindles too. I'll ask Thun what the minimum numbers would be to have a longer spindle option tooled up, because if we can have it work with the majority of mid-drives as well then that would be sweet.

Here is what the sensor looks like, btw:

THUn BB.jpg (11.69 KiB) Viewed 1493 times

The ST-01 torque sensor being shown by GreenTrans looks like it has a few benefits, namely that it senses both left and right crank torques and also has a wire exit on the side of the bottom bracket rather than through the center, so you don't need to drill a hole through the frame to feed the wire out:
http://www.greentrans.com.tw/eng/downlo ... alogue.pdf
However, the dual sided sensing means that a special adapter needs to be fit to link the chainring to a splined sleeve on the spindle. You can't just use an off-the-shelf crank and chainring on the right side if you want to "see" the right side pedal torque. And when I talked to them, they were really only interested in providing a whole package solution and not so much in supplying just the torque sensor. I'll try to follow-up but don't hold too much promise.

The other supplier is Schaeffler FAG, who do the torque sensing BB's for the Bosch mid drive module. In the press release they also list it as dual left/right pedal torque sensing:
http://www.schaeffler-group.com/content ... id=3447045
But I heard indirectly that this is only available to Bosch, and the one that they showed me at the show was single side sensing like the Thun, but instead of with a -200 to +200 NM range, it was a 0-100 Nm range. So it would probably be more accurate at measuring human watts at lower power levels, but would hit saturation when someone is really pushing on the cranks.

Definitely Thun as a company has been most responsive and the easiest to work with so far, so we'll carry their sensor to start, but it's good to see that there could be a few other options for people in this space. The last torque sensor we looked at was YST:
http://www.yst-corp.com.tw/products_vie ... 1104150001
Theirs has a non-linear varying resistance to torque relationship, which isn't very practical for device interfacing.

-Justin

[justin_le]

The other file I created was a trip summary file. Basically whenever the bike came to rest it wrote or overwrote out to a different file that contained the same "trip number" as the datalog file. It included basically all the summary stats you would see on the display. Trip times, dist, wh, wh/km, average power, max amps, min volts, etc. It was great to automatically record the summary stats for each ride. The downside was that they were each in a separate file, making it a pain to review all the trips. A better method would be to have one file that has a line per trip for all the stats. But this requires different logic on how the file is written, or how you access the file to update the trip stats. Anyway, that would be another killer feature for the CA if you can be bothered doing it.

Another really great idea. Best would be if it was right at the top of the header file, so the first thing you see on opening a log file is the trip distance, trip time, wh/km, avg speed, etc. then the list of settings, and then finally the table of raw data. As you say somewhat tricky logic to pull off given that the CA/Logger can get powered down at any random point, especially in our case since the CA and the card writer are two separate devices with only one way communication between them, but I'll see what we can do. There's enough processing power in the analogger that it could scan the entire log file and generate the summary stats and put them on the header quite independent of the CA.

-Justin

[dodjob]

Really nice improvements there!
In Europe we have the legal possibility to have a "push/start-help" 'til 6Km/h (without the PAS signal) after this speed a PAS signal is needed to reach "full" speed. Any infos If this could be inplemented or if it eventually already the case? ^^

Yes, at present I have almost the opposite. There is a "Start Speed" setting which gives a minimum speed that you need to attain before there is any output power to the motor.

Start Speed.jpg

This is there mostly for sensorless RC type setups that have issues with starting from a dead stop. There's no reason not to have a "PAS Threshold Speed" that requires pedalling above a certain speed but allows throttle only power below that. I'll probably fit this setting in with the PAS setup menu, but haven't implemented it yet.

Is it only germany that has this legislation passed or is it europe wide?

-Justin

GREAT I deal currently with cargo bikes (actually Beer-cruiser ^^) and they are really heavy to start specially when "loaded"
This should be an European rule. I know 100% that it's the case for Germany but I will check if it's the case in the whole EU.
Again, keep the good work, you rock
Gruß,
H.
*EDIT* Semms to be only the case in Germany. If someone can confirm for other lands in EU that could be great

[Trackman417]

This new CA looks BOSS! how can you put enough smileys to express that?!
Haha one question that comes to mind is does this new CA lag when it senses that one of the inputs has exceeded its max value? Or does it just not allow any of the values to be over shot? When I set the CA to not exceed a certain limit it will go over that limit for a brief second or two and then it will adjust the throttle correctly. Would the case be different with this new one?

[Tench]

This new CA looks BOSS! how can you put enough smileys to express that?!
Haha one question that comes to mind is does this new CA lag when it senses that one of the inputs has exceeded its max value? Or does it just not allow any of the values to be over shot? When I set the CA to not exceed a certain limit it will go over that limit for a brief second or two and then it will adjust the throttle correctly. Would the case be different with this new one?

It is the gain values set in your CA that govern how fast the unit responds to a limit being exceeded, you can change these yourself in the one you have, well i can in the 2 i have, v2.2 and v2.25.

Simon.

[methods]

nice..... I dont know how I missed this thread.

We are in the middle of implementing a wireless IR temperature sensor that can be mounted to the rear drop aiming at the motor. We have a tiny black box with an arduino nano shield that translates the I2C coming out of the IR sensor... which we initially intended to use to directly retard the throttle.... Now it looks like we can just scale this signal and PWM it out to your RTD input as a direct control voltage. The CA will read it just like an RTD input - but now folks wont have to open their motors up to have temperature protection.

This will be good

We have been working on some code that monitors the rate of change of temperature on the cover of the motor to predict the winding temperature internally. Smart, wireless, temperature sensor....

Parts have already arrived, prototypes are in the works.

The CA just keeps looking better and better to me. It was the first piece of ebike equipment I ever owned and I still think of it as a critical part of every ebike - as critical as the battery, motor, and controller.

Keep up the good work

-methods

[snellemin]

I'm loving this thread. I couldn't wait for the new one allready and now talk about wireless temp sensors!!!

[hillzofvalp]

Wait... Do I hear exponential torque throttle curve in this version? Eh? ----eh?

[hillzofvalp]

The throttle mapping is just icing on the cake! I can use them for any controllers now, what a great piece of kit.

Ever get any farther on integrating a watt controlled throttle or integrating amp limiting with speed limiting throttle types?

It would be epic if we cold program the CA To change the watts limit on the fly based on speed. That would solve a lot of the instant wheelie problems at low speed with a high power setup. I suppose it would have to be implemented in a safe way so that to arent suddenly launched when you are on a borderline limit. Maybe a buffer if some sort would be appropriate... Or maybe like this:

Say you have 2 speed ranges for 2 corresponding watts limits + 1 additional overdrive limit that can be called at any speed. Whenever you are 0-10 unitspod speed your limit is 1000W. When you hit 11 in speed it retains the set 1000W limit until to let go of the throttle completely.. Then when you resume throttle and you are above 10 you will see the second limit you set of say 2000W. Then whenever you want to map the full current range to the throttle you double tap the the bottojm of the throttle and you are in unlimited mode!

[stripedtuna]

Awesome product mate..

Sorry if this has been asked before, but is the output voltage of the cable for powering lights on the handlebars configurable via the CA? As in the cable for powering my front lights on my bike. I am about to wire up the front lights on my first e-bike, and when i noticed that cable coming out of the CA, i was jumping in joy. Now i just need to know if i have to wire a dc-dc step down in between or if the CA can do it for me..

Thanks heaps..

and keep up the great work mate..

cheers,

Ed.