• Hello ES! We could use some help to get us past the finish line on building the new knowledgebase for the forum.
    Can you donate? Please see our fundraising page. Thank you!

Building the Best Controller

Kingfish said:
It’s been a week since the last summary.
  • Briefly we discussed that Copper plating up to 3 oz. is reasonable. The FET board design will determine the choice of plate, whilst the MPS and MCU will likely be one-ounce.
  • Also we discussed the Alarm signal from the Power Switch which is pulled high on contact, affecting an interrupt on the MCU. I believe this circuit to be straight-up and having no conflicts.
The leading however issues require input to drive them to closure. I hesitate by fiat to lock these items down without overt opinion. Leadership being elective – I throw this list back out into the stream and fish for commitment.

  • Don’t be a lurker; Vote on the open issues: Do you agree we should lock the items in question? :)

The Editor doesn’t have a strikeout tag, therefore I’ve appended small comments based upon what has been discovered.

- from the Thread Summation Wed 2010-09-22

MPS:
  • Max Volts: 150V. I believe we are close to agreement; unless there is major dissention by rank and file I say let’s lock this down.
  • Circuits: No comments in the past week therefore are we in alignment? Can we lock this?
  • Alarm: This circuit is tbd; essentially we pick up a +V signal from the Main Switch indicating that we are in an Alarm State, and this is passed onto the MCU and/or other auxiliary devices. The voltage will be the same as the ON/OFF switch. Would anyone like to comment? Is this implied? Or shall we just lock this down? [KF: I don’t see this as an issue]
  • Architecture:
    • The conversation is leaning towards a two-tier regulation design with pre-regulator required for higher voltages, with primary regulation is accomplished by switching.
    • Secondary regulation for Aux Circuits is leaning toward switching as well to reduce the heat.
    • We expect this will cost a little more.
    • Will the circuit design allow the PCB to suffice with 1-oz Copper plate? [KF: Presume yes]
    • I presume the only real worry is heat dissipation: Would any of these switching regulators require heat sink?
With regards to the MPS, are there any other outstanding issues which would prevent us from moving to design, breadboard, and testing?

FET:
  • Number of FETs: Qty-12. For Version 1, we are centering on a 12-FET design with options on expansion. Can we lock this?
  • FET Package: TO-247 is favored.
  • PCB Copper Plate:
    • Presumed to be > 1 oz. [KF: Presume yes]
    • What is the cost-ratio of higher plate? [KF: Bidding process should keep this cost in check; expect plating to be 2-3 oz.]
    • There is an implied agreement to get away from Bus Bars/copper-wire.
    • Higher current-rated boards >150 A should be differentiated, and not included in Version 1. Is this correct?
    • Do we need to worry about high-frequency shielding?
Click to expand...

Repeating, for Version 1, do you agree:
  • MPS
    • Max Volts = 150V
    • Aux Circuits as planned
    • Alarm Signal to Main ON/OFF Switch (it’s use is optional, and the default state is OFF)
    FET
    • Limit Number of FETs = 12
    • High-Current boards should NOT be included in Version 1

I hesitate to introduce new talking points until this dust is settled. Can we get through this please? :)
Thank you, KF
Click to expand...

Bump. Come on people - give us an opinion :)

Or, are you leaving it completely for me to drive? :twisted:
~KF
 
I 'm happy now.
I agree with everything from the Thread Summation Wed 2010-09-22
As previously stated I prefer a one ounce 12 FET board for practical purposes.
I also prefer a design with no linear voltage regulators (or dropping resistors :shock: ), no need for extra heat to be produced on the control pcb.
 
rhitee05 said:
The TO-247s still share the same 75A leg current limit as the -220 packages, but have better thermal properties and some parts have larger dies and lower Rdson. So a 12-FET using TO-247s would still have the same ultimate limit of ~150A, but the heat is easier to manage so you stand a better chance of being able to achieve the current in real life.
Click to expand...

