Cycle Analyst V3 preview and first beta release

Sign me up for one beta unit Justin, I ll make sure to test it over 9999w and see if the 5 digit figures are working properly :mrgreen:
 
Guys,

Dont forget that about IR temp sensor, the measured temp must be a mat surface.. I mean if you try measuring silver paint or gloss paint aluminum ( low emissivity) the IR reading will be wrong. The emissivity of the material you measure must be good.

IR will reflect on many metal part just like a mirror so the temp you measure could be the temp o fthe reflected object thru the surface you point on... ex, if you try to measure a bare aluminum plate that is at ambiant and that you have your fbody that is in the direct incidense of that aluminum plate and the IR thermometer, you will measure your body temperature..

Best with Ir temp sensor is to have mat painted surface.. or for low temp measurement, a black electrical tape can do the job.

I see many person measuring their motor temp with Ir temp sensor.. :? .. I think we must be informet about the possible error reading we can get!: :wink:

When IR thermometers are used to measure surface temperature they can potentially sense all three kinds of energy, therefore all thermometers have to be adjusted to read Emitted energy only. Measuring errors are often caused by IR energy being reflected by light sources.

Other units have a fixed, pre-set Emissivity of 0.95, which is the Emissivity value for most organic materials and painted or oxidized surfaces. If you are using a thermometer with a fixed Emissivity to measure the surface temperature of a shiny object you can compensate by covering the surface to be measured with masking tape or flat black paint.

IR.htm1.gif


Please read this: http://www.allqa.com/IR.htm
 
hillzofvalp said:
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:

A watts limit based on speed _is_ basically a torque limit! Which is what me and Adrian were discussing a few posts back. Doing it this way (as opposed to discrete power limit steps as you suggest) would achieve what you are suggesting and would be the smoothest approach for sure..
 
I realize this is not a feature request thread, but I'd really like this feature.

Switch on the fly between 2 configs. For example
Mode 1:
500W (at the wheel output???) max 32km/h max
Mode 2:
9999W max 999km/h max.

I never have used the left button on the CA, maybe it could be used for this.
 
ohzee said:
Here's to hoping you put up some more videos of your travels to China and to see cell_man.. I very much enjoyed
all the other videos I have seen.

Well I'm not much one to take videos but I did try to get a few shots of me and Cell_Man riding on the local streets. Somehow his rear wheel and right foot managed to vanish and I grew an extra pair of arms! Silly camera.
Ride with Paul.jpg


My first long distance ride experience with proportional torque assist pedalec mode was really pleasant. After 60km, no sore wrist! On the long stretches when you are up to speed, the connection between the leg and the motor power was direct and instant, and even though I had a manual throttle I felt a huge disinclination to use it. It was really nice just to regulate the power based on how hard I was pedalling. So to all the people who used to tell us how they wanted a system like BionX, and I would say what's wrong with a throttle? now I finally get it!

However, the behaviour at low speeds in stop and go traffic conditions still needs some tweaking for optimization. Part of the problem is that the particular controller on this ebike has a very slow throttle response (about 2 full seconds to go from 0 to 100%), meaning that there was always some initial lag before the assist would first catch up when you start pedalling. And at the other end I also need to make it a bit snappier to shut off the output when you stop the pedals. It surprised me how often I'd need to go from accelerate to stop to accelerate as various obstacles came and went, and you notice if the motor carries on even for the tiniest bit when you are trying to stop. Having ebrake cutoffs wired up would have really helped here I suppose too. I tended to squeeze the brakes even while my legs were still moving.

In any case this does get back to my favorite aspect of the torque sensor, which is that at the end of the trip you get to see average the human power stats:


267 watt-hours from me. About 485 watt-hours from the battery pack. Figure ~75% average motor efficiency at that means I did a good 42% of the work on the return trip.
I'm sure with the setups on ES we'll see lots of people posting more like a 5-10% leg to motor watt-hour ratio ;)
 
Hi Justin,

Congrats! Looks very well thought out, all those features carefully packed in.

Does it protect the pack by dropping the output throttle to keep pack voltage above a minimum?

Can it be programmed to "bog" the output throttle when it estimates low remaining capacity, say the last ~25%. So that idiots like me who drive along going "wheeeeee" and ignore all gauges will get seat of the pants feedback that I'm running out of juice?

- John
 
1JohnFoster said:
Hi Justin,

Congrats! Looks very well thought out, all those features carefully packed in.

Does it protect the pack by dropping the output throttle to keep pack voltage above a minimum?

