Cycle Analyst V3 preview and first beta release

smart114 said:
It will measure the current consumption in the next days.
Would like to connect another 2 brake switches with magnet.
Connected are: T-HTwist Trottle, GEARSENSOR, PAS_12P, CA3_DAux, THERMISTOR10K
Later I would like to convert to 14 s battery.
I'm not sure what the gear sensor draws for current, but just guessing at the rest:

T-HTwist Trottle = 4.5
PAS_12P = 9
CA3_DAux = 3
NTC10K = 1
ebrakes = 1

it looks like you have about 26-18 ~= 8ma left for the gear sensor. Everything should be fine unless the sensor uses huge amounts of current. As recommended in the Guide, if you want to increase your safety margin, steal 5V from the controller. Make up a plug for the controller throttle connection and use the +5V wire to power the gear sensor. Don't use the controller throttle Gnd wire - get the Gnd wire from the CA. The controller can supply a fair bit of 5V, so you can steal power from there to operate your 5V stuff if you later significantly increase the battery voltage.

Anyhow, measuring the current for your stuff is a good step to find out where you actually are before you make unnecessary changes.
 
brickwall said:
The throttle response is a lot smoother using only the controller than going through the CA3 when the motor is unloaded. When riding I didn't feel any difference. It's like the throttle is delivered in steps rather than continuously. I've yet to learn all about the settings, so I'm sure this is a feature, but would you kindly tell me more about it?
Take a look at the [strike]Un[/strike]offical Guide.
After you have done the basic setup and everything is working properly, try switching to Current Throttle to get better throttle control. This mode behaves peculiarly on the stand when unloaded so that is not an indication of a problem. You may need to make additional ramping and gain adjustments to eliminate surging with current throttle, but those are described in the Guide.
 
I'm having so much fun confidence
teklektik said:
brickwall said:
The throttle response is a lot smoother using only the controller than going through the CA3 when the motor is unloaded. When riding I didn't feel any difference. It's like the throttle is delivered in steps rather than continuously. I've yet to learn all about the settings, so I'm sure this is a feature, but would you kindly tell me more about it?
Take a look at the [strike]Un[/strike]offical Guide.
After you have done the basic setup and everything is working properly, try switching to Current Throttle to get better throttle control. This mode behaves peculiarly on the stand when unloaded so that is not an indication of a problem. You may need to make additional ramping and gain adjustments to eliminate surging with current throttle, but those are described in the Guide.

That document was awesome. Thank you. I'm having so much fun tweaking all the settings.

I've run into an issue setting up the temp sensor for my MXUS V3 using these parameters https://endless-sphere.com/forums/viewtopic.php?f=6&t=66305&start=50#p1013306. Cycle Analyst displays ~129°C ambient room temperature using one set of sensors and ~90°C using the others. Connecting just sensor or both sensor and ground makes no difference. To me, this suggests that I've done something wrong (or that the sensors are faulty). Any suggestions are welcome.
 
Glad to hear the Guide is helping :)

brickwall said:
I've run into an issue setting up the temp sensor for my MXUS V3 using these parameters https://endless-sphere.com/forums/viewtopic.php?f=6&t=66305&start=50#p1013306. Cycle Analyst displays ~129°C ambient room temperature using one set of sensors and ~90°C using the others. Connecting just sensor or both sensor and ground makes no difference. To me, this suggests that I've done something wrong (or that the sensors are faulty).
To get the sensor working you really need to know the exact part number or specifications so the CA can be adjusted. I'm not sure what sensor the MXUS is is using these days. Last time I looked it was a KTY83-110 according to this post in March of last year:

teslanv said:
... I can confirm that all MXUS motors that have the white wire, use a KTY83/110 temp sensor.
Based on that, use the spreadsheet or spreadsheet snapshot in the CA download page <<here>>. From that sheet you need to set:

  • Temp->0degCVolts = 0.70V
    Temp->TScale = 183.30 degC/V
