Cycle Analyst V3 preview and first beta release

teklektik said:
hjns said:
My CAv3 b16 just stopped working. When I power on, the CA goes through boot, and then shows only a horizontal row of rectangles. Powering off and then on again results in the same. Should I try to flash? I am open for any suggestions!
I haven't seen this particular boot failure display symptom (mine is always blank with backlight on)...

Thoughts:
  • The v3b16 firmware file is known to be corrupted. I would immediately upgrade to a more contemporary build (v3b17) to get onto a firmware base that is known to be uncompromised. Although your CA may have been operational, the actual code it is running is unknown and hence any symptom reports are of little value. I will do that.
  • When the boot-failure issue occurs for me, it is necessary to remove the power (bike or CA) so that the CA is restored to a completely idle and inoperative condition. This can take a minute or so if the voltage is high and the CA remains connected to the controller after the power connection is severed. Failure to get to a full-power-down state invariably prevents proper reboot. I will try that.
  • I run my battery cutoff setting fairly high (e.g. for 66v nominal: Batt->VltCutoff=40v) to ensure that the CA has ample power/time to tidy up before shutdown.
My LVC is at 73V (3.65V cell level) so I should have ample power/time.
 
hjns said:
I run my battery cutoff setting fairly high (e.g. for 66v nominal: Batt->VltCutoff=40v) to ensure that the CA has ample power/time to tidy up before shutdown.[/list] My LVC is at 73V (3.65V cell level) so I should have ample power/time.
My apologies - I meant the shutdown voltage (Disp->Vshutdown=40v) not the low voltage cutoff (Batt->VltCutoff) that I mistakenly placed in the post. The LVC is an alarm level and does not affect the shutdown procedures for the unit.

To be honest, I have assumed that Disp->Vshutdown had more sweeping scope than just the display; -- the exact impact of this setting needs a bit more clarification from Justin.
 
teklektik said:
To be honest, I have assumed that Disp->Vshutdown had more sweeping scope than just the display; -- the exact impact of this setting needs a bit more clarification from Justin.

Hey guys, indeed VShutdown is the point where the CA saves all current trip data to eeprom in preparation for the supply voltage to be completely cut. It goes to sleep during this period to reduce power draw but then it still keeps a tab on the pack voltage so that if it rises again above the VShutdown point the CA can restart operation. So normally it would cross this state only when power is cutoff, not in normal use, but if you were to drop below VShutdown and then let the voltage rise again it would have the appearance of the CA resetting even though it never actually lost power.

-Justin
 
Justin-
I know that you are deep in code revisions for v3b18 (not to mention other non-CA business affairs), but here's another item for the wish list (low to mid priority):

One thing that my auto ECU offers for display that is absent on the CA is Instantaneous Mileage. In CA terms this would be Instantaneous Wh/mi. This rolls together the current draw, battery state, and actual distance returned for the energy expenditure and is not directly available from other displays. I can extract this information ex post facto from Analogger data, but the CA currently provides only an average value for the aggregate trip. Here we might be getting an update every few seconds, wheel revolution, or whatever was the most easily achievable from an internal calculation perspective.

This display would have immediate value for those trying to stretch charge mileage by giving immediate feedback relating to changes in speed, throttle, LMH setting, etc. It should make identification of the 'sweet spot' fairly easy and provide a useful metric for tuning alterations such as changes to phase amps, etc.

To a lesser extent it would also to help establish more widely known 'typical' Wh/mi readings for different speeds/terrains. For instance, there have recently been a spate of noob requests for battery configurations and many of the more experienced ES members are able to step up with good recommendations. However, for estimates without the years of experience, battery capacity calculations are trivial and fairly accurate given a reasonably accurate consumption value (Wh/mi) for the target terrain and the desired mph. Such figures are not widely available, but would become so if the CA provided them as a matter of course - it would become more common to speak (for example) of 17Wh/mi at 18mph on flat terrain, or 35Wh/mi in stop and go city traffic. This translates into estimating the size of the tank if you know the rough mpg for particular driving situations.
 
What a great idea! I would be very happy with an instantaneous Wh/km readout. It will make comparing different controllers on the same hill a piece of cake.
 
teklektik said:
Justin-
One thing that my auto ECU offers for display that is absent on the CA is Instantaneous Mileage. In CA terms this would be Instantaneous Wh/mi. This rolls together the current draw, battery state, and actual distance returned for the energy expenditure and is not directly available from other displays. I can extract this information ex post facto from Analogger data, but the CA currently provides only an average value for the aggregate trip. Here we might be getting an update every few seconds, wheel revolution, or whatever was the most easily achievable from an internal calculation perspective.

