Hi power inverter for Nissan leaf motor. Dyno's 302.3hp p15

Cool. I will work on that more later. I want the center to be see through. So I will see what I can find. I need to spend some time finding a better photo editing program. But I am not worried about making the gauges more pretty yet for now I want to make them all work better and most of my time is spent working on other parts of the car.
 
kiwifiat said:
This should satisfy the lust for speed and power:
looking good, but i would make the "chrome" ring thinner and the numbers bigger, and use 20s step, and their corresponding lines thicker than the 10er lines.
also the correct SI unit would be "km/h" and "kW". 8)
on the other hand: with such massive acceleration arlo probably never has time to look at the gauges anyway ... *ggg*
 
izeman said:
on the other hand: with such massive acceleration arlo probably never has time to look at the gauges anyway ... *ggg*


Lol correct...


I tried looking at the gauge to see how many amps or KW it hits under acceleration and its hard as the car accelerates so damn fast... What I plan to do its smooth out the amp reading and get it to 0 properly. Then I will use the go pro facing the gauges. This will give me 0-60 times and peak amps/kw data.
 
izeman said:
kiwifiat said:
This should satisfy the lust for speed and power:
looking good, but i would make the "chrome" ring thinner and the numbers bigger, and use 20s step, and their corresponding lines thicker than the 10er lines.
also the correct SI unit would be "km/h" and "kW". 8)
on the other hand: with such massive acceleration arlo probably never has time to look at the gauges anyway ... *ggg*

Good catch on the speed units, I agree on the bezel but I am using a Java library to generate the gauge faces and my Java skills are not up to modifying the library. I'll be testing the existing speedo interrupt code today based on a 24 tooth encoder so I should have some feedback later today.
 
Spent some time working on getting the current sensor to read 0 at 0 amps... I used a solid 5v regulator just for the current sensor it self. But in the end I think the metal sheild I used around the wire that I have the melixis current senor on holds magnetism and causes the readings to be off at low current.
The current sensor chip I am using is a MLX91208LDC-CAV-001-SP You can put these on a busbar but when you do you need to make a sheild as any magnetism in the area will make the readings useless. You will want to use something with low Remnance and Mu metal is something that is not to hard to find...
Its funny when I regen from 100km/h to 0 it will read -16 to -17 amps at a stand still afterwords. I am looking at ordering some Mumetal.


I also have a problem not letting me turn the amperage up as high as I want. I can run 450 field weakening amps 750 peak phase amps and 600 battery amps with success. But trying to run more makes it fault and loose sync.. But It does not record the error which means the controller either browned out or the reset button was pushed I have the reset triggered by the arduino that watches desat. I spent some time trying to make sure its not triggered to easy today by adding some pullups to the desat inputs on the arduino and I added some cap... I also added a DC/DC that takes 9-36v input and spits out 15v out regulated and that runs all the low voltage side of the controller... Its still not solved.

Oh and I can't honk the horn or it resets the controller as well. Funny thing with the horn I added 1 25v 470uf electrolytic cap local to each horn and when I honked it for short bursts it was solved... But 1 long honk and both caps exploded :) I will get it but it might take me a little longer then I had hoped.
 
I took another look at the speedometer issue and setup a signal generator to the interrupt pin and monitored the output of the speedo calculation. The reading jumps around quite a lot and I think part of your problem lies in the fact that you are disabling interrupts during the speed calculation. That approach works ok for a bicycle with a single read switch that will never miss wheel rotations but in your application where you are feeding the interrupt quite quickly at high speeds you get problems. Given that you need an Odometer and that you want to implement a 1/4 mile and 0-60 meter you need an algorithm that does not miss any pulses from the speed transducer. You can take readings from the "pulses" variable without disabling interrupts, it would also be a good idea to add an ODO parameter and increment it by the appropriate amount every time you get an interrupt. That can also be used for the 1/4 mile timer. With a tire circumference of 1.835m and a 24 tooth transducer a 1/4 mile represents 5232 trigger pulses. Setting up a timer for that should be straight forward. I also noticed that the filter implementation for the speed is incorrectly coded and that explains the weird results you were getting and I observed initially. The "calc" variable needs to be updated after the initial run through the function. The other suggestion I have for you code is that you have a number of constants in your speed calculation that should be combined into a single coefficient and that eliminates multiple x and /'s from the calculation. In fact if you divide the distance traveled between speed calculations in meters by the time in seconds you get an answer for velocity in m/s and to convert m/s to km/h you simply multiply by 3.6 so the calculation becomes distance(m)/time(s)*3.6