Incorrect. TO-247 leads are rated between ~150A and 195A. So phase currents can reach up to 390A for a 12 FET controller using this package.

For the best performing International Rectifier made 150V TO-247 FET, silicon limited current reaches 171A per FET
http://www.irf.com/product-info/datasheets/data/irfp4568pbf.pdf

However,

For the 100V version in the same family, the full 195A lead limit can be reached
http://www.irf.com/product-info/datasheets/data/irfp4468pbf.pdf
 
We are moving too slow on this thread. I have asked for the Community to weigh in several times in the last 17 days on important decisions. Perhaps a more overt hand is required to drive this forward.

Let’s kick-start this machine and get’er done!

MPS
  • Max-Volts: Locking at 150V.
  • Circuits: Locking.
  • Alarm: It’s just an optional single trace to the Keyswitch. Locking.
  • Copper Plate: The actual circuit layout will drive this – though presume one ounce.
We are done. Let’s move forward with a schematic and breadboard please.

FET
  • Number of FETs: 12. Locking.
  • FET Package: TO-247 is favored; personally I’d like to have both packages available on the PCB for greatest flexibility. Let’s see how this plays out.
  • PCB Copper Plate: Ultimately the layout will decide, though presume > 1 ounce.
Open Issues
FET High Current: Where to draw the line? Should we define a matrix as ≤ 75V, 100V, 150V vs. ≤ 50A, 100A, 150A? I am happy to work up a chart for a BOM if someone will provide the data :)

MCU
Let’s start nailing this feature set down.
VOTE/Comment:
  • One MCU to drive One Motor, or
  • One Master MCU to drive more than One Slave, or
  • One MCU that does it all (up to 4 channels)?
  • and...What is your MCU device of choice?

Yielding the Floor on FET and MCU. Jump in; let's go! :)

Thank you, KF
 
Seems like the next step on the FETS is to choose the candidate devices and thin that out to a small set. Those ultimately drive the voltage and current specs available. (the requirements guide the selection but don't determine the final specs). Choose one or more devices and derive the actual specifications/levels from that.

On CPU I would suggest Amel AVR since the best open source tools are available for them - GCC-AVR, which is good for collaboration as folks don't have to buy expensive compilers to work on it. One CPU focussed on the motor controls - best for handling hall inputs and motor commutation and PWM and provide the highest commutation rates which will be needed for some motors. Also plenty of processing power per motor will be good for sensorless and timing advance on sensored motor algorithms later on. Allow plenty of room for software to grow. Another master CPU for the rest of the feature set. Stacking motors adds motor CPUs which is the right expansion model.
 
Alan B said:
Seems like the next step on the FETS is to choose the candidate devices and thin that out to a small set. Those ultimately drive the voltage and current specs available. (the requirements guide the selection but don't determine the final specs). Choose one or more devices and derive the actual specifications/levels from that.

On CPU I would suggest Amel AVR since the best open source tools are available for them - GCC-AVR, which is good for collaboration as folks don't have to buy expensive compilers to work on it. One CPU focussed on the motor controls - best for handling hall inputs and motor commutation and PWM and provide the highest commutation rates which will be needed for some motors. Also plenty of processing power per motor will be good for sensorless and timing advance on sensored motor algorithms later on. Allow plenty of room for software to grow. Another master CPU for the rest of the feature set. Stacking motors adds motor CPUs which is the right expansion model.
Click to expand...

Alan, can you send a link to the CPU docs please; I'm keen to learn what compilers we'll need :)
Thanks, KF
 
Alan B said:
The major resource for AVR tools, information and help is http://www.avrfreaks.net

The GCC-AVR toolchain info is http://www.avrfreaks.net/AVRGCC

Atmel's pages on AVR parts: http://www.atmel.com/products/AVR
Click to expand...

Alan we're you thinking of the 8-bit megaAVR?

Description:
"The megaAVR family offers the widest selection of devices in terms of memories, pin counts and peripherals. From general-purpose devices to devices with specialized peripherals—such as USB, or LCD controllers, or CAN, LIN and Power Stage Controllers—it is easy to find the perfect fit for your project in the megaAVR product family."
~KF
 
8 bits should be enough for this application. The motor controller might not need to be a mega part, if a separate CPU is used for each motor. I would suggest a mega for the central overall CPU as they have the most expansion capability. I generally go by the features of the CPU more than the adjectives. Pretty much all those parts use the same toolchain, I would stay away from some of the really small ones or odd ones that are not well supported by GCC-AVR. No sense in making the job harder.
 
Fascinating! 8)

