Cycle Analyst V3 preview and first beta release

Kepler said:

I have done a search and haven't found anyone using an Aux pot to limit. I plan to use this for my PAS to adjust the level of assist.

There is no mention on what value pot to use but i presume 5K will do the job. On the V2 CA the On the fly adjustment pot has a 2.7k resister in series with the pot so that the range is changed from 0-5V to 0-3V.

Is this advantageous with the CA3 or has been taken care of via software settings?

Click to expand...

Please examine the Advanced Features section in the Unofficial Installation Guide. The PDF version that is located there is perhaps easier to read in that it has selected material in-line instead of accessed via hyperlink. This should address all your questions.

I have been using the Aux Pot feature in an LHM switch implementation since May 2012 and it works extremely well. The V3 Setup support for voltage range simplifies things and eliminates the resistor ploys that you found in the earlier V2 implementation.

BTW - I will be adding your technique of powering hall PAS sensors from the controller to the PAS section of that PDF - thanks for the idea

Found it. Thanks for that. So much to go through but getting there.

And glad I could contribute in relation to the PAS connection. Should have all that going by the weekend and will report on how it goes.

mrbill said:

OK, I think I've isolated the problem I reported earlier with the stored Ah and wh/mi (but not wh or mi) being reset to zero, and the forward and regen Ah being set to 2.08XX (where XX are some random digits).
The problem occurs when one goes into the SETUP -> CALIBRATION -> Zero Amps, and sets the "zero amps". If you just visit these screens, all is well, but when you actually zero the amps, the stored figures get changed.

Click to expand...

Wow, 100 bug finding points for you MrBill ! To not only catch and identify this but then to isolate exactly the circumstances that consistently reproduce it means you did all the legwork, and as a result it just took a few minutes for me to find out just what was going on and fix it in the Beta22 firmware. I don't know what you can redeem bug finding points for, but I'll think of something good

While at it I also updated the zero amps display so that it shows in real time the voltage output of each op-amp before you press and hold the button. This can be useful for diagnostic reasons to identify when there is a bad shunt connection causing wild amps and watts readings, among other things:



This is what it looks with 10mV across the shunt, the low gain amp increases by 0.1V, while the high gain amplifier output increases by 1.00V:

lollandster said:

electricwheels.de said:

Instead, the function RPM Cntrl should enable the throttle but OVER THE FULL RANGE, and not just 'full throttle'. Only if the rider pedals, the throttle should become functional in this mode.

Please Justin, change the firmware to this point, or this feature is useless to European riders.

Click to expand...

I have been begging for this feature too. Fully working throttle only when pedaling. But do this for torque mode too.

Click to expand...

OK, well here you have it. There is a new pedal assist mode called "PAS >6kph", and with this selected then the throttle works without pedaling below 6kph, but above 6kph you must be pedaling or else there is no output. It won't give assistance automatically when you start to pedal, you'll still neeed the throttle engaged. Is that pretty much what you want?



When you say you want it for torque mode too, can you clarify just what you mean? Right now if you have a THUN sensor and the torque assist mode selected, then you must be pedaling for the proportional torque assist to kick in. Unless by torque mode you mean motor torque (via a current or power throttle) and not the rider's pedal torque?

-Justin

MattyCiii said:

Here's a behavioral quirk - I don't think it's intentional:

I have the [Throttle Out --> Ramp Down] dialed way down. I have it set to 10 on a scale of 0 - 999. This achieved the following desired behavior - when I let go of the throttle, the motor speed drops off quite slowly. That's what I want, and that's what I get. I have my reasons why, if curious just ask.

Here's the strangeness. When I hit the e-brake cutoff, the motor speed drops off just as slowly as if I snap the throttle to zero.

Click to expand...

Hey Matty, that behaviour was done intentionally because I thought that whatever reasons you would have go want a controlled ramp-down of the motor would apply equally if it's because of releasing the throttle abruptly or applying the ebrakes, so no matter what you'd have the same soft disengagement. But I didn't really give it too much thought. Care to tell what you want the slow speed drop-off? I am curious!

In any case, I changed the behaviour in the Beta22 so that the ramp-down rate is ignored when you pull the ebrakes. It will drop to 0V on the output immediately. We've got some other reasons why a quick drop-off is preferred now that we're trying use the CA signal to activate controller regen without an additional wire, so it will probably stay this way going forwards.

-Justin

Hope the 6kph can be edit to 99 also

justin_le said:

... but above 6kph you must be pedaling or else there is no output. It won't give assistance automatically when you start to pedal, you'll still neeed the throttle engaged. Is that pretty much what you want?.

Click to expand...

this is only partially correct. pas and throttle should work independently. there could be an installation with no throttle at all - PAS only. so if you need assistance you switch on the motor and it assists between 6km/h and 25km/h IF you're pedalling.