I'll see if I can come up with a reliable and accurate implementation without hacking your code up too much. I prefer to use one of the counter peripherals for speed calculations but that requires custom configuration. Here is what I am currently using:
Code:
 // set up timer1 with external clock and CTC mode
              cli();  // disable global interrupts
              TCCR1B |= (1 << WGM12)|(1<<CS12) | (1<<CS11); 
              TCCR1B &= ~(1<<CS10);
              TCCR1A=0;        // reset timer/counter control register A
              TCNT1=0; // clear the timer counter
              OCR1A = ticks; // initialize compare value, this represents transducer ticks we want to time
              TIMSK1 |= (1 << OCIE1A); // enable compare interrupt
sei(); // enable global interrupts

Than you need an interrupt handler:

Code:
ISR (TIMER1_COMPA_vect)
      {
        interupt_flag = true;  //we don't want to spend any time here so lets just set a boolean flag.
      }

The main routine checks if the interrupt_flag is true and if so calculates velocity and resets interrupt flag to false. This approach unburdens the cpu from processing an interrupt for each transducer tick and because the distance represented by the ticks variable is constant the speed calculation distills down to a single constant divided by time.
 
kiwifiat said:
I took another look at the speedometer issue and setup a signal generator to the interrupt pin and monitored the output of the speedo calculation. The reading jumps around quite a lot and I think part of your problem lies in the fact that you are disabling interrupts during the speed calculation. That approach works ok for a bicycle with a single read switch that will never miss wheel rotations but in your application where you are feeding the interrupt quite quickly at high speeds you get problems. Given that you need an Odometer and that you want to implement a 1/4 mile and 0-60 meter you need an algorithm that does not miss any pulses from the speed transducer. You can take readings from the "pulses" variable without disabling interrupts, it would also be a good idea to add an ODO parameter and increment it by the appropriate amount every time you get an interrupt. That can also be used for the 1/4 mile timer. With a tire circumference of 1.835m and a 24 tooth transducer a 1/4 mile represents 5232 trigger pulses. Setting up a timer for that should be straight forward. I also noticed that the filter implementation for the speed is incorrectly coded and that explains the weird results you were getting and I observed initially. The "calc" variable needs to be updated after the initial run through the function. The other suggestion I have for you code is that you have a number of constants in your speed calculation that should be combined into a single coefficient and that eliminates multiple x and /'s from the calculation. In fact if you divide the distance traveled between speed calculations in meters by the time in seconds you get an answer for velocity in m/s and to convert m/s to km/h you simply multiply by 3.6 so the calculation becomes distance(m)/time(s)*3.6

I'll see if I can come up with a reliable and accurate implementation without hacking your code up too much. I prefer to use one of the counter peripherals for speed calculations but that requires custom configuration. Here is what I am currently using:
Code:
 // set up timer1 with external clock and CTC mode
              cli();  // disable global interrupts
              TCCR1B |= (1 << WGM12)|(1<<CS12) | (1<<CS11); 
              TCCR1B &= ~(1<<CS10);
              TCCR1A=0;        // reset timer/counter control register A
              TCNT1=0; // clear the timer counter
              OCR1A = ticks; // initialize compare value, this represents transducer ticks we want to time
              TIMSK1 |= (1 << OCIE1A); // enable compare interrupt
sei(); // enable global interrupts

Than you need an interrupt handler:

Code:
ISR (TIMER1_COMPA_vect)
      {
        interupt_flag = true;  //we don't want to spend any time here so lets just set a boolean flag.
      }

The main routine checks if the interrupt_flag is true and if so calculates velocity and resets interrupt flag to false. This approach unburdens the cpu from processing an interrupt for each transducer tick and because the distance represented by the ticks variable is constant the speed calculation distills down to a single constant divided by time.
Ok Tony has sent me some different code I am not sure if what you are looking at is current.

