Hello from Norway! VW Beetle w. 3D printed intakes, 2x DBW and staged injection

[tmbryhn]

Hi RusEFi Community!
It's about time I take on the next step in my development work, and I've been looking into this community for quite some time.

I just started my freshly built engine with a set of 3D printed intakes that I've designed myself. Up until now I've run my own MS3 based ECU design and a standalone 2x channel DBW controller. The latter is based in a 8 bit Microchip MCU and is one of my first C coding projects. I'm self thought in both hardware design and coding, and I still have a lot to learn. My background is in military avionics and I did my aircraft technician and officer education in the Norwegian air force about 10 years ago.

The engine is a 2332cc based on a watercooled VW Transporter engine case modified to an aircooled configuration. I have made a custom stroker crankshaft for it, and I'm currently running fully sequential staged injection w. passive COP coils using ECU integrated IGBT drivers, a custom 36-1 crank trigger and distributor based camshaft sensor setup. I have also implemented my own 4x EGT controller, 3-axis accelerometer and VSS on the EMS side of things. It runs great and the printed intakes are still holding up perfectly after approx 2400km, and both the ECU and DBW module works great. However, I feel there are improvements to be made in terms of a more elegant and future proof implementation and also due to the fact thay my ECU hardware isn't licensed for running the MS3 firmware.
As far as I've researched, RusEFi already supports a lot of the features I'm looking for and I view this project as an opportunity to keep improving my coding skills, and hopefully in time, be able to add new features along the way. Staged injection would probably be the first feature I'd like to start working on.

My thoughts for the ECU design:
Since I've already designed a set of working ECU hardware, I'm in favor of designing my own platform from scratch containing all the hardware needed for my needs rather than start on a ST evaluation board.
I'm envisioning an OEM Bosch style ECU case.

Features:
- WBO2: I've already designed a perfectly functioning analog/digital hybrid LSU4.9 on-board controller. I'm however open to implementing a CJ125 into my design. Input is welcome on this matter.
- Knock input. Texas DSP chip?
- Dual DBW: I'm aware of e.g. the Proteus hardware plattform. My experience lies with the MC33932, but I see no reason not to implement a different H-bridge driver if the firmware is already tailored to specific chips.

What I feel I need to start studying up on:
STM32 MCU selection for my specific RusEFi needs.
How to get started with a suitable firmware package.
STM32 coding and ChibiOS: I'm completely blank on this matter

[AndreyB]

Hello and welcome!

Very impressive first post

https://github.com/rusefi/rusefi/wiki/Hardware

image.png

[mck1117]

Welcome!

- WBO2: I've already designed a perfectly functioning analog/digital hybrid LSU4.9 on-board controller. I'm however open to implementing a CJ125 into my design. Input is welcome on this matter.

Iiiiiinteresting. Might be worth creating a separate post about this one, since I've thought about implementing a wideband controller from scratch like you've done. The CJ125 is sort of unobtanium and finnicky, so I'd love to not depend on it.

- Knock input. Texas DSP chip?

We're pretty close to having working knock input processed by the STM32. It has a lot of free cycles available, and knock can use up some of them.

- Dual DBW: I'm aware of e.g. the Proteus hardware plattform. My experience lies with the MC33932, but I see no reason not to implement a different H-bridge driver if the firmware is already tailored to specific chips.

The firmware doesn't really care exactly what motor driver gets used. That said, why not just run a Proteus? I'll be producing another batch soon (though of course you can also just build your own).

What I feel I need to start studying up on:

STM32 MCU selection for my specific RusEFi needs.

Unless you have a pretty convincing reason, the F407 or F427 are the way to go.

How to get started with a suitable firmware package.
STM32 coding and ChibiOS: I'm completely blank on this matter

Onboarding a new board is pretty easy, so long as it's a CPU that we've run before. For example, here's all the extra config that was required to onboard Proteus: https://github.com/rusefi/rusefi/tree/master/firmware/config/boards/proteus

[stefanst]

In my aircooled days I have read much about de-shrouding the Wasserboxer to go air-cooled. Very cool project and everything looks very well executed.

I don't think your engine has any highly unusual needs, so just the MRE or the Proteus board may be the way to go from a hardware standpoint.

[tmbryhn]

In my aircooled days I have read much about de-shrouding the Wasserboxer to go air-cooled. Very cool project and everything looks very well executed.

Cool to see more airheads on the forum. Here are some pics from the conversion process:

[tmbryhn]

I don't think your engine has any highly unusual needs, so just the MRE or the Proteus board may be the way to go from a hardware standpoint.