Can it be programmed to "bog" the output throttle when it estimates low remaining capacity, say the last ~25%. So that idiots like me who drive along going "wheeeeee" and ignore all gauges will get seat of the pants feedback that I'm running out of juice?

- John

The current CA already has this feature. Set the LVC to slightly higher than you want it to drop to.
 
Wow great job Justin!
 
dodjob said:
justin_le said:
dodjob said:
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.


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

In holland they sell original bikes with the 6km/h mode too.
They tell me it is for old people how kan not pull a bike when walking.
But i like it because my pas sensor need a olmost compleet revolution before i get power from the motor.
If you can add it to the CA it will be great. A mode where te throttle work @6km/h and from from 6 to topspeed when paddeling.

sorry for bad spell english is not my language
 
Congrats Justin,

Super sweet. Really worth ur time spent away imo.

Is the torque sensor module something that will come in the kit?

Do you think there is a torque sensor made that would work with a 100mm bb shell (fatbike)?

I really like the temperature sensing software you have created, with threshold and max temperature and the unit actually dialing back the amperage to motor as temps gets too hot. Are multiple temp probes possible?

Temperature sensing is something the original CA really needed.

Will a temperature probe come with the unit?

I really think what you have made here is huge upgrade to the CA and if dialed in properly could make DIY self builds more refined and reliable like expensive OEM bikes, also make it more probably for a diy bike to become commercially viable for someone like me trying to bring a DIY bike to the market.

I would love to be a beta tester if you need another one.
 
justin_le said:
hillzofvalp said:
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:

A watts limit based on speed _is_ basically a torque limit! Which is what me and Adrian were discussing a few posts back. Doing it this way (as opposed to discrete power limit steps as you suggest) would achieve what you are suggesting and would be the smoothest approach for sure..

I see that, but it does not fully solve the issue unless torque is limited under a defined speed. Otherwise I feel
Like it would feel very similar to a current throttle up to 20mph ( at least with high powered setups) with torque level set to max. We need a torque parameter with different levels of speed, I think.
 
Justin,

A few years back I exchanged emails with you and got the "what's wrong with a throttle?" response when I brought up the BionX :wink: .

The screen showing human output data is awesome, you just out-BionXed BionX with that one. Makes me recall the paper you wrote on the CO2 implications of human versus electric propulsion.

Your new V3 CA seems capable of overcoming the speed and power limitations of the the BIonX, something many of us have been hoping for for a long time!

Someone has succeeded in scoping the CanBus and reverse engineering at least some the commands and register structure, and I and others have found ways to use A123 batteries and overvolt 36 volt systems to 48 volts, but we are in dire need of overriding the BionX algorithm with its built in speed and watt limits. Riding uphill while running at 48 volts I often got up to 1200-1400 watts of output and then the system would suddenly "hiccup" as I presumably bumped into the maximum watt limit. It felt like having a rug pulled out from under me as the motor suddenly withdrew it's assistance.

So to keep this on topic, I've looked at the websites for the torque sensors you mentioned, and this led me to wonder if you think I could use the torque sensor signal from my I2C 350 watt BionX with the CA V3? I think DocBass did a little testing of the relationship between torques and signal output but did not really fully characterize it. Perhaps you know if it would be suitable- eg is it linear, etc?

My goal is to use the BionX torque sensor with my own battery/BMS and a third party controller along with the CA V3 all routing back to and driving the BIonX motor.

Great work conceiving of and implementing another big step forward. Thank you!

BTW, I was riding in China last week and was told in Macau that ebikes are completely illegal there! :roll:
 
justin_le said:
I had another idea though which might be the best option for systems that have a hard time getting closed-loop current control working smoothly, but that would still have the overall benefits of a current throttle in that the full range of the throttle motion is useful regardless of your speed. This would again require the CA knowing the Kv of the motor in kph/V. The throttle output of the CA would continuously scale upwards with the vehicle speed, such that (based on Kv) the no-throttle motor RPM is slightly less than the RPM of the wheel. Then the throttle motion moves the output voltage above this point.

So in equation format it would be something like:
Throttle Output = K1*(vehicle speed / motor Kv) + K2*(user throttle)

Where the content K1 would be figured out by the CA from the battery voltage and the throttle output range, while K2 would be a parameter that the user could set. There are a lot of advantages to running open-loop in this manner, since you wouldn't have to tune any feedback parameters and it would better cope with controllers that have response lags and latencies.
Some thoughts about this:
  • This does not appear to accommodate slowing down or speed changes in excess of the scaled throttle range of motion as limited by
    K2*(maxThrottleExcursion). For example, at any steady state speed the no-throttle setting is that necessary to maintain that speed.
  • The true zero and maxThrottle output voltages are generally not directly achievable since they fall outside the throttle range of motion (RoM)
