Cycle Analyst V3 preview and first beta release

[teklektik]

Hey Justin, That great awsome device is now on my zero motorcycle

Very slick and polished installation - it looks like OEM equipment... .

[hillzofvalp]

One more suggestion. How about a large screen showing graphics only? Battery State Of Charge Indicator, Throttle Position Slider, Human Power Bar Graph, and miles or kilometers per hour, (speed)
Like this:

Unfortunately the CA doesn't use a graphics screen, so it can only show number and letter characters and then a few graphical 'hacks' within a 5x8 character grid which you see in this one here. It doesn't lend itself well to showing predominantly visual indicators. Someday Marty a full graphic display will be in the cards and you will get your long awaited wish, but not yet! gotta grow one step at a time.

What BionX and almost all other consoles do is use a custom segmented LCD screen tooled up that exactly matches the info they want to display. It's very economical in scale, you don't need to do any graphics processing in a CPU, but it's also single function in nature and so doesn't lend itself to the kind of multi-purpose display flexibility that the CA needs.

-Justin

I still think simple sliders are very doable on this CA.. They don't have to be super pretty but they could be big enough to be useful. Even the battery indicator as is to me is not something that would give me enough resolution as a casual observer.

It looks like horizontal indicators would be most practical to use and easy to program. Maybe there could be an option to dedicate the top or bottom half of the screen to a parameter option. Even dividing the bottom half into too sliders could be easy to program.

I have not seen your code but obviously requires some rework, so I can maybe see it as a low priority. I would think the code would be redundant enough to make it less taxing

[Joe Perez]

