Shenzhen (ecrazyman) Controller Information

Knuckles said:

gip_mad said:

Knuckles said:

Just follow my instructions here and it WILL ALWAYS WORK PERFECT!
http://endless-sphere.com/forums/viewtopic.php?f=16&t=3484#p81888

Click to expand...

You should ask fetcher to post this link on the FIRST post in this topic, so new guys (and us when they ask for it) doesn't have an hard time finding it... :wink:

Click to expand...

What a great freakin idea!

Oh please "Great Fechter - Ruler of thy ES Realm" ... Thou please grant us this wish! Thou newb surfs beg thee!

Click to expand...

The following are details on the "Shenzhen Sucteam Technology Co., LTD" controller sent over by Knuckles. A discussion and history are in this thread: http://endless-sphere.com/forums/viewtopic.php?f=2&t=4109

Apparently this is very similar to the one used by Goldenmotor and possibly others.

The example I have was labeled:
Model: BL7228
Rated voltage: 72v
Max current: 28A
Rated power: 1000w
Low voltage: 62v

Here's the outside:


Opening the the case. Just remove the screws to remove the end plate.


Board top side:


Board bottom side:

Here's a diagram of the wiring connections:


The orange wire on the battery connector feeds the voltage regulator and the control circuitry. This wire needs to be connected to the red Battery + wire to turn the controller on.
This wire draws around 50-55 ma when the controller is on.

The 5v brake wire has a yellow and black. Black is connected to Battery negative.
Short the black and yellow wires to stop the motor.

The single yellow "high voltage" brake line stops the motor when a 12v-72v signal is applied to it. This was intended for installations where there was a brake light. The wire attaches to the positive side of the brake light.

Both brake inputs can work at the same time and have the same effect.

The hall sensors are powered by 5v

The throttle is a 5v hall effect type.
Red= 5v supply, Black= ground, green= throttle signal (1-4v).

The 60/120 degree jumper is set according to your motor type. Most motors are 120.

First off, lots of people want to change the Low Voltage Cutout (LVC) setting.
This particular one cuts out at 62v, which may be a bit high for many batteries.

The LVC can be set to any voltage.

The circuit looks like this:


The resistors are located here:
View attachment 3

By lowering R3 and R73, the limit will be lowered.
For example, jumpering R3 with a wire will lower the LVC to 22.5v

You could place a 100k trimmer pot across R3 (extend with a pair of wires), and make the LVC adjustable from 22.5v to 58v.

NOTE: anywhere below around 40v, the voltage regulator starts to drop out. To go lower than 40v, you need to change something in the regulator (See voltage regulator section).

Here are some resistor values to put across R3 to get various LVC settings (approximate):
3k = 29v
10k = 38v
15k =42v
25k = 47v
36k= 50v
46k= 52v
88k= 56v


Removing R11 will disable the LVC altogether, but this is not really recommended since the microcontroller can malfunction if the 5v supply drops out, potentially blowing the FETs or other parts.

To add a resistor across R3, I took a regular leaded resistor (small) and bent the legs to fit over the surface mounted one.
View attachment 1

Here's how it looks soldered in place.
NOTE: keep the resistor legs clear of the edge of the board. This part of the board slides into a slot in the case and you don't want the resistor to touch the case.

On the circuit board, there is a LED status indicator.
This is very similar to the Crystalyte v.2 controller.
Unfortunately, you have to take the controller apart to see it.
It would be possible to extend the LED to the outside with a pair of wires.

From what I can tell, the codes are:

No light: Motor running
1 flash: Standby, motor stopped
2 flashes: Throttle input fault or HV brake active
3 flashes: Locked rotor (start speed protection)
4 flashes:
5 flashes: High side FET shorted
6 flashes: Hall sensor fault
7 flashes:
8 flashes: Under voltage (LVC) active

Not sure about 4 and 8. One is most likely an overcurrent fault

Connecting a Cycle Analyst should be fairly easy.

One problem is there is no buffered output from the hall sensors to operate the speedometer input. There are traces on the board for this, but the parts are not populated. Plan B would be to use a conventional bike speedometer sensor and magnet on the wheel to provide the speed signal.

The V batt wire should be attached with a small fuse (1A) or polyfuse to protect the wiring.