I view it a bit differently. Here are some of the features the Proteus doesn't include that I would like to have on-board for my design:
- I require an integrated WB controller and have already designed the hardware for this.
- IGBT coil drivers required for eg. passive COP ignition.
- I'd like to implement suitable Knock DSP so that the hardware is readily avaliable for software tweaking.

[tmbryhn]

Iiiiiinteresting. Might be worth creating a separate post about this one, since I've thought about implementing a wideband controller from scratch like you've done. The CJ125 is sort of unobtanium and finnicky, so I'd love to not depend on it.

Cool! I'm happy to share some schematics once I start on the design process. Another note on this: I've used a small baseline Microchip MCU to controll the heater PID strategy and convert from the non-linear pump_I to a linear 0-5V output sent to the main ECU MCU.
I'm envisioning optimizing the design by removing this extra MCU and implement these functions directly into the STM32 for closed loop heater control and pump_I reading directly.

We're pretty close to having working knock input processed by the STM32. It has a lot of free cycles available, and knock can use up some of them.

That's awesome! I've been using the TPIC8108 on my previous design. Is RusEFi using the same chip, or should I opt for a different part?

The firmware doesn't really care exactly what motor driver gets used. That said, why not just run a Proteus? I'll be producing another batch soon (though of course you can also just build your own).

Apart from the fact that the TLE9201SG is driven with a single PWM signal and a toggle pin for direction (high/low), as opposed to the MC33932 which use two PWM signals per channel; one for open and one for close.
I realize that it'll probably be relatively straight forward to change this in firmware, but as of yet this seems like a rather daunting task for me since I'm barely touching the surface of programming on this plattform and have a lot of research to do before I'm able to modify and add code to the project.

Unless you have a pretty convincing reason, the F407 or F427 are the way to go.

Ok, cool. I see you're using the STM32F767ZITx for the Proteus, so this also seems like a good approach for me. Thanks for all the input btw. I think this forum will be really helpful during this process, and I'm looking forward to keep sharing my work

[mck1117]

Cool! I'm happy to share some schematics once I start on the design process. Another note on this: I've used a small baseline Microchip MCU to controll the heater PID strategy and convert from the non-linear pump_I to a linear 0-5V output sent to the main ECU MCU.
I'm envisioning optimizing the design by removing this extra MCU and implement these functions directly into the STM32 for closed loop heater control and pump_I reading directly.

The main cpu may not meet the timing requirements for dithering the nernst current, so it might require a second mcu, but that's OK.

That's awesome! I've been using the TPIC8108 on my previous design. Is RusEFi using the same chip, or should I opt for a different part?

We're going the DSP route. The stm32 has plenty of horsepower, and I have the hardware and software working on the bench (with an arb wave gen).

Apart from the fact that the TLE9201SG is driven with a single PWM signal and a toggle pin for direction (high/low), as opposed to the MC33932 which use two PWM signals per channel; one for open and one for close.

We already support both types of control

Ok, cool. I see you're using the STM32F767ZITx for the Proteus, so this also seems like a good approach for me. Thanks for all the input btw. I think this forum will be really helpful during this process, and I'm looking forward to keep sharing my work

The later revs of Proteus run an f427, but it's pin compatible with both.

[AndreyB]

We already support both types of control

TLE9201SG is only one of three different H-bridged we've worked with and all three use i-o differently.

Please consider F4 since at the moment no one uses F7 and hopefully you do not want to be alone in the F7 camp with minor important differences between the chips.

[tmbryhn]

The main cpu may not meet the timing requirements for dithering the nernst current, so it might require a second mcu, but that's OK.

That shouldn't be an issue. My design uses an analog 1kHz sine oscillator for reading the nernst cell impedance (and thus temp) in real time and outputs two analoge voltages proportional to the Pump_I and nernst temp.
All that's required is a lookup table in the STM32 to convert from the pump_I voltage signal fed to an ADC into Lambda or AFR value.
For temp control it's just a matter of setting up a simple PID loop driving the heater FET with a constant setpoint (nernst temp voltage target) vs. nernst temp voltage feedback.

We're going the DSP route. The stm32 has plenty of horsepower, and I have the hardware and software working on the bench (with an arb wave gen).

We already support both types of control

The later revs of Proteus run an f427, but it's pin compatible with both.

Ok, I guess I'll go for the f427 for as good compatibility as possible "out of the box" then. I'll also stick with the Texas TPIC8108 DSP chip then.