Hey Teklektik and thanks again for the feedback. Oddly that was the original plan in the first CA rather than showing the trip aggregate, but I found in practice it is less useful than I would have thought. Your instantaneous Wh/km moves around an order of magnitude between going up steep hills and accelerating vs. riding on the flat with a tail wind, and so seeing you briefly pull 100 Wh/km doesn't necessarily mean much (in terms of what your total usage will be) if it's getting you up to speed or up in elevation. Plus, at least in metric, the Wh/km tends to hover around 10, so in a pinch I can glance at the CA and see say 500 watts and divide that by 40 kph and know that I'm using ~12 Wh/km with minimal mental arithmetic from the existing display.

Thinking about how to implement it. RIght now you can choose between watts or amps on the main screen, and there could easily be a 3rd choice to show Wh/km instead. I'll add this to the little memo list unless you have a different idea on where you'd like it displayed? There would be room on the Wh screen to show both the trip and instant Wh/mi, but usually you want to see this in context with speed and other data. Other possibility would be to have it toggle with the Ah and Distance (and optional Temp) data. In that case though, you'd probably want it to be a longer time averaged version of the mileage.

This display would have immediate value for those trying to stretch charge mileage by giving immediate feedback relating to changes in speed, throttle, LMH setting, etc. It should make identification of the 'sweet spot' fairly easy and provide a useful metric for tuning alterations such as changes to phase amps, etc.

I think for user feedback something that is more like a 20-30 second rolling average of the mileage figure would be more meaningful that instant, which is pretty jumpy.

the years of experience, battery capacity calculations are trivial and fairly accurate given a reasonably accurate consumption value (Wh/mi) for the target terrain and the desired mph. Such figures are not widely available, but would become so if the CA provided them as a matter of course - it would become more common to speak (for example) of 17Wh/mi at 18mph on flat terrain, or 35Wh/mi in stop and go city traffic. This translates into estimating the size of the tank if you know the rough mpg for particular driving situations.

Totally agreed. The overall trip Wh/mi gives this data quite well but doesn't convey how the consumption was divied up among the different terrain. Another possibility would be to have a stats reset counter that will refresh the Wh/km figure but not say your total distance or total Ah.

-Justin
 
Dingo2024 said:
had a look at the pdf of the Thun sensor.................can this be used on a 72mm bottom bracket frame?

thanks,

That would probably be a question best posed to THUN or a bike mechanic rather than me ;)

If the thread pitch and diameter are the same and it's just a few mm wider, I'd say it would should fit close enough. If not, you could reface the ends of your bottom bracket shell to remove the additional metal and make them a bit narrower. Then rechase the threads a bit deeper if required.
 
Hi Henk, this will happen if the LCD module is not being initialized properly for some reason but is getting the full 5V. Try installing the B18 firmware which does multiple LCD initializations during the boot sequence. if that doesn't change it, then there is either a bad connection to one of the LCD header pins or something else, in which case send an email to info@ebikes.ca and we'll sort it from there.

Justin

hjns said:
Hi Justin,

My CAv3 b16 just stopped working. When I power on, the CA goes through boot, and then shows only a horizontal row of rectangles. Powering off and then on again results in the same. Should I try to flash? Any other suggestions?

I am running 20S (84V HOC, 74V nominal, 73V LVC programmed in another CAv2), with a CAv2 running a current throttle and an 18FET 4110 from Lyen. The controller is limited to 80A/210A with 100% speed setting and regen enabled at it's strongest. The CAv2 is limited to 80A 100km/h and plugged into the controller using a DP. The CAv3 is connected to an external shunt as recommended in the CA manual for external shunts (aka in line with the controller on the ground side). The CAv3 is also connected to the thermistor in my cromotor and to the CA analogger. The other connectors are not connected.

I am open for any suggestions!
 
Justin would it be possibly to have a maximum wh/mile ?
Not so much for economy but for protection for more powerful motors.

It's not one of those every day features but it could be used to protect users from cooking motors on continuous steep climbs at peak power levels that normally wouldnt bother the motor.

Eg. a guy the other day in the stealth owners thread talked about getting poor milage with some steep, rough mountain climbing. He quoted a CA whr/mi of nearly 90 which is pushing your luck even for the big, heavy 5400.
 
Paul_G said:
One change I would love to see on V3.0 is on the main screen would be to replace AH's used with WH's used.
I want to see my (gas tank) without having to go two screen deeper and then back just to see if I need to turn for home.

Hey Paul, your amp-hours is your gas tank indicator, watt-hours is not. That's because your available watt hours will depend on the current at which you drain the battery pack as the voltage sag at higher current results in fewer watts being generated by the same number of electrons.

With a lithium battery, the electron efficiency is almost perfect, so regardless of how fast you drain the pack you get the same amp-hours from the discharge each time, but you'll get a fairly different readings for your watt-hours.

-Justin
 