izeman said:

this is only partially correct. pas and throttle should work independently. there could be an installation with no throttle at all - PAS only.

Click to expand...

OK, well that is already covered, if you have no throttle then the original PAS RPM mode will automatically assist whenever you are pedaling.

so if you need assistance you switch on the motor and it assists between 6km/h and 25km/h IF you're pedalling.

Click to expand...

This functionality has always been there with the RPM PAS mode. My understanding was that people wanted it so that it doesn't automatically engage when you pedal, but instead wanted it to behave like a normal throttle control with the one difference that output gets shut off once you stop pedalling, regardless of the throttle.

With the original RPM PAS mode, both the throttle and PAS sensor work independantly. If you pedal with no throttle, that provides assist. If you throttle and don't pedal, that also provides assist. If you throttle AND pedal at the same time, then you'll also get an assistance that is still variable based on the throttle. With this new >6kph mode, the PAS sensor is more like a gate for the throttle, so once you stop pedaling then the throttle signal no longer passes through the device.

-Justin

bowlofsalad said:

Hello,
I've tried searching, but I am unable to locate something that sort of spells out the change log in versions of cycleanalyst. Does anyone know of some kind of list?

Click to expand...

As Teklektik mentioned, nothing is published yet on the V3 device since it's been in Beta, but for the record here's what's summarized at the top of the code file which gives a sense of the progress to date:


; XLP_B1 is first functioning code to use the PIC16F1936 chip, with just minimal
; code modifications from the 16F886 to make it work.
; B2 changes the data aquisition to include all the additional channels, it changes the speedo
; to use circular buffer with linear addressing, it moves all the eeprom strings to program ROM
; instead. It makes better use of the two indirect addressing registers.
; B3 aims to also:
; a) Provide RPM sensing and human power calculation
; b) Update the I/O's to match the latest PCB board revision by Michael
; c) Run off a 32 MHz clock, rather than 20MHz, and running on a (200mS/11) = 18.1818 mS timebase
; to reduce Aliasing with 120Hz
; B4 Changes the calibration routine to use exact 100mV and 10mV signals to directly
; compute InvGain and GRatio terms
; B5 Tackles the Setup Menu into 2 layer affair, and does a host of other small
; additions of items to the setup menu and human power averaging.
; B6 Changes the TMR1 prescale to 8:1, meaning an exact 1uS clock for all timing routines. It also
; Implements the RC servo output, PAS controle modesm human watt-hours accumulation, plus human
; pedal time for average human watts and revolution counter for average cadence. Plus implements
; the PAS control modes, and changes RS232 to use interupts and show all data.
; Things not yet implemented include actual temp limiting of current limit,
; and parallel throttle/PAS operation needs refinement, and the watts limit though existing in setup
; is not handled in main code, nore yet is the differential speed gain.
; B7 Does all kinds of stuff:
; * Implements Differential term for speed control, and redoes the differential speed
; * calculation so that sensitivity is not #pole dependant.
; * Reorganizes display meny
; * Adds Aux voltage adjuts of Torque Gain
; * Implements parallel throttle/PAS modes
; * Implements custom character ROM generation
; * Explores use of animations in startup splash screen
; * Fixes various bugs in the feedback calculations (like negative average torque)
; B8 has minor tweaks, and in last implementation is custom firmware for Ben of Dogati
; B9 Changes layout of setup menu, now with 11 rather than 8 categories. It also makes it so that
; if change a menu item you don't skip to the next one but can re-edit it.
; Also addes upper and lower RPM stall counts with a Threshold Speed,
; Also implements the DispStill and DispMov masks to select screens to show
; B10 implements a SOC counter based on OCV calculated from IR
; B11 Uses the PIC16F1938 chip with twice the memory,
; * Reorganizes data tables into a separate include file all in PAGE7
; * Adds separate outer level temperature menu, with selection of linear vs. thermistor
; * Adds ramp up and ramp down and V/kph rate control
; * Implements the power limit feedback code
; * Implements the ebrake cutoff, with associated graphic on main screen
; * Tidies up operation and displays in high range mode
; B12 Implements minor tweaks to intrgral feedback terms such that they
; clamped to a certain value above the current VOut for quick action
; * B12 is the first firmware shipped out with the V3 Beta CA devices
; B13 Addresses a few more things
; * Fixes throttle surge on power-on
; * Fixes occasional 0RPM glitch
; * Changes scale factor for power limiting
; * Adds throttle fault voltage
; * Adds ability to set AuxMin and AuxMax
; * Corrects eeprom lookup table for 5K rather than 10K pullup
; * Adds option for quadrature mode PAS
; * Changes kph/mph system to using flag bit
; B14
; * Gives ability for user to select display screens
; * Swaps left and right button hold functions
; * Displays realtime sensor data in high level setup menu
; * Changes how power feedback clamping is implemented in attempt at bug fix
; * Zeros the PWM duty during reset to prevent brief power surge glitch.
; * Reorganizes RAM space a fair bit
; B15 - SEE EMAIL TO ALAN,
; B16 -
; * Adds realtime display of temp calculation.
; * Adds battery A and battery B selection, and all pack specific settings linked to one or other.
; * Solves initialization bug causing high max speed readings, now peripheral interupts only enabled at end
; * Suppresses leading zero display of setup menu items
; * Increases stall counter times for lower speed readings
; * Adds new display screen showing which limits are being hit, and has new set of flags to show them
; * Improves battery SOC behaviour on system power down
; B17
; * Tidies up the leading zero suppression in setup menu, so they are shown during edit cycle
; * Enables watch-dog timer reset, although bootloader does not support change in config bits
; B18
; * Implements a "software" style watchdog timer using TMR6
; * Eliminates TMR1 overflow situations by clearing TMR1H rather than just adding to it at each main loop
; * In the end, solves crashing bug by enabling pull up on PAS input line, as this was floating
; * Solves serious bug in the calculation of vehicle accelleration that was causing throttle cutouts and
; rendering smooth PID control difficult.
; * Organized a more clear pausing and resuming of timers etc. on entering and exiting setup menu and reset
; cycles.
; B19
; * Add's menu 'guts' to all high level menu items, showing realtime signals and more summary info
; * Fixed a bug in the eebytewrite that would disable speedo and PAS interupts
; * Fixed several more scenarios that could cause false MaxS readings
; * Hid the "KV Compensation" term from setup menu as its still not being used
; B20
; * Moves splash screen display string to ROM
; * Shorts out S&H cap prior to throttle & Aux ADC sampling
; * Adds 3rd battery selection choice
; * Organizes button press more cleanly with a state machine table
; * Enables 3 mode selection via button presses
; * Changes setup menu layout and naming for better consistency
; * Moves all 16 bit constants from EEPROM to ROM
; * Adds additional "disabled" option for setup menu items
; * Tweaks setup menu display screens and display menu guts
; B20a
; * Adds timer cutouts on integral feedback, new way for it to engage
; * Adds additional setup menu for presets
; B21
; * Changes torque assist to be watts / Nm
; * Adds the ability to enter bootloader from user code on receiving 0x55
; * Changes high impedance of PWM output on eeprom write strategy to avoid throttle output glitches
; during sleep period of EEPROM write
; B22
; * Implements ifdef for V3 or V2 CA mode during compile, most code past page1 is contiguous
; * Allows both high and low range mode RShunts to have additional digit
; * Implements throttle input autocruise functionality, off or 2-6 seconds
; * Adds flashing units to main screen if limits are reached
; * Tweaks the setup dispaly routines, for "OK" blanking, sub menu navigation arrows
; * Implements cadence based human power on display if torque sensor not enabled
; * Enables a 6kph start pas/throttle mode for EU
; (...)
;**********************************************************************