How would I go about what MCU pin to use for what function or I/O? I've already looked into the TunerStudio bundle for the Proteus, and it seems to me that there's a lot of flexibility for what pins to map to what function, but are there some key functions that are locked to some pre-defined pins?
Would be helpful with a I/O reference chart when I start laying out the schematic, and if there's a lot of flexibility, that would also make the PCB routing neater and more elegant.

[kb1gtt]

Don't forget the Waltech WO2 option. It could be made into an integrated option. Some code porting would need to happen. Also would be good to select automotive grade op-amps if reasonably possible.
https://waltech.com/cszcms/wide-band-oxygen-sensor-project-report

[tmbryhn]

LQFP100:
STM32F427VGT7 - https://no.mouser.com/ProductDetail/STMicroelectronics/STM32F427VGT7?qs=OIhlmDO%252Boa4huNdF0sXbuw%3D%3D

or

LQFP144:
STM32F427ZGT6 - https://no.mouser.com/ProductDetail/STMicroelectronics/STM32F427ZGT6?qs=%2Fp4LXwb3CwHhVDQGwlrHHQ%3D%3D

?

[AndreyB]

Either way, depends on how much i-o you need. With extra stuff you probably want more i-o so 144?

[kb1gtt]

- I require an integrated WB controller and have already designed the hardware for this.

These things could easily be remotely mounted and used via CANBus. AKA minimize the length of the sensitive analog signals. Also note that wheel speed sensors, accelermoter, GPS, EGT, etc can also be done remotely. The list of things you desire to have inside the ECU will be a never ending desire. You will always want to put more in there.

- IGBT coil drivers required for eg. passive COP ignition.

I would suggest the igniter should be near the plug. The primary side of the coil is still around 300V to 500V, and the high voltage / high amps over long wires is a bit of problem with RF coupling into sensitive analog wires. You can drastically reduces the emissions by shortening the antenna. OEM's stopped putting the igniters inside the ECU's for good reasons. Also keep in mind that when the igniter fails, you'll likely have to replace the entire ECU. However with igniters that are mounted closer to the coil, they typically are much safer for the rest of the ECU, and you can replace just them, instead of un-soldering and re-soldering the ECU parts.

- I'd like to implement suitable Knock DSP so that the hardware is readily available for software tweaking.

Matt mentioned this almost exists currently. I believe software is very far along, a key issue was that there was a hardware problem on the last spin of Proteus, so it's development has been a bit idle.

I would like to encourage using the MRE or Proteus boards, then make new boards. We have not been able to get designs to work out of the box, we have always had multiple spins of a PCB, which can be costly if you try to roll your own. Plan for something like 3 or 4 design iterations. Also plan for lots and lots of validation and testing. I would like to suggest you learn from our pains, and focus on developing something new instead of re-inventing the wheel, which we have already re-invented. We have spun many board and done lots of validations. I understand the desire to do such things, but I would like to encourage a path that is more forward progress and less re-invention.

[tmbryhn]

Either way, depends on how much i-o you need. With extra stuff you probably want more i-o so 144?

Thanks.
With the ECU case i have in mind (90-way) and after I've seen what has been done with the Proteus, I'll probably end up with the 144.

[tmbryhn]

- I require an integrated WB controller and have already designed the hardware for this.

These things could easily be remotely mounted and used via CANBus. AKA minimize the length of the sensitive analog signals. Also note that wheel speed sensors, accelermoter, GPS, EGT, etc can also be done remotely. The list of things you desire to have inside the ECU will be a never ending desire. You will always want to put more in there.

Ever since I designed my first ECU back in 2012, I've developed a philosophy to differentiate between "essential" and "non-essential" hardware/features for an aftermarket universal ECU.
I already run accelerometer and EGT externally on my current setup - these obviously falls into the latter category.
WBO2 on the other hand is highly essential (along with features such as DBW and knock), thus, it should be integrated.
Noise is no concern due to the nature of the sensor and controller design. As you know, it's based on measuring "pump current" through a shunt resistor mounted close to the amplifier circuitry of the controller (You know, the 61.9 Ohm one).
Thus, EMI will be equally coupled into the IA and IP (LSU4.9 wiring nomenclature) sensor wires that makes up the external part out the pump_I circuit. My experience running multiple ECUs (also with integrated IGBTs and passive coils) and making comparisons with other external WB controllers tells me there are no concerns having the WB controller integrated inside a properly designed ECU - just like Bosch does.

