Shenzhen (ecrazyman) Controller Information

[Knuckles]

have just ordered a 24 Mhz 3 PIN CERAMIC RESONATOR off Ebay item no 270185419501 and will try that when it arrives.

Bro you are awesome! I have been looking for these! Overclock here I come!
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... %26fvi%3D1

So right now people who have this controller can modify it to work at higher critical frequency!
This fixes the problem with many geared motors.

The controller currently uses a 20-mhz MCU but only a 16-mhz resonator.
The resonator controls the clock speed of the MCU (just like in a PC CPU).
When combined with the MCU program code, the 16-mhz resonator produces a controller critical frequency of 325-hz.

The 16-mhz resonator is too slow. It is the main cause of the problem (other than sloppy code).

If a new resonator is 20-mhz, (0% MCU overclock) then the new critical frequency = 325-hz*20/16 = 406-hz.
This will solve the Bafang PMGR problem at 72V nominal.

If a new resonator is 24-mhz, (20% MCU overclock) then the new critical frequency = 325-hz*24/16 = 488-hz.
This will solve the PUMA PMGR problem at 36V nominal.

If a new resonator is 44-mhz, (120% MCU overclock) then the new critical frequency = 325-hz*44/16 = 894-hz.
This will solve the PUMA PMGR problem at 72V nominal. It may also kill the MCU or not "spark it up" at all. Oh well.

Maybe Keywin would please ask his pcb vendor to make some new boards with 40-mhz MCU and 44-mhz resonator or crystal oscillator?
There should be no additional cost to make it better and the code can stay exactly the same.

If a new resonator/oscilator is 44-mhz, and a new MCU is 40-mhz (10% MCU overclock) then the new critical frequency = 325-hz*40/16 = 894-hz.
This will also solve the PUMA PMGR problem at 72V nominal but in a safe and reliable way. 10% overclock is acceptable IMO.
Many PUMA owners would be oh so happy.

Toa Chie

[The7]

The 16-mhz resonator is too slow. It is the main cause of the problem (other than sloppy code).

Maybe Keywin would please ask his pcb vendor to make some new boards with 40-mhz MCU and 44-mhz resonator or crystal oscillator?
There should be no additional cost to make it better and the code can stay exactly the same.

Well done!
Maybe this is the best workable solution if the vendor is unable to rewrite a better code/program for the MCU.

[Knuckles]

The 16-mhz resonator is too slow. It is the main cause of the problem (other than sloppy code).

Maybe Keywin would please ask his pcb vendor to make some new boards with 40-mhz MCU and 44-mhz resonator or crystal oscillator?
There should be no additional cost to make it better and the code can stay exactly the same.

Well done!
Maybe this is the best workable solution if the vendor is unable to rewrite a better code/program for the MCU.

Heck The7. You said this all along about the code. All I did was listen to you. Once fechter put a 24-mhz crystal on the pcb and overclocked the MCU we both knew you were dead on right!
The code is way too slow after all (it should be fixed - but that is a project for another day).

Toa Chie The7

USA is #1
USA is #1
USA is #1

[fechter]

I tested the overclocked controller with a Puma motor.
As predicted, the jitter starts happening right at 488hz. Exactly.

This corresponds to the full throttle speed at 44 volts.

Up until it hits the critical frequency, it runs smoothly with no nasty spikes.

So with a 24mhz clock, this would be a workable solution for system voltages up to 36v.

I don't think the stock MCU will be happy going much faster than 24mhz. With a PIC18F series processor, the same code will work, the pinout is the same, and we can clock up to possibly 44 mhz, which should work for a Puma up to 80v max (72v system).

[Knuckles]

I wish to thank fechter, The7, Tiberius and everyone else for working together to finally solve this PUMA mystery.
Like I said in my very first ES post ... "I am a ChE but I didn't know shit about ebikes until I started reading this forum."
viewtopic.php?f=2&t=4109