Here is the code I loaded today.
Code:
#include <Nextion.h>
#include <SoftwareSerial.h>

// Tempreture constants
// Motor Temp ???
#define THERMISTORPIN A3          // which analog pin to connect
#define THERMISTORNOMINAL 15000  // resistance at 25 degrees C
#define TEMPERATURENOMINAL 25    // temp. for nominal resistance (almost always 25 C)
#define BCOEFFICIENT 12050       // The beta coefficient of the thermistor (usually 3000-4000)
#define SERIESRESISTOR 10000     // the value of the 'other' resistor
// Controller Temp
#define THERMISTORPIN2 A4         //  anlog pin for controller temp
#define THERMISTORNOMINAL2 10000  // resisatance at 25 deg C for controller 
#define TEMPERATURENOMINAL2 25   // temp. for second therminstor resistance
#define BCOEFFICIENT2 14050       //  Teh bete coefficient for therminstor 2
#define SERIESRESISTOR2 10000   // the value for the second other resistor 

// Pin constants
#define PACKVOLTPIN A0         // pack voltage sensor
#define PREVOLTPIN A1          // system voltage sensor
#define SYSVOLTPIN A2          // precharge voltage sensor
#define AMPPIN A5              // current sensor
#define SPEEDPIN 2             // The pin the encoder is connected     
#define CONTACTORPIN 12        // control the contactor 

// Vehicle Constants
//Battery
#define HIGHVOLT 480          // Maximum pack voltage
#define LOWVOLT 340           // minimum pack voltage
#define PRECHARGEPERCENT 0.95 //  precharge complete percentage
//Speed 
#define PULSEPERROT 2.4         // pulses per rotation of speed sensor
#define WHEELCIRC .1835       // circumference of wheel in meters

// Smoothing Constants        // filter co-efficient valid range 0 -> 1  0 = infinite filtering   1 = no filtering
#define FILTER_AMP 0.6      
#define FILTER_SPEED 0.9
#define FILTER_TEMP 0.4

// display variables
SoftwareSerial nextion(10, 11); // Nextion TX to pin 2 and RX to pin 3 of Arduino
Nextion myNextion(nextion, 9600); //create a Nextion object named myNextion using the nextion serial port @ 9600bps

// Interrupt variables
volatile byte pulses = 0; 

// normal variables
int kmh = 0;               // speed reading
float PrechargeVolt=0, SystemVolt=0, BatteryAmp=0, PackVolt=0, tempMotor=0, tempController=0, KW=0;
unsigned long timeold; 
unsigned long millisecsPerHour = 3600000;


/*
 * Setup function... 
 *    start serial devices and dash
 *    set pinmodes
 *    attach interrupts
 *    set start timer
 */
void setup() {
  Serial.begin(9600);   // initialize serial communication at 9600 bits per second:
  myNextion.init();
  
  pinMode(CONTACTORPIN, OUTPUT);  //
  digitalWrite(CONTACTORPIN, LOW); //Makes contactor outout LOW initially (zero)

  //Use statusPin to flash along with interrupts
  pinMode(SPEEDPIN, INPUT_PULLUP);  // using INPUT_PULLUP means no need for a external pullup resisitor.
  
  //Interrupt 0 is digital pin 2, so that is where the IR detector is connected
  attachInterrupt(0, irspeed, FALLING);  // change to falling as standard state is high

  timeold = millis();
}

/*
 * Interrupt handling 
 */
void irspeed()
{
  //Update count
  pulses++;    
}

/*
 * Main loop really simple and easy to follow
 */
void loop()
{
  readVehicle();
  updateDash();
}


/*
 * Get the values from all the sensors and calculate the "real" values
 */