For conjecture, let’s say we have the Mega as the central CPU: Would this be enough for one wheel?

Or would we need an additional unit like the 8-bit tinyAVR as the dedicated Wheel CPU for each?

I’m just trying to image what would fit on the MCU board where the goal is 1- and 2WD, and what the configuration would be for expansion. :)

Best, KF
 
I would use a CPU like an ATTiny for each motor, even the first. Then software on the main central processor would not mess up some critical motor timing. The motor CPU is HARD REAL TIME, should NEVER miss a control input/output. The main CPU is soft real time, it does not have to make a critical update EVERY time, it can be occasionally late without blowing FETs, etc.

This main processor could drive remote displays, do CA type functions, collect data for readout later, manage higher level issues like limiting speed, average current, power, etc. Hundreds of hz type rates. The motor CPU needs to have right-on timing at tens to hundreds of Kilohertz type rates. Keep it focussed on that one task.

One thing is also to keep development isolated and parallelizable and testable. Adding new features to the main processor should not require re-testing the motor control timing. If they share the same CPU testing is going to be much harder and the risk of a change causing serious issues in hardware will be greater.
 
I pretty much agree with Alan on the benefits of using a dedicated motor control MCU, because we eventually want more from this controller than just the basic and already existing ebike features we have now. I do however think that would be possible to do most if not all the features we want using just one powerfull specialised motor-control MCU (like the ATmega64A maybe) and by taking much care with the program flow (using interrupt priority and such)... but it would be simpler to implement (specially as a group effort) and be more robust to have a dedicated motor control MCU. However, a two MCU design would be a few bucks more (not a problem really considering the target niche), have more circuit complexity and size, at would take more work to get an initial functionnal prototype up and running.

Maybe we could do both in a certain way, as to avoid the two MCU approache's problems listed above? My suggestion would be to initially design and use only the motor control MCU PCB, and to implement only the most basic firmware to do motor control and basic input functions to start off. We could provide some tests points on the PCB for the temporary I/O necessary for these tasks (hall throttle A/D, etc). This initial motor control PCB would also be made to be ready to physicaly connect to the eventual 2nd MCU processor and I/O PCB. This way we can also start testing and making revisions to the FET and driver PCB faster. Heck, maybe some people would opt to just use the basic functionnalities provided by the single motor control board, and might only upgrade latter if desired/required?

I just checked out the AVR's and some of them do look quite nice for the motor control MCU, but I'm going to read them a bit to compare:
AT90PWM3B (or similar) (this one looks ultra-specialised for a possibly great dedicated motor control MCU)
ATmega88PA (or 48A, etc.) (might not be good for future sensorless version if this is a desired feature?)
ATmega64A (but lots of I/O and flash memory, overkill for an eventual two MCU controller)

I advise against using an MCU that does not have a specialised three PWM phase motor peripheral, which I think the tinyAVR's don't have?

