Cycle Analyst V3 preview and first beta release

[irq]

The ca misses an SATA port for all the special wishes

Btw i Ghetto temp fixed mine. Rewired the power out plug to use it as 12v in since i got 12v regulated supply anyway for the headlights

 

[amberwolf]

Just be aware you may have to change the setting that tells what voltage the CA need to shut down at, or it may not have time to save the data . I forgot what the setting is called, but when I ran mine off my lighting power (for a similar reason as yours), I had to lower that from the IIRC ~15v it came set at.

 

[irq]

Ah, thanks for the hint! Will check this!

 

[teklektik]

v3.1 Beta 8 Released (Repaired b7)

Thanks to lightrush's bug report yesterday on the Aux PAS limit issue, we have a new 3.1b8 release.

I'll forego the usual Release Notes summary -- this release specifically targets the b7 Aux issue so this is really just a 'fixed b7' that should work as originally claimed. There are no other changes.

I'm hoping two bogus releases in a row doesn't signal a trend - I guess we'll see when b9 comes out...
Anyhow, the code issue was minor and I did some directed testing for that failure and derivative effects in particular. Looks good on the bench and on the road, so here we go.

Because we had some wonky table indices in play, strange things can happen data-corruption-wise. To be 100% safe, I strongly recommend building a fresh config.

That said, the b7 config 'should' work okay if you just flash the xxxx_NoEeprom version then revisit and explicitly reconfigure the AuxA and AuxD limit types -even if it's to the same limit type again - they just need to be edited to purge EEPROM of the bad limit type indices from b7.

So: "Have at it!" and thanks for the bug reports -- though I do hate to get them...

Download!
View attachment CA3-1b8.zip
(Previously implemented 3.1b7 beta features (part of this build) described here and in the Release Notes.)
(Newer 3.1b9 beta release available here!)

 

[irq]

Finally found a dealer in germany who got the dn2450 in stock. Thats not that easy to find that i thought.

If any germans are looking for this fet... Reichelt.de got them in stock.

 

[irq]

Just be aware you may have to change the setting that tells what voltage the CA need to shut down at, or it may not have time to save the data . I forgot what the setting is called, but when I ran mine off my lighting power (for a similar reason as yours), I had to lower that from the IIRC ~15v it came set at.

I can confirm this, but thats not the only issue. It seems that the ca got some other problems with this way of powering the device. My 12v source is galvanic seperated which looks like causing issues with ground. Ca shows about 2-3v higher batt voltage than the battery got. Be careful, i whould not be surprised if this can damage other components.

 

[lightrush]

Because we had some wonky table indices in play, strange things can happen data-corruption-wise. To be 100% safe, I strongly recommend building a fresh config.

That said, the b7 config 'should' work okay if you just flash the xxxx_NoEeprom version then revisit and explicitly reconfigure the AuxA and AuxD limit types -even if it's to the same limit type again - they just need to be edited to purge EEPROM of the bad limit type indices from b7.

To be safest in terms of clean config, what is better, to do New file from the setup tool or to read the default config from freshly flashed NoEeprom image into the setup tool and then fill the new values?

Also should there be any difference between filling in values in the setup tool and then writing to the CA versus filling in the values directly on the CA? If yes, which one is "safer"?

 

[teklektik]

To be safest in terms of clean config, what is better, to do New file from the setup tool or to read the default config from freshly flashed NoEeprom image into the setup tool and then fill the new values?

This is a good question.

• We have these four file sources for configuration:
  
  1. Setup Utility V310.cas + V310.hex
  2. CA3-1b8_firmware.hex
  3. CA3-1b8_firmware_NoEeprom.hex
  4. CA3-1b8_firmware_CalOverwrite.hex
  You are asking, I think about using either (1) or (2) --
  For (1) -- Using Setup gives you the built-in default values for all operating parameters + the normally hidden default per-device calibration values.
  For (2) -- Flashing this gives you the built-in default values for all operating parameters (same as with the Setup Utility)
  
  So - either of these approaches will give you the same 'clean slate' base set of parameter defaults on which to base your new configuration.
  
  