If this doesn't make the CA behave, then you likely have either a different or damaged sensor. If you hook a DMM up to the sensor leads (white wire and Gnd with nothing else connected), you can check the resistance vs the spec sheet for the present room temperature. For example, the KTY83/110 at 77 deg F should have a resistance of 1000 ohms.

specSheetLookup.png
View attachment KTY83_SER.pdf
As far as the Gnd wire is concerned, that really won't change the reading with a bare CA, although it may have an effect if you run accessories for the CA power port - so what you see there is normal. This is discussed in <<this post>>.
 
teklektik said:
Glad to hear the Guide is helping :)

teslanv said:
... I can confirm that all MXUS motors that have the white wire, use a KTY83/110 temp sensor.
Based on that, use the spreadsheet or spreadsheet snapshot in the CA download page <<here>>. From that sheet you need to set:

  • Temp->0degCVolts = 0.70V
    Temp->TScale = 183.30 degC/V
If this doesn't make the CA behave, then you likely have either a different or damaged sensor. If you hook a DMM up to the sensor leads (white wire and Gnd with nothing else connected), you can check the resistance vs the spec sheet for the present room temperature. For example, the KTY83/110 at 77 deg F should have a resistance of 1000 ohms.

As far as the Gnd wire is concerned, that really won't change the reading with a bare CA, although it may have an effect if you run accessories for the CA power port - so what you see there is normal. .
Yeah, I just wanted to be clear that I've tried that too. :)

Thanks. It's with these settings I'm seeing such temperatures. Ohms are 1.523 and 1.904 on the two pair of sensors when measured at 2k. This does not really tell me anything though. Can I just change the voltage to match the room temperature? But of course, scaling might be totally different...
 
Hi,

I've been using various CAv3.1 beta releases, and while most of the features/issues I used to dream of/face seems to be fixed in latest (b16) release, I'm still having a small issue with PAS:
It works great most of the time, but whenever I only do a single pedal turn, I'm observing a huge cutoff lag: Motor remains powered 1~2 seconds after I stop pedaling.

I tried to change several settings to workaround this issue, without success:
- Tweaked throttle rates and PID gains on CAv3 and BAC 500+ controller
- Used 12 magnets pas sensor and TCDM BB
- Changed Start/StopThrsh and PASPoles (Ended up with 4/25 RPMs with 12 poles)
- Tried 1 Wire and quadrature mode

In any case, this "single crank revolution cutoff lag" is observeable. Finally, logging CA output seems to show that CA is misevaluating the RPM whenever there is one single predal turn (or less),
whereas as soon as there is more than one full rotation, CA cuts power promptly when I stop pedaling.

Here is an extract of cycle analyst log, during this record, I was starting and stopping to pedal promptly, so that torque output shows pretty accurately my activity.
When I stop pedalling, we can see "flats" in PAS RPM that stays stucked to a fixed value (as well as Human Watts and motor power) whereas I wasn't pedalling any more...

file.php

(Note: using 5 Hz logging rate and 40 ms averaging period to get an accurate output. Throttle output and motor Amps/Power are omitted as they follow pretty well Human Watts)

Hasn't anyone already noticed this issue? After diving in this post's history, I haven't seen any report about this specific power surge...
From what I've read in following posts, PAS averaging method changes between startup and established pedaling, couldn't there be an issue in the first phase leading to PAS StopThrsh not being enforced in this case?

https://endless-sphere.com/forums/viewtopic.php?p=720389#p720389
https://endless-sphere.com/forums/viewtopic.php?p=729507#p729507

Thanks,
Francois.
 

Attachments

  • ca_log.png
    ca_log.png
    25.7 KB · Views: 2,039
fanchon said:
I've been using various CAv3.1 beta releases, ... I'm still having a small issue with PAS:
...whenever I only do a single pedal turn, I'm observing a huge cutoff lag: Motor remains powered 1~2 seconds after I stop pedaling.