In my ignorance I recently asked fechter ... "So I am ignorant ... is the "analogue" v "digital" thing an issue of hall signal processing to control firing of the fets?"

fechter took the time to educate me and gave me this great answer ...

QUOTE

"If you upgrade the FETs in the old analog controller it will run much cooler.

The analog controller takes the hall signals and uses analog chips to derive the commutation sequence and the PWM. There are some dedicated brushless motor control chips available today that work like this (MC33035). There is no software, everything is done with hardware, making it extremely fast. The controllers [REDACTED] was getting from the manufacturer were made like this. They had other problems apparently.

The digital controller takes the hall signals and feeds them into a microcontroller unit. The throttle, low voltage signal, current signal, everything, goes into the MCU. The MCU uses software to process all the inputs and generate an output that looks like the analog one. All the adjustments, features, and limits can be done in software.

The "advantage" to the digital controller is the MCU is very cheap and very few other components are needed to make a controller. It's also easy to change the features by changing the software. Typical R/C controllers use this approach and seem to be quite reliable. If done properly, it works well. It is the way of the future.

I think if Keywin could find a faster processor and just substitute it for the one in there, it could go much faster ... The existing processor is clocking at 16 mhz but it is rated for up to 20 mhz (or at least the official Microchip version). It might be possible to increase the clock frequency by changing the ceramic resonator (like a crystal). I'm not sure what happens if you overclock it too much. Going from 15 to 20 mhz might give you enough speed to run the Bafang at 72v.

Let me see if I can find a faster crystal. Those are cheap ... "

END QUOTE

So you can see that fechter nailed the problem thru experimentation.
He did this by verifying the code theory as originally offered by The7.

I am lucky to know such a great group of intelligent people (endless-sphere) ... from all over the planet.

toa chie
Knuckles

[tostino]

I wish to thank fechter and The7 and everyone else for finally solving this mystery.

Please let me know when you get some updated controllers . I am dieing to get this bike up and running.

[Knuckles]

No longer necessary to "bust balls". Keywin is working on implementing a new MCU for the controllers!

cheers

[computerpc101]

Anyone is nice enough to try it on 25MHZ Please, Just want to make sure that it will run 24MHZ stable with enough room.

[fechter]

I searched a large section of my junkpile and did not find anything between 24 and 32mhz. I also tested at 40mhz using an oscillator can, but processor did not spark up. No luck at 32mhz either. That would be really pushing it anyway.

It does seem rock solid at 24mhz. The processor power consumption has not changed significantly, in fact it seems to have dropped slightly. Go figure...

[Knuckles]

Anyone is nice enough to try it on 25MHZ Please, Just want to make sure that it will run 24MHZ stable with enough room.

Funny. You can only try it if you can find it and/or buy it.

Mute point anyway. Keywin is in for 110%. he is building it now. 24mhz. "no problem"

On it's way now direct from Shenzhen.

buxie

(buxie='de nada')

[computerpc101]

I did overclock some Atmel microcontrollor chips before, They are rated at 16MHZ and running fine with 20MHZ, some up to about 22MHZ. However, After 1 year working for 24 hours per day, They can run stable at only 20MHZ now, some of them down to 18MHZ.

I tested it with 27MHZ Xtal, It doesn't work. RIghtnow, It is running at 23MHZ Xtal and stable.