Ideally, I think we want a nonlinear throttle mapping that changes dynamically with speed - something like this:


Here the relatively flat linear range is initially in effect at 0-speed and advances upward and to the right until full-speed. This has the effect of compressing the RoM in different portions of the mapping according to speed, but expanding the end(s) of the RoM so that no-throttle and WOT are still reachable.

This could be implemented as a piecewise linear approximation and segmentation of the RoM into several bands (say 0-15%, 15%-85%, 85%-100%) with associated expansion, compression, expansion effects. This will, of course, generate some knees in the throttle action. The best scheme is to derive an equation to develop the output in terms of both speed and current throttle excursion, but I confess that is a bit beyond me. A dead simple approach would be to implement a number of hand-generated curves in tabular form and x/y interpolate the mapping factor using the row/column values bracketing the speed and throttle input. A mid solution might be to use something similar to spline curves.

The adaptive nature of the system will require some reverse throttle adjustment for large excursions as the mapping curve changes under the throttle input when speed changes. However, the non-linear nature of the curves should ensure convergence before no-throttle and WOT output reducing the adjustment range and hunting effect.

Anyhow, just thought I'd throw this out there.... :wink:
 
Justin-
Not sure if you want to pursue this, but after a little tinkering, the version of dynamic throttle mapping in the post above looks pretty workable. Here's a shot of a sample map done as an experiment in Excel:

dynamicThrottleMapping5s.png
The 0% throttle map is generated from the eight values in green in the table but could be the result of any nonlinear equation that gives a desirable curve. The 100% curve is the result of mirroring the 0% curve around the 'unmapped' curve. And finally, the 'current speed' curve is a simple interpolation of the two former curves. For such a simple manipulation, the shape of the derived current speed curve looks pretty good (50% speed in this sample) - a throttle excursion from 20% to 80% only yields a change in output voltage from 40% to 60% or about a 3:1 improvement in throttle resolution i.e. (80-20)/(60-40). Similarly, the throttle resolution improvement at the extremes is about 70/15 = 4.5 to 1.

If the 0% curve is provided by equation, then it's straightforward to derive a calculation to yield the target throttle output in terms of current speed and throttle input. I don't know what chip is in the CA or how much horsepower it has, but if it's not up to the task of rapid log or other non-linear evaluations, the simple tabular scheme certainly has very low overhead.

Here's the Excel file if you want to look at other derived throttle curves - just jiggle the 'current speed' cell. Change the 0%/100% curves by jiggling the 8 green values in the table.

View attachment dynamicThrottleMap_5.xls
Not pushing for any of this, but the weather is crappy here today and this looked worth investigating a bit :)
 
you can specify both minimum and maximum input range allowing you to dial in just where the start and end zones are for the throttle motion, regardless of whether you have a potentiometer or a hall effect throttle type.

Wow I was excited while reading about all the new stuff, but the throttle features just made me stain my pants! Looks I need a 6-pack of V3 in 8-10 weeks. :lol: I am stunned by the range of new features, my head is spinning from the possibilities. Thank you for continious improvement on an already robust product.

It would be interesting to have a mode in setup that would display the throttle voltage the CA is receiving. That would be handy when one is far from home, trying to troubleshoot a throttle vs controller issue. Heck it would be handy just to confirm the throttle is supplying the range you are about to assign it.

-JD
 
Nice work Justin.

One thing I have been asking for for a while is acceleration control. That is so the bikes can accelerate at a safe (grandma) rate, but still have huge torque for climbing hills. So basically your acceleration on the flat and on a hill is the same. Hi power bike, with out acceleration dangers. Sounds like I will be able to achieve this with the V3.

Put me down as a Beta.

Kiwi.
 
+1 Oatnet, the throttle lower and upper value is a killer feature, you can virtually use anything you like as a throttle without having to play with pots and resistors.
 
silentflight said:
Justin,
So to keep this on topic, I've looked at the websites for the torque sensors you mentioned, and this led me to wonder if you think I could use the torque sensor signal from my I2C 350 watt BionX with the CA V3? I think DocBass did a little testing of the relationship between torques and signal output but did not really fully characterize it. Perhaps you know if it would be suitable- eg is it linear, etc?