justin_le said:

lollandster said:

electricwheels.de said:

Instead, the function RPM Cntrl should enable the throttle but OVER THE FULL RANGE, and not just 'full throttle'. Only if the rider pedals, the throttle should become functional in this mode.

Please Justin, change the firmware to this point, or this feature is useless to European riders.

Click to expand...

I have been begging for this feature too. Fully working throttle only when pedaling. But do this for torque mode too.

Click to expand...

When you say you want it for torque mode too, can you clarify just what you mean? Right now if you have a THUN sensor and the torque assist mode selected, then you must be pedaling for the proportional torque assist to kick in. Unless by torque mode you mean motor torque (via a current or power throttle) and not the rider's pedal torque?

-Justin

Click to expand...

The >6kph mode is very nice and perfect for EU users with normal cheap PAS.

What I meant was I would like the torque sensor to also work in the >6kph mode, not just the throttle. (The torque sensor works perfectly when using the torque mode, no complains there). If I understand it correctly the >6kph mode will disable the torque mode? I guess I'm asking for the >6kph to be a on/off choice you can combine with a PAS mode (RPM, Torque or Off). Limited usage I know, but it would be easier than disconnecting the throttle.

I have a throttle connected to use when off-road (I find using PAS offroad to be very scary), but if I'm riding on road I can't legally have a throttle that works when I'm not pedaling. Its not a big deal since I can just disconnect the throttle, but it would be nice to have an off-road mode with working throttle and no PAS and an on-road mode with working PAS and no throttle (or >6kph mode).

With PAS level on the AUX I can at least turn off PAS easily before going off-road or if I need to save battery.

I'm sorry if I'm still unclear. English is after all a secondary language to me.
Anyway, thanks again for selling a good torque based PAS system.

