RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Tue Dec 12, 2017 4:26 am

All times are UTC - 5 hours [ DST ]





Post new topic Reply to topic  [ 271 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19  Next
Author Message
 Post subject: Re: Speed Density FAQ
PostPosted: Fri Dec 30, 2011 4:07 am 
Offline
Moderator

Joined: Thu May 20, 2010 4:01 am
Posts: 2866
Location: Johannesburg, South Africa
I lean towards option c as well. Having used the 'load / maf' hack before for different reason (ie underscaling injectors) I found that AF correction swung much wider due to the 'feedback loop' being off. I'm also sure there are many other load based tables not yet defined that are not being amended, potentially causing problems.

_________________
He who dies with the most gadgets wins.

Please do not PM me - use the email option.


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Fri Dec 30, 2011 4:18 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 1:46 pm
Posts: 852
In my research, I found that VE on a turbo motor is pretty much always under 100%.

The compressor is just a roundabout way of increasing the volume of the motor, and you could see 100+ % VE if it weren't for the turbine restriction.

I'm currently running solution A, but C would do just as well.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Sun May 20, 2012 11:04 pm 
Offline
Newbie
User avatar

Joined: Thu May 28, 2009 6:13 pm
Posts: 53
Location: Liverpool, NY
Any plans to eventually add anti lag and a way to control rotational idle like the CarBerry Rom? I'm currently using a 16bit ECU, but have all the stuff I need to convert to 32bit sitting in my garage. I imagine ALS on a throttle by wire system would a bit easier to tweak since it can "throttle kick" itself, but that's my lack of programming skills talking. Either way, its great to see development in SD.

Thanks,
Garrison

_________________
CNY SCCA Solo #27 SM - EJ257 Hybrid / 06 WRX Drivetrain // 2005 Forester XT


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Mon May 21, 2012 12:36 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 1:46 pm
Posts: 852
Yep, keeping my fingers crossed to get some spark cut testing in this weekend. Once I have the ability to cut spark (X from Y), adding features like anti-lag and rotational idle should be straightforward.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Wed Jun 06, 2012 2:48 pm 
Offline
Senior Member

Joined: Fri Feb 10, 2006 7:04 pm
Posts: 2140
Location: Pittsburgh, PA
NSFW wrote:
And, whatever the reason for the discrepancy between SD-calculated-MAF and sensor-MAF, what should we - the people working on open-source SD hacks - do about it?

A) Do nothing, and just get used to VE tables that claim the engine is over 100% VE most of the time.

B) Do nothing, keep the VE percentages reasonable, and just get used to MAF and load numbers that are about 30% smaller than usual. When switching from MAF to SD, tuners will need to rescale all of the tables to accomodate for the fact that the calculated load will be about 30% smaller than before. This would be a pain in the ass, and it would not be practical switch between SD and MAF modes just by toggling the 'enable' switch that Merp added. Also, data logs wouldn't make sense unless you know what fueling mode the ECU was using, because the MAF and load values would be so different (that's a minor issue today due to injector scaling discrepancies, but this would be quite a bit worse).

C) Add a magic multiplier to the code so that you can keep realistic-looking numbers in the VE table and yet still end up with familiar MAF numbers. No table rescaling necessary. Merp's enable/disable switch would let you easily switch fueling modes. We could even add a fallback mechanism so that if the MAP sensor fails, the car switches to MAF mode.

I lean toward C, because having a hidden magic number that makes everything align bothers me slightly less than having VE > 100% across the board.

Put your OCD away. Choose option A. Relabel the VE map to say 'SD compensation (3D)' and get on with tuning.

_________________
OpenMS41 Project Leader & Co-Developer (2012 - present)
- IDA/ECU/Engineering Analysis
- Original E36 USDM M3 MS41.2 ECU Editor Definitions
- Technical Writing & Support


Donations Appreciated : http://www.paypal.me/AbhishekShinde


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Wed Jun 06, 2012 2:51 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 1:46 pm
Posts: 852
mrf582 wrote:
NSFW wrote:
And, whatever the reason for the discrepancy between SD-calculated-MAF and sensor-MAF, what should we - the people working on open-source SD hacks - do about it?

A) Do nothing, and just get used to VE tables that claim the engine is over 100% VE most of the time.

B) Do nothing, keep the VE percentages reasonable, and just get used to MAF and load numbers that are about 30% smaller than usual. When switching from MAF to SD, tuners will need to rescale all of the tables to accomodate for the fact that the calculated load will be about 30% smaller than before. This would be a pain in the ass, and it would not be practical switch between SD and MAF modes just by toggling the 'enable' switch that Merp added. Also, data logs wouldn't make sense unless you know what fueling mode the ECU was using, because the MAF and load values would be so different (that's a minor issue today due to injector scaling discrepancies, but this would be quite a bit worse).

C) Add a magic multiplier to the code so that you can keep realistic-looking numbers in the VE table and yet still end up with familiar MAF numbers. No table rescaling necessary. Merp's enable/disable switch would let you easily switch fueling modes. We could even add a fallback mechanism so that if the MAP sensor fails, the car switches to MAF mode.

