Cycle Analyst V3 preview and first beta release

I think you first need to address the setup posted above from Justin to get the device operating in the proper range. Then I suggest you pursue the gain settings described in the other post above.

You could try a pot (or limit switch) with AuxPot configured for PAS Assist Level so you could dial in the desired assist - but only after you've done the above.

If you have only a single chainring and have a low cadence on hills, then there are going to be issues and the AuxPot input may be your only route. Normally, a hill is met with a downshift and higher rpm which gives more assist and up-the-hill you go.
 
Hi@all!

Throttle Ramping Adjustments problem?

I'm on on Prelim6 and have the following problem that was already posted by hjns » Wed Jul 10, 2013 2:54.

Ramping units in V/Sec works well for me. Ramp down is at 99.99V/Sec (immediately). Running everything in Power throttle. Wgain is at 5. However, if after strong acceleration (>50A) I abruptly let go of the throttle, I can feel a power surge for a milisecond before all power dies. I will try out different Wgain settings.

My settings that could be relevant are:

Battery: 74V with DD Motor.

Throt in: Pass thru
Throt out: 1.00-3,65V

Up Rate: 10.00 Vlt/Sec
Down Rate: 10.00 Vlt/Sec
Fast Rate: 9.99 Vlt/Sec
Fast Thrsh: 0.00 Amps

I want that if I just let go the throttle pysically from "100%" to "0%" imediatly, that there is no power surge for some milliseconds. If you are at a high speed and you want to reduce speed immediatly the bike should respond immediatly. I have not tired Down Rate: with 99.99V/Sec yet. I'll try tomorrow. In the forum for older firmware "DownRate" was recommended to 500 milliseconds to have brisk throttle response. How to translate this to V/Sec? I just want that the throttle behave like in legacy mode without changing to that mode. Maybe the needed Settings to modify are somwhere else?

PAS Sensor: Off
TRQ Sensor: Disabled
Temp Sensor: Disabled
Aux POT: Disabled

Thanks for help and for recommended settings!
 
That brings up a good point does the throttle ramping for the torque pas fall under the global setting or is it ignored. I have my throttle ramp up rate at about .4v/sec.
 
icecube57 said:
That brings up a good point does the throttle ramping for the torque pas fall under the global setting or is it ignored. I have my throttle ramp up rate at about .4v/sec.
Sorry - a little confusing - there is no 'throttle ramping for Torq PAS' setting.
'Global' settings refer to settings which are not 'preset-specific'.
Please refer to the actual parameter name on the CA Setup screen (e.g. ThrO->UpRate) - saves confusion...

From the Guide:
4.0 Throttle Ramping Adjustments

...
Throttle ramping affects Throttle OUT universally and so plays a role in operator throttle, closed-loop throttle, PAS, auto-cruise, etc. The ramping logic appears as a clamping mechanism to moderate the rate of throttle change. It only participates when the the rate of Throttle OUT change exceeds configured limits – at lower rates it has no effect.
 
dunja said:
I'm on on Prelim6 and have the following problem that was already posted by hjns » Wed Jul 10, 2013 2:54.

Ramping units in V/Sec works well for me. Ramp down is at 99.99V/Sec (immediately). Running everything in Power throttle. Wgain is at 5. However, if after strong acceleration (>50A) I abruptly let go of the throttle, I can feel a power surge for a milisecond before all power dies. I will try out different Wgain settings.
We can see from the quote that he was using Power Throttle and so the Power PID controller is in play - this is not your situation at all since you are using ThrI->CntrlMode=PassThru which pipes the operator throttle directly to the ramping logic directly (no PID controller).

dunja said:
My settings that could be relevant are:

Throt in: Pass thru
Throt out: 1.00-3,65V
Up Rate: 10.00 Vlt/Sec
Down Rate: 10.00 Vlt/Sec
Fast Rate: 9.99 Vlt/Sec
Fast Thrsh: 0.00 Amps