justin_le said:

[...]

; B22
; * Implements ifdef for V3 or V2 CA mode during compile, most code past page1 is contiguous
; * Allows both high and low range mode RShunts to have additional digit
; * Implements throttle input autocruise functionality, off or 2-6 seconds
; * Adds flashing units to main screen if limits are reached
; * Tweaks the setup dispaly routines, for "OK" blanking, sub menu navigation arrows
; * Implements cadence based human power on display if torque sensor not enabled
; * Enables a 6kph start pas/throttle mode for EU
; (...)
;**********************************************************************

Click to expand...

Hi Justin:

Any chance you can increase the maximum valid "time-to-lock" of the auto-cruise to something between 10 and 15 seconds? Six seconds might be a bit short and under some circumstances could be annoying. I think several years ago you sold controllers set to auto-cruise at 8 seconds, and I found that to be about right. The EB3xx Infineon controllers' programming software allows up to 15 seconds for auto-cruise.

Thanks for including this functionality into the next beta release.

justin_le said:

With the original RPM PAS mode, both the throttle and PAS sensor work independently. If you pedal with no throttle. That provides assist. If you throttle and don't pedal, that also provides assist. If you throttle AND pedal at the same time, then you'll also get an assistance that is still variable based on the throttle.

Click to expand...

Justin- (great to have you back!!!)

I need a bit of help here... I'm a little unclear on the underlined section and reconciling simultaneous independent operation of PAS and throttle - that is, operating with both modes of pedaling-applies-full-throttle-until-limiting and variable-assist-with-throttle at once. Since pedal-only drives the throttle to max, and throttle scales against max, doesn't applying throttle imply that PAS mode is effectively disabled when throttle is non-ZERO - at least from a user perspective?

If so, it seems that the RPM and PAS>6kph modes can both be viewed as gating modes, just the opposite of one another... Based on this interpretation here is a re-statement in slightly different words - does this seem correct or have I wandered off track?

• PAS Mode – Select which pedal assist (PAS) mode is used:
  • PAS Off: With this setting, pedal rotation or pedal torque does not drive the throttle output of the CA. You can still see and log your cadence RPM and human watts, but you must use a throttle to regulate the motor power.
    
  • Trq Cntrl: With this setting, if the user throttle is off but the CA detects that you are pedaling, it will drive the controller with a current limit that is proportional to the amount of human pedal torque, enabling proportional assist.
    
    
  • RPM Cntrl: With this setting, throttle greater than ZERO acts as a gate to enable and disable PAS assistance:
    • With no throttle, pedaling drives the controller at ThrO->MaxOutput until one of the limit terms is reached. This case provides PAS-only operation if no throttle is connected.
    • With throttle, the PAS assist mode is effectively disabled and the throttle operates normally with or without pedaling.
  • PAS>6kph: With this setting, the PAS 6kph threshold acts as a gate to enable and disable normal throttle operation:
    • below 6kph the throttle operates normally with or without pedaling
    • above 6kph the throttle is disabled unless there is pedaling

lollandster said:

What I meant was I would like the torque sensor to also work in the >6kph mode, not just the throttle. (The torque sensor works perfectly when using the torque mode, no complains there). If I understand it correctly the >6kph mode will disable the torque mode? I guess I'm asking for the >6kph to be a on/off choice you can combine with a PAS mode (RPM, Torque or Off). Limited usage I know, but it would be easier than disconnecting the throttle.

Click to expand...

Ah thanks, now that makes it perfectly clear. Effectively you want to be able to software disconnect the throttle while still in proportional torque assistance mode. I think the way that I'll be handling this is with a new field to the throttle control mode. Right now there is Off (CAUTN) which causes the default throttle output to be high, while I could have another "Off" option where the throttle input is ignored and the default output is low instead, and then output only goes high if it is driven by one of the PAS settings.

That won't do the throttle-up-to-6kph thing but it would achieve your goal of easily disabling the throttle functionality when you are in street legal mode without having to physically unplug it.

-Justin

justin_le said:

lollandster said:

What I meant was I would like the torque sensor to also work in the >6kph mode, not just the throttle. (The torque sensor works perfectly when using the torque mode, no complains there). If I understand it correctly the >6kph mode will disable the torque mode? I guess I'm asking for the >6kph to be a on/off choice you can combine with a PAS mode (RPM, Torque or Off). Limited usage I know, but it would be easier than disconnecting the throttle.

Click to expand...

Ah thanks, now that makes it perfectly clear. Effectively you want to be able to software disconnect the throttle while still in proportional torque assistance mode. I think the way that I'll be handling this is with a new field to the throttle control mode. Right now there is Off (CAUTN) which causes the default throttle output to be high, while I could have another "Off" option where the throttle input is ignored and the default output is low instead, and then output only goes high if it is driven by one of the PAS settings.