I lean toward C, because having a hidden magic number that makes everything align bothers me slightly less than having VE > 100% across the board.

Put your OCD away. Choose option A. Relabel the VE map to say 'SD compensation (3D)' and get on with tuning.


I've gone with C. If people want "accurate" values, edit the multiplier. Otherwise get to tuning :mrgreen:

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Wed Jun 06, 2012 3:08 pm 
Offline
Moderator

Joined: Thu May 20, 2010 4:01 am
Posts: 2866
Location: Johannesburg, South Africa
mrf582 wrote:
Put your OCD away. Choose option A. Relabel the VE map to say 'SD compensation (3D)' and get on with tuning.


Chuckle, that was my choice in the end...

_________________
He who dies with the most gadgets wins.

Please do not PM me - use the email option.


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Mon Jul 16, 2012 7:33 pm 
Offline
Newbie
User avatar

Joined: Tue Jun 02, 2009 10:20 pm
Posts: 52
Been searching around but not finding many results for what people are actually doing..
For those of you running SD, where did you install your IAT sensor? I'm planning to put mine in my FMIC charge pipe right before the throttle body. Ideally I'd like to remove one of the TGV-deleted intake risers and install the sensor there, but I'm not sure if it's worth the hassle or a good idea with fuel spraying nearby. I'll be running MAF and testing the new sensors out before I switch over.

_________________
-Franz
2005 Subaru Legacy GT 6MT w/ twin scroll EFR 7163


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Mon Jul 16, 2012 8:03 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 1:46 pm
Posts: 852
On my personal car, I run the oem MAF/IAT in a cold air intake. While not perfectly accurate, as Freon originally wrote in the SD Faq... it's good enough and runs well when properly tuned.

With that said, on the next build up I will be adding a manifold IAT sensor using the OEM MAF sensor IAT element siliconed into a pipe-plug.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Wed Jul 18, 2012 1:17 am 
Offline
Moderator

Joined: Wed Nov 22, 2006 10:23 pm
Posts: 2428
mrf582 wrote:
Put your OCD away.


:lol:

I earned that.

_________________
2005 Legacy GT w/ ATP 3076, IWG, MBC, BCS, BC 272, LC, FFS, OMG
Please don't send me tuning questions via PM - use the forums instead. Thanks!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Thu Aug 09, 2012 11:35 am 
Offline
Senior Member

Joined: Fri Feb 10, 2006 7:04 pm
Posts: 2140
Location: Pittsburgh, PA
FFS:

The 16-bit Carberry SD ROM uses a significantly better FFS algorithm. It actually figures out what gear the transmission is in, then based on the programmed gear ratios, it actually matches the FFS rev limiter to the vehicle speed. This keeps the gear changes smooth no matter what RPM you shift at. With your current implementation, you pretty much have to shift at the same RPM everytime for a smooth shift.

Any chance you'll be able to alter your algorithm to match that of the Carberry ROM? I'm sure Jason wouldn't mind working with you on that.

_________________
OpenMS41 Project Leader & Co-Developer (2012 - present)
- IDA/ECU/Engineering Analysis
- Original E36 USDM M3 MS41.2 ECU Editor Definitions
- Technical Writing & Support


Donations Appreciated : http://www.paypal.me/AbhishekShinde


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Thu Aug 09, 2012 1:18 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 1:46 pm
Posts: 852
I was thinking about this the other day, and started coding something up.

It will require another FFS enable threshold for rpm (when the clutch is initially pressed) to be compatible with downshift rev matching.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Thu Aug 09, 2012 1:34 pm 
Offline
Senior Member

Joined: Fri Feb 10, 2006 7:04 pm
Posts: 2140
Location: Pittsburgh, PA
Or just set the TPS threshold for FFS really high. Like 95+%. When I rev match downshift, the TPS never goes above 95%.

_________________
OpenMS41 Project Leader & Co-Developer (2012 - present)
- IDA/ECU/Engineering Analysis
- Original E36 USDM M3 MS41.2 ECU Editor Definitions
- Technical Writing & Support


Donations Appreciated : http://www.paypal.me/AbhishekShinde


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Fri Sep 28, 2012 9:58 am 
Offline
Newbie

Joined: Fri Nov 19, 2010 10:48 am
Posts: 8
Went to this map a few days ago and after a few hours of tuning I can't believe the results compared to my 83mm MAF setup. Never going back.


Top
 Profile  
 
 Post subject: Re: Speed Density FAQ
PostPosted: Sun Nov 25, 2012 12:44 am 
Offline
Newbie

Joined: Sat Jul 07, 2007 1:47 am
Posts: 38
Merp wrote:
Yep, keeping my fingers crossed to get some spark cut testing in this weekend. Once I have the ability to cut spark (X from Y), adding features like anti-lag and rotational idle should be straightforward.


I have deep interest in this. Let me know if you need a tester for A2ZJB11J


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 271 posts ]  Go to page Previous  1 ... 14, 15, 16, 17, 18, 19  Next

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


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 © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl