Can any of you who use VT on series 1 take a look at the Dashboard and the auxiliary port valve status (values 0 -4) and tell me what it reads for your car at idle, please?

Both of my '8s are always showing "4", regardless of RPM, and so did my previous one. This leads me to believe they've all been stuck open, which seems strange, even though they are notoriously prone to it.

I contacted VT with this question and they responded, saying: "We need to perform additional testing with those parameters to verify the scaling, but our test vehicle needs some fixing before we can do that."

Thanks, guys.

 

I've never bothered to use that data channel.
I normally look for the different ports opening by dips in the Injector Duty Cycle, AFR or Calculated Load changes.
I'll try and get out today and see what I get.

Just a couple thoughts and I see you are corresponding with VT:
- There are two tables for the Auxiliary Port Valves in VT - APV 1 and APV 2. I don't know why, I'm pretty sure the APV servo/actuator opens both sides at the same time.
- VT stock map has APV1 opening at 6250 rpm and APV2 at 6100 rpm. Why? <shrug>
- Furthermore there is only a single dashboard channel to monitor the "Auxiliary Port Valve Status". What do the numbers mean? Does this one channel monitor both APV valves? <dunno>
- We know that some of the parameters VT will allow you to monitor don't really do anything (Desired AFR and Knock, off the top of my head)
- I'm still trying to wrap my brain around what exactly the Desired Torque table is actually effecting. Does it actually do anything?

TBH I wouldn't hold a lot of weight in that parameter. But I'll try and check it out today so we can get a another data point.

Side note: I thought it was the SSV that was prone to sticking and the APV electric servo would just fail (Open or Closed)? Particularly in a turbo application due to heat exposure. But I guess anything can get stuck.
(just what I thought I had read in other posts)

 

Yes, regarding sticking valves that all sounds correct; SSV is prone to sticking due to carbon buildup and APV(s) are prone to getting "stuck" in whatever position they're in when the electric motor fails.

I had noticed the 2 separate tables for APVs but hadn't made the connection that they're connected and should each open at the same time. Talk about redundancy! Another point of contention and source of unnecessary confusion. It's finally sinking in that VT is notably devoid of substance in some pretty fundamental areas...but at least it has launch control! LOL 😂

I'm curious to hear what you find when you check your dashboard for APV values...pretty sure it should default to zero and then jump to 4 when revved above it's actuation point.

 

Alright. Looks like you are correct that your Aux Valve is not opening.
My Aux 1 and 2 are set to 6500 rpm and you can see that they open right that rpm as expected.



I can attach the log file if you wish to review all raw channel data.

 

Ok, cool. I will log a run and see what they're doing (or not doing).

Did you actually look at the value though? Being constantly at 4, I believe mine are stuck OPEN, but maybe "4" represents closed position? I've seen stranger things!

 

Looking at your graph closer I see where it identifies 4 as "max". Thank you!

 

(Hopefully this explains some other undesired behavior as well...)

 

Sorry I guess I should have used better colours and labels to distinguish the readings on that graph (DOH)

I look forward to your update.
g/l

 

Yep, there it is flatlining along the top of the graph.

I should've thought to do this before starting a thread about it!

Thanks for nudging me back in the direction of logic and common sense.

BTW, what do you think of the MOP graph? (black line)... does that seem normal to you? The output has been significantly increased so I thought it would look different. I think it is just the switch being monitored, but my understanding is that the switch is actually the sensor so it shouldn't be just an "on/off" reading...obviously I need to educate myself on that one next.

 

Huh, I don't use that parameter.
I use the "Metering Oil Pump Position" parameter not "switch"
I don't know what that switch is actually.
I've never had an issue using the "Pump Position" parameter.



Attaching my Oil Metering settings for your perusal.




I will try and get out today and do some data logging using the Metering Position and Metering Switch for you to compare.

 