I could somewhat contribute to firmware code creation because I already use a similar MCU to these AVR ones, Microchip's PIC18F4431. Of course if we would use the 18F4431 itself (or a smaller variant) I could contribute more since I already know how to set up and use the PIC's motor-control PWM peripheral and such. However I have to use a pirate C compiler for the PIC, which might not be great for group work. :( There might also be other negative (and positive) comparison points between the AVR's and the PIC, a better study of the datasheets will be necessary.

Pat
 
Working backwards.
I have some experience with PICs, though not motor control (unless you count turning them on and off :) ), but am limited to pic basic pro or pirated c.
Free compilers and other tools would be a major reason for using AVRs, (if they're any good, I haven't taken the time to check them out).

I agree that the processor on the FET board should have a dedicated motor module, although once you separate them, that's easier to upgrade in alternate versions.
As to economy and complexity, by using smaller chips dedicated to their functions (fast with minimal mem for the motor, and slow, low power, and with lots of memory for the master), we could keep the cost and power consumption down near where one large fast complex chip would be. Overall, it would be very little more complex, and since the complexity is distributed between boards, the PC design should be easier.
Does the FET board design team object to a processor on their board?

As to software, multiprocessors almost have to make that part easier (and faster to develop).
Also, as previously mentioned, helps keep people like me from causing hardware damage with ill conceived mods to the main SW. Half the idea is to make it easy for people to make their own unique build, both hardware and software, isn't it?

I pretty much agree with Allan B on all points except as noted.

What I DON'T understand, is why there's not more activity on this thread. This should be exciting to ALL of us (at least all one percent of us).
Bob
 
Kingfish said:
MPS
  • Max-Volts: Locking at 150V.
  • Circuits: Locking.
  • Alarm: It’s just an optional single trace to the Keyswitch. Locking.
  • Copper Plate: The actual circuit layout will drive this – though presume one ounce.
We are done. Let’s move forward with a schematic and breadboard please.
Click to expand...

The 150Vmax spec is only possible if we keep our current requirements low and/or succeed in making a functionnal switching-type pre-regulator circuit (as Eric said he might succeed at a while back - have you managed to test that, Eric?). If the LM2575 is used as the primary PWM regulator and only a linear-type pre-regulator is used, then I can't see going over 100V and also sticking with a lowish current draw spec (meaning no aux output rated at 2A+ and such extras). Maybe we should "lock" this spec as 100V/~150V depending on our pre-regulator design success?

One ounce is more than enough for the low current requirements of the power supply.

Now just what schematic/PCB editor are we going to use anyways? I used to use a open source PCB layout editor named freePCB a couple years ago, but dropped it to learn and use Altium Designer instead (pirated again like the C compiler, by necessity!) because it lacked one or two features I wanted back then. It does not do schematics though, and I have no idea either if there's better open source PCB tools out there?

Pat
 
Rather than give up the 150v option, I would give up acc power, or even accept series resistors like the infineons.
Has anyone tried 100-240v LCD supplies for their 12v accessories buss? I just hooked up a 12/5v disk supply rated at 2a ea to some sla batteries that I have setting here. The LED didn't come on at 36v, but did at 48. I was holding wires to connections, and didn't have enough hands to measure any voltages under load. No load the voltage measured 12.07 and 5.40, exactly the same as when connected to 120 I hooked it to an OLD hard disk, which didn't spin, but did when it was hooked to 120........ I'll get some Idea of it's voltage and current abilities at different voltage in, and also try some of the LCD supplies I have around here. This approach would be fine for me, at least for the non controller related supplies (probably derated to 1/2 or 1/4 of 120v current).
Have others tried this approach and rejected it?

Getting ahead of the project again, I would suggest that the software be 'modular' as well. So I can use subroutines (plugins?) written separately by Tom, Dick, and Harry, and still have some hope of their compiling and working together, as long as they had been tested and accepted by the appropriate team. Which brings up a couple more questions, but I guess I won't push it. :)

Bob
 