I would suggest the igniter should be near the plug. The primary side of the coil is still around 300V to 500V, and the high voltage / high amps over long wires is a bit of problem with RF coupling into sensitive analog wires. You can drastically reduces the emissions by shortening the antenna. OEM's stopped putting the igniters inside the ECU's for good reasons. Also keep in mind that when the igniter fails, you'll likely have to replace the entire ECU. However with igniters that are mounted closer to the coil, they typically are much safer for the rest of the ECU, and you can replace just them, instead of un-soldering and re-soldering the ECU parts.

From a theoretical point of view, i completely agree. However, In my view, IGBT also falls into the "essential" category because I believe that an aftermarket ECU should be able to run both logic and passive coils without the need for ugly external ignition amplifier modules (now we're back to the philosophy side of things ). Besides, I'm highly dependent on this feature due to the engine plattform I will do initial testing on (read introduction to thread). All my prior ECU designs have had these integrated, and not even once have I experienced the issues regarding EMI (running R-plugs obviously ). All my analog sensor inputs have had simple RC low-pass filters and the rest has been done through software filtering.
I believe there are multiple reasons why many OEM in all essence stopped doing integrated IGBTs - not just because of EMI.

"When the ignitor fails?" Why would it fail? Potential firmware lock-ups latching the gate in ON-state should be circumvented with fuses, properly dimensioned PCB-traces and using IGBTs that are actually rated to the coils maximum current consumption post-saturation. Yes, I've had problems with coils having too low primary resistance, and frying my IGBTs lol Besides, I'm experienced with SMD work, so I'm happy to fix potential damages that may arise My thought is to "multiplex" the first four ign. channels with IGBTs and LOGIC 5V stages, and have the remaining, say, four or eight ignition outputs LOGIC only.

Matt mentioned this almost exists currently. I believe software is very far along, a key issue was that there was a hardware problem on the last spin of Proteus, so it's development has been a bit idle.

Then I should try to get the hardware right the first time, then I guess that's the beauty of sharing work like in this community - Even though I'm designing a new hardware plattform, there are a lot of pitfalls I have the potential of navigating around due to the fact that we're sharing experiences and having openness throughout the planning and execution phase.
Another reason that makes me feel rather safe and confident in my work, is the fact that I'm already using a lot of my previously tested hardware for this particular design.

[kb1gtt]

A very common igniter failure is caused by not gaping your plugs. Over time the gap gets larger and the primary voltage increases until the driver fails. When the igniter breaks then the voltage goes back up and you burns up your primary wingdings.

All the car's I've owned have been from the mid 80's and forward. They have always had external igniters, typically integrated with the coil, or the spark plug.

[mck1117]

An intermediate option is to fab an adapter board. Throw the wideband, IGBTs, etc on an adapter, but use the proven and tested core functionality on MRE or proteus.

[kb1gtt]

Yes we have several of these PNP boards which could be used as a reference. It would remove a bunch of risk from a new spin.

[tmbryhn]

I've come a long way in the schematics work and currently using Proteus v0.3 as a reference.
First I'm noticing is the fact that the schematics on the github are for the STM32F767ZITx MCU. How significant is this?

USB:
I've planned to use an FTDI FT232RL as the USB/UART adapter, primarily because it's well supported by TunerStudio.
Which STM32 pins are suggested for TX/RX? Any other approaches that are considered to be better with the STM32F427ZGT6?

WBO2:
I'd like to have the nernst cell temp and the pump_I current through the pump_I amplifier circuit read directly by two ADC inputs on the STM32.
Which two pins would you suggest being used as two additional analog inputs given that "AV1-12 and AT1-4" is to be kept as external analog inputs?
I would need some help or guidance adding the PID heater control and pump_I voltage to AFR conversion features in firmware at some point.
If someone's interested in that, let me know. If no one has the time, I'll simply implement my WBO2 design as is on the first spin, using the Microchip MCU with my already existing firmware as a heater controller and "pump_I to 0-5V linear output" converter. Might be of interest later to implement the code - either when I'm up to speed coding on this plattform, or if someones interested in the addition of a "non-CJ125"-based onboard WBO2.

Knock:
CLK - SPI Clock (pin#13 @ TPIC8108), this goes to PC10 Pin#111?
"MISO" and "MOSI", goes to which pins on the TPIC8108?
Got the feeling from some previous posts that there were some HW mistakes on the pinout, so would've been nice to get it right on the first board spin.

MAP/BARO integration: I'm thinking of implementing this into the ECU design. Looking for 2x additonal ADC inputs for this purpose similar to the above mentioned WBO2 proposition, if possible.

Sorry for the "n00b questions", but I guess one gotta start somewhere
Thanks for the input.

[AndreyB]

I've come a long way in the schematics work and currently using Proteus v0.3 as a reference.
First I'm noticing is the fact that the schematics on the github are for the STM32F767ZITx MCU. How significant is this?

Latest Proteus was populated with stm32F4. There is a chance that 144 package is 100% pin compatible between F4 and F7

[tmbryhn]

I've come a long way in the schematics work and currently using Proteus v0.3 as a reference.
First I'm noticing is the fact that the schematics on the github are for the STM32F767ZITx MCU. How significant is this?

Latest Proteus was populated with stm32F4. There is a chance that 144 package is 100% pin compatible between F4 and F7

Yeah, probably since there doesn't seem to be a specific board revision for the MCU swap. It seems the F4 doesn't support direct USB connection though. Am I missing something?

What were the main reasons for RusEFi settling for the F4 in favor of F7?

[AndreyB]

It seems the F4 doesn't support direct USB connection though. Am I missing something?

I am pretty sure that F4 supports direct USB we must be talking about different things.

Historically rusEFI was started with F4. While F4 and F7 are 97% the same, the 3% are different. We do not have resources to support both F4 and F7, we focus on F4 to make our lives easier. One day this might change but for now there are not enough reasons to deal with the extra pains of incompatibilities and differences.

[tmbryhn]

It seems the F4 doesn't support direct USB connection though. Am I missing something?

I am pretty sure that F4 supports direct USB we must be talking about different things.

You're of course right I checked the datasheet for USB specifically, and the same pins are indeed used on this device. I got confused due to the fact that USB wasn't mentioned on the pins definition list for PA11 & PA12, but rather the term "OTG_FS_DM" and "OTG_FS_DP" which I initially overlooked. I'll continue implementing according to Proteus USB layout.

I got to sleep on the WBO2 idea, and I've decided to implement the circuit as mentioned above for direct STM32 read/control, but with the addition of a stand-off header that'll allow for installing one of my WBO2 expansion modules directly on the PCB, by-pasing the WBO2 circuit on the main PCB until the RusEFi firmware is updated for direct wideband sensor control and read through the WBO2 circuit. That way both solutions can be utilized without a re-spin of the board - more development friendly.

Still awaiting confirmation on the correct Knock DSP signal routing though.

[tmbryhn]

It's on!

Start routing.jpg

[tmbryhn]

Can someone point me in the right direction for the correct knock DSP chip connection with the MCU?

[mck1117]

Can someone point me in the right direction for the correct knock DSP chip connection with the MCU?

No dsp chip, doing the DSP in software in the stm32

[mck1117]

First I'm noticing is the fact that the schematics on the github are for the STM32F767ZITx MCU. How significant is this?

The 144 pin F4 and F7 are 100% compatible. 0.3 was built with f427.

USB:
I've planned to use an FTDI FT232RL as the USB/UART adapter, primarily because it's well supported by TunerStudio.
Which STM32 pins are suggested for TX/RX? Any other approaches that are considered to be better with the STM32F427ZGT6?

Use native USB. It's significantly faster, more reliable, and less cpu intensive than UART.

WBO2:
I'd like to have the nernst cell temp and the pump_I current through the pump_I amplifier circuit read directly by two ADC inputs on the STM32.
Which two pins would you suggest being used as two additional analog inputs given that "AV1-12 and AT1-4" is to be kept as external analog inputs?.
MAP/BARO integration: I'm thinking of implementing this into the ECU design. Looking for 2x additonal ADC inputs for this purpose similar to the above mentioned WBO2 proposition, if possible.

Just sacrifice a few analog volt inputs, wiring them to the sensor or whatever instead of an external pin.

Are you really sure you need a full board, instead of building an adapter that you can stack Proteus on top of? You haven't yet described any features that aren't possible with an adapter vs. full ECU.

[mck1117]

I ask whether an adapter is reasonable because there is nonzero cost required to maintain additional board configurations. Keeping the compatibility matrix as small as possible is good for everyone

[AndreyB]

USB:
I've planned to use an FTDI FT232RL as the USB/UART adapter, primarily because it's well supported by TunerStudio.
Which STM32 pins are suggested for TX/RX? Any other approaches that are considered to be better with the STM32F427ZGT6?

This is a very worrisome statement.

My preference is to be blunt here: this concludes my availability for guidance for this this project. I have very limited resources and a large new board would not help me in any way while drain too much of those limited resources. I am happy to join the party once the party would be adding something on top of the existing foundation. See you on Slack!