gemellocattivo.com

Which means "Evil Twin". Lets see your projects where you change boring into fun or create the fun from scratch.
It is currently Thu Mar 28, 2024 11:54 am

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed Oct 28, 2015 6:25 am 
Offline

Joined: Sat Jan 03, 2015 5:40 am
Posts: 208
For my engine build, I plan to use 12 ITB's with individual filters and no common air boxes, hence no MAF sensors.

For load sensing I will only have MAP and TPS, however I wish to be able to synthesize a MAF signal for the OEM ECU's, which will still be "somewhat" in the system, but not actually running the engine. However, I want to try and keep them happy and not throwing MIL's or CEL's

Would anyone have ideas how to synthesize a MAF signal? I understand the MS III does this?


Top
 Profile Send private message  
 
PostPosted: Wed Oct 28, 2015 7:45 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
cribbj wrote:
For my engine build, I plan to use 12 ITB's with individual filters and no common air boxes, hence no MAF sensors.

For load sensing I will only have MAP and TPS, however I wish to be able to synthesize a MAF signal for the OEM ECU's, which will still be "somewhat" in the system, but not actually running the engine. However, I want to try and keep them happy and not throwing MIL's or CEL's

Would anyone have ideas how to synthesize a MAF signal? I understand the MS III does this?



The first step is calculate the MAF, which the model I have does, but it will probably need one more line of code to make it 6 cylinders of MAF.

Then we just need to know how the sensor you have works? If it's a frequency based thing then we can send the calculated MAF to and PWM output with an appropriate pull-up voltage (this is probably the type an MS3 could support). If it's a 0-5V signal its tougher because you need an analog output which the ecu doesn't have....a high frequency PWM with a filter maybe?


Top
 Profile Send private message  
 
PostPosted: Wed Oct 28, 2015 11:10 pm 
Offline

Joined: Sat Jan 03, 2015 5:40 am
Posts: 208
Thanks Mark - the MAP sensor I'd planned on using is definitely 0-5v, however I really don't need one quite as fancy as I'd planned, so am flexible if a PWM based MAP would be easier to work with.

On the MAF, I've forgotten what type of Bosch MAF sensor Ferrari uses, and whether it's analog out or frequency out.


Top
 Profile Send private message  
 
PostPosted: Thu Oct 29, 2015 5:26 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
Are you going to buy the haltech simulator?

enginelab is also going to have a simulator....but you might have enough channels in the -8/-10/12 to do what you need with some external stuff to make good analog outputs. There is a crank simulation funtion so you can output the correct crank and cam signals to say tell the ECU it's at 1000 rpm, then all your analog signals just become simple voltage dividers I'd think.

I still think though that we can figure out what the OBDII signal is supposed to look like and make it happen in the real ECU.


Top
 Profile Send private message  
 
PostPosted: Thu Oct 29, 2015 10:23 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
If the OEM ECU isn't running the engine, what is it doing? Would it be easier to remove it entirely?

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Thu Oct 29, 2015 11:57 am 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
If the OEM ECU isn't running the engine, what is it doing? Would it be easier to remove it entirely?


OEM ecus do a lot of things these days but all most ECUs will do is run the engine so with an engine simulator you make the ECU think it's running the engine so everything else works (ABS or trans or dash, etc and most importantly OBDII ) and let the new ecu run the engine. This lets you can live with WAY less ECU processor and pins saving a money and time in the upgrade.

In this case though I think it's only the OBDII port that needs to still function.


Top
 Profile Send private message  
 
PostPosted: Thu Oct 29, 2015 1:27 pm 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Fully faking an engine with no codes set is extremely difficult. Most OEM ECU's can detect engine simulators, even the ones which are used for their own development. It's not their intent to detect a simulated engine, but the simulation must be extremely detailed for the ECU to believe it.

If it's a really new car, it probably uses UDS https://en.wikipedia.org/wiki/Unified_D ... c_Services over CAN which isn't that hard to implement in software
If it's older, then there are a variety of options which it could be, and it's probably not on CAN, and that is quite unfortunate.

For other bus features (ABS or automatic trans), it's a lot more work.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Thu Oct 29, 2015 6:09 pm 
Offline