(...) I'll try calibrating Rbatt and see if that makes it behave more logically- based on Justin's post on page 14 (where RBatt = (V1 - V2) / A) it looks like I should configure it as 066 (it's at the default 199 right now)

Well that's just darned interesting. With Rbatt set to 066, the strange behavior in the SOC indicator went away. I'd really love to know what the algorithm is which is driving that display. (edit: Oh, I get it now. Rbatt is used as a compensation relative to instantaneous current, to compensate for voltage sag under load. That way the gauge doesn't fluctuate as the load causes battery voltage to go up and down. Genius!)

Ah, well. All in all, this CA3 is just absolutely phenomenal.

Something amusing occurred to me over the weekend. When I saw a lot of folks in this thread making impassioned suggestions about table-based (or otherwise non-linear) throttle scaling, I couldn't figure out what the big deal was. Of course, at that time I was riding with an Amped Bikes direct-drive motor (2807) and an anemic 36v bottle battery, so for me, the idea that you'd ever need anything less than 100% throttle all the time seemed unfathomable. (translation: the Amped system is weaksauce.) Now that I've upgraded to a 10T geared MAC and a Cell_Man 52v battery, I suddenly understand what all the fuss is about. It's kind of hard to keep this thing from wheelieing if you accidentally apply more than 0.05% throttle from a stop.

Actually, now that everything is up and running, I probably need to experiment with current-mode throttle, as opposed to pass-through as I have it now. That alone would probably make things a lot easier. Off to do more reading.


At any rate, Justin, this is a hell of a great product. I seriously cannot express in words how much I like what you've created here.

[justin_le]

I saw that, along with his note that "If you are running LiFePO4 just ignore the fuel gauge until the Ah accumulation is integrated in the beta software here."
Since I am running a LiFePO4 battery, I understand that it's not up to par yet, this particular behavior just struck me as exceedingly odd. I'll try calibrating Rbatt and see if that makes it behave more logically- based on Justin's post on page 14 (where RBatt = (V1 - V2) / A) it looks like I should configure it as 066 (it's at the default 199 right now)

Hi Joe, indeed this behaviour is coming from an incorrect (too high) battery resistance value. When you are drawing current, the CA tries to extrapolate what the actual pack voltage would be with no current before it references the lookup table. So suppose you are drawing 10A, and reading 47V from the pack. If RBatt was set to 200 mOhm, then the CA would assume your actual battery voltage is:
47 +10A*0.2 Ohm = 49V

If your actual RBatt is only say 100mOhm, then the actual open circuit voltage of the pack is more like 48V
47 +10A*0.1 Ohm =48V

If you then increase the current draw to 20A, the voltage on the pack would fall down from 47V to 46V, but the CA would overcompensate even further when extrapolating the open circuit pack voltage, now to:
46 + 20A * 0.2 Ohm = 50V.

So this is why with RBatt too high, you have an effect where drawing more current causes the battery indicator to go up. Once you play around with it you can find a value that causes the graph to neither go up or down with increased load.

This is however somewhat moot as the Beta15 code no longer lets you input the RBatt value. Instead, it computes it in real time, and this allows it to track your changing battery resistance both as it ages and as it varies with temperature and state of charge. So there is now a new screen which lets you see the instantaneous RBatt value that the CA has deduced from watching the recent voltage/current history, and you as a user no longer need to worry about setting this up:

CA3_BattSOC.jpg (18.83 KiB) Viewed 1932 times

[hillzofvalp]

That is super cool. Thanks for including that.

[justin_le]

I'd really love to know what the algorithm is which is driving that display. ([i]edit: Oh, I get it now. Rbatt is used as a compensation relative to instantaneous current, to compensate for voltage sag under load. That way the gauge doesn't fluctuate as the load causes battery voltage to go up and down.

This came in after I had already written but forgot to submit the previous post, but yes spot on. However, the Beta15 algorithm does things on the display quite a bit differently in that it is also looking at your amp-hour history. The look-up table approach gets increasingly inaccurate as you draw more and more current, so in this situation the CA3_B15 weights more heavily towards looking at your change in amp-hours to determine how the SOC should go down, and increasingly ignores the look-up table value.

At the end of the day though, amp-hours can go in and out of the pack without the CA knowing and this in and of itself causes an amp-hour based approach to SOC display to fail. So whenever there is relatively little current draw, then the CA will see where the open circuit pack voltage is at and gradually cause the SOC graph to drift towards that.

It's the kind of thing that was conceptually pretty straightforward to work out, but a bit of a challenge to implement on an 8-bit micro, so that's why it's taken a while to roll this out.

Now that I've upgraded to a 10T geared MAC and a Cell_Man 52v battery, I suddenly understand what all the fuss is about. It's kind of hard to keep this thing from wheelieing if you accidentally apply more than 0.05% throttle from a stop.

Indeed had to have a similar realization test riding other people's ebikes before appreciating this too . That happened after years of wondering what the fuss was about 3-speed switches.

-Justin

[justin_le]

So attached here is the B15 version of the CA3 code. Please note that I've only had a few hours to field test on the bike and haven't run through nearly all usage scenarios, so there may be newly introduced bugs but to a first order it seems OK.

Differences with Beta14 are:

1) No longer a field to input RBatt
2) Battery SOC algorithm now takes into account the pack capacity in Ah, so be sure to input this value in the battery setup.
3) Display Screen # 10 shows Volts, Amps, RBatt, and %SOC
4) Serial data output stream has been modified to include the throttle input and throttle output voltages as well, and gets rid of the instantaneous torque (but still includes average torque). A screen capture of the data stream looks like this:

CA_V3_Output.gif (8.68 KiB) Viewed 1927 times

[hjns]

Very nice, very useful. V3 keeps getting better and better, and I love it! Thanks, Justin!

[johnrobholmes]

What is the time span the torque is averaged over?

[teklektik]

Differences with Beta14 are:
...
4) Serial data output stream has been modified to include the throttle input and throttle output voltages as well,...
...

Thanks, Justin - much appreciated!!!

[teklektik]

Setup Summary for CA v3B15

The setting summary for the newer v3B16 release is available here.
The setting summary for the previous v3B14 release is available here.
Unofficial basic setup notes are available here.
Values shown are defaults after loading firmware.

