So to be clear, A 350V tesla battery pack can feed a prius gen 3 inverter, and with that inverter I can controll a 308V 98KW 3 phase Audi electric motor? Yes. More info on gen2: https://openinverter.org/wiki/Toyota_Prius_Gen2_Board More info on gen3: https://openinverter.org/wiki/Toyota_Prius_Gen3_...

Hello everybody, My name is Rob and I’m a complete newbie in this space. It is great to see how much knowledge is here and I’m stunned by the projects some of you pull off. I already read a lot and watched a lot of youtube to learn as fast as I can, but it is a lot….. I have this plan in mind that ...

I tested more today. The only way to mitigate the problem is to completely turn off regen when coming off throttle. The way I have it set up in my VCU is 4 regen levels, where level 1 completely disables off-throttle regen but brings in regen proportional to brake pedal pressure. So now I can quickl...

108 MHz, wow So you could just connect it to the 10 MHz crystal and it will happily run at 90 MHz. Just the LED will blink a bit too fast

Oh, yes just did :) Tested a bit more today and still hit over current when coming off throttle at 7500 rpm. It could be my parameters: throtcur 5.5A, ocurlim=900A. This means theoretically up to 550A + 225A (throtcur*100/2) field weakening can be commanded. That is 1160A peak! At least the horrible...

@arber: The changes don't affect the core control of sine firmware. You'd just need to make a regression test.
@boxter: the Jon Volk mod is not yet in there. I was gonna include it but resolving the FOC windup issue made me release it ASAP

There is a new and strongly recommended release of the inverter FOC firmware. It fixes an issue with the PI controllers that could cause the car to switch to uncontrolled strong regen when deep in the field weakening range and coming off the accelerator. It will be tested more, but basically there w...

Shiiiet, all that good work for nothing. Still, was fun
Hmm, 8.8 kHz means we need to bump control loop frequency to 17.6 kHz. Or deploy one of the extra timers for generating it in a well synchronized manner.

The primary reason for the F1 is recursive: we use the F1 today because we used the F1 yesterday. The primary reason to stick with the F1 is code base. The secondary reason is requirements: its resources are more than adequate for what we do, the added performance of the F4 won't make any motor run ...

We'll see. PLL allows multiplication of 7, so we could run at 70 MHz. Everything becomes a bit slower, e.g. 8.5 kHz PWM instead of 8.8

Both interfaces work, just no update over USB possible. Works on all STM32 based hardware, gen2 and gen3
https://openinverter.org/wiki/GEN2

Oh, my CHAdeMO test didn't go well, it turns out I have a super charger charger

Now, looking at the super complicated schematic I found the clock comes from outside. What speed crystal is it? Looking at all the pin changes I think it will live on a different branch for now and can be unified later. What is a good way to detect that we're on an M3? Like what pins behave differen...

So turns out reading DBGMCU_IDCODE is unreliable on older devices. So I changed the boot loader again. It deletes a page assuming it is 1k. Before deleting the next page it will check if it was already deleted. If so, we deleted a 2k page in the first place. In any case we always collect 2k of data ...

Yes will do.
There is quite a lot of extra M3 logic, so I'm starting to wonder how to cause the least "pollution" (for lack of a better term) to the main branch. E.g. if for some reason someone enables the DAC logic their processor will just crash because there is no DAC.

We wanted sine, right? We have sine: IMG_20210506_184208.jpg for (int i = 0; i < sizeof(dacdata); i++) dacdata[i] = SineCore::Sine(i * 256) / 270 + 128; We pull one full period from our SineCore module, divide it by 270 (not 256, because maxing out the DAC creates distortion) and add 128 because it'...

Yep, sounds like a root cause, well spotted!
Did you buy that from me? I'm trying to spot these upon arrival. Meh.

Ok, that took slightly longer. Generating a 4.4 kHz sawtooth from DMA: IMG_20210506_182355.jpg We need more clocks: rcc_periph_clock_enable(RCC_TIM5); //DAC timing rcc_periph_clock_enable(RCC_DMA2); //DAC rcc_periph_clock_enable(RCC_DAC); Now comes a lot of init. First the DAC dac_enable(DAC1, DAC_C...

I found a sudden urge to experiment with the DAC. I have here an STM32F107VCT6. Just sort of "blogging" about it here. Starting out simple with software triggering. First had to upgrade libopencm3 because the forked version didn't have DAC functions. setup: rcc_periph_clock_enable(RCC_DAC)...

Not all shutdown signals are evaluated, just emcystop and mprot which are always high on Tesla hardware. So yes you can go from Off to run with active overcurrent flags.

yes: https://github.com/jsphuebner/bms-hardw ... b-bom.xlsx

Charger envy, huh

Just have to build a shell for it, this looks ridiculous when charging at a public station...

As you might have seen here I'm using a Gen2 Tesla charger as CHAdeMO EVSE. I had to make some small changes to the software to make it work: - Fix the 0x102 message (enable bits now start at bit 40, not 32) - Added an "enablepol" parameter to start charging when the enable pin is LOW Inte...

Behold, another mayhem from the charger front. Got a good price on a Gen2 Tesla charger and as I'm now maintaining the software I thought it would be good to have one. Then I went to the scrap yard and got a water pump and a, irony of fate, Polo passenger heater assembly. Yes the one the killed my P...

OVERCURRENT is triggered by 3 items, unfortunately:
- The comparator that compares the current sensor signals to ocurlim
- The 3 fault signals from the gate drivers
- UVLO

One of these may be floating or have a bad solder joint

Scored one in Norway, the one from the first link.
Getting exciting again