I don't have a good setup to measure the shunt resistance, but it is somewhere around 2 -2.5 milliohms. Hopefully someone else will make a better measurement of this.

I think these are the same connectors:
http://www.allelectronics.com/cgi-bin/item/CON-640/189/6-CONDUCTOR_LOCKING_CONNECTOR_W__LEADS_.html
Or you should be able to get them from ebikes.ca http://www.ebikes.ca/

The rest of the connections should look like this:

The voltage regulator section is an interesting cascaded LM78xx linear regulator design.
They seem to run quite hot, and I would be inclined to put some heat sinks on the regulators.

Here's the basic layout:


The 5v processor control power starts to crap out at around 40v input in the stock configuration.

By jumpering R1, you can go down to around 30v (50v max).
By jumpering both R1 and R2, you can go down to 15v (35v max).

Here's the location of R1 and R2:

I tested this controller with a Puma motor and seemed to run into the same problem they were having with the Crystalyte v.2 digital controller. Above a certain speed, the current starts spiking way high, threatening to blow the FETs.

The Shenzhen does have a two stage current limiting circuit, and detected the spikes causing it to shut down before any damage was done (good feature).

After doing a crapload of testing, I determined that above 30v full throttle speed, the timing of the FET switches goes haywire, causing the spikes. At this speed, the hall signals are running about 325 hz. At 72v, this could be around 1000 hz.

I don't think this is caused by the inherent timing advance of the Puma motor anymore.
It may be that the little microprocessor is just too slow to keep up with the motor at full speed.
I think this is exactly the same problem reported with the Crystalyte v.2 controllers.

We'll see if there's a workaround for that.

Here's a "normal" motor, a small Litton brushless motor
The top trace is one phase to ground, the bottom trace is the hall signal.


Here's the Puma motor when it starts to screw up:

Here's a video of the oscilloscope trace.

The top trace is drive to one of the low side FETs
The bottom trace is the hall signal. The scope is triggering off the hall signal.
Sweep speed is 0.5 mS/div.

At the beginning, you can see the timing of the waveforms is steady. After speeding up just slightly, you see the timing start to jitter and change pulse width.

View attachment Puma motor waveforms.wmv

It's still not clear what's going on. It seems like the MCU should be fast enough. It is running somewhere around 4 MIPS, and the program is not that long (less than 200 lines or so total). I checked the power supply to the MCU and I did not see any big noise. There is at least one report on the forum of someone using a Crystalyte v.2 controller with a BMC motor at 66v or something.

The 3 pole salient winding configuration of the Puma has much the same effect as a skewed stator on a 'regular' motor. The BEMF waveform of the Puma looks essentially the same as a Crystalyte motor. It is a trapezoid.

Before the jitter starts, the shunt current shows some rather large but short spikes timed with the commutation. When the jitter is happening, the spikes are still there but the baseline current goes high.
I'm not sure if these current spikes are real or just some kind of noise in the signal.

It might be possible the spikes are triggering the overcurrent protect sort of half way. If a spike is big enough to trigger overcurrent, I think the controller is supposed to shut down and blink 4 or 7?

The spikes seem to be both positive and negative, which suggest some kind of ringing. The Puma has a very low inductance, so the resonant frequency will be much higher. It might be interesting to add some inductance to the phase wires and see what happens. The low inductance of the Etek motor has caused controller problems in the past and adding inductance has solved it.

Here's what the voltage across the shunt looks like when it's running normally:
Top trace is current, bottom trace is hall signal. Current scale is roughly 25 amps/div.


When the jitter is happening, here is the same measurement:

As observed, the spikes are separated by 60 deg which is the conduction period of a 6-step controller.

The high voltage spikes will occur at the instant of switching OFF by the FETs. I would also think "going +ve and -ve" is due to ringing.
It seems normal for the spikes to appear in the current shunt.

I would like to ask why for the following difference:
a) The top screen shows that there is an difference of about 24 deg between the spike and the Hall signal.
b) The bottom screen shows that there is no delay.

I noticed that too, but have no idea why that is.

When the spikes are out of phase is when it's operating normally.
When it malfunctions, they line up, but also the phase outputs are getting shifted, so perhaps that explains the shift. You can see the shift happen in the video.

