Open Source Electric Supercharger
 

Since there has been much interest in the Phantom electric supercharger, and many people throwing around ideas oh how it could be improved I'm starting this thread for interested tinkerers like myself to share information and brainstorm designs and improvements.

Important things to keep in mind
1. Safety First
Electricity can be cause damage to your car, and more importantly to you. Experiment at your own risk.
2. All ideas are welcome
Feel free to contribute but at the same time make sure you've read the whole thread and are not just rehashing something that's already been brought up.
3. Be Respectful
People have different skill/knowledge levels. Don't make someone else feel dumb just because they asked an honest question.
4. This is open source only
The goal is to share information, not create a commercial product.

Parts

-MAP sensor connector: Sumitomo HX 040 3-way (need to verify)
-Throttle Position Sensor Connector: Yazaki 6-Way (need to verify)
-Crank Position Sensor Connector: NipponDenso 2-way (need to verify)
-MAF Sensor Connector: TS 025 5-way (need to verify)

Useful Links

Phantom Superchargers
http://www.phantomsuperchargers.com/
@fenton 's Phantom Supercharger Build
http://www.ft86club.com/forums/showthread.php?t=39719
EFI connection (excellent source for automotive electrical connectors)
http://www.eficonnection.com/
Kinugawa Turbo (for compressor housing/wheel parts)
http://kinugawaturbo.com
An interesting papaer on electric supercharging
http://www.movingmagnet.com/medias/d.../m12-12-16.pdf
A large collection of compressor maps
http://www.not2fast.com/turbo/maps/all.html

Here's what I've got so far..It's not much.
[ame="http://www.youtube.com/watch?v=b2UH8CMC780"]At dunno motor 1 - YouTube[/ame]

Neutron256's electric supercharger build
 

Relevant Skills:
-Basic Electronics (including some experience with micro controllers)
-Hobby Machinist
-CAD (preferred program RhinoCAD)
-Hobby Mechanic

Speciality Tools:
-Benchtop CNC Mill
-Benchtop Lathe
-3D Printer
-Assorted Shop Tools
-Limited access to a full Machine Shop

My Build

Compressor
-TD05/06 Compressor Housing (ordered)
-20G Compressor Wheel (ordered)

I may have to switch to a 25G wheel and housing but I will see how the 20G performs first.

I'll have to custom machine the backplate for the housing to serve as a mount for the motor.

Some sort of adapter will need to be created to mount the compressor wheel directly to the motor shat

Motor
Turnigy SK3 (3968-1500KV)

Kv (rpm/v) 1500 (theoretical top speed 45K RPM)
Weight (g) 363
Max Current (A) 110
Resistance (mh) 0
Max Voltage (V) 30
Power(W) 3000
Shaft A (mm) 8
Length B (mm) 68
Diameter C (mm) 39
Can Length D (mm) 68
Total Length E (mm) 92

Speed Controler
Turnigy dlux 120A HV Brushless Speed Controller

Spec.
Max Cont Current: 120A
Max Burst Current: 140A
BEC: N/A
LiPo: 6~12S
NiMH: 16~36cells
Weight: 129grams
Max RPM (2-pole): 200,000rpm
Size: 60 x 33 x 23mm
Motor Plug: Female 4mm bullet Connector
Battery Plug: Nil
Features: Spark Eliminator Lead with 2mm Plug