[...] = numeric entry field
{ ... | [...] } = menu chooser where [...] = default selection

1. Setup Calibrtion
   
   1. Cal -> Range
      { [Lo (W)] | Hi (kW) }
   2. Cal -> RShunt
      [1.000] mOhm
   3. Cal -> V Scale
      [31.05] V/V
   4. Cal -> Zero Amps
      (Press/Hold to normalize the currently detected Amp reading to 0.0)
2. Setup Spdometer
   
   1. Spd -> Units
      { mi | [km] }
   2. Spd -> Wheel
      [2075] mm
   3. Spd -> #Poles
      [23]
   4. Spd ->TotDist
      [00000] km
3. Setup Speed Lims
   
   1. SLim -> Max Speed
      [99.0] kph
   2. SLim -> Start Speed
      [00.0] kph
   3. SLim -> IntSGain
      [200] Gain
   4. SLim -> PSGain
      [0.59] V/kph
   5. SLim -> DSGain
      [002] Gain
4. Setup Power Lims
   
   1. Plim -> Max Current
      [99.0] Amps
   2. Plim -> AGain
      [150] Gain
   3. Plim -> Max Power
      [9999] Watts
   4. Plim -> W Gain
      [050] Gain
5. Setup Throt In ........ Live Data = < 0.00V >
   
   1. ThrI -> Cntrl Mode
      { [Pass-thru] | Current | Speed | Disabled }
   2. ThrI -> Min Input
      [0.99] Volts
   3. ThrI -> Max Input
      [3.99] Volts
   4. ThrI -> Fault Volt
      [4.49] Volts
6. Setup Throt Out
   
   1. ThrO -> Output Mode
      { [Voltage] | R/C Pulse }
      (if ThrO->OutputMode = { Voltage }
      
      1. ThrO -> Min Output
         [0.90] Volts
      2. ThrO -> Max Output
         [3.74] Volts
         )
      (if ThrO->OutputMode = { R/C Pulse }
      
      1. ThrO -> Min Output
         [0.90] mSec
      2. ThrO -> Max Output
         [3.74] mSec
         )
   2. ThrO -> Up Ramp
      [500]
   3. ThrO -> Down Ramp
      [500]
   4. ThrO -> KV Comp.
      [0.95] V/kph
7. Setup RPM Sensor ........ Live Data = < Rev Hi > >
   
   1. RPM -> PAS Poles
      [08]
   2. RPM -> Dir Plrty
      5v={ [Fwd] | Rev }
   3. RPM -> Quadrtr
      { Disabled | Enabled }
   4. RPM -> Strt Delay
      [25] x 18ms
   5. RPM -> Stop Delay
      [15] x 18ms
8. Setup Trq Sensor ........ Live Data = < 3.37V >
   
   1. Trq -> Trq Scale
      [-200.0] Nm/V
   2. Trq -> Trq Offset
      {2.49V 2.43V}
      (Press/Hold to update eeprom offset voltage on left with current voltage on right - similar to Zero Amps)
9. Setup Cntrl Mode
   
   1. Ctrl -> PAS Mode
      { [PAS Off] | RPM Cntrl | Trq Cntrl }
   2. Ctrl -> Assist Level
      [0500] mA/Nm
   3. Ctrl -> Aux Funct
      { [Off] | Amps Lim | Speed Lim | Power Lim | Pas Level }
   4. Ctrl -> Min Aux In
      [0.99] Volts
   5. Ctrl -> Max Aux In
      [3.99] Volts
10. Setup Temp Sensr
    
    1. Temp -> Sensor ........ Live Data = < 4.93V >
       { [Disabled] | 10K Thrmstr | Linear Type }
       (If Temp->Sensor = { Linear Type }
       
       1. Temp -> 0 Deg
          [0.99] Volts
       2. Temp -> TScale
          100.0 Deg/V
          )
    2. Temp -> Thrsh Temp
       [090] oC
    3. Temp -> Max Temp
       [130] oC