...Changed Start/StopThrsh and PASPoles (Ended up with 4/25 RPMs with 12 poles)
I believe you will find that your cutoff-lag issue is traceable to the Start/Stop thresholds. These are described in the SettingsSummary.txt file installed with b16, however, the explanation there was not as clear as we liked and has been improved slightly for the next release (pretty timely, eh?).

See if this helps:
CA3_PasTips.png
So, in short, jack up your start threshold quite a bit and things should improve. This seems a little counter-intuitive, but give it a whirl. :)
 
brickwall said:
Yeah, I just wanted to be clear that I've tried that too. :)

Thanks. It's with these settings I'm seeing such temperatures. Ohms are 1.523 and 1.904 on the two pair of sensors when measured at 2k. This does not really tell me anything though. Can I just change the voltage to match the room temperature? But of course, scaling might be totally different...
Yep - the resistance test was just to determine if you indeed had a KTY83/110 sensor - and it seems pretty clear you do not.

Unfortunately, it's pretty much impossible to accurately calibrate the sensor with it installed, so at this point you really need to go back to the vendor to identify what parts you actually have in your motor. This may eventually lead you back to Mxus, but I'd start with your direct retail source if that's someone else.

Meanwhile, you might also put up a specific thread here on ES with a title like "What's the temp sensor in my MXUS?" to catch the attention of the MXUS folks who are knowledgeable in this area (regardless of their CA expertise).
 
teklektik said:
brickwall said:
Yeah, I just wanted to be clear that I've tried that too. :)

Thanks. It's with these settings I'm seeing such temperatures. Ohms are 1.523 and 1.904 on the two pair of sensors when measured at 2k. This does not really tell me anything though. Can I just change the voltage to match the room temperature? But of course, scaling might be totally different...
Yep - the resistance test was just to determine if you indeed had a KTY83/110 sensor - and it seems pretty clear you do not.

Unfortunately, it's pretty much impossible to accurately calibrate the sensor with it installed, so at this point you really need to go back to the vendor to identify what parts you actually have in your motor. This may eventually lead you back to Mxus, but I'd start with your direct retail source if that's someone else.

Meanwhile, you might also put up a specific thread here on ES with a title like "What's the temp sensor in my MXUS?" to catch the attention of the MXUS folks who are knowledgeable in this area (regardless of their CA expertise).

Thanks for the advice. Now I know what's going on and where to look next. :)

Road tested the bike today! Good thing I got the CAv3. Without throttle ramping I'd kill myself.
 
fanchon said:
Hasn't anyone already noticed this issue? After diving in this post's history, I haven't seen any report about this specific power surge...
From what I've read in following posts, PAS averaging method changes between startup and established pedaling, couldn't there be an issue in the first phase leading to PAS StopThrsh not being enforced in this case?

https://endless-sphere.com/forums/viewtopic.php?p=720389#p720389
https://endless-sphere.com/forums/viewtopic.php?p=729507#p729507

Thanks,
Francois.

I'm also using a torque PAS TDCM setup and noticed the same. One half pedal RPM leads to a power kick (which is wanted), but with quite long delay.
My stop and start thrsh settings are quite close together, but i will take a look again.
From the diagram it looks like there is a differnt problem.
 
madin88 said:
I'm also using a torque PAS TDCM setup and noticed the same. One half pedal RPM leads to a power kick (which is wanted), but with quite long delay.
My stop and start thrsh settings are quite close together, but i will take a look again.
From the diagram it looks like there is a differnt problem.
The first thing to do with Francois' report was to get the Start/Stop squared away since it was a clear problem area. That said, there may be something else in play that deserves attention as your report seems to corroborate. I'll post it up for discussion here...

Thanks for the posts guys. :)
 
teklektik said:
I believe you will find that your cutoff-lag issue is traceable to the Start/Stop thresholds. These are described in the SettingsSummary.txt file installed with b16, however, the explanation there was not as clear as we liked and has been improved slightly for the next release (pretty timely, eh?).