Cool, thanks. That's useful as I just sorta upped the numbers of one of the VT tunes to use on this car because it has 180K Mi on the original motor and I just got it from the O.O. He never even premixed and the damn thing just gets up and GOES. Good comp #s. (There's no icon for blown mind here, but BANG.)

Anyway, I got my APV functioning again. Must've been a contact thing because I disconnected it to test the motor with a 9V battery and it worked; continued to do so after being reconnected. (Definitely would rather it be a contact issue than a sticking issue.)


That being said, now that it opens I'm doing a deep decarb on the LIM...hopefully that'll keep it from sticking for a while, what with the additional oil blowing around in there now.

It's about done soaking, actually.... gotta go make some smoke now (4am nobody calls the fire dept.)

 

LOL I love smoking out the neighbors.
You must really feel a difference now that the APV is working?

Now I did this logging with the Metering Oil Pump Switch and Metering Oil Pump Position parameters and noticed something odd right away.
FIRST:
The Metering Oil Pump Position logging values did not correspond to what I expected to see.
The values being reported are between 0.00 and 1.17 while I expected to see values that would match the Oil Injection - Load or Throttle tables.
(This also made me realize the last time I must have looked at the OMP Rate was using the Cobb AP which did report the values as seen in the table mappings)
I'm not sure how these values translate.

1st Screen shot
A Cold Start, the Metering Switch Position turns ON and the OMP Rate is Max (or what I currently believe to be max 1.17 value).
The OMP Rate remains at an increase level until the ECT is up to temp.
I'm not sure why the Switch Cycled from On to Off then On again briefly.



2nd Screen shot
Note the OMP Rates drop as the ECT rises.
Then the OMP Rate follows the Load as I pull out of the garage.
This is the same as I've seen on the Cobb AP except the recorded values reflect the Oil Metering tables. (So far so good)


3rd Screen shot
Now my route for Logging gives me suitable drive to bring the car up to temperature and 2 spots where I can open the taps.
I then have a safe place to pull-over and check that the log and save. Then turnaround and repeat on the way back home.
This first log shows under high(ish) load the OMP Switch turns ON and this wasn't entirely surprising to me.
Note the ABS Load, Accel Position, Metering Pump Position, because we are going to look at those again in the next screen shot.


