Synapse PDM is an open-source, automotive power distribution module with mobile data, GPS connectivity, SD card logging, an on-board IMU and battery backup.
During my Triumph Spitfire restoration and conversion to EFI, I wanted a better solution to the whole car running on three fuses. Especially given the additional circuits required for all the EFI components, fuel pumps, ignition system and injectors.
This led me to start development of Synapse PDM. Originally a basic unit with six channels that I was going to use along side the existing fuse box. It's now grown to 14 channels which will run all the circuits in the car with a few more nice-to-have features.
I don't believe there is currently an open-source PDM of this size on the market. Much of the inspiration for this project has come from the likes of Haltech, Aim and Link. All of these companies manufacture professional, cutting-edge PDM solutions, packed with features and rugged enough to meet the demands of motorsport.
I see Synapse PDM filling a gap in the market for DIY car enthusiasts that run the likes of Speeduino or RusEFI in their cars who want a fully featured PDM without the professional-level cost.
As of 2025, it is very much in beta phase. Expect missing features and bugs.
For discussion and updates, join the Facebook Group.
Some features aren't implemented. Check the GitHub repositories for info.
The functional state of the device is still in beta. The hardware is 95% complete, bench tested and functional but there hasn't yet been sufficient field testing. Firmware and configuration software utility is ongoing. See the GitHub pages for the firmware and configuration utility for progress.
The SynapsePDM firmware repository can be found here.
The Cortex software repository can be found here.
The hardware can be found on OSHWLab, here.
Enclosure CAD can be found here.
I'm actively seeking developers and testers for this project. Please Contact me if you are interested in contributing.
The 4-layer PCB measures 186mm x 160mm. Outer copper needs to be 2oz to effectively dissipate heat. The high-side drivers are fed by threaded terminals for high current capability. Seven drivers along each edge of the board with four layers and thermal vias to dissipate heat. Most of the other connections are made using the 35-way Ampseal connector.
On the board, you'll find a micro SD card socket, SIM card socket, GPS and mobile data U.FL antenna connectors, display header, programming header, internal battery header, external USB-C socket, debug USB-C socket for the SIM7900X module and the usual STM32 boot mode selection headers.
Input power is protected from over voltage (load dump) and reverse polarity.
Inputs are over voltage and under voltage protected as well as being current limited.
The CAN interface is protected from transients.
The connection to VBatt along the top row of drivers (U27) is also used to power the control electronics.

I selected the BTS50025-1TEA due to their extremely low on resistance. Worst case being 5mΩ. If we take a maximum single channel steady-state current of 20A and calculate power dissipation (I2R), we see a power dissipation of 2 watts per channel. Thermal resistance given in Infineon's datasheet of 22°C/W yeilds a temperature rise of 44°C. This of course, describes the thermal characteristics a single channel. Multiple adjacent channels at full load will enevitably see a greater temperature rise. They are rated to 150°C operating temperature so should withstand high currents even at relativley high ambient temperatures.
The current carrying traces to the connector are probably the limiting factor in maximum achievable current. They are 4mm wide. On 2oz copper, on a 4-layer board with internal ground planes at 20A, that gives a temperature rise of 42°C. 25A on the same trace gives a temperature rise of 70°C which is getting too close in an ambient environment that may be 40°C or more.
Below are some thermal images from my testing. A single channel loaded at 17A (left) and an adjacent pair loaded at 24A (12A each, right). Testing was done on a channel closest to the edge of the board which has the worst case copper area for dissipation. The board was mounted in the 3D printed enclosure with the 5mm aluminium heat spreader attached to the under side of the PCB using thermal tape.
The highest temperature rise was for the single 17A test, that channel saw a 25°C rise.
I have more thermal testing planned to fully load several adjacent channels, but looking at these initial results, I don't see any cause for concern.

There are two variants of the enclosure. The 3D printed variant caters for 5mm aluminium heat spreaders which can be attached to the underside of the PCB using thermal tape. The full aluminium enclosure is designed so the area beneath the drivers is in contact with the enclosure itself, using thermal interface tape.
The Amphenol connector is rated to 17A per pin and only a certain subset of pins can be loaded according to their datasheet as seen in the derating table below. Use of the gold contacts is also a requirement for these ratings.

It is worth pointing out that this derating table applies to the connector at an ambient operating temperature of 125°C. In practice, loading multiple pins at 17A outside of this pattern is probably going to be fine and in fact, 20A should be easily achievable.
Given these limits, I decided to hard-code the firmware with a 17A limit. Channels can be paired for this reason, to allow control of high-current devices. As more testing time on the bench and in the field is accumulated, I could see this limit increasing to 20A per channel.
The main power is supplied via an Amphenol SurLok connector. These robust and IP rated connectors are ideal for this applicaton. The one I fitted can supply 200A. Cable connector part number SLPPB50BSR0, panel socket part number SLPRBBPSR.



