INFINEON CONTROLLERS FOR DUMMIES

[Almasi]

So that signal work or doesn't work with CycleAnalyst?

Does the noise is always the same...even with lower or higher battery voltage?

 

[philf]

So that signal work or doesn't work with CycleAnalyst?

OK... I would appear to have mis-spoken. The trusty counter I was using to count the pulses per wheel rotation is the thing with the noise problem. Dunno what happened to it all of a sudden, but it's giving me garbage with a known-good setup.

I was able to deduce what is happening by other means, though. I would seem the Infineon is sending out a pulse with EACH STEP of the commutation process. Instead of getting the expected 23 pulses per rotation, I'm seeing SIX TIMES that. I have two problems with this - firstly that the Cycle Analyst can't handle the high count (it'll be 138 for my wheel, and the CA can take 99 max). The only way to "fool it" would be to put in a number like, say, 92 (four times the desired number) and then drop the wheel circumference to fake out the speed and distance. Messy.

The other worry I have is that the signal may be as unreliable as the original (Shenzhen) controller I modified to add the speed function to in the first place. When I looked at only ONE hall sensor, a huge issue arose when the motor was stalled, juddering under load, or even sitting at "rest" at just the right place in its rotation. You wound up getting an artificial train of pulses - indicating speed - without there actually being any forward motion. That's what prompted me to put a circuit in place which guaranteed that the wheel had to move through a minimum of two commutation steps to register a pulse.

I'm not SURE that this is what the Infineon is doing - the signal appears to come from the MCU (via the programming header). I'm hoping that the firmware looks after the situation I'm describing - but, still, it's driving out way too many pulses to be useful without the fake-out. Sure would be nice to get ahold of the code in that sucker .

 

[geoff57]

OK... I would appear to have mis-spoken. The trusty counter I was using to count the pulses per wheel rotation is the thing with the noise problem. Dunno what happened to it all of a sudden, but it's giving me garbage with a known-good setup.

I was able to deduce what is happening by other means, though. I would seem the Infineon is sending out a pulse with EACH STEP of the commutation process. Instead of getting the expected 23 pulses per rotation, I'm seeing SIX TIMES that. I have two problems with this - firstly that the Cycle Analyst can't handle the high count (it'll be 138 for my wheel, and the CA can take 99 max). The only way to "fool it" would be to put in a number like, say, 92 (four times the desired number) and then drop the wheel circumference to fake out the speed and distance. Messy.

The other worry I have is that the signal may be as unreliable as the original (Shenzhen) controller I modified to add the speed function to in the first place. When I looked at only ONE hall sensor, a huge issue arose when the motor was stalled, juddering under load, or even sitting at "rest" at just the right place in its rotation. You wound up getting an artificial train of pulses - indicating speed - without there actually being any forward motion. That's what prompted me to put a circuit in place which guaranteed that the wheel had to move through a minimum of two commutation steps to register a pulse.

I'm not SURE that this is what the Infineon is doing - the signal appears to come from the MCU (via the programming header). I'm hoping that the firmware looks after the situation I'm describing - but, still, it's driving out way too many pulses to be useful without the fake-out. Sure would be nice to get ahold of the code in that sucker .

hi
what motor are you using?
I tried simmilar with a puma and got some realy daft results out, have a look at what doctorbass put herehttp://endless-sphere.com/forums/viewtopic.php?f=6&t=6629&p=134504#p134100 think iI willtake his advise and contact justin
Geoff

 

[philf]

what motor are you using?
I tried simmilar with a puma and got some realy daft results out, have a look at what doctorbass put herehttp://endless-sphere.com/forums/viewtopic.php?f=6&t=6629&p=134504#p134100 think iI willtake his advise and contact justin
Geoff

The test was with a bike (that's inside in the warm ) with a Golden on it. I would get the same count from my Crystalyte, too - my own speedometer setup works fine with both (at 23 pulses per rotation). I've been playing with Justin's latest beta software - asking him to increase the count COULD be done. I think, as a programmer and knowing how much is happening inside the CA, that handling the bigger number might not be the ideal solution. Each pulse of the speed line generates an interrupt to the MCU, which is how it counts 'em without missing any. If all the ISR is doing is "counting", this is no biggie in terms of timing. But if it's holding the count or performing any math, this could be a big hit.

Will check with him, as you suggest (he's extremely busy just now, working on some good stuff ). This is definitely not the hardware issue that is described in the above link, though. That's all about using a magnetic reed switch as a speed input, and is addressing contact bounce of that mechanical switch.

In the meantime, when I get a chance (my "day job" is keeping me busy), I'll throw a one-chip divider in there. Even a simple flip-flop doing a divide-by-two will get the number down to where the CA can handle it. WIll post findings surrounding the result, and whether the potential commutation error I described in an earlier post exists in the Infineon. My gut says it doesn't - the signal is being generated by the MCU. That's the only way I can figure you'd get 138 pulses. If the signal was raw, I'd expect the number to be 1/3 of that.

 

[geoff57]

hi
if you have a scope put that over the blue wire and see what is coming out.

Geoff

 

[fechter]

It wouldn't be too hard to do some kind of divider, but it would be nice to avoid.
It might be easier to build a buffer for one of the hall signals.

Yes, having the full program code would be fun.

 

[Knuckles]

What would be the diode you would use shown in the pic?

The shottky is in series at V+(in). So it looks like a protection diode in case of revers polarity.
May be a blocking series-shottky at V+(out) should de recommended as well, preventing harmful back current, when the Recom is powered down.
Georg

First ... Thanks to K__4 for the "heads up" on the RECOM part. This has great potential.
http://endless-sphere.com/forums/viewtopic.php?f=2&t=8457&start=60#p132993
I am trying to get my hands on one now for testing on an Infineon pcb.

Second ... The shottky diode would be placed at that location simply because the "slot" would be open.
I figured ... heck ... what cheap (useful) part could be put in that space. It may not even be needed but it can't hurt.

My idea is to make the simplest "Any Voltage" mod possible by eliminating ALL resistors and ...
By using the three available slots for other (off-the-shelf) parts that fit super easy.

Also, if I am correct, this would allow plenty of spare power for a 12V ebike lighting system and/or other peripherals (like cooling fans).

-K

 

[philf]

OK. I couldn't stand it. Took an hour out to do an experiment on this speed logic issue...

It looks like my original assertion is correct - that blue wire is delivering 138 pulses per wheel rotation. I thought I'd throw together a quick divide-by-6 circuit, but was stunned to find that my junk box doesn't have a single appropriate counter chip in it, and I wanted to do this with ONE chip. I was *sure* I had a half dozen 74HCT92's in there somewhere, but couldn't find 'em. So I had to settle for divide-by-2. I just used a 74LS74 (I don't have a 74HCT74 handy, but as this was just an experiment and would only take a few minute to try, I went for it).

This ugly "chip on a stick" was stuck in a piece of heatshrink tubing before mounting...

For anybody paying too much attention, that decoupling cap really does go between pin 7 and pin 1. Pin 1 happens to be tied to its neighbour across the street (pin 14) underneath, which is VCC.

To do this right, one should feed the signal from the MCU into the divider, and the output of the divider (through a resistor) into the base of the transistor that's already on the circuit board. You get a nice open-collector (with pull-up) signal this way, rather than feeding a raw TTL signal to the outside world - but, again, just an experiment.

So, I hooked this in to one of the Infineons, set the CA for 69 poles per revolution, and tested it out...

Perfect. Reads the same as one of my other controllers that (correctly) reads out 23 pulses per rev. So there's the rub... Something else to ask Keywin if he has any control over.

I'm not going to do any further testing on the accuracy of the signal (false positives) - if I'm going to have to mount an additional package in the controller to get what I want, then I'm going to add one that I've tested and is bulletproof. In fact, I think I'll make a up a proper PCB for it - the ones I have in the Shenzhens are hand wired on perf board. I dunno if I lost everybody on why I don't like using just ONE hall signal as a speed indicator. Might be time for a YouTube video so I can demonstrate the issue...

 

[Knuckles]

"chip on a stick"

DUDE! You get the "FRIED GUINEA SPLIFF" Award!

 

[philf]

I love that picture :lol:

I thought I'd post the circuit for what I had INTENDED to put together, in case anyone else wants to do this. Using a 74LS92 (yes, LS - I was stunned to find that other flavours have pretty much become unavailable - I'll say something more about that in a minute), you can get a divide-by-6 with one chip.

If you imagine wiring this directly to the pins, as I showed in the previous post, and that the pads in the diagram are just flying leads that you solder to the controller board... you get the picture.

Anyways, what bugs me about using "LS" parts in this application is that they're really more suited to life inside a computer than in a piece of moving (outdoor) equipment. They don't like sub-zero temperatures, use a bit more power than their newer counterparts, and are pickier about what you feed them (in this case, not a worry - the power supply we're tapping is the output of a 7805 regulator already on the controller board, and in this application it isn't like we're decoding a signal in MHz ranges).

There is a CMOS chip which might be a better candidate (just did a quick Google, and I believe the one I'm thinking of is the CD4018). CMOS won't drive the signal directly into the CA as well as a regular 74 series chip, but if you're just feeding the transistor already on the board, then super! If anybody is really keen on *any* of this, I'd be happy to post a more explicit diagram...

 

[Knuckles]

I Propose that Endless Sphere DESIGN our controllers!

I'm IN!

 

[Almasi]

I Propose that Endless Sphere DESIGN our controllers!

I'm IN!

X2

It look like we have better engineer here than in China...and we are just people having fun with their Ebike

 

[solarbbq2003]

might be of interest just general info on recom dcdc converters
http://www.recom-international.com/press/DC/DC-Converter-Modules.html
seems recom have some manufacturing in china will check into that side first knuckles might be able to get cheaper than from australia

 

[geoff57]

To do this right, one should feed the signal from the MCU into the divider, and the output of the divider (through a resistor) into the base of the transistor that's already on the circuit board. You get a nice open-collector (with pull-up) signal this way, rather than feeding a raw TTL signal to the outside world - but, again, just an experiment.

So, I hooked this in to one of the Infineons, set the CA for 69 poles per revolution, and tested it out...

Perfect. Reads the same as one of my other controllers that (correctly) reads out 23 pulses per rev. So there's the rub... Something else to ask Keywin if he has any control over.

I'm not going to do any further testing on the accuracy of the signal (false positives) - if I'm going to have to mount an additional package in the controller to get what I want, then I'm going to add one that I've tested and is bulletproof. In fact, I think I'll make a up a proper PCB for it - the ones I have in the Shenzhens are hand wired on perf board. I dunno if I lost everybody on why I don't like using just ONE hall signal as a speed indicator. Might be time for a YouTube video so I can demonstrate the issue...

hi
great results the reson why not to use a haal sensor for speed on a motor with a freewheel is when the motor stops spinning the wheel carrys on but the speed reads zero
bafang had a go at fitting a fourth hall sensor in the motor that pulsed 5 times per rotation required one extra wire out with the halls, for some reson they droped this i saw only 2 rear 26" models.

Geoff

 

[philf]

great results the reson why not to use a haal sensor for speed on a motor with a freewheel is when the motor stops spinning the wheel carrys on but the speed reads zero
bafang had a go at fitting a fourth hall sensor in the motor that pulsed 5 times per rotation required one extra wire out with the halls, for some reson they droped this i saw only 2 rear 26" models.

Geoff

There's always a challenge .

I thought about my my "fool proof" speed sensor boards, and (a little insomnia last night) committed them to a circuit board design. I actually got it onto a single-sided board, while still using SMDs! That's usually a challenge, because you can't route signals between the pins of the chips, making things a lot more challenging. (You should have seen what the Eagle auto-router came up with... It was HILARIOUS and could only do half the job).

The actual board is .9" x 1.4" in size, and I've added diagnostic LEDs to the thing. Red LED's light to show each phase of commutation, and a green LED blinks out the actual speed indicator pulse. The thing actually could be a useful tool for helping determine phasing in unknown situations. Alas, this is still only useful for setups that use Halls that are active as long as the wheel is spinning. I dunno if someone who has more experience with the analog parts of the controller might have some ideas on how I might use either back EMF, or some other indicator of motion, to drive a similar circuit - for those who run sensorless.

I can't think of a solution for the freewheeling crowd . Other'n the ol' magnet and reed switch solution. I think I'd be inclined to epoxy two small magnets to the motor casing (opposite each other for balance), and mount the switch on a small boom mounted inside the fork, rather than use one of those spoke magnets - which I've lost many of back in the days of primitive bike computers.

I'm thinking the only thing to do with a motor that freewheels

 

[geoff57]

[
I dunno if someone who has more experience with the analog parts of the controller might have some ideas on how I might use either back EMF, or some other indicator of motion, to drive a similar circuit - for those who run sensorless.

I can't think of a solution for the freewheeling crowd . Other'n the ol' magnet and reed switch solution. I think I'd be inclined to epoxy two small magnets to the motor casing (opposite each other for balance), and mount the switch on a small boom mounted inside the fork, rather than use one of those spoke magnets - which I've lost many of back in the days of primitive bike computers.

I'm thinking the only thing to do with a motor that freewheels

hi
for the back EMF we have to look at the R/C gang I mesure my pumas rpm using a feature of a R/C meter that mesures back EMF the power analiser pro up to 60v the power goes through it over that I disconnect the power from the setup and just have the GND wire linked and the sensor wire to a phase wire all my test data comes from this and is acurate all we need is to find out how it is done there must be information around somewhere.

the idea of fixing a magnet/s to the case of the motor and a a sensor to the fork instead of on a spoke, I agree I never fit to a spoke unless I have to, my wifes trike had her magnets glued to the case of the motor, I have attached to a disk brake rotor before.
bafang just used a hall sensor on the inside of the motor as this would not need to be checked it was still inline after a wheel removal.

Geoff

 

[John in CR]

Here's a 15 FET controller that comes with some motors I have. It has the XC846MCU and looks a lot like the boards you've been talking about here. Unfortunately the maker sanded the FETs, so I don't know what they are. It's supposed to be a 60V controller with 50V cutoff and 73V limit. I've been using it without issue, other than heat, in the recommended voltage range, but I'd like to be free of the restrictions and try some of the stuff you guys have unlocked.

I'd like to try some of the stuff you guys are doing, but this stuff is mostly greek to me. Specifically I'd like to figure out if there's a reverse switch, and regen braking. There's already a wire going to BK from the outside, which I'm told takes a 12V input as the signal for the electronic brake cutoff of the controller. There's the unused EBS pin, which to me would seem natural to be for electronic/regen braking. There is no DX3 pin, but others might be a reverse. How to do go about trying these things? Is it ok to carefully hook an open controller to a motor and try jumpering some of these to ground and see what happens?

Does it look like the same resistor/transistor mod would work for this controller too?

John

 

[John in CR]

Here's a closer shot showing the available pins that I found interesting to try, like AUX, XC, EBS, etc.

John

 

[methods]

Ok, I have rummaged around all the Infineon controller threads but I seem to never find a link to the software.
Come on guys. . . Spill the beans!

I have an RS232 to 3.3V converter. Think I can get away with that or should I dig deeper and find a RS232 - 5V converter?

I am getting impatient By dark I will probably have the soldering iron out in haste.

-methods

 

[philf]

Ok, I have rummaged around all the Infineon controller threads but I seem to never find a link to the software.
Come on guys. . . Spill the beans!

-methods

Yup - that's one of the problems I have with most modern "forum" software (I have a long history with this stuff, going back to the pre-(public)internet days of the BBS. The software you can get - free, or otherwise - is feature-rich, but none-the-less still based on the unimaginative shit-list of "expected" functionality of yesteryear).

Here's what you're looking for...

http://www.endless-sphere.com/forums/viewtopic.php?f=16&t=7361#p110931

 

[methods]

I missed that entire thread :?

Thanks Philf!

I got that little weenie controller today.
48V 15A small as a turd.

Took me 20 minutes to hack all those wires out and set it up for the CA.
Will post some pictures someplace later.

thanks,
-methods


EDIT: I know why I never found it, because it was moved to the "technical reference area".

 

[Knuckles]

Here's a 15 FET controller that comes with some motors I have. It has the XC846MCU and looks a lot like the boards you've been talking about here. Unfortunately the maker sanded the FETs, so I don't know what they are. It's supposed to be a 60V controller with 50V cutoff and 73V limit. I've been using it without issue, other than heat, in the recommended voltage range, but I'd like to be free of the restrictions and try some of the stuff you guys have unlocked.

I'd like to try some of the stuff you guys are doing, but this stuff is mostly greek to me. Specifically I'd like to figure out if there's a reverse switch, and regen braking. There's already a wire going to BK from the outside, which I'm told takes a 12V input as the signal for the electronic brake cutoff of the controller. There's the unused EBS pin, which to me would seem natural to be for electronic/regen braking. There is no DX3 pin, but others might be a reverse. How to do go about trying these things? Is it ok to carefully hook an open controller to a motor and try jumpering some of these to ground and see what happens?

Does it look like the same resistor/transistor mod would work for this controller too?

John

This 15-fet pcb is fascinating! It is clearly a xie-change Infineon pcb.
(AND sanding off the fet markings ... Oh So Chinese! )
It may be an older Infineon design long since abandoned OR something with benefits we don't yet understand!

John ... So VERY COOL! Hmmm ....

 

[philf]

That absolutely looks like a candidate for ALL of the stuff we're talking about here, John - right down to the programming header - which has the same pinout as the other units we're discussing.

How big are those caps, BTW? 470uF? 100V? Seems common for the "regular" voltage controllers to have a single 1000uF 63V on the power input, where the units intended for higher voltage come with two 470uF 100V units in parallel (100V 1000uF caps that will fit inside the case aren't common). Yours looks like the latter.

There could be multiple reasons for sanding off the part numbers on the FETs... If you had a board that was designed for 4110's or 4310's, but decided to populate the thing with a lesser (cheaper) part - perhaps because supply was short - you might sand the part numbers off, too - a bit shady, but this stuff happens. If you were concerned about keeping secrets, you'd be more inclined to take the numbers off the MCU - that would make the board MUCH harder to figure out.

How severely are those transistors sanded, BTW? I *have* seen someone sand a transistor case to remove enough plastic to improve heat dissipation to the air - can't believe that makes a huge difference when the thing is on a heat sink.

Forgive me if someone else has already confirmed this (and I just missed it), but from what I've been able to glean from trying to read Google-translated Chinese, I'm fairly certain that ANY of the Infineon boards are built around a single programming spec. I'm thinking that these Infineons are supplied pre-programmed, and the board makers work around the MCU as a full featured part, rather than design a controller with a particular MCU in it, and then write software for it accordingly. Some of the functions provided on these boards seem overkill for an e-bike, but wouldn't be in a larger/different EV.

The possibility/probability of this crossed my mind as I've been working with a similar "packaged processor solution" on another project. The heart of that project is an NXP MCU that comes pre-programmed with certain firmware (which includes some licensed code from other sources). To integrate the chip into a design, you're not just concerning yourself with the electrical design, but with how the overall unit behaves. In fact, you throw out the raw pin names for the MCU, and refer to them by their programmed function.

This would explain why there appear to be so many flavours of these controllers, but nobody knows the finer details of what the code is doing - the chips came pre-programmed. Dunno if Knuckles has had the conversation with Keywin - but I'd be surprised if Keywin has the actual source code for these things...

All this kinda makes me want to go back and have a much closer look at the new Golden controller (they took the part number off the MCU).

I don't have them handy, but there are software features in that controller that can be activated by doing silly input operations (things like holding the e-brake and twisting the throttle four times while rubbing your belly and tapping your left foot). One of those operations makes the controller run without the Halls! Others activate anti-theft features.

Hmmm...

I'd definitetly be giving that programming header a whirl, though, John .

 

[Knuckles]

I'm fairly certain that ANY of the Infineon boards are built around a single programming spec.

I agree.

I'd definitely be giving that programming header a whirl, though, John .

Not gonna happen (unless John can do a software "flash" with an oxy-acetylene torch).
John not like compuutr's. He like ... metal stuff.
(Stuff he can bang with hammer)

 

[The Stig]

Actually, Philf that controller switches to sensorless mode automatically! as soon as you unplug the hall sensors!
It can also calibrate for different phase angles and to get it to do that you have to do all sorts funny hand twisting, brake pulling inputs.