• In contrast, flashing (3) only puts new program code in place and does not restore parameter defaults or change the per-device calibration. Any previous settings or corruption all remain unchanged (particularly consistency issues, lifetime stats corruption, or issues with 'hidden parameters' that are not visible for configuration). This is not a good choice to get a clean slate since it leaves all EEPROM in the original (possibly corrupted or version-incorrect) state.
  
  
• Version (4) is not usually distributed and gives you the built-in default values for all operating parameters + the normally default per-device calibration values.
  This gives you the 'clean slate' and also clobbers the factory calibration for your specific CA with some 'pretty close' default calibrations (generally a few percent off). This file may be sent out by Support to fix CAs that are really messed up to the extent that the firmware won't operate. An alternative means to achieve this is to select "Preferences/Show Protected Settings" in the Setup Utility which makes all the hidden per-device calibration stuff appear. You can then enable the parameters as needed via checkboxes and update the CA to overwrite the existing calibration, etc.
  
  When you read a configuration from the CA, you get both the regular parameter settings as well as the per-device configuration (which is hidden in the Setup Utility by default). Such files can always be used to restore the regular parameters as well as to optionally restore the per-device calibration. This kind of makes it a good idea to suck the CA config and save it at least once to preserve your factory calibration. Do the 'Protected Setting' and checkbox thing above to restore your specific per-device calibration. If you don't have the exact same version as your present or desired firmware, do it anyway to get the per-device calibration back, then proceed as above to fix up the regular parameter versioning errors to match the firmware.

Also should there be any difference between filling in values in the setup tool and then writing to the CA versus filling in the values directly on the CA? If yes, which one is "safer"?

Another good question.
In the end they are the essentially the same - the same parameter values get placed into EEPROM and one is as 'safe' as the other. There are, however, a couple of subtle differences...

• There is slightly different rounding for data entry/display so the same value entered in one may appear off by a percent or so in the other. This is a little nonsense we need to work on and typically appears as an entered value of '5.00' appearing as '4.99'. No biggie, but it does make entering stuff in the CA Console sometimes yield cleaner number displays.
• There are a few inter-related values, particularly in the later features where certain CA Console selections or values will automagically alter or hide other parameters. The setup parameter information in the V310.cas and V310.hex files is not capable of providing such complicated Setup Utility behavior, so some things in the Utility do not get hidden or altered, or values can be entered that are not consistent for proper operation. However, this is only a Setup utility display issue. When such files are loaded into the CA proper, the CA runs though all inter-related values and enforces consistency. When subsequently displayed on the CA Console, the proper stuff appears and appropriate parameters are hidden.
  
  So - short form: the CA Console always has the most accurate and consistent display whereas the Utility display may allow certain wonky value entries that are 'fixed up' by the CA on download. The end operational result is identical.

Well - that might be more detail than necessary, but it's all the stuff in play for configuration...

 

[lightrush]

Good stuff. Thanks!

 

[JeffH]

A user definable preset name would be nice for me.

Yep - problem is that we are running out of configuration memory, so a custom name is very expensive because it takes a lot of room, but a small index into a table of fixed names already exists - so the 'fixed name' approach is 'free' and wins...
We'll use the 'saved' memory for other more interesting features.

Copy that.
My first use of the presets was with a different motor on the same controller and CA and a generic label doesn't really work - no big deal though, #1, #2, and #3 work fine.

BTW thanks for all of your efforts with the CA manual and upgrades.

Jeff

 

[teklektik]

A bit back Fastolfe asked about the minimum speed and I believe merlin had asked about this earlier as well:

...the Cycle Analyst stops displaying the speed (it drops to 0) and stops updating the distance below 3 kph or so. I'm not sure if the speed limit is hard-coded or if it's because the time between magnet pickup ticks becomes too long. In other words, I don't know if adding a magnet to the wheel would lower the limit - I haven't tried - but it'd be nice if the limit could be lowered in the firmware without adding another magnet. I very often grind uphill at speeds under 3 kph

I gave a response that was correct from the perspective of how the CA blanks noise and the idea that increasing spoke magnets will not improve response, but incorrect as to the reason for that particular 2.5mph/kph lower bound. My Bad. In fact, the cutoff speed derives from the fact that the internal speed is calculated every wheel (motor) revolution and the display becomes very laggy if allowed to track these slow updates at very low speeds or when stopping - so the display is just suppressed. For instance, at 1kph the update takes about 10seconds so the display would take a really long time to show the bike has actually stopped...