void readVehicle(void)
{
  // Read battery information
  PackVolt = analogRead(PACKVOLTPIN) / 2.048;       //Outputs values from 0-1023, so 2.048 will make the maximum voltage 500V.  Set appropriate voltage divider!
  PrechargeVolt = analogRead(PREVOLTPIN) / 2.048;   //Outputs values from 0-1023, so 2.048 will make the maximum voltage 500V.  Set appropriate voltage divider!
  SystemVolt = analogRead(SYSVOLTPIN) / 47.34;      //Outputs values from 0-1023 so 63.94 is 16v with a 5v input
  
  // Filtered Amp reading
  BatteryAmp = BatteryAmp + FILTER_AMP * ((analogRead(AMPPIN) * 1.710655 - 897) - BatteryAmp);     // Bidirectional current sensor 2.5v at middle
  // Non filtered Amp Reading
  // BatteryAmp = analogRead(AMPPIN) * 1.710655-890;
  
  KW = (BatteryAmp*PrechargeVolt/1000);
  
  // Enable the contactor if the pack and precharge are ok
  if  (PackVolt > LOWVOLT && PackVolt < HIGHVOLT            // pack voltage within correct parameters
        && PackVolt * PRECHARGEPERCENT <= PrechargeVolt)    // 95% precharge, change 0.95 to whatever to get you want your precharge to be
  {
    digitalWrite(CONTACTORPIN, HIGH);
  }

  // calculate speed
  if (millis() - timeold >= 100)  
  {   
    detachInterrupt(0);
    int calc = (WHEELCIRC / 1000 * (pulses/PULSEPERROT))  * millisecsPerHour / (millis() - timeold);  // raw calculation
    kmh = kmh + FILTER_SPEED*(calc -kmh);  // filtered speed
    timeold = millis();
    pulses = 0;
    attachInterrupt(0, irspeed, FALLING);
  }

  // read and calculate tempretures  
  tempMotor = tempMotor + FILTER_TEMP * (readThermistor(THERMISTORPIN, THERMISTORNOMINAL, TEMPERATURENOMINAL, 
                                                BCOEFFICIENT, SERIESRESISTOR) - tempMotor);     // filtered read
  tempController = tempController + FILTER_TEMP * (readThermistor(THERMISTORPIN2, THERMISTORNOMINAL2,TEMPERATURENOMINAL2, 
                                                BCOEFFICIENT2, SERIESRESISTOR2) - tempController); // filtered read
  
  //Write it out to serial port
  Serial.print("Speed: ");
  Serial.println(kmh, DEC);
  Serial.print("Temperature 1 "); 
  Serial.print(tempMotor);
  Serial.println(" *C");
  Serial.print("Temperature 2 "); 
  Serial.print(tempController);
  Serial.println(" *C");
}

/*
 * Update the display with all the values
 * ALL logic around display including calculations are here
 */
void updateDash(void)
{
   int displayKMH, displayAMPS;
  
   displayKMH = kmh*1.25;
   if(displayKMH<60) displayKMH += 300 ;
   else displayKMH -= 60;                 // get the needle to start at 0 which is 300 deg in nextion

   displayAMPS = (BatteryAmp+100)/2.8676470;   
   if(displayAMPS<66)  displayAMPS = 295 + displayAMPS;
   else  displayAMPS = displayAMPS - 66;
   
   myNextion.setComponentValue("n4", tempMotor);
   myNextion.setComponentText("t12", String(PrechargeVolt));  // update text using original sensor value
   myNextion.setComponentValue("z2", displayKMH);
   myNextion.setComponentText("t13", String(SystemVolt));  //12v battery gauge
   myNextion.setComponentValue("n0", BatteryAmp);
   myNextion.setComponentValue("n1", kmh);
   myNextion.setComponentValue("n5", tempController);
   myNextion.setComponentValue("n6", KW);
   myNextion.setComponentValue("z1", displayAMPS);
} 

/*
 * Utility function to get the tempreture in degrees C from the thermister
 */
float readThermistor(int thermPin, int nomResistance, int nomTemp, int seriesRes, int bCoefficient) 
{
  float reading = 0;
    
  reading = analogRead(thermPin);
  
  // convert the value to resistance
  reading = 1023 / reading - 1;
  reading = seriesRes / reading;
 
  float steinhart;
  steinhart = reading / nomResistance;              // (R/Ro)
  steinhart = log(steinhart);                       // ln(R/Ro)
  steinhart /= bCoefficient;                        // 1/B * ln(R/Ro)
  steinhart += 1.0 / (nomTemp + 273.15);            // + (1/To)
  steinhart = 1.0 / steinhart;                      // Invert
  steinhart -= 273.15;                              // convert to C
  
  return steinhart;
}
 