11. Setup Battery
    
    1. Batt -> Chemistry
       { [LiMn] | LiPo | LiFe | SLA | NiMH }
    2. Batt -> String#
       [10] Cells
    3. Batt -> Capacity
       [10] Ah
    4. Batt -> Vlt Cutoff
       [019.0] Volts
    5. Batt -> V Gain
       [0800] Gain
    6. Batt -> TotCyc
       [0000] Cyc
    7. Batt -> TotAhrs
       [00000] Ah
12. Setup Display
    
    1. Disp -> Main Disp
       { [Watts] | Amps }
    2. Disp -> Averaging
       [5] Duration
    3. Disp -> RS232
       { [1] | 5 } Hz
    4. Disp -> Vshutdown
       [10.0] Volts
    5. Disp -> Stop Scrns
       [11111111111]
       (Binary digits select display of 11 screens starting with Main)
    6. Disp -> Movn Scrns
       [11111111011]
       (Binary digits select display of 11 screens starting with Main)

Printable version:

CA_3B15_ConfigSettings.zip

(1.53 KiB) Downloaded 28 times

[Tench]

Thanks Teklektik, got myself a cable, laptop accepts it, com port i dentified, b15 downloaded, i just need to print one of your sheets off, note down my current settings and i am going to have a go at installing the new version, Prepare to get bombarded with questions when i no longer have a bike that works! This will be a first for me, never flashed a device before.

Simon.

[justin_le]

What is the time span the torque is averaged over?

Great question. It's actually averaged over each full pedal rotation rather than over a time span. This way there is no undulation from the pulsating human pedal torque aliasing with the average rate in different ways. However, it also means that the torque signal is pretty useless (ie won't change) unless you similarly have an RPM meter hooked up. For use in a dyno type application on fast spinning motors, then the torque value would be nearly instantaneous as the motor is probably doing several revolutions between each data transmission.

-Justin

[johnrobholmes]

Great answer, and an even better implementation of the averaging!

Can't thank you enough

[rscamp]

I just have to say. I'm very impressed with this new version of the CA and all the discussion here.

This thread is chock full of goodness.

[Joe Perez]

Actually, now that everything is up and running, I probably need to experiment with current-mode throttle, as opposed to pass-through as I have it now. That alone would probably make things a lot easier. Off to do more reading.

Yup, that did the trick. Still running B14 (will probably put off the upgrade until this weekend) but current-mode throttle *really* improved the controllability.

[hillzofvalp]

I'm just going to desolder most of the accessory wires.. Do u have any units you can offer the $140 price sans extra harness?

[Waldo]

I notice that speed less than 4 mph does not show on the display, nor is it in the data file record.
With CA2 V2.25 the lowest indicated speed is 2.5mph.
Wheel = 2105.
It would be great if the CA could show speed aproaching 0.00.

Waldo

[Tench]

I notice that speed less than 4 mph does not show on the display, nor is it in the data file record.
With CA2 V2.25 the lowest indicated speed is 2.5mph.
Wheel = 2105.
It would be great if the CA could show speed aproaching 0.00.

Waldo

I am using a wheel driven speed sensor on my CA, i tried fitting 3 magnets to the disc spider but their strength and proximity caused a field too strong for the reed switch to release. If you can use multiple evenly positioned magnets and change the pole count accordingly it is bound to give a higher resolution to your signal and may allow it to function at lower speeds?

[teklektik]

I notice that speed less than 4 mph does not show on the display, nor is it in the data file record.
With CA2 V2.25 the lowest indicated speed is 2.5mph.
It would be great if the CA could show speed aproaching 0.00.

I use three evenly-spaced spoke magnets and get speeds down to about 3.25-3.45 mph which is fine for me. This was a quick test a couple of minutes ago, but a sudden downpour ended the test after only a couple of tries, but I don't think it will go much lower.