However, Justin points out that it is possible to trick the CA into displaying lower speeds by making the wheel (motor) appear to be rotating more rapidly and so giving an acceptable (reasonably displayable) update rate at a lower actual speed. Unfortunately, this only works with DD motor poles, because spoke magnets may not be equally positioned.

• The distance covered per pole is given by:
  
  • (Spd->Circumf) / (Spd->Poles) e.g. 2075mm / 23 poles
  The 'trick' relies on the ideas that CA will read the same speed/distance if we adjust these values while maintaining the same ratio and that the CA will think the wheel is spinning faster if the pole count is reduced. (Since Speed pulses arrive at the same rate, fewer poles mean the wheel is spinning faster...)
  
  So, in the example above, we could cut the minimum displayable speed in half by using half the poles (23/2 ~= 11) and calculating a new phony circumference to match our phony pole count:
  
  • Circumf_new = (Circum_real / Poles_real) * Poles_new = (2075mm/23poles) * 11poles = 992mm
  Reducing the pole count further to 10, 8, etc will still read the proper speed but will decrease the minimum displayable speed as long as the circumference is adjusted proportionately.

 

[irq]

i received the replacement fets today, but things are still strange and i am not 100% sure if the fet is the right one:

http://www.reichelt.de/DN2450K4-G/3/index.html?ACTION=3&LA=446&ARTICLE=153612&artnr=DN2450K4-G&SEARCH=DN2450K4-G

the tantalum capacitor is also replaced, d3, too

when i connect the CA to a controller, display backlit turns on but flickers a bit and r9 gets hot. so i started measuring around the fet, between drain and source i measure around 9 ohms in the circuit, which cant be right? i got the full battery voltage on C3 not only ~12v

the ca itself still seems to be alive, when feeding 12v on the source solder pad of q1 (q1 removed of course) it turns on and boots up like it should. i can even hook it onto a controller and get everything working.

i somehow think that i noted the wrong fet type, the markings on the stock one where hard to identify due to the sealing of the pcb. could have been dn3xxx, too

anyone around who knows the exact stock type?

 

[irq]

Correcting myself... Dn2470k4

 

[amberwolf]

https://endless-sphere.com/forums/viewtopic.php?f=2&t=19540&p=679054&hilit=depletion+mode+fet#p678269

 

[izeman]

Teklektik, as much as i welcome your response and ideas about very low speed display (<4km/h, which is quite annoyoning to me) i think it would be much easier to accomplish with magnet speed pick ups. I installed 3 of them, and they are very evenly placed. So if it's possible to show 4km/h with one magnet it should be no problem to show 1.3km/h with 3 of them?!


Gesendet von iPhone mit Tapatalk Pro

 

[Jackass]

Question about interaction between CA3 and PAS BBSHD settings.

I'm using EM3ev's settings on my BBSHD and tried about every setting on my CA3 (like slower throttle out ramp up and lower power gain) to get a responsive but smooth pedal assist. It's either very unresponsive or too jerky.

The only solution I've found so far is using my potmeter as an indirect 'power throttle' while pedaling.

I'm suspecting interaction between the BBSHD settings and the CA3 settings.

Especially the PAS settings of the BBSHD could interfere, like the Start Current (10%), Slow Start Mode (4), Time of stop (10), Current Decay (4) and Keep Current (80%).

Any suggestions for BBSHD settings so there is no influence of the BBSHD's settings on the CA3 settings?

 

[teklektik]

Teklektik, as much as i welcome your response and ideas about very low speed display (<4km/h, which is quite annoyoning to me) i think it would be much easier to accomplish with magnet speed pick ups. I installed 3 of them, and they are very evenly placed. So if it's possible to show 4km/h with one magnet it should be no problem to show 1.3km/h with 3 of them?!

I'm not 100% sure what you are suggesting.

• The CA does not measure the time between pulses - it effectively works based on complete wheel revolutions. This means that simply increasing the number of poles has no effect and also implies that exact spacing of the poles (spoke magnets) is not required.
  
  
• If you mean to try the hack in the post above with spoke magnets, it might work. On a quick glance, it may introduce jitter into all the speed/distance related calculations because of magnet positioning differences. This may not be noticeable in your configuration, but I haven't tried it and haven't thought through all the code ramifications. Anyhow it's easy enough to try.

 