kiwifiat said:
I took another look at the speedometer issue and setup a signal generator to the interrupt pin and monitored the output of the speedo calculation. The reading jumps around quite a lot and I think part of your problem lies in the fact that you are disabling interrupts during the speed calculation. That approach works ok for a bicycle with a single read switch that will never miss wheel rotations but in your application where you are feeding the interrupt quite quickly at high speeds you get problems. Given that you need an Odometer and that you want to implement a 1/4 mile and 0-60 meter you need an algorithm that does not miss any pulses from the speed transducer. You can take readings from the "pulses" variable without disabling interrupts, it would also be a good idea to add an ODO parameter and increment it by the appropriate amount every time you get an interrupt. That can also be used for the 1/4 mile timer. With a tire circumference of 1.835m and a 24 tooth transducer a 1/4 mile represents 5232 trigger pulses. Setting up a timer for that should be straight forward. I also noticed that the filter implementation for the speed is incorrectly coded and that explains the weird results you were getting and I observed initially. The "calc" variable needs to be updated after the initial run through the function. The other suggestion I have for you code is that you have a number of constants in your speed calculation that should be combined into a single coefficient and that eliminates multiple x and /'s from the calculation. In fact if you divide the distance traveled between speed calculations in meters by the time in seconds you get an answer for velocity in m/s and to convert m/s to km/h you simply multiply by 3.6 so the calculation becomes distance(m)/time(s)*3.6

I'll see if I can come up with a reliable and accurate implementation without hacking your code up too much. I prefer to use one of the counter peripherals for speed calculations but that requires custom configuration. Here is what I am currently using:
Code:
 // set up timer1 with external clock and CTC mode
              cli();  // disable global interrupts
              TCCR1B |= (1 << WGM12)|(1<<CS12) | (1<<CS11); 
              TCCR1B &= ~(1<<CS10);
              TCCR1A=0;        // reset timer/counter control register A
              TCNT1=0; // clear the timer counter
              OCR1A = ticks; // initialize compare value, this represents transducer ticks we want to time
              TIMSK1 |= (1 << OCIE1A); // enable compare interrupt
sei(); // enable global interrupts

Than you need an interrupt handler:

Code:
ISR (TIMER1_COMPA_vect)
      {
        interupt_flag = true;  //we don't want to spend any time here so lets just set a boolean flag.
      }

The main routine checks if the interrupt_flag is true and if so calculates velocity and resets interrupt flag to false. This approach unburdens the cpu from processing an interrupt for each transducer tick and because the distance represented by the ticks variable is constant the speed calculation distills down to a single constant divided by time.

Some nice ideas there for some of the stuff. Yep the speed had an error that has been calculated.
I might have a look at moving the calculation of speed outside the disabled interrupt as it is only the reset of the volatile variable that is "required" to be in there.
If the odometer is required then reworking the speed calc makes sense
 
I also have a problem not letting me turn the amperage up as high as I want. I can run 450 field weakening amps 750 peak phase amps and 600 battery amps with success. But trying to run more makes it fault and loose sync.. But It does not record the error which means the controller either browned out or the reset button was pushed I have the reset triggered by the arduino that watches desat. I spent some time trying to make sure its not triggered to easy today by adding some pullups to the desat inputs on the arduino and I added some cap... I also added a DC/DC that takes 9-36v input and spits out 15v out regulated and that runs all the low voltage side of the controller... Its still not solved.

this is exactly the type of issues one gets at higher power, why i say you have smaller margin of error at higher power. what you write reminds me of a million hours spent debugging what was ultimately just 'not good enough' hardware architecture. noise! it sneaks around and does all sorts of weird things exactly like what you describe. eventually you learn to design for it, but in the initial days learning the hard way... they be long days ;)
 
HighHopes said:
I also have a problem not letting me turn the amperage up as high as I want. I can run 450 field weakening amps 750 peak phase amps and 600 battery amps with success. But trying to run more makes it fault and loose sync.. But It does not record the error which means the controller either browned out or the reset button was pushed I have the reset triggered by the arduino that watches desat. I spent some time trying to make sure its not triggered to easy today by adding some pullups to the desat inputs on the arduino and I added some cap... I also added a DC/DC that takes 9-36v input and spits out 15v out regulated and that runs all the low voltage side of the controller... Its still not solved.