Controller
-Microcontroller (haven't decided but I favor the PICaxe because its cheap and simple)
-Display (I really just want a simple LED Bar display to show charge)
-Inputs
Tap into the throttle position sensor
Boost sensor
Battery Charge
Power Switch
Arm Switch

Battery
-Testing
Turnigy nano-tech A-SPEC 4000mah 10S 65~130C Lipo Pack (This will be charged outside the car. Test setup will not include a charging system)

-End Goal
Still Researching

General Concept

The boost sensor will allow the Micro Controller to keep the compressor running at a speed to match atmospheric pressure reducing intake restriction when the system is in standby. When the system is active the Micro Controller can use the boost sensor to match the amount of boost to a given throttle position.

Other Thoughts

It might be nice to have selectable recharge rates to allow the driver to choose how much and when the extra load of the battery charging happens.

Great idea, subscribed.

x2

Cool coool, funky that you are typing the %? as you go :thumbup:
Write a simple simulation function to do 5% increments with 100-500ms as well as simple print instructions per each step probably would help later for testing purposes too.

Here are some potential high rpm motors: http://www.neumotors.com/Site/1500_series.html

I'd like to go all out and build a GUI showing:
turbo power %
TPS %
MAP in/hg
TPS change in % over past x ms

For you programmers out there, how hard do,you think it would be to adjust the speed of the motor in a liner way to match a target boost pressure?

I'm not a programmer, but I play one on TV. To do it VERY WELL, it would be similar logic to how a balance bot works, but instead of aiming for "straight up an down", you'd be aiming for "this much MAP voltage"

is that what you mean?

It's definitely one of the more (if not the) most challenging aspect. Very similar to "gain" on an EBC. "Gain" could be done with a pot.
I don't translate my thoughts to words well most of the time. This is no exception.

GUI on what platform? Mobile?

We should start a github repo for the controller code, models, etc.

Fairly easy using a brushless motor, you basically just need six mosfets and switch them on off in the right order. But its easier to buy an inverter package and tie your controller into it

I built one in Univ for fun for ~80$ I think. Used an arduino controller to convert a 0 to 5V signal from the pedal (or in this case you'd use the throttle body signal) and change it to a PWM to pulse the mosfets on and off which controls how much power you send, then during all that you alternate which mosfets you are driving to charge the right windings and push the motor forward. I think what I built was good for 48V / 30A. I used a inverter IC package since they frowned upon building something for that much power myself O.o

Obviously with something for a car it has to be more robust / withstand heat, but its not hard.

The coding was simple, like 15-20 minutes probably depending on how fancy you wanted it. Obviously with a GUI / other external stuff its different, but for just a basically throttle to output its a simple loop to build.

The easiest way would be a closed loop system using the map sensor. It's fairly simple, in terms of logic.

Now with completely unrealistic accelerator and engine sounds (impossible to hear over the motor). Currently it's a 1:1 of accelerator to motor with no RPM, MAP inputs.

[ame="http://www.youtube.com/watch?v=LstTJbAI95M"]Arduino electric supercharger 2 - YouTube[/ame]

I'd actually be curious to see how well this would work with a 1:1. I'd still want some sort of closed loop to prevent restriction when the system is in standby.

ehh, that'd be easy for sheezy but would run the battery down. Maybe something like
0-15% throttle = off
15% - 50% throttle = linear enough not to be a restriction
50% - 100% throttle = linear x% to 100% power (MAP limited for boost control) <---still...I think this could be more difficult than expected

I would run it off under some variable rpm (maybe 2.5k or so) and just closed loop to a boost target from there on out, with a variable target and gain. That seems like the biggest ban for the buck in terms of implementation effort.

Also, have some minimum (variable) throttle % so that you won't be boosting off throttle.

Once we know how to interface with the motor (control and monitor its speed), that shouldn't be difficult at all.
It's as simple as watching rpms and throttle position and referencing a table that has target boost values stored where they cross. The motor speed is adjusted up or down until the boost pressure matches the target.
Just a little more sophistication and you can reference a second table that provides rpm for the target boost.

Sounds awesome. It'd be great to try and use off the shelf components as much as possible and to make it modular as well so people can run whatever combination of hardware suits their needs (and budget). What about an arduino to drive the logic? It seems like it has more than enough I/O capability for this application.

You don't need any of that. Way too complicated. You don't need to know how fast the motor is spinning to control boost. All you need to know is what the target is at any given time and what your current value is relative to it. A wastegate doesn't know anything about the turbo it is controlling. It only knows what it's spring pressure is and what it's boost reference is relative to it (mechanically speaking, but you get the point).

Sorry should have specified, I was thinking of using "Processing" processing.org but that would just be for finalizing code. Arduino can output to LCD screens. That would be great for the final implementation.

Throttle body signal vs. pedal signal.

Pedal shows your intent while throttle body shows what's really going on. Not sure which would be best. Maybe an average of the two?

heres literally a 20-second effort at what we'd want, in Ruby just for kicks.

# half-baked example code
board = Dino::Board.new(Dino::TxRx.new)
sensor = Dino::Components::Sensor.new(pin: 'A0', board: board)
motor = Dino::SomeSubclassOfMotor.new(some_options)

TARGET_BOOST = 10.0
GAIN = 1.0

sensor.when_data_received do |data|
current_map = sensor.from_adc(data)
return if current_map == TARGET_BOOST
current_map >= TARGET_BOOST ? motor.throttle_down(GAIN) : motor.throttle_up(GAIN)
end

again just a quick thrown together example to illustrate the idea in a language people who don't code can read and understand. obviously this would probably be c, and a lot more complex.

sorry this stupid ass ancient relic-from-the-90's forum software doesn't understand markdown and won't let me format anything properly.

dangit. My MAP sensor won't show up till Thursday and I'm gonna be out of town till Sunday....not that it really makes a difference because I have no way of turning motor RPM into actual pressure :(
@jamesm - I hope it's close-to-that-simple. I mean...it could be. It would just have to know how often to adjust the ESC.

Off topic, but Ruby looks weird as balls. Your code reminded me to make a proper object out of my motor. I usually code procedurally. I'm about 20 years behind programming-wise.

if by 'weird as balls' you mean 'the most beautiful awesome thing ever', i totally agree :).

seriously though it pretty much is that simple. that's code i roughly ripped from another project i've done that basically did the exact same thing (headspeed governer for an rc helicopter, using a hall sensor for feedback instead of map, but same difference). works like a charm. i didn't even re-write it in C, just ran it as straight ruby off of a raspberry pi with a slave arduino feeding events. very, very simple and effective way to control the speed of an electric motor based on some sort of feedback and target. the trick is tuning the gain, but that can be a simple pot to make it easily adjustable (boost could as well).

of course for this purpose i'd re-write it (and the rest of the necessary code) in c and burn it to an atmega so it'll be self-contained and cheap as hell to reproduce.

The three dimensional reference table gives us the ability to have different boost targets based on the combination of rpm and throttle position. This is far more versatile than just a simple loop keeping the boost stable relative to throttle position or rpm.
It could be done without the motor speed but I wanted it for a reason that eludes me now.

i agree. the boost target could be referenced from a table of throttle position and rpm, that's simple enough. the part i was talking about being too complicated was the suggestion of adding motor rpm. we need to control boost, we can read boost, so no need to know the motor rpm required to achieve said boost i guess was my point.

basically you shoot for a boost target, not a motor rpm target, because you don't need to know or care how many rpm's it takes to make the boost you want at the rpm and throttle position you're currently at. only need to know your current value relative to the target.

think like a wastegate. wastegates don't care about compressor rpm :).

There was a good reason for wanting to know the motor speed but I can't remember it right now. Sucks getting old. It'll come back to me eventually though.

Tuning gain is great, but a system like this would require the ability to correct offset as well. Otherwise the system could settle out at the wrong boost pressure and as long as the error signal (feedback compared to setpoint) is steady then the system wouldn't correct for it.

I've calibrated and rebuilt more then my fair share of pneumatic controllers that can do this, but I have no idea how to do it in the digital world. Basically for this to work well a controller that can do both proportional and integral adjustment is what to look for. A full PID wouldn't be required though, I don't think.

Or am I an idiot and that's already in the code above?

Also, I really think we need to get past the idea of boosting to the back of a partially closed throttle. That's inefficient and with a setup like this shouldn't be required. If BRZ edit could be used to remap the throttle plate vs. pedal maps, then you could just set WOT to something lower in the pedals travel range then 100% and then use the rest of the pedal's travel to increase boost pressure to a max.

Motor overspeed maybe? Or perhaps compressor surge?

The code above, as over-simplified as it is, will not settle outside of the target unless the target is unreachable due to a hardware limitation. It's pretty simple, basically says "keep increasing motor speed by x until map == target boost, them quit, if map >= target boost, reduce motor speed by x". Rinse and repeat. Again very simplified and not representative of a full implementation, but that's the idea, and it works well enough to control head speed to within 1 or 2 rpm @ 3k rpm.

Certainly there are improvements to be made, just advocating the general idea of using a boost target and a feedback loop.

Ahhaha programming drives me nuts. I've never had a knack for it. I'll stick with the hardware/electronics side of things. :)

I'm still of the notion that I don't want to have to reprogram the car's ecu. With a 3-d table we can set the boost at low rpms and partial throttle positions to levels that won't trip a code.

Please do, we need that even more :)

Yep. You could have any boost at any combination of rpm and throttle position, within the limits of the system. You could set it up any way you like, and alter it as needed when you upgrade in the future. It's a pretty exciting idea really.

Unichip?

The idea here is to have a kit that requires no additional purchases that we can just hook up and have it work. You buy a list of parts and put it together. We would make available the code with instructions on how to load it. I bet there would be members who would build them for a small price for those who either can't or don't want to.

:thumbsup:

That's easy. I expect I'll have the hardware prototype ready to test in a couple weeks depending on my free time and motivation.

I'm currently running Unichip and I think this is a great idea. It supports this type of mapping, it's already getting the most of the data needed, and could probably directly output a control signal to the motor controller.

If I recall correctly its $200 for the tunner software/hardware. Not bad if I knew for sure I could get it to work.

So now I have to look up Unichip and learn about those so I can participate in those discussions. sigh...

the problem is that it is proprietary. it would be great if it could be controlled by as many engine management systems as possible, but you wouldn't want to require it.