Pretty timely indeed ;) I just didn't looked at this file... :oops: The explanation is pretty clear and helpfull to understand the side effect of lowering start threshold...

teklektik said:
So, in short, jack up your start threshold quite a bit and things should improve. This seems a little counter-intuitive, but give it a whirl. :)*

Indeed, raising start threshold to recommended 10 RPMs helps to bring this "single crank revolution cutoff delay" back to a reasonable value, at the expense of an increased lag when starting from a standstill. I'll have to do some more tests to find a sweet point...

Anyway, wouldn't it be possible to improve the PAS startup detection algorithm in some way, in order to avoid having to do this kind of compromise?

From what I understand/guess, start threshold is used as a stop threshold in the startup phase ( 60s /( 4 RPMs * 12 poles ) = 1,2s between pulses, which roughly corresponds to the observed lag ). If stop threshold can't obviously be enforced in startup phase, wouldn't it be possible (and relevant) to use kind of derivative approach for that purpose? For example, couldn't CA consider that pedaling has stopped if delay between consecutive pulses suddently doubles ou triples?

In other words, couldn't cutoff delay be calculated as following:
Cutoff_delay = 60 / ( min ( current RPM / 2, StopThrsh) * pole count )

It's not a big issue anyway (all the more as it's being documented), i'm not complaining here, just discussing to see if that great device can be brought even closer to perfection ;)
 
I have a SEMPU SP-B03 Torque Sensor wich the following datas:

tne4le8y.jpg


what do I have to setup on "Trq Scale" and "PAS Poles"?

Thanks for yyour Help!
 
gronph said:
what do I have to setup on "Trq Scale" and "PAS Poles"
sempuSpecs.png
(Green) The spec is a little confusing about the speed and direction signals, but the CA can only support up to 24 PAS poles so you should set PASPoles to 16 which is either just right if you are getting a quadrature signal or exactly 1/2 the number of poles if you are getting RPM/Direction as pulses and a level. (Interestingly, one of the early 3.0 releases actually supported 32 poles - just for the Sempu - but the limit was rolled back to 24 because the "16 is 1/2 of 32" trick worked fine...)

(Yellow) According to the spec, when you zero the pedal force, you should get a voltage of 1.50V. The full output range is 3.0V-1.5V or 1.5V, but the units are in 'force' not 'torque' (???).
The spec is inadequate to determine the proper Nm/V scaling factor since it seems to be measuring something they call 'pedaling force' rather than 'torque'. This looks to be another device similar to the TDCM that does not actually measure torque but provides a varying voltage for some other characteristic that is indirectly related to torque. Without a description of exactly what force they are measuring, we can't really convert that into a torque scale.

Grin has hooked up Sempu sensors experimentally and I recommend that you email them get some setup suggestions.
 
what do I have to setup on "Trq Scale" and "PAS Poles"?

I have that Sempu BB too, though a square taper version, and I set the following parameters to the CA v3.1b20.

The PAS poles count on the BB indeed is 32. I even confirmed that with the help of the CA PAS diag. The CA max. setting for that is 24 though. But the 24 poles setting work OK, only the Pedal RPM display is not quite the correct. But it doesn't bother me at all.
BTW, when I bought the CA the original FW version on the unit did accept a 32 poles setting. And it did work just the same as the 24 poles setting on a never firmware.

Then the CA Zero torque Offset is that 1.5V listed in the specs. Max voltage the BB outputs is around 3V.

I set the Torque Assist Averaging to a value 16 poles. Which seem to work quite well too, it will affect the PAS assist startup delay, and this seem to be quite OK setting.

Then the Trque scale i.e. the Torque the BB outputs is a more difficult question. My experiments by measuring it with a known weight on the pedal resulted with two quite different values by two measurements with a different weights and one measured with the weight on top the pedal and the other with a weight hanging on a pedal axle between the pdal an d crank.

