the rear inverter has pyro fused "crow bar" phase terminals, where as the front inverter dose not (rear being permeant magnet motor, front being induction motor)
davefiddes wrote: ↑Tue Nov 18, 2025 6:06 pm
Did you check the board was working before soldering it to the inverter chassis & mosfets? I would recommend bench testing with just 12V and CAN. The inverter should come up and report that the gate drivers are all OK. It doesn't need the big mosfets to function. You shouldn't need to dismount to debug though.
The REGERRR and REGERRL errors are the sort of thing I have seen when the gate drive PSU is turned off. It would be worth double checking the gate drive PSU for each phase in turn. You do this with TP6/TP7/TP8 for phase A, TP9/TP10/TP11 for phase C and TP12/TP13/TP14 for phase B. I measured 12.7V for the positive supply and -5.1V for the negative supply for each phase. This matches Damien's video I think.
If the phase C PSU is not working it may have current limited as Damien explained. You might have to desolder the relevant STGAP1AS to see if it is a PSU problem or a gate driver chip problem. I found access around the "hot" side of the gate drivers to be quite fiddly. I can imagine it being really easy to end up with a short or nudging one of the many passives.
Jack Bauer wrote: ↑Tue Nov 18, 2025 6:23 pm
Running the latest build in the V50 now from Dave's github. All temps reporting correctly.
In general, do please follow the procedure in the video. I know it's tempting to skip parts when you want to see a result , I know that all too well but it almost never works out to be quicker.
I did check these voltages as per the video when I did it initially - the video only covers TP6/TP7/TP8. I didn't know to check the other ones. The other mistake I did make was that I didn't check with WiFi after this step to see that they were all ok.
That said, these are my voltages. Interestingly, I only see a discrepancy on Phase B (which seems inverted compared to the silkscreen labels and with drastically different voltages)
Phase A TP7: TP6 / TP8: 12.74V / -5.16V
Phase B TP13: TP12 / TP14: 3.544V / -14.02V
Phase C TP10: TP9 / TP11: 12.83V / -5.12V
I can understand Phase B giving me problems given it was the first set of gate drivers I soldered on. Is there a chance the errors on the interface are attributed to the wrong gate driver? In the mean time, I'll check the Phase B gate drivers and see what's going on
Yeah the zener "lifts" the iso ground to 5.1v thus creating the neg and pos supplies from a single output of the transformer. Its not a very strong ground so any short or damage will cause it to read weird.
Not much to report today as not much traction during monsoon season. That said I have now desatted this inverter at least 50 times and it just starts back up. I might try and make diy mud tyres by driving a box of tek screws into them...
@Dave, here's a PR that addresses the error ordering. I don't have the board in front of me to test unfortunately, but let me know how it gels with your understanding of the hardware: https://github.com/davefiddes/stm32-sine/pull/1
Thanks for finding the problem there outlandnish. It's a pretty facepalmingly stupid bug on my part. No idea how I managed to get that in there. Your fix is on the right track but is actually the reverse of what's required. The way the gate drivers work is that the first data to be clocked out when reading the status comes from the last chip in the chain ( i.e. phase A high-side) and ends with phase B low-side.
Armed with the results of Damien's testing and the knowledge that I can fix anything if I let the magic smoke out I found a way of triggering faults on the high-side. I found that if I short the Source and Gate pins of the high-side drivers I can trigger a UVLOL error. With my most recent commit in place I can now force an error in each high-side and the correct error is reported over CAN. No magic smoke so far.
I've not found a way of getting the low-side gate drivers to fault individually. It doesn't matter as the ordering of data is obvious (when I pay attention ).
As part of my work on the gate driver I've built a Saleae Logic analyzer plugin. This is quite useful for verifying the hardware is behaving the way it should and saves a lot of tedious and error prone parsing of serial data streams. Not necessary to find the bug but a reassuring cross-check. I plan on publishing this in the Saleae Logic 2 Extension "store" as it seems useful beyond our project here.
I received my beta board this week and got started on soldering the transistors, gate transformer then the gate drivers . Got to the first 12v power up test but got the gate fault l.e.d. lighting up tried resoldering a few of these drivers assuming they may be the culprit but still have the same three leds lighting up with the activity light blinking. I noticed in damiens video that he hooked up the wifi board. My question is if there was a way to isolate the problem driver or other component with the WiFi web interface or some other troubleshooting method. Thanks in advance for any ideas or support!
davefiddes wrote: ↑Thu Nov 20, 2025 12:55 pm
Thanks for finding the problem there outlandnish. It's a pretty facepalmingly stupid bug on my part. No idea how I managed to get that in there. Your fix is on the right track but is actually the reverse of what's required. The way the gate drivers work is that the first data to be clocked out when reading the status comes from the last chip in the chain ( i.e. phase A high-side) and ends with phase B low-side.
Armed with the results of Damien's testing and the knowledge that I can fix anything if I let the magic smoke out I found a way of triggering faults on the high-side. I found that if I short the Source and Gate pins of the high-side drivers I can trigger a UVLOL error. With my most recent commit in place I can now force an error in each high-side and the correct error is reported over CAN. No magic smoke so far.
I've not found a way of getting the low-side gate drivers to fault individually. It doesn't matter as the ordering of data is obvious (when I pay attention ).
As part of my work on the gate driver I've built a Saleae Logic analyzer plugin. This is quite useful for verifying the hardware is behaving the way it should and saves a lot of tedious and error prone parsing of serial data streams. Not necessary to find the bug but a reassuring cross-check. I plan on publishing this in the Saleae Logic 2 Extension "store" as it seems useful beyond our project here.
All good, I had similar types of weirdness with an ST daisy chained driver for low / high side drivers in my VCU. What ended up helping there was grabbing a couple of reference boards to do tests like that without wrecking a full board. That's cool you built an extension for that. I'd love to learn more!
I've published my Saleae Logic 2 extension for the gate drivers here: https://github.com/davefiddes/STGAP1BS-SPI-Analyzer Hopefully it'll appear on their "store" shortly. You can install it manually by downloading it and loading it in Logic 2. Instructions for how to do this are in the repo README.
I wished I had started with the Logic 2 analyzer. It would have saved a lot of time and bugs. Definitely a skill that's worth learning if you are dealing with complicated serial protocols. Debugging analyzers can be a bit painful so I'd recommend starting small and building up incrementally.
Gr8adventures wrote: ↑Fri Nov 21, 2025 1:04 am
My question is if there was a way to isolate the problem driver or other component with the WiFi web interface or some other troubleshooting method. Thanks in advance for any ideas or support!
I'd definitely recommend getting set up with a CAN configuration tool, either esp32-web-interface or OpenInverter CAN Tool. You'll need this once the inverter is bolted into the motor.
The WiFi interface works just fine on the bench and will get you up an going if that is all you have to hand.
To debug your problem with the gate drivers you should look in the Spot Values for the "m3_phaseX_XX". When operating correctly these should be "Ok" but as your fault LED is lit (the one near the US/IE flag) it'll be an error. Some possible errors:
RxCRC indicates that data is not making it back from the gate driver chain. Check the soldering on the upper side of the chips.
If you see different errors on different chips it would be advisable to upgrade the firmware to the latest build from https://github.com/davefiddes/stm32-sine/actions. As above I fixed a problem where the gate driver error wasn't being reported to the correct phase.
Latest firmware, cranked field weakening to 150Amps, tied the T3RD to the back of the JCB and opened up the taps. Sadly the 9kwh bmw hybrid pack aka "ScamBatt 9000" is sagging and limiting power but not much left of the tyres.
Here is a log driving around the yard along with the current parameter set from today's testing. Dave, is it possible to alter the logging time interval?
Yes but only in 1 second steps. If you add "-s 5" or "--step 5" it'll go in 5 second steps. I'm guessing you're looking for less than 1 second though?
Edit: If you are after smaller time steps than 1 second you're better setting up a CAN map for the params you are interested in. You can use "oic can export --format dbc my-datalog-map.dbc" to create a DBC that is acceptable to SavvyCAN. Then just use SavvyCAN for logging. The CAN SDO protocol used by OpenInverter CAN Tool et al is quite verbose and will clog up the CAN bus when polling for lots of variables at high frequencies.
You never know until you try stuff. I've updated OpenInverter CAN Tool to allow fractional second steps between log entries. With a step of 0.1 and you log ALL parameters you only get about 3 a second, VALUES does better at about 6 entries. Nothing melts down and the inverter runs fine.
For proper real-time performance a CAN map is best but this probably easier.
about 10 minutes with a cheap heated solder sucker, and some flux, and the board is free!
(starting to build out wiki)
its a rather simple process. place the solder sucker over the pin, let the solder flow, and suck!
After repeating across all the pins, i would then check the pin for free play, and if not, get the solder flowing again, and nudged it with a small scalpel so it doesn't rest against the board and solder its self back again. once all pins where free moving, removed all 11 screws and start to rock the board free. it should come off with ease. no force.
then clean up all the pins, removing any excess solder, then dropped replacement board in place! take your time. a few pins might need to be tweaked to get them to line up.
from my take, with a completely populated board, swapping boards and getting a OI M3 inverter is going to be a relatively simple and straightforward process. the heated solder sucker makes it very easy!
I was doing that yesterday too. Desoldering the PCB was pretty painless as you point out.
One gotcha that has bitten me since is to do with the current sensor housing. I hadn't appreciated the order from Damien's video and had forgotten to heat the current sensors prior to levering away at the sensor housing. I managed to snap the sensor heads off both hall effect sensors. Damn. I have replacements at least.
As part of the clean up I had reason to try the MG CHEMICALS 8310A Conformal Coating Stripper mentioned a while back. It works quite well on the Musk Goo. Softens it up nicely. Seems to need a little bit of physical scraping with something blunt (matchstick, etc) to remove. It doesn't remove the silkscreen or solder resist or cause obvious corrosion.
I am writing up the install process as I go though I've not put anything on the Wiki. I was going to start a new page specifically for that. Will get what I have up shortly.
davefiddes wrote: ↑Tue Nov 25, 2025 5:04 pm
As part of the clean up I had reason to try the MG CHEMICALS 8310A Conformal Coating Stripper mentioned a while back. It works quite well on the Musk Goo. Softens it up nicely. Seems to need a little bit of physical scraping with something blunt (matchstick, etc) to remove. It doesn't remove the silkscreen or solder resist or cause obvious corrosion.
just learned that acetone dose absolutely nothing to the musk goo. so good to know the MG chemicals works like a charm
I don't know if I'm the first other than the developers to have a working beta board, but I'm happy to report that my motor is running!
After some initial attempts I couldn't get a working angle readout, but it soon turned out that the correct settings had not been entered.
I'd installed Demain's settings and the angle readout worked, so I applied 50 volts to it with a lab power supply and tested it. And yes, the motor ran very smoothly! I'm so happy that this works and how relatively simple the conversion is, hats off to the work that went into this!
just to summarize my findings, I have a Tesla Model Y motor, the 3D7. But I still had an older 3D5 inverter lying around, which I used for the conversion so that if something goes wrong, the 3D7 inverter wouldn't immediately break.
I noticed the motor isn't spinning very fast, but I think it's at its maximum speed with the 50 volts I'm using. About 1060 rpm, if I'm not mistaken. When I switched the power supply to 60 volts, it started spinning a bit faster. I heard from Demain in the video or read here that the field weakening isn't turned on, which could also be the reason the engine doesn't run any faster. Perhaps that's just a matter of tuning?
I'd read about it before, but my motor doesn't have a temperature sensor. I do get an oil temperature reading that seems pretty good, so using that as an motor temperature wouldn't be a bad idea.
The oil pump starts running as soon as it receives 12 volts. I expected it to only turn on when the inverter is running. But perhaps that still needs to be implemented. when I set a speed the pump does not respond to that, again I don't know if that should work or not. But I do get oil pressure and temperature feedback from the pump (around 50-60 psi) when the pump is on, and if the pump doesn't have 12 volts, I get an error message about the pump. So at least the Linbus communication is working.
The start and forward signals are on pins that didn't have wires in my standard Tesla wiring harness, so I had to switch a few wires. I switched the wires for the second CAN bus on the original inverter (pins 20 and 30). and the reverse signal had a wire in the Tesla wiring harness. Perhaps it's a good idea to put these signals directly on pins that already have wires in the Tesla wiring harness so you don't have to reroute pins? But then it won't be pin-compatible, so maybe not such a good idea either.
Then some suggestions about the PCB. It's not a criticism, because I can see how much work goes into it and how complex the PCB is. But there are still some points I would personally address.
I think that the inductor L1 of the 5 volt buck converter U70 and the diode D15 are to far apart. you always want to keep this distance of the switching line as short as possible, also prefer a large copper path instead of a small track.
The DC/DC converter PS1 is a fairly heavy component and is now located at the very edge of the PCB, quite far from a mounting point. I can imagine that resonances could cause the PCB to flex, so I would prefer to see this component a little closer to a mounting point if possible. preferably between multiple mounting points. I haven't actually looked at the space inside the enclosure properly, and if this seems to be the only place it would fit. In that case, maybe there could be some mounting holes next to it so a standoff can fit in, which can be glued to the capacitor, for example.
And then my final point: in several places, the track width isn't consistent. Sometimes it's a bit wider, sometimes a bit narrower. I also saw a few 90-degree track turns, but those are minor issues, of course.
I previously posted a 3D scan with a DXF file. I happened to have access to a laser 3D scanner (these are significantly better), so I rescanned the PCB and this time with much better resolution. I'll adjust the DXF file a bit because it could have been better in some areas, and then I'll repost it.
Those are my findings so far, if there are any updates I'll let you know.
Brilliant that it's running. I suspect it is also the first model y motor to run on OI What value of syncofs are you running? if it my original value of 2200 that explains the low motor speed as I made a silly mistake and got it 180 degrees out. You need a value of 34968 (2200+32768). Also worth upgrading to the latest binary from Dave's github as it will get temp sensors working correctly etc. I think a lot of the more modern drive units have ditched the motor temp sensor (I have 3 and only 1 has it) so we'll look at using oil temp as motor temp. That's weird that the oil pump speed does not respond. Have you tried setting it to 0 to see if it will stop? The pump will run at full speed in the absence of LIN so would need to be on a switched 12v feed.
I have attached a parameter set that I am now running in the car with field weakening enabled. If you are running on a bench reduce the value of throtcur to 1 or 2 to avoid Elon practising the high jump.
Much appreciate the PCB advice and feedback. I hope to spend a few days over the weekend getting the board modified and send off an order for a first production batch.
).