| Ampseal pin | Function | Ampseal pin | Function | Ampseal pin | Function |
|---|---|---|---|---|---|
| 1 | Output 3 | 13 | Output 2 | 24 | Output 1 |
| 2 | Output 4 | 14 | Digital in 1 | 25 | Analogue in 1 |
| 3 | Output 5 | 15 | Digital in 2 | 26 | Analogue in 2 |
| 4 | Output 6 | 16 | Digital in 3 | 27 | Analogue in 3 |
| 5 | Output 7 | 17 | Digital in 4 | 28 | Analogue in 4 |
| 6 | CAN L | 18 | Digital in 5 | 29 | Analogue in 5 |
| 7 | CAN H | 19 | Digital in 6 | 30 | Analogue in 6 |
| 8 | Output 8 | 20 | Digital in 7 | 31 | Analogue in 7 |
| 9 | Output 9 | 21 | Digital in 8 | 32 | Analogue in 8 |
| 10 | Output 10 | 22 | Igntion | 33 | 5V Reference |
| 11 | Output 11 | 23 | Output 13 | 34 | Ground |
| 12 | Output 12 | - | - | 35 | Output 14 |
Understanding this part of the circuit design is key to understanding how the power modes work.
Most peripherals are turned off when the PDM goes into sleep mode to save power before the processor goes into sleep mode.
Board versions prior to v1.6 have an error on the nets for the SIM module supply. v1.5 and older boards will not support tracking features without the car battery supply.
The firmware is written using PlatformIO and the STM32 Arduino core targetting the STM32F446ZET6. Functions are called at different intervals depending on priority.
Outputs are configured as either digital or PWM. PWM frequency is fixed at 200Hz. This is a limitation of the Infineon HSD but is high enough frequency to run brightness control for lighting, speed control or to allow for soft-starting accessories. PWM control is acheived through DMA register manipulation. This allows for accurate timing with minimal CPU load.
Digital inputs are quite basic, they are just configured as active high or active low. No pull-ups or pull-downs are configured. External resistors should be used if required.
Analogue inputs have several configurable properties. Internal pull-up or pull-down resistors can be configured, the input can behave as a digital input or an analogue input. In analogue mode, the input can be purely passive and accept an analogue signal. As an active analogue input, a pull up can be enabled to effectively create a resistive divider with an NTC thermistor for example. Analogue inputs can be configured as thresholds for a digital output, or scaled for PWM outputs. Analogue signals are read in the range of 0 to 5V. Inputs are 12V tolerant.
Outputs have several protection features.
Under current is the lower current thrshold for open-circuit detection. Should an output be active but the current is below this threshold, the output will be disabled with an open-circuit fault.
Over current threshold is used for detecting over current and short circuit events. Exceeding this value will either trigger retries if they are configured, or an over current fault, disabling the channel.
Inrush delay can be configured up to 2 seconds. This effectively ignores the current limit during this time at the point the the channel is enabled. This is inteded for use with accessories such as cooling fans that will draw many times their steady-state current at power on.
Retry attempts can also be configured. The retry interval is approximately 150ms. This allows the PDM to make several attempts at activating an output with an over current fault before the number of retries is reached and the output is disabled a fault.
Outputs can be grouped simply by assigning the same input to multiple channels. The current limits applied to each channel can therefore be summed for the total output current available. Generally current sharing is reasonable between channels, but thermal factors prevent them from current from being distributed completely evenly. Expect to see some channels bearing more current than others and adjust limits accordingly.
Bear in mind that if one channel in a group fails, the rest of the channels in that group will try and take the load. So long as limits are set appropriately, those channels will correctly fault also. The PDM will protect iteself, it's the wiring you need to consider.
Faults are reset the next time the associated input transitions from inactive to active.
Data logging is always enabled. All channel and sytem parameters are logged at 10Hz. A new log is started at ignition on.
Date and time are obtained from GPS.
The CPU shuts off all uneccessary peripherals & power rails and enters sleep mode when the ignition input goes low. Only the CPU itself and the IMU are kept powered during sleep. Testing shows a sleep current of approximately 2.2mA.
The system exits sleep mode either by interrupt from the IMU (vehicle movement) or via the ignition input.
In sleep the IMU is armed to trigger an interrupt on any movement. This wakes the processor. Upon waking, the system checks the ignition input state amd monitors movement for the configured period of time. If no movement or ignition is detected in that time, the system goes back to sleep. If movement persists, other actions can be taken such as reporting to a web service with GPS co-ordinates. The PDM has an internal backup battery which can keep the system alive for many hours in the event that the main power is removed.
Currently there is no implementation for telemetry reporting or a security system as such. I envisage using something like ThingsBoard to implement telemetry & GPS tracking using MQQT. Security could be done by securing the PDM via an encrypted CAN message from a CAN based NFC module or similar.
Written in AvaloniaUI for C#.NET, Cortex is the configuration utility for SynapsePDM which uses the USB interface/virtual COM port of the STM32.
The utility allows you to connect and configure the controller.

SynapsePDM hardware is licensed under CERN-OHL-S v2. SynapsePDM firmware and the Cortex application are licensed under the GNU GPL 3.0.