I want that if I just let go the throttle pysically from "100%" to "0%" imediatly, that there is no power surge for some milliseconds. If you are at a high speed and you want to reduce speed immediatly the bike should respond immediatly. I have not tired Down Rate: with 99.99V/Sec yet. I'll try tomorrow.
A couple of things:
  • First, setting ThrO->FastThrsh= 0 effectively disables ThrO->FastRate so that setting is superfluous in your case. Just an FYI so you can avoid messing with that setting... :D

  • Next - and to your real question - you have ThrO->DownRate set to 10V/sec. This means that when you go from 100% to 0% throttle, the ThrO signal level will transition from 3.65v to 1.00v or 2.65v. Your DownRate setting means this will take 2.65v / 10V/sec = 0.265sec or about a quarter of a second. There should be no 'surge' in the ThrO voltage level but there will be a very noticeable response delay.

    To remedy this, increase the rate - for instance, the fastest rate is: ThrO->DownRate = 99.99V/s. This will give you a delay of only 2.65v/99.99V/sec = 0.0265sec - pretty undetectable by human standards.
dunja said:
In the forum for older firmware "DownRate" was recommended to 500 milliseconds to have brisk throttle response. How to translate this to V/Sec? I just want that the throttle behave like in legacy mode without changing to that mode. Maybe the needed Settings to modify are somwhere else?
Well the present default value is 2V/sec which frankly is kind of slow. I can't find the earlier post to which you refer (500 msec) but the old dimensionless value *was* 500. I can't remember how to convert that off the top my head, but I think that what you may really want to know is what number to use to get a specified delay from WOT to ZERO throttle. If so, then you can get that from:

  • ThrO->DownRate = (ThrO->MaxOutput - ThrO->MinOutput) / (DesiredDelayInSeconds)
So, in your case if you want 100msec, you would use: ThrO->DownRate = (3.65v - 1.00v) / 0.1sec = 26.5V/sec
Similar calculations can be used for the other ThrO->xxxRate parameters.

BTW - Thanks for all the settings, etc - made the question/situation very clear...
Hope this helped... :D

Hmmm - maybe a similar sample calculation would be good in the Guide....
 
So if the Thro out up rate is set for a slow ramp up then would this cause a sluggish and delayed reaction in the Torque Pas which would may cause an over shoot if I was pedaling hard on the start and felt the bike get away from and stop pedaling which may lend to the surging. I have to recalibrate my sensor cause I got my new chain ring and from what I read the torque that it senses will be much lower. I have to recheck all my settings again.
 
icecube57 said:
So if the Thro out up rate is set for a slow ramp up then would this cause a sluggish and delayed reaction in the Torque Pas which would may cause an over shoot if I was pedaling hard on the start and felt the bike get away from and stop pedaling which may lend to the surging.
The PID controller behavior can be difficult to figure out - which is why they can to be a bit troublesome to tweak in. That said - if you are getting overshoot, I would suspect too much gain rather than too much ramping.

I have a very slow ramp myself (over-volted gear motors) and run with a PLim->WGain of about 8-10 (can't check exactly - bike is slightly disassembled just now...)..
 
Thanks to teklektik and icecube57 for your detailed answer.

I have now tested with:

Up Rate: 99.99 Vlt/Sec
Down Rate: with 99.99V/Sec

and... the problem is gone: the throttle behaves as needed. I don't feel any delay in power reduction. Thanks for your input! I just didn't know that 99.99V/Sec is the maximum setting to "disable" ramping. I'm very happy now because I don't have any problems with settings anymore, everything is fine :)

Next step would be to have speed limit of 25kmph with presets or "Aux POT" switch. (that was the reason why I bought CA3) Therefore I think I have to change to speed throttle instead of "Pass thru". In that case I can legal drive on the street in the city with limited speed setting and can drive at unlimited speed outside the city.

thanks again 8)
 
dunja said:
the problem is gone: the throttle behaves as needed.