4th Screen shot
At this point I've pulled over to save the log and start a new log for the drive back home.
The car has not been turned off, only a new log file started.
The entire drive back the log file indicates that the OMP Switch never turned again.
Trying to understand by correlating the Accel Pedal (WOT), the OMP Rates (isn't quite as high) and the Load (not as high) however I would have expected to see the OMP Switch = ON during peak load.
<shrug> I need to repeat this process a few more times and see if I can't figure out exactly what is the variable. I did switch to a slightly lower boost setting for the return drive but its enough to push it in to the 150% Calculated Load.


With all these questions I'm going to start by reading up on a thread posted by Brettus on the OMP
And do more testing/logging

 

Yeah, it's doubtful that I'd come up with much to contribute to this one, as the simple fact that the zero values in the last shot no longer line up is enough to confuse me. I'm sure you just moved things around. LOL

I did have a few thoughts though:
In the first shot from cold start the duration is only like 24 seconds or so. The unexpected cycling of the mop switch...isn't that right about when the smog pump would be doing it's thing? Maybe don't wanna be blowing extra oil onto a cat that's being forced to heat up? I don't suppose the mop has "knowledge" of the air pump having been deleted.

Also, maybe the mop switch is just a binary representation of the sensor? Sensor in max position = switch on? Doesn't explain the switch being off the rest of the time while the sensor is working its *** off folowing the load wherever it goes.

Maybe Versatune is just part fluff -- a significant amount of its tools/features being either superfluous or redundant?

Hopefully not! I can appreciate your determination to figure it out. Ill check mine and see if the behavior is the same, both before and after I adjust my MOP values.

 

On a separate but related note, I've used VT to help sort out the APV situation on this particular '8 and a few weeks ago I used it to disable (not using the term "mask" anymore because "disable" is the term VT uses although the former is more accurate) all codes associated with Secondary Air Injection System because I was getting P2259. Though I haven't removed the pump yet I disconnected it because it's failing.

Have been daily driving this car for weeks now without any CEL until today when it came back on, along with P0410, P0411 and P2259, which are all SAIS-related codes.

I'm not using VT to disable any other codes. Just SAIS-related.

This is the 3rd RX-8 I've used it on and the 3rd car to show me disabled codes, though not the same codes for each car.

REALLY wondering what's up with this program. This, along with numerous other issues including nonsensical table values and inconsistencies in performance have got me feeling like I'm not getting what I paid for.

That's all. No questions this time, just comments.

 

Having different numbers logged than what you see on the tables is pretty normal.

I didn't know the switch would come on during driving but it's not a surprise. My guess is that any time it reaches max setting ...the switch is triggered . And that the double swing of the rate on first startup is part of the self checking regime.

 

Hey guys one quick question I am considering Versatune....In your opinion is it worth it?

 

Thanks Brett. I guess it's just due to my limited exposure to tuning with only using Cobb ATR made me think I would see similar values in the log. I'm half tempted to switch back and see the difference now that I'm pretty use to VT.

And that makes sense about the OMP switch, thanks for the help.

 

That's honestly hard to answer because it depends on a few factors.
- What are you trying to accomplish?
- What are you comparing the VT product to, MazdaEdit? It's the only other ECU flasher I can think of..hmmm. Both come with pro's and cons.
- Are you going to tune it yourself or pay a pro tuner?
- are you looking for off the shelf tunes?
- Are considering an ECU flasher versus a Stand alone option? (I'm not sure if there are any piggy back solutions anymore)

 

I'm asking myself the very same question at this point.

It's useful but disappointing at the same time.

I've installed it on every RX-8 I've owned, so maybe that's saying something...

 

My personal experience with VT has been positive and I believe for my goals it has been more than worth the cost.
I purchased VT to replace my Cobb AP and ATR software which it has done perfectly and with (IMO) better software and support.
The Cobb was not without its own issues and poor table definitions and again sometimes you would wonder if they even did anything.

Maybe Brett or someone else that has experience with ME can chime in but I suspect ME might also suffer from poor table information (I'm guessing).

So I think that in terms of "is it worth it?" really needs to be quantified with your goals.

Is ME or VT worth it to mask a catalytic converter CEL - no not likely
Is VT worth it for the canned tunes (OTS - off the shelf) it offers on a stock RX8 - well I've never used any of them but I would say no
Is VT worth it for the canned tunes (OTS - off the shelf) it offers on a modified RX8 with aftermarket Coils, Intake, Cat delete - maybe (to me it's yes)
Is ME or VT worth it to get a professional tune and maybe gain 10hp or so .... I think so but this maybe not for everyone
Is ME or VT worth it for use on a Boosted RX8 without having to setup a Standalone ECU - IMO absolutely

I agree with you @sheeRXhilir8tion it could be better but its also not bad either in the same breath.
I'm not going to throw the baby out with the bath water tho...

I just had another thought, I have the Cobb AP manual around somewhere with all the table information in pdf format.
VT and Cobb ATR are very very similar maybe we can gleam some info from the old Cobb documentation.
If I find it I'll post it here.

Edit: Adding Cobb ATR documentation
AccessTUNER_HelpFile_Mazda.pdf

 

I have installed MazdaEdit and used it a fair amount. It's a different creature almost entirely.

Very unlikely that the table values would be off or misrepresented as the owner/designer/programmer/mastermind behind it all will be the first to tell you it is perfectly written and flawless in every way (but otherwise he won't give you the time of day).

ME is in no way as user friendly as VT. He didn't bother candy coating it with a user interface (obviously it has SOMETHING, it's not just a bunch of zeroes & ones) or include something to take the edge off like an instruction manual. And why bother with support when it's a waste of his time!

You're pretty much on your own to figure it out, but there are YouTube videos where you can watch someone (maybe him) fly through some basic functions at a "keep up or be left behind" pace.

There are MANY differences between VT & ME but the primary one based on my application was that ME actually disables the system and prevents it from checking for the DTCs you've masked. It's
like they're just gone. OBDII systems can't see or find them...and they don't just come back all of a sudden after 6 months either.

So, this is a serious program not intended for "noob" tuners. It is powerful enough to allow you to really f*ck up your car if you dont know what youre doing.

It also doesn't play well with others, so don't even think about using it in tandem with another tuning software.

Not the easiest to uninstall either...better hold on to your stock tune dump file and make copies of it.

(Some of these things may have changed or may no longer be accurate as I haven't used ME in a few years. Maybe he has implemented some support or more resources for the user. I don't know because I can't access the program anymore...a software update a while back required new product keys to be assigned and he won't issue mine to me. He's holding it hostage until I apologize to him for calling him an "elitist ****" (in Russian). Long story, but I'd rather bolt on a catalytic converter for a few days every other year if necessary and settle for a less powerful tuning software than do that. (If I did, it would be a lie anyway.))

 

LOL oh that post just made my day, beautiful.

 

SheeRX
I think you must be the guy that the Russian complained to me about ...lol
I've got used to him and actually find him quite helpful most of the time these days.

 

Here's the follow up regarding logging of MOP switch behavior in relation to MOP sensor.

The switch reacted to the sensor (which was reacting to load) in the expected fashion. Consistency was what I was primarily looking for and at first it appeared as though there was some issue... a point at which the sensor crossed the threshold but the switch appeared to have not reacted at all...but then I shifted the cursor position on the graph and adjusted the zoom and the spike appeared.

All of these screenshots are of roughly the same section of the same log, but the representation of the MOP switch turning on and, for some strange reason, it's magnitude (it's either off or on...no grey area, right?) comes and goes based on it's location within the display. Perhaps this is what you were experiencing in your first couple of screenshots, WCS?

Although I have no understanding of why this is happening or what causes it, I can confidently say the the mere fact that it IS happening is incredibly lame and honestly inexcusable. Who knows where else it may be occurring and what other parameters it effects? If I hadn't been playing around with the graph size, etc. I wouldn't have noticed this anomaly and would have been left thinking that I had a problem with my switch. What's the point in data logging if the data you're provided with can't be trusted to be complete?

At least this glitch isn't severe enough to completely prevent me from seeing that the MOP switch does appear to be functioning normally.

(If I've got it wrong or am misreading things and it's really ME who is the glitch please let me know!)

 

Interesting, yes I was able to reproduce this issue.
Furthermore the spike size and value would change as I zoomed in and out. This is most likely a bug.
1) Almost zoomed all the way out / small spike incorrect value provided


2) Partial zoomed in (2 clicks on the +magnifier) and spike grows and now I get a new value of 0.6 when I click the top of the spike


3) Zoom all the way in and the switch event is completely show and I get a value of 1.0


Definitely witnessed its magnitude changing (the actually value that was provided) as I zoomed in and out but I can't reproduce anything by its position on the screen.

In that particular log no EVENT for the MOP Switch was recorded even though I was logging that channel. You can tell as there is no Max reading of 1.0 for the MOP Channel Switch representing an "on" event (See left column in red square).


One thing to consider here is perhaps the sampling speed.
Depending on how fast the MOP switch event occur, the sampling frequency may not be fast enough to pick up the event.
I noticed your logs have a lower resolution of 83ms while mine (using a Bluetooth) are 137ms, this maybe why I missed some of the MOP Switch events.
Are you using Bluetooth or Cable for data logging?
And of course the number of data channels being recorded will impact the sampling rate.
In conclusion I believe I have reproduced the issue you found and I think it's a bug.
However depending on how quick the MOP Switch events occur we may be limited by the sampling rate.

Side note:
FWIW I normally just take a surface evaluation of the data in VT and then transfer the raw CSV file to MegaLogViewerHD to do all my data analysis.