So cannot say what is the rel correct value but something like 38Nm/V is quite close I believe and works OK for me.

The BB has a separate wire for the PAS direction signal, but nevertheless on the CA you have to select PAS Signal type as 1-Wire signal. Otherwise the PAS doesn't engage at all. The BB will output 5V when pedaling forward and 0V when pedaling backwards.

And in order to get the PAS assist startup delay minimum I set the Sart RPM threshold to 5 RPM and Stop RPM Threshold to 18 RPM. And assist Start Power as -22HW.
It is really sensitive though and will engage even when the cranks rotate by themselves without actually pedaling.

A good idea maybe is also set The throttle Input Mode to Power and then control the output power with a DigiAux buttons or a potentiometer.
I have a Digiaux with the number of levels set to 8 levels.

Assist power factor I use is 1.00W/HW.

But actually the BB doesn't work very well in detecting the human power, as the max. torque it will measure is so low that you achieve that by merely resting the feet on the pedals.

The max torque it measures is 58Nm/V.

But actually if you set the crank alignment a little bit offset what is recommended (90 degrees), you must pedal a little bit harder to get the max. voltage out.

I found that when I accidentally bought a taper square cranks which had a different angle on the axle hole. The shimanos 45 degrees hole direction is correct. then you get the correct crank alignment.

And I tested it with my old bike Shimano nexus cranks the first. Thats why I discovered the very low max torque value the BB measures.

Some guys in the German pedelec forum had reviewed the BB too, and I think they judged the quality of the BB quite low. Lets see how it lasts, so far it has been working fine.

BTW. there is a new torque sensor from Bafang coming too: http://www.szbaf.com/en/components/component/sensor/sr-pa2132st.html
It has 32 poles as well.
 
Hi
One strange thing with the latest beta firmware.
I have 3 position switch installed, controlling 3 preset modes (legal,economy,unlimited).
If I drive in unlimited mode with auto-cruise on and then change to to another mode with switch, everything is ok.
But when I switch back to unlimited mode, auto-cruise function is still enabled, so the bike starts to accelerate uncontrollable.

How can I solve this issue?
 
Thank you very much teklektik and psatu!
I will try the settings the next days and post a result :)
 
cero said:
Hi
One strange thing with the latest beta firmware.
I have 3 position switch installed, controlling 3 preset modes (legal,economy,unlimited).
If I drive in unlimited mode with auto-cruise on and then change to to another mode with switch, everything is ok.
But when I switch back to unlimited mode, auto-cruise function is still enabled, so the bike starts to accelerate uncontrollable.
Hey cero-
So - this is unexpected and not very nice behavior...
I cut a problem report for this, so it will be pursued, but unfortunately I can't duplicate it. It looks like we may need some particular mix of configuration to evoke it.

>>> Could you possibly pull a setup file and post it here or in a PM to me? <<<

  • I did notice another odd autocruise behavior, though. It seems that if autocruise is presently engaged and the preset is changed to a preset where autocruise in not enabled, the 'engaged' condition persists until manually disengaged. So, the configuration option only affects 'engagement' but not the 'steady state' autocruise condition.

    This is sort of a weird but inoffensive edge case and I don't believe anyone has complained, but it may need a little attention...
 
of course I can send you setup file, just give me couple of days to get to the bike with comp
 
Beta Testers!

There has been a long-standing problem of the various beta firmware versions being indistinguishable to the Software Setup Utility as all being of type "3.10". Among other difficulties, this meant that it wasn't possible to open a setup file from one beta release and manually transfer the contents to another (new) beta version (unless you had two Setup Utility installations). There also was no warning if a setup file was opened in the Setup Utility that had subsequently been updated with a newer incompatible EEPROM layout. So, a bunch of annoyances...

A new Software Setup utility (1.41) has been released on the Grin CA V3 page and is described in the blog. This version differentiates these beta versions avoiding some of these issues. It does not have the ability to automagically remap one EEPROM layout into another, but it does identify and handle many conflicts.