For 16MHZ, MY small Schwinn AL1020 (16" wheel) runs very strong up to 35KM/h @ 48Volts.
For 23MHZ, It runs very strong up to 50KM/h @ 60 volts
not bad for a this Tiny electric bike.

Thanks for whoever find this, good work.

[The7]

I wish to thank fechter and The7 and everyone else for working together to finally solve this PUMA mystery.

Tiberius should also be named because his test results and scope pictures provide us with many good information for this finding.

The code in the MCU has an upper limit of phase frequency of 325 Hz when the clock frequency is 16MHz.
This controller will act as normal 6-step controller up to 271 Hz when viewing the waveform from Tiberus.

It seems that there is some kind of "wait times" between the execution of events (or instructions). Usually MCU uses a certain "no of clock cycles in a wait loop" as a "wait time". It is not necessary to execute the next event immediately if it is known that the next event will NEVER happened within a certain "wait time". The "wait times" between different events could be different.

If the "wait time"s is cause, then it is only necessary to shorten the wait time by reducing the no of clock cycles in the "wait loop".

1) Why the phase voltage start "squaring" from 271 Hz to 325 Hz?
Possible explanation using the wait time:-
The "wait time" for 120 deg conduction becomes so long that it extents the conduction period when the phase frequency exceeds 271 Hz.
At 325 Hz, the conduction period reaches 180 deg and the phase voltage becomes "square".
Between 271 Hz and 325 Hz, there should be no adversary effect except that the "square" waveform will have more "harmonic current" losses than the "trapezoidal" waveform (at 120 deg conduction).

2) What would happen if the phase frequency try to exceed 325 Hz?
If the phase frequency tries to exceed 325 Hz, the conduction period tries to exceed 180 deg.
If the conduction period exceeds 180 deg, both top-side FET and low-side FET of the same phase will be fired at the same. It will effectively provide a "short circuit" path and very large current will flow to damage the FETs.
Since Tiberus used PSUs with current limt at about 2A, it will only trigger the current limt without demaging the controller itself.

[Knuckles]

The processor power consumption has not changed significantly, in fact it seems to have dropped slightly. Go figure...

You actually measured the change in MCU power consumption from 16-mhz to 24-mhz? Man that is freaky!

Dang!

Does this have anything to do with the orange wire?

[Knuckles]

If the "wait time"s is cause, then it is only necessary to shorten the wait time by reducing the no of clock cycles in the "wait loop".

Refer to ... http://www.sparkfun.com/commerce/presen ... king+a+PIC

QUOTE

20 MHz Test:
If you look at the code, you will see a value inside the rs_wait function. The function dictates the baud rate. Depending on how many cycles the rs_wait loop goes through changes the width of the rs232 pulses - ie baud rate. For 9600 bps with a 20MHz crystal, this value is 36. Sho' nuff, we got hyperterminal to read the text that was being sent from the PIC.

END QUOTE

Does the controller MCU code require tuning to 'jibe' with the MCU (over)clock speed?

I have the code as a txt file btw

[The7]