Question about the FET board.
Will we be able to use the 12 FET board with 6 FETs? Perhaps with some strategic trace cutting?
As far as using TO220 with a board designed for TO247, I would think large pads with a second set of holes near the inside edges of the outer pads would be fine. If others didn't object, the center lead could be staggered, allowing for larger pads all around. I too would like the option of using TO220 for lower current applications.
Bob
 
Is there enough cost difference between TO247 and TO220 in the target FETs to bother supporting both? (Just a question, I have not researched that).

I would think 6 FETs would be possible by leaving out every other one. The paralleled FETs should be adjacent for thermal equalization. But the board would not get smaller and the cost savings is probably small.
 
Alan B said:
Is there enough cost difference between TO247 and TO220 in the target FETs to bother supporting both? (Just a question, I have not researched that).

I would think 6 FETs would be possible by leaving out every other one. The paralleled FETs should be adjacent for thermal equalization. But the board would not get smaller and the cost savings is probably small.
Click to expand...


360nC to 715nC is about the range to expect for the TO-247 packages worth using

http://www.irf.com/product-info/datasheets/data/irfp4468pbf.pdf

http://ixdev.ixys.com/DataSheet/DS100181(IXFK-FX360N15T2).pdf



The common TO-220 packages (like the 4110) are around 150-200nC

http://www.irf.com/product-info/datasheets/data/irfb4110pbf.pdf
 
I buy the 4468's for $3 (minium lots of 50)

That beautiful (did you notice the Pd on that? Grrrreat!) IXYS 150v 360amp fet is a spendy bugger. $15/each in lots of 50minimum.


Remember, Digi-rip sells the 4110's for $4.80, and I was able to source them mfg direct for $1.60.

As long as we need at least 50 (one strip, and the lowest quantity they will work with), then I can generally do about 1/3rd of digikey's prices on IR parts, and roughly 2/3rd-1/2 price on IXYS parts (which tend to be the most spendy of anything out there, but also the best).
 
Not to mention a dozen of them! :twisted:
Wonder how cheap we could find them on a group buy?
I admit I'm out of my depth just TALKING about the FET board (I wouldn't want to try and design the drivers for those monsters), but couldn't a driver designed for the big fets handle the TO220s? Just over kill, or is there something I'm missing? Of course a separate TO220 board could be designed later on if there's demand.
I see liveforphysics answered the first part of my question. And I suspect the second just shows off my ignorance. :)
 
The Pd and Rth on that 150v IXYS fet are soooo sexy. :)

A 6-fet from that bugger would be capable of higher continuous current than a 24fet made from the IRF4115. :)


Too bad 150v simply doesn't make sense to use for our application, because it would be a screaming good FET if it did.

This one that I posted about on ES a year before IXYS formally released it is actually the best ebike FET i've ever seen anywhere at any price. Just last week IXYS finally formally announced it exists even! lol


http://www.powerpulse.net/story.php?storyID=22975

6 months ago or so, I got pricing for $11/each, but they wouldn't move for any quanity under 1,000 pieces. I told them that was fine, lets make it happen, and the deal fell apart when they talked to their pre-existing Microsquash rep and somehow found out that I was buying them for my own personal interests rather than for MS. They wouldn't accept my money, and wouldn't sell to a private individual or non-approved company... IXYS is kinda a bunch of bitches like that. I have a new hook-up to buy from them though, through my local future electronics rep, but then we pay middleman costs of course.
 
You must log in or register to reply here.

Similar threads

B
JN controller 5v logic cable location?
Replies
7
Views
1,255
Bikeronin
B
A
"The Mule" calls for your help to speed up Phaserunner setup with hub rear motor with unknown characteristics
2
Replies
35
Views
2,813
aigoual
A
Q
    • Like
Ultra reliable setup for remote area boating.
Replies
3
Views
1,180
last20
last20
G
Controller advice required due to meeting UK law.
Replies
13
Views
512
stancecoke
stancecoke
V
    • Like
Imitation torque controller Kunteng
Replies
4
Views
2,626
vladobac
V
Back
Top