this is exactly the type of issues one gets at higher power, why i say you have smaller margin of error at higher power. what you write reminds me of a million hours spent debugging what was ultimately just 'not good enough' hardware architecture. noise! it sneaks around and does all sorts of weird things exactly like what you describe. eventually you learn to design for it, but in the initial days learning the hard way... they be long days ;)

I will crack this nut!

So its about 50% chance the DC current is making noise causing my issue.... and 50% chance the controller is loosing control.
The good news is I can run EPIC phase amps and it doesn't konk out. So far I am at 750 phase amps (peak) and thats ~75 more then needed to make the slicks smoke even with some heat in them on the street. It will be different at the track for sure. I will worry about running more phase amps when I can flatten the torque curve some more by increasing the DC amps.
I will Test more soon. But it is not an easy thing to test. If the problem is DC amps then the solution is as easy as adding some shielding to the wires causing the problem or the wires that are picking up the noise. I have a main connector in the center of the pack that is 2 2awg wires in parallel to an anderson so I can disconnect it to split the pack in 1/2 for "safer" maintenance. It is not shielded and runs close to the back of the controller and might cause some issues. I tried a steal plate in between it and the controller for a shield but it did not help. I will be taking this apart very soon to rebuild it with the 800a igbts. So when I do I will try to add some things to help shield wires better.
Also Some times the desat trips at high DC current and some times its the controller konking out. So Noise can cause that but so can lack of precise current control. The IGBTs could be at a limit (most likely) where they are close to desat and they only need a small error in current control to enter the flat part of the curve where they don't add current just more voltage drop. So adding the 800a IGBTs will help that. I plan to do that soon. :)
 
Arlo1 said:
So Noise can cause that but so can lack of precise current control.

With this respect I am now busy with what I consider to be the holy grail: constantly measuring the motor resistance and inductance while the motor is running and being (ab)used. I thought I had it this weekend but it turns out it needs some extra code to monitor the 'quality' of the data. Had to convert the part of the chip dealing with impedances to floating point (hand-made floating point as the chip has no hardware floating point). So far it has added 1200 lines of (assembly) code, I expect to need another few 100. Rom is at 94% full now...

I built a model of the motor, controller and impedance measurement code in Octave (Matlab equivalent). When I start a simulation run the fan comes on and the thing is busy for 10 minutes :) been blowing hot air like that for 3 hours yesterday evening :mrgreen: the thing never worked so hard in its life
 
Lebowski said:
Arlo1 said:
Had to convert the part of the chip dealing with impedances to floating point (hand-made floating point as the chip has no hardware floating point). So far it has added 1200 lines of (assembly) code, I expect to need another few 100. Rom is at 94% full now...

Are you going to port the code to a processor with an FPU?
 
zombiess said:
Lebowski said:
Arlo1 said:
Had to convert the part of the chip dealing with impedances to floating point (hand-made floating point as the chip has no hardware floating point). So far it has added 1200 lines of (assembly) code, I expect to need another few 100. Rom is at 94% full now...

Are you going to port the code to a processor with an FPU?
I've been thinking about an Arm Cortix-M4F but I find the ecosystem not very good. Documentation is in general very bad (Microchip has excellent docs), no nicely integrated (free !) software environment, hard to find chips (with not too many pins, tqfp 64 or less) that have everything on board. Oh and 5V supply, definitely not 1.8....

At the moment if I would go to a different chip, the Microchip 33EV series looks nice (256kB ROM, 16kB RAM if I remember correctly) and runs at 70 MIPS. To compare, the 4011 has 48kB ROM, 2 kB RAM and runs at 30 MIPS.
 
I love sticking to 5v supply its more noise immune and easier to deal with on all levels.

As for the rest.... I don't care who makes it but the dspic30f4011 is close to maxed out ;)
 