That won't do the throttle-up-to-6kph thing but it would achieve your goal of easily disabling the throttle functionality when you are in street legal mode without having to physically unplug it.

-Justin

Click to expand...

That sounds perfect. Thank you.

teklektik said:

If so, it seems that the RPM and PAS>6kph modes can both be viewed as gating modes, just the opposite of one another... Based on this interpretation here is a re-statement in slightly different words - does this seem correct or have I wandered off track?

Click to expand...

Yes, I suppose that is one neat way of looking at it! Once all the final modes are hashed out we'll need to make some kind of flowchart diagram so that people can visually see and understand how the different settings cause the different signals to interact and generate the output.

• PAS Mode – Select which pedal assist (PAS) mode is used:
  • PAS Off: With this setting, pedal rotation or pedal torque does not drive the throttle output of the CA. You can still see and log your cadence RPM and human watts, but you must use a throttle to regulate the motor power.
    

Correct

• • Trq Cntrl: With this setting, if the user throttle is off but the CA detects that you are pedaling, it will drive the controller with a current limit that is proportional to the amount of human pedal torque, enabling proportional assist.

Correct, except that since B21 it is driving with a wattage limit rather than a current limit, so that your assistance factor will be independent of battery voltage sag.

• • RPM Cntrl: With this setting, throttle greater than ZERO acts as a gate to enable and disable PAS assistance:
    • With no throttle, pedaling drives the controller at ThrO->MaxOutput until one of the limit terms is reached. This case provides PAS-only operation if no throttle is connected.
    • With throttle, the PAS assist mode is effectively disabled and the throttle operates normally with or without pedaling.

Correct, though it should be made clear that by 'with throttle' you mean with the throttle engaged, rather than just with the throttle plugged in.

• • PAS>6kph: With this setting, the PAS 6kph threshold acts as a gate to enable and disable normal throttle operation:
    • below 6kph the throttle operates normally with or without pedaling
    • above 6kph the throttle is disabled unless there is pedaling

Correct

mrbill said:

Any chance you can increase the maximum valid "time-to-lock" of the auto-cruise to something between 10 and 15 seconds? Six seconds might be a bit short and under some circumstances could be annoying. I think several years ago you sold controllers set to auto-cruise at 8 seconds, and I found that to be about right.

Click to expand...

Yup, that could be done for sure, although the current timer configuration will overflow at about 9sec so that's the most I can do in a pinch. I'll be wanting to get some feedback on this feature so any other opinions are appreciated too.

Here is how the current implementation is set up, and I've been really digging riding around with the autocruise feature for the last couple days. There is a new option in the Throttle Input setup menu where you can choose autocruise, from Off, 2sec, 3sec, 4sec, 5sec, or 6sec.



Then on the next screen, you can choose the autocruise holding sensitivity from 0.01 to 0.25V. This basically sets the +- voltage band that the throttle needs to stay within for the "cruise time" period for the auto cruise to kick in. If you want it to require very precise throttle holding for the cruise to latch, then you would set that to a low value like 0.03V. While if you have it at like 0.2V, then even riding with a thumb throttle on a bumpy road you should be able to make the cruise latch. But, it would also be more likely to latch if you are gently modulating the throttle and don't necessarily intend to be holding it for cruise.



The autocruise mode is indicated on the main screen by a slightly flashing throttle marker at the cruise position. When you then release the throttle you can see the actual throttle bar slide down, while the cruise throttle position stays blinking at the location where it has latched to cruise at:



This way you can know for sure that the cruise has latched before you let go of the throttle and have to start the cruise timer process again. The cruise is cleared when either the actual throttle moves upwards from its current position, or when the ebrakes are engaged.

So far I've only had this properly rolling for a week now but have been really digging it. I find 3 seconds is about right now that I have my ebrakes hooked up so that I can intsinctively clear the cruise in a split second if it's not desired.

However, I do find that sometimes after braking I want the autocruise to automatically resume where it was at rather than having to relatch it. While other times (say after you come to a stop), that would be quite disconcerting. So I am considering adding an option where you can have it resume when ebrakes are released if you've only slowed down but haven't come close to an actual stop.

justin_le said:

MattyCiii said:

Here's a behavioral quirk - I don't think it's intentional:

I have the [Throttle Out --> Ramp Down] dialed way down. I have it set to 10 on a scale of 0 - 999. This achieved the following desired behavior - when I let go of the throttle, the motor speed drops off quite slowly. That's what I want, and that's what I get. I have my reasons why, if curious just ask.

Here's the strangeness. When I hit the e-brake cutoff, the motor speed drops off just as slowly as if I snap the throttle to zero.

Click to expand...

