rusefi.com

The challenge of rusEFI as of 2019 is the fact that hardware is way ahead of software at this point. With just a few programmers and the complexity of the project, it would be a while until normal users would be benefiting from rusEfi because of the complexity and knowledge required.

But if for any reason you would prefer to use rusEfi and look for any specific feature, money can probably help you! Myself and a probably at least a couple other developers would be willing to accept payment to develop features you are unable or unwilling to develop yourself. This does not mean I will not be constantly working on improving the code, only that I will take money to change my focus to something you want me to develop instead of what *I* want to develop

I am available for any custom work at a fixed $150 per hour rate - whatever would positive result of such paid work would go into the official publicly available open source version of the firmware. There is a serious probability that there are cheaper yet equally or more qualified people available for custom feature development, so here is the thread to discuss this.

See also https://github.com/rusefi/rusefi/blob/master/misc/Strategy_2019.md

FAQ

Q: "does this means that rusEfi feature work is stopped until there is $$$"?

A: No, this means that rusEfi is a hobby project. Every developer is volunteering their time and mostly focuses on what he/she personally wants to work on. If one really want a specific feature to move forward while developers are not volunteering to work on that feature, we shall harness the power of market economy to bring together the demand and action.

you forgot "/it"
sorry, couldn't help adding that remark.
just wondering, are there any girls doing rusefi?

Hello all,

Do we have a place where we can enumerate the features that would be needed?
The winter holidays are closing in and i would like to make some time to develop something, right now i am playing with the idea to make an ardu-stim and connect it to the microRusEfi board but beside this i am playing with the idea:

-> create a small ecu with the following features:
- Knock -> two microphones
- O2 with the CJ125
- EGT?
- Can interface
- serial interface for debugging/config
- VR inputs for wheel sensors?
- small STM32F1xx? as a base
- boost controller (this would be included just tu extend a diesel car that we equipped this year with biturbo and the oem ecu cannot control them both)

I am targeting DRAG applications and i would like to use microRusEfi but i do need some extra inputs and this would extend it nicely via CAN interface, making it available to connect it to a dashboard as well.

The issue is that i am new for kicad so probably the schematic will eat all my time

md_sanci wrote: ↑

Wed Dec 04, 2019 8:42 am

Do we have a place where we can enumerate the features that would be needed?
...
The issue is that i am new for kicad so probably the schematic will eat all my time

https://github.com/rusefi/rusefi/issues is where we track issues and requests

If you can write software, please focus on writing software. I am sure you can convince someone to design a custom board for you if you show firmware progress

Hi!

If you need Boost control, I have it working in both open/closed loop.

960 wrote: ↑

Wed Dec 04, 2019 1:11 pm

Hi!

If you need Boost control, I have it working in both open/closed loop.

KNeJIE5K4m.png

AiEkVxuRdH.png

Is it available in the repository? if yes that is a good news since i am playing with the idea to convert my w202 C180 to turbo

20 US Bounty to make launch control properly working!

atntpt wrote: ↑

Thu Apr 16, 2020 9:27 pm

20 US Bounty to make launch control properly working!

Another 20 for launch control!

Not sure if this is possible, but I'm wondering if code could be added to allow for a "piggy back" tuner for stock ECUs?

for example, rather than having to re-wire most or all of the stock ECU wiring, the Rusefi could simply intercept the crank sensor and MAP/MAF signals
and allow augmenting of those to either add or subtract fuel, and advance or retard the timing.

Years ago i used such a system, i think it was called "perfect power", to tune EFI cars and trucks that had no other options.
It used a lowly ATMEGA328 IIRC. It was actually very useful and effective.

This is not really a software issue, it's more a hardware issue. See this thread https://rusefi.com/forum/viewtopic.php?f=4&t=454

Joey120373 wrote: ↑

Wed Jun 03, 2020 11:01 pm

Not sure if this is possible, but I'm wondering if code could be added to allow for a "piggy back" tuner for stock ECUs?

for example, rather than having to re-wire most or all of the stock ECU wiring, the Rusefi could simply intercept the crank sensor and MAP/MAF signals
and allow augmenting of those to either add or subtract fuel, and advance or retard the timing.

Years ago i used such a system, i think it was called "perfect power", to tune EFI cars and trucks that had no other options.
It used a lowly ATMEGA328 IIRC. It was actually very useful and effective.

You can absolutely wire an ECU to operate as a piggyback. Snip injector wires, route to ECU. Tap in to crank/cam/sensors.

In all, it's not really a feature we're very interested in putting time towards. We're a standalone ECU first. If there's some hardware/software feature required to run a car, we'd prefer to just run it fully with rusEfi instead of a half-cooked piggyback solution.

Oh, was that the question, if we could piggy back the signals doing signal manipulation to make the OEM ECU dump more fuel, etc. I've seen that with I think it was UTec. Holly crap that's an easy way to trash your engine. I suggest avoiding that type of thing. You would be better off putting banana's in your gas tank.

kb1gtt wrote: ↑