The problematic noise could be at really high frequencies where a simple bypass capacitor or ferrite tube on the lines can attenuate it. I've seen LC and RC filters used as well but you need to keep the cutoff frequency high enough to not interfere with signal timing. Stick the filters right where the wires come out off the board. This might be easier than shielding.
 
fechter said:
The problematic noise could be at really high frequencies where a simple bypass capacitor or ferrite tube on the lines can attenuate it. I've seen LC and RC filters used as well but you need to keep the cutoff frequency high enough to not interfere with signal timing. Stick the filters right where the wires come out off the board. This might be easier than shielding.

Yeah that's not going to happen. All the brain signal wires have the filters I intend to run. When you start messing with adding random filters you mess a lot of stuff up. For instance I am using a 10nf cap on each phase current signal wire and combined with the 1k resistor that feeds it from the voltage divider it adds timing retard so for that reason its kept as low of cap value as possible. All signals have some sort of cap and or resistor setup on the brain.

Its not the way to solve this.

Nissan had the positive and negative routed together out of the controller (which I kept) they also have a braided and grounded shield wrapped around the main DC wires.

If my problem is from noise its from the batteries and or non laminated non shielded DC wires right behind the controller.
Its not a high frequency problem either as I can put massive AC current into the motor with no problem
Its only when the DC current gets to high it creates a problem. Also I have done some testing and with the battery current set to 525 amps it hits peaks of about 650 amps DC! So it seems possible its a control issue.
This also goes away when I turn the field weakening off to 0 amps and I can set the DC amps as high as I like....
 
Arlo1 said:
This is with 0 field weakening... I had tried 750 phase amps and I can't get the slicks to hook up at 750 phase amps no matter how many burnouts I do.
At the track it will be much more sticky so I will hope to turn it up more.
I also auto completed the current menu and forgot the field weakening at 0 So at 100 the current falls off fast. And top speed was 130 anyways it was a fun night.

Strapped the front end as well

[youtube]hL2T0bsk804[/youtube]


Very nice, Arlo! :mrgreen:

-JD
 
So this last few days I took the inverter apart and cleaned up the housing and welded up the holes that go into the coolant jacket.
I then rebuilt it all with the 800a IGBTs and drove it home so far so good. I didn't even change anything in the code yet...

I also tried to make videos as I assembled it to show how it all goes together.

[youtube]jY7IJOiqTec[/youtube]
 
izeman said:
it makes me nervous to even WATCH it. i'm really afraid of high voltage/power electrics. and YOUR'S is one for sure :)
Thanks....;)

As I stated in the video everything is shut off and there is a manual disconnect in the battery as well so there is no voltage potential other then the 12v system battery.
 
I am back up to the power I was before and might turn it up more but I have no traction.

So its set to 750 peak phase amps 525 battery amps (which allows 650 battery amps)

At first it was tripping desat easier then before thats right the 800a IGBTs with the lower voltage drop were tripping desat easier so I thought maybe its because they turn on slower and I added another 100pf cap to the blanking circuit which was already at 200pf this did not help then I played with the foc % which is a % of the measured inductance the controller uses for its calculations I had to got from 63% which worked with the 600a IGBTs to 70% which works now.....

Anyways its warm out the slicks are on stay posted.
 
Trying to figure out this noise. It might be related to my desat tripping problem
[youtube]RBv85M7oH0s[/youtube]
 
Still had some fun tonight.

Specs on the other guys car its a AMG C63 that does 0-60 in 3.9 sec or less.... http://www.fastest-mercedes.com/2016/07/2017-mercedes-c63-amg-horsepower.html

[youtube]7irVaITZV-0[/youtube]
 
Arlo1 said:
As I stated in the video everything is shut off and there is a manual disconnect in the battery as well so there is no voltage potential other then the 12v system battery.
i liked the idea of "i have the key in my pocket ..." as extra safety. i would touch my pockets to check every minute :D
it was a very nice video to watch. funny to see the same thing i have on my bike just several numbers bigger. sure i use FETs and not IGBTs and my currenct sensors look different, but other than that it looks quite similar.
i saw you spent quite some time on explaining how to use the popsticle stick for correct distance between the pcbs. stupid question maybe, but wouldn't it be easier to make them 2mm less wide?
 
Back
Top