Greetings...

[ssmith]

Well I don't have any actual hardware yet, but I decided to start working on the software side of RusEFI.

A little about my car: I decided to transplant a new-ish motor (BMW N20, turbo 4-cyl GDI) into an old-ish car (BMW E46). I joke that I have a real 4-cyl M3 The car road races in NASA ST4 in California. I suppose I could have tried to get it running with the stock wiring harness, but didn't want to deal with all of that. So I went with an aftermarket engine management computer - there aren't a lot that can run GDI and have the features I want, but I settled on Link G4+ Force GDI as having a good set of features and a reasonable price (compared to a Motec M142 with GPR-DI, maybe development package). But as it is, the Link ECU can't handle a number of things - variable valve lift, digital sensors for oil pressure and oil level, an electronic wastegate, or have all the configurability that I wanted. So I built a second computer to handle boost, some sensors, etc and the two talk over CAN. This works reasonably well but I'm not thrilled by having two computers. I've run this for a little over a year.

When I looked around for open source choices, I saw MegaSquirt, Speeduino, and RusEFI. None really have GDI support (yet!) I was really impressed by the hardware on RusEFI - especially the Hellen project. The idea of modular hardware with minimal effort to bring up a board is brilliant! I figure maybe I can contribute on the software side as my hardware skills are hobby level.