For 16MHZ, MY small Schwinn AL1020 (16" wheel) runs very strong up to 35KM/h @ 48Volts.
For 23MHZ, It runs very strong up to 50KM/h @ 60 volts

Glad that you have also confirmed our finding because the speed at 325 Hz is about 37 km/h (not 32) in your AL1020 motor.

I think you should use 23 MHz clock because AL 1020 has a max speed of 40-45 km/h on flat using 48V with the analog C-controller.

Noted that you are in computer field. Glad if you could share your experience about the MCU.

[solarbbq2003]

you guys are gurus!

[solarbbq2003]

does v2 crystalyte controller have a resonator?

[fechter]

does v2 crystalyte controller have a resonator?

Nope. Don't see one. I suspect the MCU has an internal clock. It should be possible to find a datasheet for the MCU that would give clock information. Sometimes you can change clock speed in software.

[Herrsprocket]

Over in the thread titled," version 2 clyte information" in the last few posts, I see that Brett posted some MCU stats there. Instead of pasting everything here too, perhaps folks could look at the data and discern if an answer to the MCU being able to provide a "software upgradeable" solution to the "jitters"is possible, since it appears that the clyte controller may not have an external resonator to impose a change. Also interesting is the voltage input into the chip may have something to do with altering the clocking speed?

[Tiberius]

Hi Guys,

I have just done an experiment to confirm/investigate the clock speed/timing issue.

I removed the 16 MHz ceramic resonator and clocked the processor from a pulse generator. That way I can vary the clock speed over 0 to 20 MHz.

Running my motor/controller combination at "half" speed - ie., 36 V, full throttle - giving about 160 Hz rate on the Hall sensors. I find the following: As I reduce the clock speed it is ok down to 8 MHz, then the ramp on the motor drive disappears and it becomes a square wave. If I take the clock speed any lower, it all falls apart. The motor phasing goes wrong and there are nasty noises from it. On the good side, nothing breaks or catches fire.

At partial throttle much the same occurs.

It looks like previously, because I could only raise 84 V from the PSUs, that I was reaching the first signs of trouble, but was just short of the point where it really goes wrong.

At least now I have a way of investigating the limit point without having scary amounts of electrical or mechanical energy flying about.

I'll try to capture some traces and post them over the weekend. That's all for now, because I'm 8 hours ahead of most of you and its the magic time that my friends drag me out of the lab and off to the pub.

Nick

[The7]

Running my motor/controller combination at "half" speed - ie., 36 V, full throttle - giving about 160 Hz rate on the Hall sensors. I find the following: As I reduce the clock speed it is ok down to 8 MHz, then the ramp on the motor drive disappears and it becomes a square wave. If I take the clock speed any lower, it all falls apart. The motor phasing goes wrong and there are nasty noises from it. On the good side, nothing breaks or catches fire.

At partial throttle much the same occurs.

Very informative!
It seems that the current limit in your PSUs prevent the damaging.
Wonder if you could also note the clock frequency at which the "squaring" starts?
Like to look at the traces when ready.
Thanks.

[fechter]

Cool.
Too bad your pulse generator doesn't go over 20mhz. I'd like to know how high it can go before it goes unstable.

[Stevil_Knevil]

Just a wild thought that ran through my head.. can we have the planet gears in the Bafang PMGR hub motors upgraded from nylon to -- whatever can/will handle ~110 pounds of thrust?

[Knuckles]

It is not the Bafang gears that worry me, it is the total mass of the motor. Because the rotor rpm is higher than a DD motor, a PMGR is generally more efficient. But never 100%. So heat will always be generated in the stator. But a DD motor has more mass of copper and is larger and can dissipate heat better than the smaller PMGR.

Push either type motor too hard and, bammo! … Blown hall sensors. IMO the Bafang PMGR and Grubee DD motors should never be pushed beyond 72V & 30-amps. Even if you replace the wire harness with thicker phase wires (highly recommended btw. See ... viewtopic.php?f=2&t=4626), 2000W into the motor is about the max you can go without overheating the motor and blowing the hall sensors.
NEVER RUN THE BAFANG ABOVE 30 AMPS!

Hey, Maybe we should commission the Bafang Company to build a 5KW PMGR that we can push to 20KW! I'll put that on my girlfriend's bike (he he) along with some rockets!

I am diggin' Tiberius' pulse generator analysis. It is the final nail in the coffin to the demise of the mystery (i.e. the mystery is now dead and the solution is crystal clear).
Increasing the MCU clock speed is a no-additional-cost solution that will work 100% for the PUMA and most any other motor.
The code should be fixed also just because I abhor sloppy code (ahem ... Microsoft).

[The7]

Just a wild thought that ran through my head.. can we have the planet gears in the Bafang PMGR hub motors upgraded from nylon to -- whatever can/will handle ~110 pounds of thrust?

P2 (solarbbq2003) using one metal and two nylon in the planetary gear seems to be an optimal choice.
The metal one could nearly transmit all the mechanical power from the sun gear to the ring gear.


The temperature of the outer hubs of both geared and gearless motors may appear to be the same.
But the winding in geared hub motor will be usually hotter than that of gearless hub because the rotor of the geared one is inside the outer hub (ring gear) while the outer hub of the gearless one is the rotor .
This would also mean that the Hall sensors in geared hub are also subject to a higher tempaerature.