But I do not have the toroids in hand, they are inside the housing. So assumptions, hesitations, and changes I made:
- min wall thickness is 1mm to be able to get these printed by say JLC3DP.
- shortened the pins to 3mm tall, 5.25mm tall 2mm dia. pin is begging to be be broken easily, 3mm is more than enough
- spacers are drawn up to what Tesla used, may need to adjust slightly for what you can get
- no toroid in hand so made assumptions of the toroid area, if someone has one and can share accurate dimensions it would be appreciated
- stock is PBT glass reinforced I believe, gluing the lid on may be tricky if printing these in nylon
- stock design has nothing to hold the toroid lid on if the glue fails, may make sense to add some mechanical features to help hold the glue / snap the lid in place
- note this is a high voltage source that can inject hv to the board if something goes wrong with cracking or failing, do not print this in cheap or conductive plastic
The temp sensors are next. I'm thinking of making the little towers then holding the sensor itself at the right height.
davefiddes wrote: ↑Wed Mar 18, 2026 7:00 pm
Seems like now is the time to go through the install documentation and simplify it by removing the beta specific steps. Any objections to me just getting on and doing that? I don't think there's anyone with a beta board out there that hasn't finished their install.
might be good to keep for legacy/ anyone thats building they're own boards
This firmware release matches up with the firmware Damien used for testing and is shipping in his 3.2 PCBs. I would recommend everyone upgrade to these firmware binaries.
The firmware package contains updated tesla-m3-rdu-foc-bench-params.json and tesla-m3-rdu-sine-bench-params.json parameter sets. These are cleaned up versions of the files Damien posted the other day with the correct temperature sensors configured. There are no changes to motor parameters. These should be suitable for bench testing.
Support for the FDU variant is included in the firmware but is still under development.
I dont mean to make more work for this, finding a NTC is proving to be problematic for the pc board version temp sensor. It looks to be a 0402 on the tesla temp sensor board but all I'm finding on Digikey are 0805s with the specs of NTC, 47KOHM, 4450K B25/100 from the B57164K0473J000 reference.
The thermistor pcb I pulled out seems to have cut a trace on removal. From that failure, I changed how tesla did this slightly on the copy I made, added a bit more copper at the connector tabs and an extra via for each.
I have the board drawn up, just stuck on sourcing the thermistor for it.
My plan was to panelize 3 with vcuts between them.
I did some admittedly poor testing as I have the meter probes touching the thermistor and had a temp sensor in the same area. I gave it about 2 minutes for the probe tips to normalize to the hot air for each and got the following temps / resistances:
53.7k @ 19.78°C
13K @ 61.11°C
11.7k @ 69.44°C
I'll work on fixing the trace with some solder and try to get better reads. Looking for info on what you guys got for values to compare and look at alternatives / options.
Wow thats amazing progress. Picked up a new fdu on my logging trip to evbreakers. From a 2024 highland m3 am told. Will pull off the inverter tomorrow and see what story it tells.
I have completed the updates to the written installation procedure https://openinverter.org/wiki/Tesla_Mod ... CB_Install to reflect the updates for the V3.2 PCB. Lots of steps have been deleted which simplifies it somewhat. Still a very complex process.
I've left the pre-install power-on check and gate driver voltage tests. It seems a good idea to check everything is in place and works before soldering to the MOSFETS and chassis.
So seems I got lucky with the highland M3 front inverter from evbreakers. Looks to be the "newer" rev pcb so with luck will have gate spi and lin info for us
Sitting here wiring up to the gate driver spi of the M3 FDU that I dont need but bought at evbreakers to help the project and boom. I knew it wouldn't take long. Thankfully I neither sold many nor at a higher price. Have asked paypal to issue a refund. Of course the person never tried to contact me or work anything out.
Edit : all refunded.
Attachments
Screenshot from 2026-03-24 11-17-47.png (11.02 KiB) Viewed 515 times
### Frame 0x0A — Status/Command Frame (120 occurrences)
- Byte 0: Always 0xFF — likely a node address or broadcast marker
- Byte 1: 0x00 initially, then 0x1E (30 decimal) after initialization — possibly a mode/state indicator
- Bytes 2–7: All zeros throughout — unused or reserved
### Frame 0x2A — Sensor/Measurement Data (120 occurrences)
This frame shows the most dynamic behavior — likely sensor readings:
- Byte 0: Transitions from 0x00 → 0x01 (active flag)
- Bytes 1–2: Gradually increasing values (e.g., 0x00,0x00 → 0x21,0x27) — could be current/power measurements ramping
up
- Bytes 3–4: Slowly decreasing (0x40,0x32 → 0x39,0x23) — possibly voltage dropping under load or temperature rising
- Bytes 5: Decreasing (0x3E → 0x34) — another declining measurement
- Bytes 6–7: Increasing values — possibly accumulated energy or duty cycle
### Frame 0x30 — System Measurements (118 occurrences)
- Byte 0: Constant 0x28 (40 decimal) — possibly a node ID or fixed parameter
- Byte 1: Ramps up from 0x00 → 0x3F then stabilizes around 0x35 — looks like a duty cycle or power level (0–63 range,
~55% steady state)
- Bytes 3–4: Large values that shift over time — possibly RPM, frequency, or multi-byte sensor reading
- Byte 6: Increases from 0x00 → 0x04 then holds — could be a state counter or operating mode
### Frame 0x31 — Temperature/Thermal Data (118 occurrences)
- Byte 0: Steps up 0x00 → 0x04 → 0x08 → 0x0A → 0x09 → 0x08 — possibly a fan speed or cooling stage
- Byte 1: Increases then stabilizes (0x00 → 0x0E → 0x0B) — related measurement
- Bytes 3–6: Four bytes that all decrease together from 0x3B,0x3A,0x3A,0x39 down to 0x34,0x34,0x34,0x34 — strongly
suggests 4 temperature sensors cooling down or being read in sequence (values 59→52 in decimal, plausible for °C)
- Byte 7: Constant 0x4D (77 decimal, ASCII 'M') — possibly a unit marker or checksum
### Frame 0x32 — Empty/Reserved (118 occurrences)
- All 8 data bytes are 0x00 throughout the entire capture
- Likely a placeholder frame in the schedule, or a slave that isn't responding with data
### Frames 0x3C/0x3D — LIN Diagnostic Frames (11 pairs)
These are standard LIN diagnostic frames (Master Request / Slave Response):
- All use NAD 0xD0 — the slave node address
- Queried PIDs: 0x0D (4 sub-IDs), 0x0A (2 sub-IDs), 0x09 (4 sub-IDs), 0x14 (1 sub-ID)
- Notable responses:
- PID 0x0D, sub 0xFF → response 0x05 (total count of something)
- PID 0x0A, sub 0x00 → response 0x21,0xDC (8668 decimal — could be a serial number or calibration value)
- PID 0x0A, sub 0x01 → response 0x18,0xCE (6350 decimal)
- PID 0x14 → response 0x01 (version or config flag)
## Key Observations
1. This appears to be an FDU (Fan Drive Unit) — the data patterns strongly suggest a cooling system controller:
- Ramping power/duty cycle (0x30 byte 1)
- 4 temperature channels declining together (0x31 bytes 3–6)
- Current/power measurements increasing (0x2A)
2. The capture shows a startup sequence: sleep → wake → diagnostic query → normal operation with the fan ramping up
3. No errors detected — all frames use direction flag S (successful), no checksum errors or framing issues noted
4. The 4 temperature values in frame 0x31 are the most interesting — they track closely together but aren't identical,
suggesting 4 separate thermal sensors (possibly motor, ambient, heatsink, and coolant)
So I've been through the Gate driver SPI capture. It's a bit different from the earlier capture (which was a bit messed up) and the RDU. Salient differences between the RDU and FDU:
I've had a look at the LIN capture. It starts out querying PID 0x3c and 0x3d which seem to be some sort of LIN diagnostic query/response mechanism that I need to do some reading up on.
Based on the reply it gets from your pump it quickly switches to the 0xa command, 0x2a, 0x32, 0x30 and 0x31 request sequence we know from the capture I took back in 2022. So presumably it should work fine with the current code. Would be good to test this. Can you plug one of your boards into the pump and see that it is happy with the response?
I suspect you have a newer pump than our 2019/2020 pumps but not new enough to be problematic like the Model Y pump that was giving someone problems.
The Saleae Logic software has a half way decent LIN analyzer that I've built tooling on to off. Any chance of a Saleae Logic capture of the oil pump LIN? A capture of without the pump connected as well as with would be useful.
Happy to help, thanks for all of your efforts in this Damien. The one piece for you to think about is the thermistor, what I have is close-ish and is a placeholder for now.
Thanks for the scan!
Panelization was with KiKit, https://github.com/yaqwsx/KiKit It takes some time learning to use it but then it panelizes the boards very quickly.
Damien, Dave, and anyone else helping with the PCB side of things, this should be able to swap the place of the through hole thermistor and should also work with the other version of the 3D printed towers for the through hole temp sensor.
The center point of the assembly is the center of the 2 slotted through holes to make it easy to use / reference.
Besides finding the right 0402 thermistor / one you guys are happy with, both this temp sensor PCB and the 3D printed tower are ready to order a test batch.
Melt rivets and the through hole temp sensor towers are good to test too. Melt rivets are 7 all stuck together in the 6 around the outside, one in the middle. They're small and easy to lose, should easily separate with cutters.
If / when someone gets toroid dimensions or wants to mail me one (PM me) to reverse engineer, I'll update the current sensor block to hold them properly, mod the caps and housing with snaps to help hold it in place.