Next step would be to have speed limit of 25kmph with presets or "Aux POT" switch. (that was the reason why I bought CA3) Therefore I think I have to change to speed throttle instead of "Pass thru". In that case I can legal drive on the street in the city with limited speed setting and can drive at unlimited speed outside the city.

Glad to hear the throttle issue is fixed :D

For the speed limiting, you really only need to set SLim->MaxSpeed = 25kph to get the limiting you need. This will limit your top speed but leave the throttle response unchanged. You can just set this in a second preset. If you wish, you can rig up a 2 or 3 position switch on AuxPot to change presets. You didn't mention if you have PAS - if so, then AuxPot might better serve you as an Assist Level adjustment.

Frankly, 'speed throttle' is very strange - I personally don't care for it at all. So - you could leave the throttle in PassThru mode if you wish, although I would recommend that you try 'Current Throttle' as an experiment. It links the controller current to throttle rotation and generally makes the bike much more controllable. Some of the advantage will be lost if you have a cheapie non-linear throttle, or if the bike is only limited power and 'twitchie throttle' is not an issue -- still, worth a try...
 
Ok Teklektik. I tip my hat off to you. With the new chain ring and tweaking a few settings on the CA I pretty much got it dialed in. I changed the gain which was at 50 down to 10. That eliminated 95% of the surging. Im sure even if I tuned it down a little bit more it would eliminate it totally. This also reduced the surging when the thermal rollback kicks in. Two birds with 1 stone. I have my Aux Switch setup to 33%% 66 and 99% . I have the Torque Pas Start when it senses 50w of human assist...This is just out of pure laziness and the assist times is at 30x. So with the switch this should limit the power to 10x 20x and 30x human power. This also translates the human watt assist over the entire range of the usable wattage range of my bike. So switch position 1 I burst up to 1000w-2000w if I crank down on the pedals. Switch position 2 2000-3000 Switch position 3 3000-4000w. If Im really into it I can get it to push out to the max of the controller but its a good things that Im stopping well shy of this in most cases. I was trying to reduce my consumption on the tip in and provide more assist and it looks like I achieve what I was going after. The thing with this large chain ring it feels natural yet super human. I just have to learn not to pedal in corners or get shorter crank arms.
 
This is excellent news - glad you are closing in on the behavior you want. I found that after some use to acclimate to the PAS, going back and tweaking things got me a really nice personalized setup. It's a lot to take in at once so a bit of time and adjustment should get you home.

There are a number of interacting adjustments for PAS which can seem annoying, but when you realize the spectrum of vehicle weights, motor power, power curves, PAS sensors, riding styles, and personal tastes to be addressed, it's pretty neat that the gadget can be tuned in to accommodate the bulk of them....

I installed PAS on a lark, being very very happy with simple throttle-only use, but was completely won over by the different riding experience. Now I wouldn't have a bike without it - set up to switch between throttle and PAS as the situation allows.
 
icecube57 said:
I have my Aux Switch setup to 33%% 66 and 99% . I have the Torque Pas Start when it senses 50w of human assist...This is just out of pure laziness and the assist times is at 30x. So with the switch this should limit the power to 10x 20x and 30x human power. This also translates the human watt assist over the entire range of the usable wattage range of my bike. So switch position 1 I burst up to 1000w-2000w if I crank down on the pedals. Switch position 2 2000-3000 Switch position 3 3000-4000w.
...
I was trying to reduce my consumption on the tip in and provide more assist and it looks like I achieve what I was going after.
Something to consider might be a pot instead of the switch, or a combined pot/switch as described in the Guide (compliments of Kepler :D ). The pot might let you better tune the assist level to keep yourself on the edge of 'ideal' assist and stretch out your range. I do this myself when I'm on a long run and PAS can definitely squeeze extra miles out of the battery (it can be difficult to be thrifty with throttle-only, but PAS can be more of a taskmaster). You have an advantage over me in that I have only a PAS wheel and RPM-scaling (no torque sensor) and so setting the assist level is little more critical, but I think you might still find the pot helpful.

ebikes.ca now sells the eZee pot which will do the job if you want to skip the mounting fabrication.
 