I've yet to measure the characteristics of one electronically, but it is a strain gauge on the rear axle, which means that:
a) The output voltage signal (prior to getting digitized) is exceedingly linear with strain/flex in the rear axle, but
b) Because it is measuring flex in the axle, the strain signal is a function of chain tension, and hence for the same amount of pedal torque the signal coming from the BionX gauge will vary with your bicycle gearing ratio. Since the CA has no information on the gearing, it would be difficult translate the BionX strain gauge signal into a pedal torque as required for calculating the human power in watts.

My goal is to use the BionX torque sensor with my own battery/BMS and a third party controller along with the CA V3 all routing back to and driving the BIonX motor.

So the answer to this would be yes, if your main objective is to get the proportional torque assistance working and if you don't care so much on the accuracy of the human watts and watt-hour info.

I would need to think about the physics of the BionX pedal tension -> axle strain relationship. But if it happens that it's not too sensitive to the position of the chain on the rear sprocket, then so long as you have only a single chainring on the front it would be possible to have it show human watts accurately too. It would be an easy test if you have a multimeter or I2C hack measuring the BionX torque output. Just put like a 100lb tension on the chain and compare the output with the chain both in high gear and in low gear of the rear sprocket, if they are similar then the CA could do proper human power accounting. You would need to install a simple magnetic PAS sensor on your cranks too to get the pedal RPM, but that's easy enough.

BTW, I was riding in China last week and was told in Macau that ebikes are completely illegal there! :roll:

It's an Upsetting Technology, that excites some people and scares others!
 
My friend, it would seem to me that if you have the voltage off the strain sensor on the rear axle, and a single hall signal, and the number of poles is known, than you have all that is needed to know human added pedal torque regardless of gearing or gearing compensations.

This is because you have both the human torque applied (regardless of RPM, the torque and RPM will vary inversely to stay in balance), and the RPM of the motor at which this human added torque is being applied.
 
IIRC the layout of the signal level connections to the internal controller on a Bionix hub correctly (I think they were 90deg SMD JST connectors), I think you could potentially offer a cable that plugs in between the existing signal connectors, and has a pig tail that runs up to the CA to give you all the required human power input info.

That said, I personally am not a fan of the way Bionix does things with the dinosaur closed-system product model, I would bet that even removing the screws to look in a bionix hubs results in both a warranty voiding and some type of hex being placed on you. lol ;)
 
Justin and LFP,

Thanks for your advice and insight, you guys rock.

LFP, I don't know what to say about BIonX, the closed system part does suck. I've voided the warranties several times over and fried one while running at high voltage. If I could tell you how awesome it feels to fly around in the night on a BIonX, up and down huge hills (I get up to 1500 watts of assist when overvolting) with no thought about interface, its like the bike comes alive. You pedal harder, it pedals harder... until you're pushing it for all you can get...

I've driven a roadster and know the kick ass feeling of acceleration that knocks your head into the headrest like a dropped bowling ball hitting the floor all under the eerily silent and vibration free power of the motor, so I get where you're coming from too...

It is great how Justin's new V3 brings both sides of ebiking together.
 
liveforphysics said:
My friend, it would seem to me that if you have the voltage off the strain sensor on the rear axle, and a single hall signal, and the number of poles is known, than you have all that is needed to know human added pedal torque regardless of gearing or gearing compensations.

This is because you have both the human torque applied (regardless of RPM, the torque and RPM will vary inversely to stay in balance), and the RPM of the motor at which this human added torque is being applied.

That would be true if you had the torque applied but I don't think you do with BionX. Rather, you have the human chain tension. It's not a torque strain gauge, it just measures the flex of the rear axle as it bows inwards when you pull on hub side plate via the chain. The amount of torque that is on the rear hub for a given chain tension depends on the sprocket diameter at the back, so to do it based on motor RPM you would need to know the rear sprocket diameter. If instead you were to calculate human power based on on the pedal RPM, you would need to know the front chainring diameter. You could get away not knowing any gear sizes if instead of using an RPM pickup you had magnets along the chain and actually measured the chain velocity.

But, holy smokeballs, I just realized that the CA can indeed figure out what gearing you're in. Since it knows both the pedal cadence and wheel speed, it knows your exact gearing ratio when you are pedaling. This ratio in and of itself isn't enough, as you can have the same pedal/wheel ratio with small gears and a high chain tension, or large diameter gears and a low tension. But so long as there are just a discrete number of gear ratios in the system (21 speed, 24 speed etc.), then it could do a look-up table and figure out which of the available sprockets you are using on the front and the back, and tell you not just your human watts but also what gear you're in. Damn, now my head is hurting!

-Justin
 
Back
Top