Cobb vs UpRev

Denny McLain

My feeling also and really why I posted it. By pure luck I need to change it the most where there are the most points. Guessing it may have something to do with the ECU as I don't see the logic.

1slow370

The target AFR is only supposed to be a guideline. It tells the ecu about where you want the AFR to be so it should be set around 12.5-12.8 and leaner down low near idle midrange. You change the MAF tables to tweak how the engine runs or the VE tables which it doesn't look like you have access to. Target AFR is there to tell the ecu when to start correcting itself. You need to change the air flow tables to make the ecu run right in the first place in order to give you the afr values you want. Both tables need to be changed in order to work together but the Target AFR table shouldn't have to be changed that much maybe a few points here and there.

Basic guide to nissan tunning
http://www.plmsdevelopments.com/file...ing_basics.pdf

Denny McLain

Except for the fuel/air guideline ratio's, that is basically what Cobb is saying to fine tune. The gross tune does come from the fuel tables as I have both the stock one and the Cobb table to compare. No one seems to know (including Cobb as Calvin admits they are in a learning curve) or if someone does, are not willing to tell what is the best general AFR. Cars will vary and it's what that particular car likes best. (My Corvette liked around 13.3 to 1 - FYI, Pro Stock runs in the mid 14's - Forced induction in the 11's)

These cars appear to be different if that is the way to go as that is not what the tuners I'm used to dealing with do and certainly not what I've done in the past. (Yes, I'm an old Corvette, Chevy guy but owned a lot of imports also)

It used to be the first thing I did was either buy a larger Billet MAF or port the existing one. (More flow is better right?........ Only if it needs it Home!!) Found out later it made them harder to tune. The current trend among the people I talk to is to stay away from playing with the MAF, use stock tables as the only way to go.

Different strokes for different folks and what works.....works. An old dog can change his stripes. I'll read the guide as the software in it looks more like I'm used to as the Cobb software is certainly different. Certainly is a learning curve to all of this.

Thanks for the guide.

1slow370

you can always do what we used to to find out what works. Simply find someone with a technosquare tune as it makes the most power right now and rip it from thier ecu then copy and paste baby Used to do it with .bin from the mclaren special grand prix tgp turbocharged 3.1 l engine when running forced induction on our cars. I'm sure you could rip the nismo tune too.

Denny McLain

I doubt the Nismo tune is nothing more than raising the red line. I'd be very curious as to the Technosquare tune as I'm still wondering if the Cobb tune helped or not. (yes, the air/fuel changed) Or...... is it a matter of different dyno's or...... the computer somehow needs time to learn and is holding it back as the car did not immediately respond. May make another trip to Cobb and see if I can get another baseline on their dyno to compare apples to apples.

1slow370

Ok and a minor update on the Cobb vs. Uprev issue Apparently Uprev exists they just won't give it to us yet but it is in fact in use and will say no more than that for now.

Hi-TecDesigns

Reading this thread with heavy interest as I'm trying to decide which system will prove more useful. I'm an EE that does embedded hardware/firmware design, so I can attest to the fact that reverse-engineering a system is not easy, though certainly doable with enough time.

I have no specific knowledge of what any particular company is doing, but in uprev's case the use of a complete custom OS may be a bit of a misnomer. By the time all modifications are made I imagine it would appear to be completely custom, but it most likely grew out of the stock system little by little. My approach would be similar to the following:
1) Determine where maps exist (regardless of what they do), not terribly hard as they usually consist of large chunks of slowly changing values
2) Once these are known, it's a fairly simple matter of determining the code that access each maps (still may not know what each does).
3) Modify code form step 2 to branch to another location, one that includes custom code allowing for returning map data from multiple custom maps located elsewhere in memory.

This is only the beginning, mind you, but it would allow for a fairly quick modification of a stock ECU to run with (multiple) custom maps. Granted, it does not grant the programmer with any special knowledge as to what those maps actually do (that's where the experience with tuning helps to recognize data), but it shows you how easy a simplistic mod can be. Understanding what effects any changed maps will have on other portions of the system is beyond the scope of such a simplistic change, and that's where the time sink comes in.

On to our coding exercise:
4) Trace back sensors to the processor pins (not always easy due to multi-layer PCBs).
5) Pull out processor data sheets to determine what pieces of code are accessing each of those pins.
6) Start making connections between each piece of code identified in step 5) and the maps those same pieces of code access.
7) Begin to see a pattern emerging, then realize you've merely had too much Red Bull and Twinkies.
8) Put down Red Bull and Twinkies, then start praying you still see a pattern emerging.

That's the process, in a nutshell. It's not necessarily difficult, but it is slow, tedious, and often times not straightforward.

So, who'll be the first to tell me to ?

__________________
http://hi-tecdesigns.com/images/pict...on%20Small.gif
2000 S2000 Brickyard Red Metallic w/ Romanesque Crimson Kandy, custom everything else