I am getting glitches with the max speed recording on my CA. I was very excited when I saw 69 mph as the max speed. However on that run I only got up to 61 mph (GoPro was watching CA because I don’t have an Analogger yet). The run before I hit 64.4 mph and that was displayed as the max speed correctly.

I also ran into the same problem yesterday the top speed I hit in reality was 65.9 mph but the CA said 68.7 for the top speed.

I am no expert and this is only a minor problem, but maybe the CA code should be changed for the max speed where the top speed must be held for 0.1 seconds vs. 0.001 seconds which it might be currently (just an example). As I said I’m not an expert in this field but just a guess at what could be causing the problem/glitch.
 
speed errors are regular on my CA V3.

it's caused by contact bounce in the reed switch.
i routinely see max speeds of over 600kph :)

i think your idea that it has to be sustained for some time before being logged as a valid speed would help eliminate the error.

Jason
 
Diamondback said:
speed errors are regular on my CA V3.

it's caused by contact bounce in the reed switch.
i routinely see max speeds of over 600kph :)

i think your idea that it has to be sustained for some time before being logged as a valid speed would help eliminate the error.
Changing the firmware to mask symptoms of defective hardware makes little sense IMHO.

Contact bounce is not normal - replace your pickup...
 
Maybe a compromise ? a firmware change to allow a user set-able 'Max Speed" averaging time...This is already partially in place in , at least a V2 CA, for displayed current and voltage and speed instantaneous . I believe I have seen that as an option. to give more stable current / voltage display
 
NeilP said:
Maybe a compromise ? a firmware change to allow a user set-able 'Max Speed" averaging time...
The problem is that there is very limited space for configuration parameters and each has been selected for inclusion based on utility. IMHO it makes no sense to utilize a valuable configuration parameter to mask a hardware failure when that will unquestionably result in loss of some other useful feature.

There seems no product or market advantage to burning irreplaceable device resources to accommodate operation of defective equipment. Just fix it.

  • As an example, in a critical firmware revision last year, support for three batteries was abandoned in favor of only two simply to get configuration space for other product features.

    In the end, it's in Justin's hands, but he has been scrupulous in the past about avoiding overlapping or unnecessary features.
Display averaging is already available:

Unofficial Guide said:
2.4 Display Averaging

Measurements for voltage, amperage, and temperature values can be prone to jitter so the Cycle Analyst smooths display of these values according to the Pref->Averaging Setup parameter. The configured value determines the period of time over which consecutive data values are averaged; a new sample is obtained every 18msec and the average is cleared and begun anew when the average is computed and the display is updated. Averaging affects only the display – all other internal calculations use instantaneous measurement values.
 
teklektik said:
The problem is that there is very limited space for configuration parameters and each has been selected for inclusion based on utility. IMHO it makes no sense to utilize a valuable configuration parameter to mask a hardware failure when that will unquestionably result loss of some other useful feature.

Not aware of that..in that case, then yes...fix the sender
 
teklektik said:
Changing the firmware to mask symptoms of defective hardware makes little sense IMHO.
If hardware is faulty it totally makes since to fix it vs. changing software.
I am confused on how my hardware is faulty. I am not using a reed switch on the front wheel with a magnet on a spoke. I get my speed from the controller through the CA DP plug from the hall sensors.

Am I missing something here?
 
Scott said:
Am I missing something here?

To be more accurate, you missed it in your first post....missed giving that info that you do not use a reed switch that is.

In the post after yours, Diamondback mentioned a reed switch, and since you never corrected that, then, the assumption was made that you had a reed switch too.

As to now where this goes..over to the experts as to why the motor speed sensor is giving wrong speed info. As a basic guess..did the wheel ever spin a little faster ...get airborne for a second or two, loose traction for a second or so?...Agree though, even if that were the case, Max speed should not be so sensitive to register that
 