Gab said:
hi guys should of added more detail. this is for a brushless middrive setup. i have heard of occurrences of the magnets shatering at high rpm and the way too high rpm could happen is dowhill or too low a gear hence not enough load. do you think this is possible to show motor rpm in the ca? or should i try and find a controller to do the rpm limiter ?

Hey Gab, you can show motor RPM by putting a single magnet and pickup on your middrive motor and setting it up in the V3 CA as your "PAS sensor". The CA will think this is your pedal cadence rather than motor RPM but no problem there. Then you go to the 3rd display screen which shows volts, amps, speed, Human watts, and RPM, so you can see speed and RPM side by side. There aren't any limiting features implemented around the RPM data yet.

In general, your motor RPM will be dictated by your battery supply voltage, so if you are worried about magnets shattering you'd be smart not to pick a supply voltage and Motor KV that puts it in danger of this.

-Justin
 
[EDIT - attached firmware file removed due to apparent corruption issue, see later posts. Working to sort that and host the firmware downloads from an external site]

Attached is the Beta18 firmware. I was really hoping to have nailed the bug that has been causing the CA to randomly freeze for 20-30 sec. on some people, but in the end have not once been able to replicate this phenomenon or get much meaningful clue as to where it is coming from. So what I have done instead is write various check conditions throughout the code and if things are anomalous, the CA will immediately put the throttle output to 0V and then show a message on the screen. In the event of some blocks of code taking longer than expected there will be a message saying "TMR1 XXXXXX", and if the CA ever gets stuck in a loop, it will show the message "CRASH" followed by the last 3 program counter locations. This can then hopefully be used to trace back where in the code things were running when it got loopy.

If either of these incidents happen, you can just press the right button and everything will resume again, no need to power cycle, but it will be good to take note of the numbers shown on the screen. At least though the throttle will get driven low so you won't have a stuck on high throttle if it does crash.

Other changes are more minor tweaks since the focus was really on this bug fix. However, I did also sort out what was going on with the differential speed control, so you no longer need to set the DSGain to 0 to sort the throttle startup issues. The CA's data output stream now includes a last column that is the vehicle's accelleration in m/s/s (so roughly divide by 10 to get 'g's), and the feedback can be tweaked to give smooth speed limiting without overshoot and oscillations.

I've had good results with my system (48V eZee kit) setting the IntSGain to about 50-60, the proportional to about 0.5V/kph, and the DSGain in the 200-300 range.

-Justin
 
Please consider NOT having alternating displays. That feature of the CA caused my son to crash by diverting his attention waiting for the number to come up a little bit too long. Gaining screen space by dropping some excess digits and leaving off units would be safer. People quickly learn which number is where and can glance at the screen.

The trick with short term displays like watts and watt hours per mile is to get the filtering right, instantaneous values are too jumpy to be of great use. The adjustable averaging is a good solution for that.
 
justin_le said:
Hi Henk, this will happen if the LCD module is not being initialized properly for some reason but is getting the full 5V. Try installing the B18 firmware which does multiple LCD initializations during the boot sequence. if that doesn't change it, then there is either a bad connection to one of the LCD header pins or something else, in which case send an email to info@ebikes.ca and we'll sort it from there.

Justin

thanks, Justin. I will do that tonight and report back.
 
justin_le said:
teklektik said:
Justin-
One thing that my auto ECU offers for display that is absent on the CA is Instantaneous Mileage. In CA terms this would be Instantaneous Wh/mi.
Oddly that was the original plan in the first CA rather than showing the trip aggregate, but I found in practice it is less useful than I would have thought. Your instantaneous Wh/km moves around an order of magnitude between going up steep hills and accelerating vs. riding on the flat with a tail wind, and so seeing you briefly pull 100 Wh/km doesn't necessarily mean much (in terms of what your total usage will be) if it's getting you up to speed or up in elevation. ... you'd probably want it to be a longer time averaged version of the mileage. ... I think for user feedback something that is more like a 20-30 second rolling average of the mileage figure would be more meaningful that instant, which is pretty jumpy. ... Another possibility would be to have a stats reset counter that will refresh the Wh/km figure but not say your total distance or total Ah.
Justin-
Thanks for the quick response. I agree 100% with your assessments of the problems with an instantaneous value. I find the same issues with Instantaneous MPG in my auto and address them in a manner similar to what you have proposed - resetting the Avg MPG for a test run or repeatedly as a poor man's rolling average.

I really wanted to fly the basic idea and leave the details up to you since the biggest part of the problem is not the calculation but resource management - display area, top level button pushes, memory for rolling calculations, additional configuration, etc. Some of the solution could be tied to the configurable screen concept discussed in earlier posts, etc, so diving into supporting details seemed like it might muddy the concept presentation.