Hey Matty, that behaviour was done intentionally because I thought that whatever reasons you would have go want a controlled ramp-down of the motor would apply equally if it's because of releasing the throttle abruptly or applying the ebrakes, so no matter what you'd have the same soft disengagement. But I didn't really give it too much thought. Care to tell what you want the slow speed drop-off? I am curious!

In any case, I changed the behaviour in the Beta22 so that the ramp-down rate is ignored when you pull the ebrakes. It will drop to 0V on the output immediately. We've got some other reasons why a quick drop-off is preferred now that we're trying use the CA signal to activate controller regen without an additional wire, so it will probably stay this way going forwards.

-Justin

Click to expand...

Thanks Justin!
In my very limited experience - two bikes, both RC setups - a slow throttle ramp down is quite nice. Riding along at WOT, I can slowly throttle back or even release the throttle altogether, and the motor will back off slowly - this is good for freewheeling along or slowing a bit. And the fact that the motor backs off slowly means that if I then punch the throttle a couple of seconds later, the drive is already pretty high in the throttle's map leading to faster engagement of power drive with less shock to the mechanical parts. I'm sure this it the original intent of the throttle down ramp setting. So - ease back or release throttle to glide and slow down a bit.

In contrast, if I hit the brake, I am making a concerted effort to slow down. The system doesn't know whether I want to just tap the brakes, or if I'm in a panic stop. Most of the time I'm tapping the brakes or decelerating slowly, and in such cases even a very slow ramp down does not fight the braking power. It's that on in a hundred panic stop where the slow ramp down means my braking force is resisting both momentum and drive train. The risk adverse way to treat e-brake cutoff is to ramp down aggressively, so there's no chance of having the drive system materially impact a panic stop.

Thanks for implementing it this way in B22 - I hope the change won't negatively impact other users

justin_le said:

mrbill said:

Any chance you can increase the maximum valid "time-to-lock" of the auto-cruise to something between 10 and 15 seconds? Six seconds might be a bit short and under some circumstances could be annoying. I think several years ago you sold controllers set to auto-cruise at 8 seconds, and I found that to be about right.

Click to expand...

Yup, that could be done for sure, although the current timer configuration will overflow at about 9sec so that's the most I can do in a pinch. I'll be wanting to get some feedback on this feature so any other opinions are appreciated too.

Here is how the current implementation is set up, and I've been really digging riding around with the autocruise feature for the last couple days. There is a new option in the Throttle Input setup menu where you can choose autocruise, from Off, 2sec, 3sec, 4sec, 5sec, or 6sec.

View attachment 1

Then on the next screen, you can choose the autocruise holding sensitivity from 0.01 to 0.25V. This basically sets the +- voltage band that the throttle needs to stay within for the "cruise time" period for the auto cruise to kick in. If you want it to require very precise throttle holding for the cruise to latch, then you would set that to a low value like 0.03V. While if you have it at like 0.2V, then even riding with a thumb throttle on a bumpy road you should be able to make the cruise latch. But, it would also be more likely to latch if you are gently modulating the throttle and don't necessarily intend to be holding it for cruise.

View attachment 2

The autocruise mode is indicated on the main screen by a slightly flashing throttle marker at the cruise position. When you then release the throttle you can see the actual throttle bar slide down, while the cruise throttle position stays blinking at the location where it has latched to cruise at:



This way you can know for sure that the cruise has latched before you let go of the throttle and have to start the cruise timer process again. The cruise is cleared when either the actual throttle moves upwards from its current position, or when the ebrakes are engaged.

So far I've only had this properly rolling for a week now but have been really digging it. I find 3 seconds is about right now that I have my ebrakes hooked up so that I can intsinctively clear the cruise in a split second if it's not desired.

However, I do find that sometimes after braking I want the autocruise to automatically resume where it was at rather than having to relatch it. While other times (say after you come to a stop), that would be quite disconcerting. So I am considering adding an option where you can have it resume when ebrakes are released if you've only slowed down but haven't come close to an actual stop.

Click to expand...

This is all very cool. I hadn't considered that by narrowing the holding voltage sensitivity, a lower latching time might work well. Still, if it doesn't consume too many resources, a 8- or 9-second maximum setting would be nice to have, so the user has more flexibility.

A "resume" feature would be quite nice, especially in those situations where it is necessary to tap the brakes and slow momentarily but not stop. Automobile cruise controls lose resume "memory" when speed drops below some threshold speed like 25mph, rather than zero mph. The problem is how to implement it without adding new hardware. How would you instruct the CA to resume previous cruise setting?

Thanks for giving this some thought.

mrbill said:

A "resume" feature would be quite nice, especially in those situations where it is necessary to tap the brakes and slow momentarily but not stop. Automobile cruise controls lose resume "memory" when speed drops below some threshold speed like 25mph, rather than zero mph. The problem is how to implement it without adding new hardware. How would you instruct the CA to resume previous cruise setting?