Thu Jun 04, 2020 12:37 am

Holly crap that's an easy way to trash your engine. I suggest avoiding that type of thing.

Exactly why I'd like us to avoid it.

Holly crap that's an easy way to trash your engine.

This could be said of just about everything related to any aftermarket EFI system, or performance part ever invented, i don't see the logic.

Again, maybe i did not explain it well.

RusEFI, or any tunable EFI system for that matter, you are reading inputs and the "tuning" is altering the computer does with those inputs to effect the outputs .

All i suggested, is altering the inputs of a working system to change what it outputs.

Most of what we are looking to do with an aftermarket ECU is gain control over the fuel ratio and spark timing. With a fully functioning (v8) existing system, yes, i can cut 8 injector wires, 8 coil wires, tie into the Crank sensor signal, MAF or MAP, TPS, CTS, IAT etc and have full control over the fuel and spark. and now i also have to build the fuel and spark tables, and all associated trims to those tables, from scratch. And I also have every opportunity to trash my engine by not tuning it correctly, or mis-wiring something.

Or i can tie into just the Crank sensor signal, MAF or MAP, and TPS, modify just 2 of them and achieve exactly the same end result.

this is the product i was referring to:


https://www.perfectpower.com/index.php/products/piggy-back/smt8

back when i did a lot of tuning, i used a previous version of this. As i said, for a vehicle that already had an existing EFI system, it was a very simple and effective solution.

A key difference with rusEFI is that rusEFI knows what happens in the middle. With ECU manipulation you are trying to control an unknown. The general process is something like this.

inputs --> logic, physics and math --> outputs

vs

inputs --> Top secret not for your eyes black magic specifically and intentionally designed to make it hard for you to do this --> outputs

For some of us, knowing what is happening is of significant importance. We do Open Source so we can know exactly what is happening. Because of this tendency, I don't think you'll ever find an open source ECU manipulation effort. I know several of the core developers here are not interested in sinking resources into this kind of effort. It's just not interesting to us. We have no problems with controlling engines in a method where we know what is going on, so we have a lack of interest in controlling them with a room full of monkey's in the middle. The next issue is that the only reason you want ECU manipulation instead of replacing the ECU, is because you want to bypass safety and emissions design considerations. We are not interested in picking that kind of fight. That is a fight that the government will win. We are also not interested in sinking resources into debating with you about this feature. If you want to develop it and share it, we might find it interesting to see what you did, but from what I have seen, we are not interested in developing it ourselves.

Kb1gtt,

I completely agree with what you said about wanting to know, and having full control over, what is happening between the inputs and outputs.

And I would much rather those of you that can contribute to the advancement of the code spend your time on what interests you.

Just a thought: with all these wireless connectivity options, security becomes sort of a concern. I'd suggest to implement a 'read-only' mode for such communications, to be enabled/disabled either with a physical jumper or a password-protected checkbox.

puff wrote: ↑

Mon Feb 22, 2021 9:37 pm

Just a thought: with all these wireless connectivity options, security becomes sort of a concern. I'd suggest to implement a 'read-only' mode for such communications, to be enabled/disabled either with a physical jumper or a password-protected checkbox.

Is WPA2 (wifi) or a Bluetooth PIN not adequate?

In a hostile environment, nope.
Bluetooth is a joke. Totally vulnerable to brute force plus the keyspace is tiny.
WPA2 is close but still dicey.

See also https://github.com/rusefi/rusefi/wiki/Standalone-on-Demand

It would be nice if pin selection drop-down list in tuner studio displays only pins that are actually available for the feature, e.g. vss input can only be assigned to pins of a certain category. Moreover, AFAIK, can, usart or spi (if at all available), is assigned to couples or groups of pins, i.e. i wouldn't be able to set rx pin to usart1, tx to usart2. However, it is probably possible to set it for receiving or transmitting only, leaving the other pin unused and available for other features (of that is supported by mcu).

puff wrote: ↑

Sun Aug 15, 2021 8:21 am

It would be nice if pin selection drop-down list in tuner studio displays only pins that are actually available for the feature, e.g. vss input can only be assigned to pins of a certain category. Moreover, AFAIK, can, usart or spi (if at all available), is assigned to couples or groups of pins, i.e. i wouldn't be able to set rx pin to usart1, tx to usart2. However, it is probably possible to set it for receiving or transmitting only, leaving the other pin unused and available for other features (of that is supported by mcu).

We already do this.

The focus of this specific topic is really on the "bounty" part, not on the "request" part.

My bad, was innatentive reading first post..

I am putting a $200 bounty on https://github.com/mck1117/wideband/issues/7

$bottle of bourbon from KY for getting boost control working on Hellen 128

duhafnusa4 wrote: ↑

Tue Aug 31, 2021 3:08 pm

$bottle of bourbon from KY for getting boost control working on Hellen 128

Please be much more specific either on github or in a separate forum thread like https://rusefi.com/forum/viewtopic.php?f=5&t=1541

How much someone would charge to make a stock “rom” for VQ37?