Joined: Thu Jan 01, 2015 6:47 pm
Posts: 4251
apalrd wrote:
Fully faking an engine with no codes set is extremely difficult. Most OEM ECU's can detect engine simulators, even the ones which are used for their own development. It's not their intent to detect a simulated engine, but the simulation must be extremely detailed for the ECU to believe it.



hmmmm...Haltech has a product for this purpose

http://www.haltech.com/product/accessor ... ntrollers/

and enginelab is probably going ot have one...but I know newer ecus all test sensor function so just sending a voltage to the input is probably not enough now that I think about it.

You might be right.


Top
 Profile Send private message  
 
PostPosted: Fri Oct 30, 2015 12:17 am 
Offline

Joined: Sun Oct 11, 2015 2:07 pm
Posts: 134
Per OBD2, every emissions-critical sensor/actuator requires a 'rationality'. This is an algorithm which compares the sensor readings to another sensor or a model to check that the sensor readings are reasonable, even if the sensor passes short/open circuit checks. For actuators this makes sure that e.g. a linkage or hose isn't disconnected or something like that.

For a few super critical sensors (usually just the throttle and pedal), this is provided by a fully redundant sensor. Prior to ETC, no sensors had true redundant pairs.

Usually they will try to rationalize the sensor data to a model or a similar sensor. For example, coolant temperature might be rationalized to oil temperature if there's a sensor for that. Throttle and MAP will probably be rationalized to each other. MAF will be in on it too, if the engine has one. Inlet air temp is probably rationalized to ambient temp provided by the vehicle (most cars have a sensor for that now, although some use the engine air temp sensor). Coolant temp is probably rationalized to an engine thermal model of warmup/cooldown also.

If the engine was not originally electronic throttle, and you are forwarding all real sensor data to the older ECU, and all of the appropriate loads are connected (e.g. inductors/resistors for fuel injectors), there is a good chance it won't set a fault for rationality. If any of the data is fake and not modeled very well, it probably will notice but it might take time or only set under some conditions.


In addition to rationalities, there are major monitors which are also part of OBD2. Major monitors can take a long time to detect and pass/fail, and report if they have run to completion yet in addition to if they passed. They include misfire, fuel system, catalyst, evaporative, EGR, secondary air, O2 sensor performance. Evap diagnostics takes days to test.

Misfire shouldn't be set with simulated crank signals, however the ECU will look for crank speed oscillations with compression/firing. Fuel system could set, depending on how you fake the data. Catalyst monitor uses the upstream and downstream O2 together to determine catalyst health and you probably can't fake it. Evap will fail if it is disconnected but it will take a few days to set, unless there is a circuit fault (disconnected valve or sensor) which would be detected quickly. Resetting the module (unplugging) should start over with all of the major monitors and some of the models for rationalities.

If the ECU does an intrusive test and doesn't see a response, it can also fault. This is infrequent but does happen. In this case, the ECU diagnostics take control from the normal software to try to drive a sensor response by moving an actuator. This proves that the actuator is moving correctly. Normally, they try to look at sensor data immediately after an actuator moves normally to see a response but in some cases they will force the actuator to move to look at the response.

I think Haltech's box doesn't even include a processor, it's just a few inductors and resistors. You could probably make something like that quite cheaply.

_________________
"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

"Any sufficiently advanced technology is indistinguishable from magic" ~Arthur C. Clarke


Top
 Profile Send private message  
 
PostPosted: Sat Oct 31, 2015 8:22 pm 
Offline

Joined: Sat Jan 03, 2015 5:40 am
Posts: 208
The idea is to run an aftermarket ECU (like the Enginelab that Mark is putting together) in parallel or piggyback with the OEM ECU's. The OEM units will have all the original sensors as inputs (except for MAF, which will hopefully be simulated somehow), but the OEM ECU's will be "firing" into the Haltech injector/coil simulators.

The aftermarket ECU(s) will be sharing all the input sensors with the OEM, however it/they will be firing the actual injectors & coils.

This engine/car is a first generation OBDII Motronic 5.2 setup, so there's lots of things that didn't work that well, such as misfire detection. Too it's still using mechanical throttles instead of DBW (Thank God), and all the dash is analog, not digital. The ECU's are synchronised to an extent over CANBus, but again it's a first gen implementation. Ferrari only used these ECU's for 2 models of cars, then went straight to the Motronics 7.1.x series.


Top
 Profile Send private message  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group