A single magnet was working fine (I never bothered with super low speed checks) but upgraded to try to smooth out low speed 'Speed Throttle'. With only a single magnet I was only getting a speed update about every 6m (very delayed feedback to the CA compared to 20-something motor poles) - with three, it's about every 2/3m. Other pressing matters prevented finishing up those tests, but I'm hoping to return to them shortly.

I am using a wheel driven speed sensor on my CA, i tried fitting 3 magnets to the disc spider but their strength and proximity caused a field too strong for the reed switch to release.

Clever idea. If you haven't abandoned that setup entirely, you can try attaching a small magnet with reverse poles to your pickup. This works pretty well in general with reed switches - sometimes you need to position it away from the center of the switch towards one end.

... If you can use multiple evenly positioned magnets...

Although in this case your recommendation is clearly going after more frequent and evenly-spaced updates, Justin reports that in the general case, additional wheel magnets do *not* need to be evenly spaced. This is nice since, for instance, on my bike my 'evenly spaced' options are 1, 3, and 9.

BTW - Although spoke magnets from just about anywhere will work, ebikes.ca will sell them individually - if you're thinking on these lines, email and have them throw a few in the box when you order your new v3.

[Joe Perez]

Just got back from my first ride on the b15 code. Still working nicely in current-throttle mode, but I do have one new bug to report:

When I got home and reviewed the data from the trip, the main screen told me that I'd ridden 11.4 miles (which is correct) and consumed 4.45 Ah (which is probably correct, based on past experience), however a few screens over it claimed that I'd achieved an efficiency of 13.8 watt-hours per mile. Given that I have a 52v LiFe battery, this is wrong. (Normally, the displayed wh/mile value matches a manual computation [Ah / miles * 51] and produces a value of around 20-23 depending on terrain and rider effort.)

I did verify that the realtime voltage display indicated normally both at rest and while under load, so I know that the CA is still reading voltage correctly.

[Joe Perez]

I've also noted another odd phenomenon, which I believe is new in b15.

Each time I power up the system, the odometer on the main screen increments by approximately 0.16 miles:



You can see in the video that each time I switch it off and then on again, it increments from the previous position at the last shutoff, and yet the bike isn't moving at all. I am using a reed sensor with a single magnet on the front wheel, so 1 pulse per rev.

[amberwolf]

Funny you shoudl post that just now. On my older V2.x LSCADP, I have occasionally seen it do something similar--not at power up, but if I am touching the two reed swtich wires, and let go. I never really saw what the increment is, but I would see MPH flicker at some value I didn't get a chance to read usually, but sometimes saw as several hundred MPH, then it would zero and the odo would slowly increment like you see in your video. I suspect the two are related, and that it's an older "bug" that's made more problematic by one of the new features.

If it would help anyone troubleshoot this, I can attempt to replicate my version of the issue on video, but it is quite intermittent.

[Joe Perez]

Huh, until you'd mentioned it, I hadn't even noticed that my speedometer was in fact reading 400+ MPH while this was occurring.

My new bike is fast, but not that fast.

It's such an interesting coincidence that this is occurring at the same time that I'm getting an efficiency measurement (wh/mi) which is far too high. An inaccurate speed indication would explain the erroneous efficiency measurement were it not for the fact that the odometer reading was correct at the end of the ~11 mi trip.

[amberwolf]

If the speed reading (and odo) were reading too high, you would actually get a *lower* Wh/mile reading, showing higher efficiency than actual.

(this happens to me when my my speedo wires come untwisted; ever since one of the dogs chewed thru my speedo cable I have just left them twisted together, as it makes threading the cable thru things easier anyway, when I move the CA from bike to bike for experiments...this also makes possible my accidental touching of hte wires that let me see the error you see, from a different but probably related cause).

Just curious--does it matter if your magnet is near your sensor when the error occurs? Or does it only happen when the magnet is either on the sensor or away from it?