"Shift Happens"

Hi fechter,

It could possibly be a resonance, for instance between one set of smoothing capacitors and the motor winding. But that may not explain why the effect turns on above certain rpm.

A question - are these traces taken when running at full throttle? Ie, are we seeing only commutation effects? Or are there throttle turn down effects too? What does the zoom in on the PWM throttling waveform look like?

The7's observation about the phase angles strikes me as important too.

Given that the effect turns on a particular rpm, I would be suspicious of timing errors between the hi side and lo side FETs.

HTH,

Nick

PS. Think this crossed with your post

Very interesting thing when the jitter is happening:

The drive to the lo side FET jitters and loses sync with the Hall signal.

But the large current swings are sync'd to the Hall signal.

I don't know the explanation for that.

Nick

One more test...

I took my standard test motor and gave it enough voltage to hit 325 Hz and the jitter still happened. My test motor is very small, neutrally timed, wye configured. At full speed it draws about 0.25 amps no load. When the jitter starts, the current jumps to over 1 amp.

This tells me the problem is not unique to the Puma, but any motor with enough rpm will run into the same limitation.

Back to making the code run faster.....

BTW, the Shenzhen controller has what appear to be connection points for a PIC in-system programmer interface. The MCU appears to be something like a PIC16F72.
Does anyone know of any software I can use to talk to the chip? I have an Atmel AVRISPmkII, but the software is Atmel specific (you need to choose an Atmel device from a list). My AVRISP is USB connected.

Tiberius said:

A question - are these traces taken when running at full throttle? Ie, are we seeing only commutation effects? Or are there throttle turn down effects too? What does the zoom in on the PWM throttling waveform look like?

Click to expand...

Those are all at full throttle, 100% duty cycle.
Here's what it looks like at partial throttle:

I suppose any controller would have to have an upper rate limit.
Its just that you would hope that hitting it resulted in something benign or graceful degradation.

Over the limit, the controller is getting jitter on its timing and there are current spikes. Which is cause and which is effect?

fechter, if you back off the speed, does it return to normal ok and at the same rate, or is there a hysteresis effect?

Nick

fechter said:

Here's a video of the oscilloscope trace.

The top trace is drive to one of the low side FETs
The bottom trace is the hall signal. The scope is triggering off the hall signal.
Sweep speed is 0.5 mS/div.

At the beginning, you can see the timing of the waveforms is steady. After speeding up just slightly, you see the timing start to jitter and change pulse width.

Click to expand...

As obverved from video:
The period of the hall signal = 3ms
Then its frequency is about 333 Hz.

At frequency below 333 Hz, the gate signal to the low-side FET is stable with its falling edge in phase with the rising edge of the hall signal. The gate signal is normal.
When the speed is increased slightly (when output freq is increased above 333Hz), the gate signal is jittering. It becomes abnormal.

My comment is as follows:
The gate signal is controlled by the MCU. There could be an over-speed limit programmed in the MCU.
As the MCU senses an over-speed (when the output frequency exceeds a certain value (say 333Hz), it will retard and/or reduce the gate signal width in order to reduce the speed.
As soon as the speed is reduced , the MCU will advance and/or increase the gate signal width again.
Thus jittering of the gate signal occurs for such retarding and advancing.

If the motor overspeeds into the malfunction region, there is a good chance of FET destruction.
It would be a good self preservation feature if the speed was limited to slightly below the malfunction point.
You would want to limit the speed by reducing the PWM, though, not by changing the timing.

Of course it would be better if the controller was just so fast that the motor flies apart before it malfunctions.

Tostino said :" when the motor gets near the RPM where it cuts out, it starts to whine at a pretty high pitch." for his contoller in
http://endless-sphere.com/forums/viewtopic.php?f=3&t=4007&st=0&sk=t&sd=a&start=15


Did your test motor behave in a similar way?
a) make strange noise near the critical speed (the critical output frequency, say about 333Hz)?
b) cut out or stop if you try to increase the speed further?

As the speed just approaches the point where it goes weird, you can see the waveform gradually distorting. This happens over about a narrow rpm range. At one point, the trapezoid looks more like a prefect square wave, which I'm sure would make it noisy. If you try to make it go faster, it goes into more of an oscillation.