This new 1.41 utility comes with 3.1b20 and 3.03 already installed. 3.1b20 is the firmware equivalent of 3.1b16 but has the extra stuff to do the versioning detection. 3.03 is the present production software release.

Moving forward all CA releases (3.0, 3.1, etc) require the new 1.41 Setup Utility.
Importantly, all older 3.0 and 3.1 firmware zip packages can only be used with the old 1.31 Setup utility.

The next 3.1 release will be 3.1b21 which definitely has a new EEPROM map and will require a fresh setup. Since there's no functional difference between the previous 3.1b16 and the new 3.1b20, there's no compelling feature or performance reason to update between these versions in advance of b21.

Just a heads-up about what's coming... :)
 
I found another technical data on the Sempu:


PUJAM—BB Dual Side Torque Sensor
1.Technical Data:
1 Input Voltage 5(±0.05) VDC
2 Input Current <60 mA
3 Max output power <300 mW
4 Reference Voltage V0 1.5 (±0.05) V
5 Zero drift @(-20°C +50°C)V0±0.05 V
6 Torque output sensitivity 14.7 mV/N.M
7 Speed sensor 32 pulses/R
8 Direction sensor:
Rotate forward output high electrical level (5) V
Rotate backward output low electricallevel(0) V
9 Length 127.5mm 124.5mm 122.5mm 116mm 115mm,special size accept customize MM
10 Working temperature +50 / -20 °C 11 storage temperature +55 / -25 °C


see PDF on attachment

Here we have a V/NM
 

Attachments

  • Sempu Torque Sensor.pdf
    570.3 KB · Views: 83
Oh, man, been hoping for this forever! Flashing...

teklektik said:
Beta Testers!

There has been a long-standing problem of the various beta firmware versions being indistinguishable to the Software Setup Utility as all being of type "3.10". Among other difficulties, this meant that it wasn't possible to open a setup file from one beta release and manually transfer the contents to another (new) beta version (unless you had two Setup Utility installations). There also was no warning if a setup file was opened in the Setup Utility that had subsequently been updated with a newer incompatible EEPROM layout. So, a bunch of annoyances...

A new Software Setup utility (1.41) has been released on the Grin CA V3 page and is described in the blog. This version differentiates these beta versions avoiding some of these issues. It does not have the ability to automagically remap one EEPROM layout into another, but it does identify and handle many conflicts.

This new 1.41 utility comes with 3.1b20 and 3.03 already installed. 3.1b20 is the firmware equivalent of 3.1b16 but has the extra stuff to do the versioning detection. 3.03 is the present production software release.

Moving forward all CA releases (3.0, 3.1, etc) require the new 1.41 Setup Utility.
Importantly, all older 3.0 and 3.1 firmware zip packages can only be used with the old 1.31 Setup utility.

The next 3.1 release will be 3.1b21 which definitely has a new EEPROM map and will require a fresh setup. Since there's no functional difference between the previous 3.1b16 and the new 3.1b20, there's no compelling feature or performance reason to update between these versions in advance of b21.

Just a heads-up about what's coming... :)
 
I updated the firmware using the Windows utility. Keyed in all my parameters in the setup utility and loaded them onto the CA. The CA then told me that something is wrong with my throttle. The throttle icon showed full throttle and was blinking. Pushing the throttle didn't produce actual effect. I went in and looked at the values. They all looked correct. I hypothesized that the 0.00V for me zero throttle may be a lie (rounding off error) so I entered 1.11, saved, then entered 0.00, all on the CA. My throttle began working as normal.

This is a little worrying because I'm not sure if I can trust what the setup utility shows and what actually gets loaded onto the CA. Generally lots of values get decreased by one hundredth (0.5 -> 0.49) but when the number in the CA doesn't even reflect that, it's not good. I'm planning to re-flash the CA and key-in all the values via the CA itself just to be sure nothing is off.
 
Back
Top