Scott said:
I am not using a reed switch on the front wheel with a magnet on a spoke. I get my speed from the controller through the CA DP plug from the hall sensors.
Am I missing something here?
No, but as Neil said, the discussion did get derailed. Apologies.

Scott said:
I was very excited when I saw 69 mph as the max speed. However on that run I only got up to 61 mph...
... but maybe the CA code should be changed for the max speed where the top speed must be held for 0.1 seconds vs. 0.001 seconds which it might be currently (just an example). As I said I’m not an expert in this field but just a guess at what could be causing the problem/glitch.
It seems highly unlikely that the true max speed could have ever reached 69 with a display average of only 61mph since even with the longest display averaging we are looking at a computation window of 1.2sec - that would have been remarkable acceleration/deceleration. This should not be a case of an true transient high speed so that leaves a signalling or calculation issue.

  • With the hall input, I can't really see how you could be consistently getting a bogus signal so close to a real speed reading (e.g. a loose connection, noise, wiggling the bike back/forth while standing, etc).
  • The CA speed calculation is trivial and it seems doubtful that there is a problem in there, although anything is possible - particularly with the display averaging two-step going on.
So - a bit confusing...

  • I don't always look at the MaxS display, and have from time to time seen values that seemed high - but since I don't normally watch the speed while riding and the 'high' values always were less than, or exactly at, the tested top speed of the bike, I never made much of it (I assumed just a little more WooHoo! than I noticed during the ride).

    I do have an Analogger, but my bike is off the road just now - I hope to get it together and out for the balmy 30's weather promised for the weekend. As soon as it's on the road again I can collect some data and specifically compare with MaxS over a few rides. This can't disprove your observation, but might confirm it. I will post back when data is in hand.
That said, an email to Justin might be useful.
 
Another consideration, although having the max speed relatively close to real speed, is outside electrical interference.

I have once seen a speed readout on the display with the bike stationary, leaning up against a shop window. Display lighting electronics were the cause
 
I’m sorry,that was a miscommunication on my part it took me a while to realize that a reed switch was the Speedo thing that goes on the front wheel.
NeilP said:
As a basic guess..did the wheel ever spin a little faster ...get airborne for a second or two, loose traction for a second or so?
As for losing traction I never came close the losing traction at high speeds but I did go over some very large tree roots on the sidewalk at 5-10 mph before I looked at the max speed. In this case the max speed was 69 mph when I went 61 mph in reality.
The run before this one I hit 64.4 in reality and the max speed said 64.4 also. So it seems like an intermittent problem.
On my old ebike which I sold the max speed said 106mph one time but I only went around 50 mph down a hill on that ride.

The second time I went for a ride I went to a different place and there were no bumps of any kind that would make my wheel slip or anything even at low speed and the max speed was still 3mph higher than my real top speed

teklektik said:
The CA speed calculation is trivial and it seems doubtful that there is a problem in there, although anything is possible - particularly with the display averaging two-step going on.
when my gps works.... about 1/4th of the time. The speed on the CA is around 0.5 mph slower than my GPS at 65mph and 54 mph. So I would say the CA speed is pretty spot on.

I will try to wiggle the wires the next time I ride my bike, but it will be rainy for the next few days.

Thanks for all your help!
 
Looking for HELP
Trying to update the firmware to prelim 6

It seems to hang at this point in the firmware update tool v1.1

Now flashing with CA3_Prelim6_NoCal.hex
Cycle Analyst 3 detected with bootloader version 0202
Please cycle power to the device....


When I turn on the CAv3, it flashes CAv3 beta21 ....this isn't same as CA3_Prelim6_NoCal is it? (why not just call them by the same name!)

I bought a cheapo USB-TTL thingo from http://www.banggood.com with leads hanging off it and soldered a 3.5mm audio jack to it, so I assume if the update tool gets to the "Now Flashing" stage the USB-TTL thingo should be fine.
Anyone else had this problem?
 
Many had the same problem.
Its the prolific chip. you need shorter wires from the USB-TTL to the CAv3 i mean realy short like 5cm.
 
Back
Top