at what point does this occur relative to throttle position? 50% of the throttle? 80%? 90%

i'm just trying to get a feel for when this happens. only the last little portion of the throttle range or is a whole bunch missing?

what is the actual motor RPM for the PUMA motor when this happens? 200rpm? 300rpm? 500rpm?

rick

rkosiorek said:

at what point does this occur relative to throttle position? 50% of the throttle? 80%? 90%

i'm just trying to get a feel for when this happens. only the last little portion of the throttle range or is a whole bunch missing?

what is the actual motor RPM for the PUMA motor when this happens? 200rpm? 300rpm? 500rpm?

rick

Click to expand...

For me, it happens at about 10-15% throttle on my BMC motor. So a whole bunch is missing.

I don't exactly know the RPM, but i'd guess it's spinning a little over 300-400 when the noise appears.

rkosiorek said:

at what point does this occur relative to throttle position? 50% of the throttle? 80%? 90%

i'm just trying to get a feel for when this happens. only the last little portion of the throttle range or is a whole bunch missing?

what is the actual motor RPM for the PUMA motor when this happens? 200rpm? 300rpm? 500rpm?

rick

Click to expand...

It depends on the applied voltage.
If I set the voltage to 30v, I can go full throttle without a problem, as the motor never gets going fast enough to reach 325 Hz. If I use a higher supply voltage, then it starts jittering before I reach full throttle. The higher the voltage, the lower the throttle setting where jitter starts.

For the Puma, this works out to about 1200 rpm on the rotor. Gear ratio from rotor to hub is about 5:1 as I recall. That would make 240 rpm on the wheel.

For the 600w BMC non-hub motor, you would reach 325 Hz at around 2400 rpm. As I recall, mine goes about 5000 rpm @ 48v.

So far as observed:

1) Shenzhen (ecrazyman) Controller has a cut-off (or critical) frequency of about 325Hz. I think this cut-off frequency is programmed in the MCU.

2) It will behave normally if the output frequency is lower than the cut-off frequency.

3) The cut-off rpm of rotor = The cut-off frequency X 60 / (No of pole-pairs)
If the no of pole-pairs = 16 (say for the Puma) .
Then the cut-off rpm of the rotor = 325X60/16 = 1218 rpm

4) If the motor does not reach the cut-off rpm at a certian battery voltage at full throttle, you will not notice it at all.

5) If you use a higher battery voltage, the motor will reach the cut-off rpm at a partial throttle. The position of the partial throttle depends on the battery voltage.

Some comments:
A) It is a good feature to have an cut-off frequency ( cut-off rpm) so that the legal maximum assisted only speed does not exceed the legal speed limit.
But it should be selectable by the end-users because the end users could have motors of various pole-pairs and gear ratios.

B) At rpm near the cut-off rpm, the controller should not behave abnormally to cause any damage to the motor and/or to the controller itself. The controller should reduce the power gradually when the motor approaches the cut-off rpm and cut-off the power when it exceeds.

C) It seems that this controller does NOT fully satisfy (A) and (B).

Some further math:

For 5305 motor with a wheel diameter of 20 in
No of pole-pairs = 12
If the cut-off frequency = 325Hz
Then the cut-off rpm = 325 X 60 /12 = 1625 rpm
Hence the cut-off speed = 1625 X (3.1416 X 20X25.4 /1000)x 60/1000 = 156 km/h

For a speed of 50 km/h, the output frequency is only 104 Hz at 520 rpm at the wheel.
This controller will not cause any problem for direct drive hub motors like 5XXX and 4XXX.

But it wiil be a different story for geared hub motors like Puma.
The Puma motor will be cut-off at an speed of 23 km/h with a wheel diameter of 20 in at wheel speed of 240 rpm.
Fechter -[For the Puma, this works out to about 1200 rpm on the rotor. Gear ratio from rotor to hub is about 5:1 as I recall. That would make 240 rpm on the wheel]

On a 20" wheel it should still run about 20 mph (Pi* 20=63 inches*240=15120"/12=1260'/60=21mph or 29.5kph. Not bad for an old guy on a trike, but not suitable for young speed demons! Of course my math could be wrong! I did see the 23 kph above.
other Doc