That said, a rolling mean with a configurable max period (sample lifetime) of 15-30 seconds would be terrific even if the granularity of the rolling sample period was only something like 5 seconds. Different levels of reset are somewhat attractive, but I don't believe the feature value warrants complicating the button press situation (particularly those that need to be accomplished while underway).

justin_le said:
Thinking about how to implement it. Right now you can choose between watts or amps on the main screen, and there could easily be a 3rd choice to show Wh/km instead.
Since these are in the same general category of energy expenditure metrics, this could be a nice approach.

justin_le said:
Other possibility would be to have it toggle with the Ah and Distance (and optional Temp) data. In that case though, you'd probably want it to be a longer time averaged version of the mileage.
This seems less attractive, but still workable. In this case, you might forego the rolling average in lieu of a running average that resets when the Wh/mi display value goes out of sight. It would then begin accumulating the new value and continue to average in new values until reset again in the next rotating display cycle. The advantage would be eliminating the configuration of a rolling period (driven instead by display period), and eliminating storage needed to maintain a rolling value (there would only be the current accumulated average since last reset). This seems slightly sub-optimal but still valuable as a compromise while we're saving resources for other goodies...

Anyhow - glad to have this on your memo list for consideration... :)
 
I just tried to flash/configure the v3B18c firmware and found that a new Cal->Rshunt value can be entered but cannot be saved to alter the default 0.000 configuration value.

Justin is nailing down the final locations for critical calibration parameters and I believe this and other firmware versions moving forward should preserve select calibration values and so tried a couple of re-flashes of past builds to get different default data in eeprom. Re-flashing with v3B18c as the final flash always seems to suffer the same Rshunt-save problem.

I did not pursue test of other setup values or general firmware functionality.

Anyone else having this Rshunt-save issue? Justin may be tied up with business and personal matters for a bit, so any feedback from other beta testers would be welcome.
 
teklektik said:
Anyone else having this Rshunt-save issue?

Yes, on two "pre production" CAv3's
 
hi justin.

I have a problem about CAV3.
Can I do something to clear probrem?

I think this is firm bug. because From the thro terminal, default voltage is outputted correctly.
(I have sent "info@ebikes.ca",But your mail server judged my mail to be a junk mail. :cry: :cry: :cry: so, it contributed here.)

Naix
---------------------------------------------------------------------
below is Condition
err1_2R0010610_R.jpg

err2_R0010613_R.jpg


FirmVer
R0010580_R.JPG


Settings
R0010612_R.JPG

R0010611_R.JPG

R0010604_R.JPG

R0010606_R.JPG
 
naix said:
hi justin.
I have a problem about CAV3.
Can I do something to clear probrem?
I think this is firm bug.
As mentioned above, Justin may be tied up for a bit, but maybe forum folks here can help until he can get back to reviewing the posts. The functionality you are describing is very basic and has been well exercised, so I think a little Setup tweaking may address the problem...

First, as noted in a recent post, the v3b16 firmware file is known to be corrupted and the v3B18 appears to have difficulties. I would recommend upgrading to v3B17 to get onto the newest firmware base that is known to be uncompromised.

Next, please verify that you have configured according to the unoffical setup instructions in this post and as noted there, have not configured any other CTRL, limit, or gain settings. (Verifying the setup procedure eliminates many potential debug questions... :) )

And last, although you provided some values by photo, it would be helpful if you could provide all the settings for ThI and ThO setup parameters as well as the throttle type (hall/resistive) - (just type the values - no need for photos)...
  • Setup Throt In
    1. ThrI -> Cntrl Mode
    2. ThrI -> Min Input
    3. ThrI -> Max Input
    4. ThrI -> Fault Volt
  • Setup Throt Out
    1. ThrO -> Output Mode
    2. ThrO -> Min Output
    3. ThrO -> Max Output
 
Hi teklektik.
Thanks for kindly responce :) :)

I have tried upgrade firm 16B->17 to clear configuration.
Its very ok. Clear my probrem now :D :D :D
thanks very much.

below is my setting
It is same when 16B.
so 、The cause is unknown. I would like to expect justin :) :) :) .

  • Setup Throt In
    1. ThrI -> Cntrl Mode : pass through
    2. ThrI -> Min Input :0.9V
    3. ThrI -> Max Input :3.8V
    4. ThrI -> Fault Volt : 4.5V
  • Setup Throt Out
    1. ThrO -> Output Mode :voltage
    2. ThrO -> Min Output :0.9V
    3. ThrO -> Max Output:3.8V

Naix
 
teklektik said:
naix- This is great news! I'm very happy all went well. Enjoy your V3! :D
thx too much your helping :D :D :D
I will enjoy much :D

by the way . I want to ride without throttle. because of the law of the country .
but pas mode have start delay.so i will try torque mode mainly.
What is a recommended setup for giving a quick response to start dash?
 
Back
Top