Click to expand...

I was thinking to just have it resume to where it left off automatically shortly after you release the brake levers, rather than by tapping a resume button or similar. The 'cruise resume speed thershold' as such could be programmable, so if you brake and release and stay above that threshold then the autocruise resumes, and if you slow to below the threshold then you have to manually bring it back in.

I've added the 8 second option. I don't think there is much point to have more time than this. Already 8Sec feels like a really long time when you are on an ebike trying to engage a certain feature.

-Justin

MattyCiii said:

Thanks for implementing it this way in B22 - I hope the change won't negatively impact other users

Click to expand...

AFAIK users who are making use of the throttle ramp-down feature can be counted on one hand, so I don't expect much widespread disruption!

Thanks for the additional insights. -Justin

In relation to ebraking, I find fitting brake sensors tedious and messy especially since most of my builds use good quality Hydros. Sure you can fit micro switches and there is even a cool hydraulic switch made by Magura now. However, typically my bikes dont get ebrakes because of the above which can be a bad thing.

What i would like to see is an accelerometer incorporated in the CA that detects sudden deceleration and activates the ebrake function based on the level of deceleration. This removes the need for brake switches and the associated mess of wiring that goes with it. Sensitivity would need to adjustable to suite the rider's riding style but at least every build with a CA3 would have an active ebrake function which would be a be a great safety feature. The accelerometer ebrake could be interlocked with the throttle so that if a certain percentage of throttle is being used, the ebrake function becomes inactive.

My appologies if the above has already been discussed but this is a long thread and being quite technical in its content, makes it hard to flick through quickly. The search function found no reference to the above so hopefully I am not going over old ground

justin_le said:

mrbill said:

A "resume" feature would be quite nice, especially in those situations where it is necessary to tap the brakes and slow momentarily but not stop. Automobile cruise controls lose resume "memory" when speed drops below some threshold speed like 25mph, rather than zero mph. The problem is how to implement it without adding new hardware. How would you instruct the CA to resume previous cruise setting?

Click to expand...

I was thinking to just have it resume to where it left off automatically shortly after you release the brake levers, rather than by tapping a resume button or similar. The 'cruise resume speed thershold' as such could be programmable, so if you brake and release and stay above that threshold then the autocruise resumes, and if you slow to below the threshold then you have to manually bring it back in.

I've added the 8 second option. I don't think there is much point to have more time than this. Already 8Sec feels like a really long time when you are on an ebike trying to engage a certain feature.

-Justin

Click to expand...

That sounds good.

So, when breaking cruise and slowing with the intent to resume cruise, one would need to keep the brake levers squeezed enough to close the ebrake switch. This could be squeezing the lever only enough to close the switch but not hard enough to apply the brake pads to the rim/rotor as if one wished to slow by coasting. Then, as long as the speed has remained above a user-settable threshold over the period that the ebrake switch was closed, releasing the ebrake levers and opening the switch instructs the CA to resume previously set cruise speed, subject to the other limiting factors.

Have I understood the behavior correctly?

Now the only thing missing is the ability to incrementally adjust the cruise speed after it has been engaged, sort of like the "accel" and "decel" buttons on an automobile cruise control. But, maybe with a short latch time, resetting cruise to accomplish this is not as inconvenient as it would be with an 8-second hold period.

Thanks for allowing up to 8 seconds. I may yet find that a shorter latching time works for me if I can adjust the hold voltage sensitivity.

mrbill said:

So, when breaking cruise and slowing with the intent to resume cruise, one would need to keep the brake levers squeezed enough to close the ebrake switch. This could be squeezing the lever only enough to close the switch but not hard enough to apply the brake pads to the rim/rotor as if one wished to slow by coasting. Then, as long as the speed has remained above a user-settable threshold over the period that the ebrake switch was closed, releasing the ebrake levers and opening the switch instructs the CA to resume previously set cruise speed, subject to the other limiting factors.

Have I understood the behavior correctly?

Click to expand...

Yup.

Now the only thing missing is the ability to incrementally adjust the cruise speed after it has been engaged, sort of like the "accel" and "decel" buttons on an automobile cruise control. But, maybe with a short latch time, resetting cruise to accomplish this is not as inconvenient as it would be with an 8-second hold period.

Click to expand...

That's the hope. While I get the appeal of a set of buttons to increase/decrease the cruise level, I'm equally averse to adding any more handlebar hardware and wiring to an ebike setup, so to the extent that we can repurpose the inputs that are already wired in the system I think we should. So hopefully this implementation will be good enough.

Kepler said:

In relation to ebraking, I find fitting brake sensors tedious and messy especially since most of my builds use good quality Hydros. Sure you can fit micro switches and there is even a cool hydraulic switch made by Magura now. However, typically my bikes dont get ebrakes because of the above which can be a bad thing.