Ideally I would like to see the software have the configurability of a Link G4+/G4x - the ease of editting tables, choosing axis, etc, as I think it would simplify code development (for any input in the code, you wouldn't have to indicate which variables are controlling what inputs to the table as the software would understand the relationship between logged variables and axis to tables). It has been pointed out this might be a huge undertaking but perhaps there are ways to get the benefits while still using TunerStudio for most editting.

I would also like to see the expected functionality working - knock sensors, wideband (ideally integrated into the main ECU for cleanliness of design), traction control, boost control (maybe a different PID application for electronic wastegates to take into account the different motor behavior), GDI/HPFP control, etc. I may add using electronic throttle as a short term boost controller (though with a sufficiently flexible UI/table design, this could be done without code changes). Oh and maybe ion sensing if the BMW S65 coils act the way I think they will.

Basically I want to replace my pair of computers with one that is as easy to use and as flexible as the ones I'm replacing. Ok my own ECU isn't that easy to use

[AndreyB]

We are truly excited to have you around!

In light of the software progress let me revive hardware side of GDI progress. At the moment we have a pretty abandoned https://github.com/rusefi/hellen154vag-9.1 but I think I can get it finished and somewhat test it on my rotting GDI test mule

[ssmith]

BTW if I had a board wishlist, it'd probably include (and no I'm not saying do this for me, it's more to plant ideas on what others may find useful):

1. Large connector so I can have lots of goodies. I saw the 121 pin connector on Aliexpress that is probably the same as some VAG/etc connectors. I don't mind wiring my own ECU though to start I might mimic the headers I currently have to I could try out the ECU without rewiring my entire car just in case I run into software troubles.

2. Various digital inputs capable of capturing microsecond accurate edge signals. That would allow me to sample the oil pressure and oil level sensors. They are PWM modulated signals with basically a sync pulse, a pressure (or level) pulse, and a temperature pulse. Here's a sample datasheet:
https://www.hella.com/emergency/assets/media_global/KI_OPS_T_HELLA_EN.pdf
I assume whatever captures the trigger signal would be good enough for this, I'd just want enough digital inputs to capture:
Crank, Cam1, Cam2, OilTempPressure, OilTempLevel, AbsWheelLF, LR, RF, RR, Coolant level
(that's 10, just for high frequency digital inputs!)
All my triggers are hall effect but I need pull ups on the lines.

3. Coolant level sensor. Modern cars use basically a capacitive level sender. You send a wide pulse to charge it then measure how long it takes the voltage to decay. You need a little board space for a couple of resistors (use one pin to drive the pulse, use another pin for analog in to measure when it falls below a certain level).

4. Lots and lots of analog inputs. I think I use around 16, but can always use more. I end up using the ECU for fuel level, accusump pressure, etc. EGT using Amphenol PT200 RTD sensor (used on BMW S54 engines and I think some Polaris). Yeah I could use a my dataacq for that but honestly it's cheap to add it to the engine computer, so why not have an excess? I did see some comments in the code that said there's a limit of 16 inputs but I also saw where multiple ADC are supported so I think you have support for more than 16.

5. Valvetronic control using BTN8982. Just wire up the two control signals and the software is easy, but those suckers can pump 10A so you need a wide enough trace to handle it. I need three, which actually take up a lot of room.

6. Drivers to ground capable of a couple amps with implicit pull ups. Can be used to power the solenoid to the Accusump, or VVT. It's overkill but can also be used to signal the electric water pump (no power draw on signal wire). https://tecomotive.com/download/PWMinfo_EN.pdf - a general purpose PWM output works fine for that.

7. No internal ports. Knock sensor output (if not using USB - that's on my todo list) should be accessible by external pins. Ditto for USB (works fine for full speed, I don't know about high speed). Possibly even a hard reset/programming line (though maybe it'd be enough to sense the USB voltage on boot up and use that to decide whether to go into the DFU/bootloader or not?) Nobody wants to take apart their ECU which is secured to the car just to tune it. Easier on a universal board than a plug and play.....

If you ever wanted to run a BMW S54 engine, you'd need special VVT control (they use separate wires to advance and retard each cam, and they're high side drive not low side drive, but you can break open the controller and remove some diodes to make them low side drive if you rewire it). Also the S54 has a VR crank signal.

I recognize I'm a different user from others in that the plug and play is not interesting to me; I prefer custom wired in solutions. But the nice thing is if you have a feature-full enough universal board, then you can satisfy all the universal board users with one board.

I was actually wondering if the GDI circuitry could be dumbed down to work for non-GDI cars? I.e. since it can do boost/peak/hold, can it also just do peak/hold? And if it can do that, it can probably handle saturated/high impedance injectors too... One Board To Rule Them All!

I guess I need to learn KiCad. I always knew I should switch over but I have too much inertia. I've been using gEda/gschem/pcb for my small boards.

[mck1117]

I was actually wondering if the GDI circuitry could be dumbed down to work for non-GDI cars? I.e. since it can do boost/peak/hold, can it also just do peak/hold? And if it can do that, it can probably handle saturated/high impedance injectors too... One Board To Rule Them All!

Meh, high-z injectors are so easy (small board area, cheap, etc) to control that it'd be worth having both on board. Especially since some engines use port-over-DI, so you might need those drivers anyway on a DI engine.

[AndreyB]

Ohhh you are touching a huge topic. I would love to discuss this further but open question is what is the best format and when would that communication be most effective.

For multiple reasons forum long form is my third preference. One on one voice over phone with screen sharing is the best remote medium for me, would you be interested to sync up like that at some point?

At the moment I am taking a break from our group chat Slack which is usually my second choice.

[AndreyB]

MegaSquirt is not OSS

At least two Hellen boards have TWO on-board WBO controllers. Note that this is accomplished by having three stm32 MCUs total on that board. We will return to multiple MCUs in a bit. Hellen 121 Nissan uses that 121 you've mentioned https://github.com/rusefi/rusefi/wiki/Hardware/Hellen/hellen121nissan-rev-B-with-connector.jpg while https://github.com/rusefi/rusefi/wiki/Hellen-154-Hyundai uses 154 pin connector. https://github.com/rusefi/rusefi/wiki/Hellen-One-Platform

JLCPCB gives us best assembly experience at cost of single side limitation thus question of total surface area. With a huge wish list we would not fit into any OEMish metal case available new from China. Plastic or 3D printed cases could give us extra surface area.

While stm32 has up to three ADCs considering pin overlap and other overlaps it's not 3*16=48 analog inputs at all. A number of nasty limitations really limit number of useable stm32 analog inputs towards 20ish. https://github.com/rusefi/rusefi/issues/3350 is currently the most promising idea in this area, with multiple stm32 chips being the next one.

You remember that we already have three stm32 on board? Today I've nearly typed up a ticket suggesting that we start using those secondary chips for extra analog inputs.

Anyways, as I said my preference is a phone conversation but that's just background.

[bill]

Well I don't have any actual hardware yet, but I decided to start working on the software side of RusEFI.

A little about my car: I decided to transplant a new-ish motor (BMW N20, turbo 4-cyl GDI) into an old-ish car (BMW E46).

do you have some pictures of the car? and engine?

i have a VEE12 bmw, that is looking for a chassis to transplant into

[ssmith]

Here are some not great pictures. Try not to mock my wiring

1.jpg (1.68 MiB) Viewed 6238 times

2.jpg (1.63 MiB) Viewed 6238 times

[AndreyB]

So I built a second computer to handle boost, some sensors, etc

Can you please elaborate with maybe two pictures of said computer? Would be worth 2048 words.

[ssmith]

So I built a second computer to handle boost, some sensors, etc

Can you please elaborate with maybe two pictures of said computer? Would be worth 2048 words.

It's in the picture of the interior of the car. From left to right there's my made up PDM (I don't recommend that as a project), my boost controller, and the Link ECU (you can see the sticker).

Boost controller uses a Cinch ME case with two Molex 20-pin connectors.
NXP MKE18F MCU, 5V capable ARM M4f 64-pin chip with tons of analog inputs - maybe you guys can consider using this for extra analog inputs?
three BTN8982 for valvetronic/variable valve lift
TLE9201 for electronic wastegate
three BUK9M15-40H for accusump, blow off valve, and oil pressure control (forgot to mention, the N20 has user controllable oil pressure)
MCP25612FD for dual CAN bus
MCP2221A for USB (also controls reset and bootloader pins so I can reinstall on an MCU even if my code is completely broken)
AP22652W6 for external 5V limiting (I don't like having a separate 5V bus for user sensors as I don't want to deal with error % introduced by different regulators)
14 digital/analog inputs with just a simple pull up following by RC, relying on the protection diodes of the MCU. RC is 5kO/33nF for analog, 100kO/330pF for digital.

It's mostly wired on the top layer with 6 traces on the bottom; middle two layers are ground and bottom layer is split 12V and 5V. Pretty simple layout but I spent a ton of time mapping the pins to make it possible.

[ssmith]

Ohhh you are touching a huge topic. I would love to discuss this further but open question is what is the best format and when would that communication be most effective.

For multiple reasons forum long form is my third preference. One on one voice over phone with screen sharing is the best remote medium for me, would you be interested to sync up like that at some point?

At the moment I am taking a break from our group chat Slack which is usually my second choice.

Posting for posterity as requested by AndreyB -
Had a chat over the phone, and touched upon:
1. For in depth conversations like the one we just had, phone works best (Slack loses history, requires too much attention, low efficiency for longer conversations). Forum posts sound great in my head but don't always come out the way I was thinking (but at least I can go back and edit)
2. I am not particularly tied (or care about) STM32, but I do prefer Arm for my designs. JlcPcb doesn't seem friendly to non STM32 MCU which means if you manufacture for production, you're choosing STM32.
3. I think RusEFI should take on more HAL than just using ChibiOS, at least for the really important stuff - high res timer (microsecond timer - looks like there's already some Stm32 specific code), software PWM out, input capture, and ADC. AndreyB wants to leverage external code as much as possible to focus on core logic but I think with the right HAL core logic becomes simpler.
4. I am a systems programmer, so I'm happiest in C++ / HAL / OS type code.

[nmstec]

Honestly for Analogue signals and such I'd recommend offboard computer anyway. On 99% of cases 8 is more than plenty. And as most other manufacturers do, if you need more, they develop a canbus module to handle those cases. (Haltech, EGT sensors, WBO, etc).