[teklektik]

I'm suspecting interaction between the BBSHD settings and the CA3 settings.

There's no question this is the case and has presented obstacles to others making similar attempts. It becomes an issue of two different controllers in the same feedback loop, each with different goals. Arguments break out...

The CA is expecting a dumb controller and the BBSxx is not dumb.

I'm out of my depth here with regard to the BBSxx and can only recommend you look up Kepler's work in this area if you haven't already done so.
Two threads come to mind:

BBS0x controlled by Cycle Analyst V3
Latest road and single track weapon

 

[madin88]

[*]The CA does not measure the time between pulses - it effectively works based on complete wheel revolutions. This means that simply increasing the number of poles has no effect and also implies that exact spacing of the poles (spoke magnets) is not required.

However, Justin points out that it is possible to trick the CA into displaying lower speeds by making the wheel (motor) appear to be rotating more rapidly and so giving an acceptable (reasonably displayable) update rate at a lower actual speed. Unfortunately, this only works with DD motor poles, because spoke magnets may not be equally positioned.

Do you think that it would improve things if you reprogram the setting from "complete wheel revolotion" to something like "distance between pulses"?
this would mean for 1 magnet it is like before and if you use lets say 3 magnets, the wheel circumferrence needs to be diveded by 3 or much higher number if a DD hub is used.

 

[izeman]

Hmmm. Was puzzeled at first, but now i guess i understand. Thanks teklektik for explaining the internals.
Let's say i have 3 spoke magnets and circumfence of 2060mm (number out of my head) and then set that to ONE pole and 687 it would show sub 4km/h speeds?? That would be great.


Gesendet von iPhone mit Tapatalk Pro

 

[izeman]

@maddin88: yes. You are right. I guess the way the CA calculates speed is to be re-thought to be more flexible.


Gesendet von iPhone mit Tapatalk Pro

 

[teklektik]

Do you think that it would improve things if ...

'Improve' is a slippery term that often gets play when the entirety of a problem is not in view.
There are other considerations beyond being able to see speeds below 2.5mph.
Tradeoffs - as always...

 

[Jackass]

I'm suspecting interaction between the BBSHD settings and the CA3 settings.

There's no question this is the case and has presented obstacles to others making similar attempts. It becomes an issue of two different controllers in the same feedback loop, each with different goals. Arguments break out...

The CA is expecting a dumb controller and the BBSxx is not dumb.

I'm out of my depth here with regard to the BBSxx and can only recommend you look up Kepler's work in this area if you haven't already done so.
Two threads come to mind:

BBS0x controlled by Cycle Analyst V3
Latest road and single track weapon

While modding (actually goofing around) I managed to kill my BBSHD controller. RIP.

Maybe, instead of ordering a non-potted controller from EM3ev, I should forget about the 'smart' BBSHD controller (which screws up the CA3 PAS function) and buy a 'dumb' controller.

Any ideas which one to buy?

And how to connect it to the motor? (because apart from the three phase wires there are some other wires coming from the motor and Bafang is very secretive about the internal wiring diagram of the BBSHD)

 

[irq]

CA is back alive \o/

surprise... with the correct mosfet the ca became happy again. not really easy to get in germany, digikey (with discount shipping of more than 20€ for a transistor..). finally i found it on ebay uk where its getting sold at a normal pricing. and shipping from uk -> de is rather cheap (~8€).

got 4 more spare left, who knows ... if anyone else here got the same problem and cant find this fet, i whould give away 2 of the 4 (pricing 1:1 what i paid, excl. shipping). but i decided to stay with external powering of the CA, so currently i can choose between external power through the power jack which is default for power output or by the controller (default powering)

 

[irq]

Question about the Digi Aux Feature:

Presets can be changed directly through the 2 Buttons on the CA, which is nice but far away from my fingers in Case of Emergency. Is it possible to configure a 2 Button Digiaux Setup to do the same?

Press Both Buttons at the same time, keep one pressed until preset menu shows up and push the 2nd one to change to the decided preset. i think the reason why it should not be sooo easy for everyone to figure out how presets get changed is clear if you look at my location.