Click to expand...

Tell me about it! Clamp on ebrake cutoffs for attaching to 3rd party levers are long overdue. BionX had an OK system with a normally closed reed sensor that slides in and out of a tube that is doublesided taped to the the brake body, plus a small magnet that you glue to the lever. But what I'd like to see would be more like two micro 'C' clamps that you can positively secure to the lever and body with set screws to dial in the exact position where it triggers the electrical switch. No gluing or taping.

What i would like to see is an accelerometer incorporated in the CA that detects sudden deceleration and activates the ebrake function based on the level of deceleration. This removes the need for brake switches and the associated mess of wiring that goes with it. Sensitivity would need to adjustable to suite the rider's riding style but at least every build with a CA3 would have an active ebrake function which would be a be a great safety feature. The accelerometer ebrake could be interlocked with the throttle so that if a certain percentage of throttle is being used, the ebrake function becomes inactive.

Click to expand...

By this, when you say ebrake function you mean not just a cutout but actual controller regen? It seems that a cutout based on decelleration is pointless since you already let go of the throttle when you brake. But to have a mechanical slowdown kick in the regen of a controller is an intriguing thought and hasn't come up before. You'd have to be careful that it's not so sensitive that it suddenly starts doing regen when you transition to an uphill grade and start to slow down from that. That's be an unfortunate be a doublehit to your momentum, not only fighting the hill but then having to fight the motor too.

The accelleration in m/s^2 is computed internally by the CA and also spit out in the datalogging output stream. So if you have an anlogger you can record the various accelleration/decelleration values and correlate that to points where you are stopping versus changes from varying grades and see if there are thresholds that make sense.

-Justin

mrbill said:

Automobile cruise controls lose resume "memory" when speed drops below some threshold speed like 25mph, rather than zero mph.

Click to expand...

Unless cruise control is actually switched off, my car never loses resume memory - even at zero mph.

justin_le said:

I was thinking to just have it resume to where it left off automatically shortly after you release the brake levers, rather than by tapping a resume button or similar. The 'cruise resume speed threshold' as such could be programmable, so if you brake and release and stay above that threshold then the autocruise resumes, and if you slow to below the threshold then you have to manually bring it back in.

Click to expand...

A fixed speed threshold seems too situation-dependant - after all, the cruise speed itself isn't fixed. For a speed-related resume threshold, a configurable percentage of the present cruise speed might make more sense, allowing the cruise feature to automagically adjust the resume threshold from bike path to commuting speeds.

justin_le said:

While I get the appeal of a set of buttons to increase/decrease the cruise level, I'm equally averse to adding any more handlebar hardware and wiring to an ebike setup, so to the extent that we can repurpose the inputs that are already wired in the system I think we should. So hopefully this implementation will be good enough.

Click to expand...

I agree that re-purposing inputs is a good idea and appreciate that mandating extra buttons can be an issue from a product marketing perspective. However, I personally prefer to have explicit control rather than implied or automatic operation and don't really mind an extra button - particularly when the AUX Pot feature already has sent us down the road to 3-position switches and PAS-level pots.

For instance, a bike is unlikely to have both a PAS rpm sensor and THUN unit simultaneously installed and most bikes will have neither. On the other hand, cruise control will have much broader appeal and usage. Unused PAS/THUN inputs might be used with a configuration option Cruz->Mode={Speed | PAS | Trq}. Speed would operate as you have already described. PAS or Trq would re-purpose either of the RPM or Trq inputs respectively as a cruise control input. The control would be a simple button normally pulled to 5v and going to Gnd when pressed.

• Tap to set cruise control to the current speed or release cruise if already engaged.
• Ebrake disengages cruise.
• Press-Hold to resume (press and just release when the bike begins to accelerate to speed).

This would provide an explicit and familiar cruise control that could be left armed at all times - the time delay latching business would not need to be enabled/disabled by situation. This could be extended in a number of ways. A software upgrade might provide increase/decrease capability without another button:

• If cruise is engaged and throttle is greater than ZERO, Press-Hold and the present cruise speed slowly increases at Cruz->Rate (similar to ThrO->UpRamp configuration).
• If cruise is engaged and throttle is ZERO, Press-Hold and the present cruise speed slowly decreases at Cruz->Rate.
• (This implies you can Press-Hold and wiggle the throttle On/Off a bit to get the speed 'just right' - then release button).

Anyhow - the proposed B22 cruise control is a nifty and welcome feature - just thought I'd throw in a vote for explicit control and a slightly different re-purposing strategy...

EDIT - Hmmm - oops, small mistake - the RPM input is actually in use for THUN sensors so this strategy wouldn't work with THUN installations.