Dealing with two different conversions within the same table

[ericruhl]

I don't know the best way to deal with this, but first perhaps a pic will help. This is a Nissan fuel map which contains both open and closed loop data.



The section of the map which makes sense is the AFR for the Open Loop portion of the map. The section in blue which is significantly smaller in value on this map is the Closed Loop portion of the map. The AFR's are actually quite similar to what you see on the red and orange sections of the map (14-15 AFR), but a different conversion is used for this section of the map. When looking at the unconverted decimal values, all of the open-loop cells are less than 100, and all of the closed loop cells are greater than 100 which is how the ECU determines whether or not to use closed-loop control within this area of the map. So what I'd like to do is basically an IF statement within the conversion:

If the cell decimal value < 100 then use conversion #1 and shade the cell red. Else, use conversion #2.

Shading the cell indicates which parts of the table are using which conversion.

Is this already possible within TunerPro (two different conversions within the same table)? Right now what I do is I have two tables for the same data set, one uses conversion #1 for looking at the Open Loop AFR and the second table uses conversion #2 for looking at the Closed Loop AFR. It would be much nicer/cleaner/more convenient to view and edit this info on one table / plot.

Here's another possible (better?) way to deal with this... add a conversion flag to the Table editor tools. Specify two conversions in the XDF and then use the Table Editor flag to specify which conversion that cell should use. In my example above, I would select all of the closed-loop cells and check the box to use the alternate conversion. The cells would then change color to indicate that they are using the flag (alternate conversion), and the cell values would now be consistent with the rest of the map.

Hopefully this makes sense. Thoughts?

[Mangus]

This issue with Nissan has been brought to my attention by another fellow who uses TunerPro with Nissan (which I think is awesome, by the way).

I'm trying to think of a good solution, but currently there isn't one.

The spark maps have a similar problem. Nissan spark tables use the most significant bit to signify that a cell is "knock enabled". However, TunerPro uses that bit as a sign bit (that is, if that bit is a '1' the number is negative, if it's 0, it's positive).

I'll have to think up a good way to get around that so that the spark table is a bit easier to understand and more cohesive.

Thanks for reporting this and thanks for posting some good ideas on how to make this work (it's not often a user poses a problem and takes a shot at a solution). Please continue to let me know how I can make TunerPro work better with Nissan!

By the way, is there more information on how this works with Nissan? A newsgroup post somewhere or maybe a FAQ? The more information I have the better armed I am to get this working great for you Nissan guys.

[rybowen]

The fuel tables actually work the same way as spark tables. The MSB indicates "closed loop" operation.

The decimal factor is 128, not 100.

There are a lot of Nissan ECU guys at http://ecu2.forumwise.com/

I have many disassemblies which show it a little better if you're conversant in 6303 assembly!

[Mangus]

I have many disassemblies which show it a little better if you're conversant in 6303 assembly!

I'm not, but if it's well commented I can probably string myself along...

[Mangus]

Looks like it might be possible to re-work TunerPro to log the Nissan datastream too? I'm interested in finding more info on that. Any primers?

I'm in the process now of re-writing the whole data acquisition engine in TunerPro, so I might as well plan for this while I'm at it.

As it stands now, TunerPro integrates data tracing for GM, so it wouldn't be a stretch to get the same in there for Nissan. Many guys on that forum seem to point to the lack of such functionality as quite debilitating.

[ericruhl]

That would be fantastic Mark, thank you for looking into this!

Looks like it might be possible to re-work TunerPro to log the Nissan datastream too? I'm interested in finding more info on that. Any primers?

There is some good info on the Nissan Consult (datastream) protocol here:
http://plmsdevelopments.com/consult_if.shtml

Specifically the protocol description and the list of registers.

The decimal factor is 128, not 100.

I was simplifying Actually isn't it 192? (X+128) for open loop and (X-64) for closed?

The spark maps have a similar problem. Nissan spark tables use the most significant bit to signify that a cell is "knock enabled".

That I'm not aware of, but it sounds like rybowen has encountered it. I've only been messing with the Z32 (300zx) which has only two timing maps, Primary (no knock) Timing and Knock Timing. Each of which utilizes a single conversion for the entire timing map. Rybowen or I can forward you a copy of the XDF for the Z32 if you're interested, and he has a detailed one for the Q45 as well.

Many guys on that forum seem to point to the lack of such functionality as quite debilitating.

There are some good datalogging packages out there, but I've yet to see one which captures the alphas (map correction factors) like WinALDL does. This is a nice feature to have to guide map adjustments and is sorely missing from the Nissan collection of software. Several even have realtime map tracing, but they don't tell you the correction factors that are being used at each cell on the map I have a GM 1228746 ECU as well and I haven't really tried datastreaming with TunerPro yet (I tried once but something must have been wrong with the config file), I've just been running WinALDL and TunerProRT simultaneously for realtime tuning. I need to try it again with TunerProRT.

Thanks again for your efforts Mark!

[Mangus]

There is some good info on the Nissan Consult (datastream) protocol here:
http://plmsdevelopments.com/consult_if.shtml

Specifically the protocol description and the list of registers.

So is this Consult interface the only one people are using? I don't fully understand the electrical interface (specifically the "clock" stuff), but the serial commands look pretty simple and shouldn't represent a problem.

Are any others offering interface hardware?

[ericruhl]

Are any others offering interface hardware?

There are a few different sources for the hardware/cable ranging from DIY instructions to complete cables. I got mine from http://blazt.biz/ and I liked it because it integrates the electronics into the serial connector so they're essentially hidden (others have a "black box" in the cable to house the electronics). I purchased the software from there as well, it's called Nissan Datascan. There are a few free datalogging programs out there as well, I have a "Summary of available software" (and cable suppliers) on the 300zx tuning forum that Rybowen mentioned above (look for my username Z90). If I remember correctly some of the free software might have the source code available. A couple guys have even implemented it on their Palm organizers (nProbe was a popular albeit expensive option for the Palm users but it has been discontinued).

Unfortunately I won't be of any help with regard to the actual protocol. The links I provided are all that I know. There may be some additional info on the tuning forum, I'll see if I can find anything.

[rybowen]

The physical interface is nothing special - RS232 to inverted 12v serial. The clock is independent of the interface, just a free-running reference pulse.

The serial commands are simple, some people have complained about the streaming function since it is easy to lose your place in the stream if you have a slow interface.

You can download the entire bin by querying for 8 bytes at a time.

[JP86SS]

I had an idea on that table issue that may work.
What if you put in a "Y2" scale and allow that to be selectable.
that may be what was suggested but in different terms.
Maybe a "combine table" flag to use a second table data set to be displayed on the "Y2" while sharing the common "X" axis values.

[max240]

I am not sure if this pertains to all nissan fuel maps but I was able to use this conversion to view AFRs(in a negative value).. (x-128)*.1-14.7
Try it out, it works for me.

Edit.. try this for a positive value ((x-128)*.1-14.7)*-1

[ericruhl]

I am not sure if this pertains to all nissan fuel maps but I was able to use this conversion to view AFRs(in a negative value).. (x-128)*.1-14.7
Try it out, it works for me.

Edit.. try this for a positive value ((x-128)*.1-14.7)*-1

Perhaps I'm misunderstanding your reply, but my concern wasn't with the equations themselves. The feature I'm requesting is the ability to use two different conversions within the same table. For example, pick your favorite 16x16 table and try to specify your first equation for the top 8 rows and the second equation for the bottom 8 rows, without using two table items. I want to be able to display the entire table on a single chart, and have the data make sense (see the map in the first post). Currently I have two entries for the same table, one for the first equation and a second for the second equation. This means I only get to (realistically) look at one half of the table at a time and it makes it difficult to spot "steps" from one section to the next (in this case between closed-loop and open-loop).

Mark, have you had any additional thoughts on how to incorporate this?

[ericruhl]

I had an idea on that table issue that may work.
What if you put in a "Y2" scale and allow that to be selectable.
that may be what was suggested but in different terms.
Maybe a "combine table" flag to use a second table data set to be displayed on the "Y2" while sharing the common "X" axis values.

Sounds interesting, but I'm specifically looking to maintain a single "Z" scale. This is in regards to a 3-D map, X & Y axes with the cell values represented in "Z".

Edit: Perhaps this will help clarify. Here's a stock fuel map (using a different Nissan-specific program) where the red cells denote "closed loop" and the blue cells denote "open loop". There are two different conversion equations used depending where you are in the table (blue has equation #1, red has equation #2).


Note the rows are also inverted in this example compared to TunerPro's format (a previous feature suggestion).

If I try to view the same data in TunerPro I have to pick which equation I want to use and look at each section independantly:

Open Loop ("Blue") section using equation #1 (again, inverted from above).

Notice how the "closed loop" section is nonsense?


Closed Loop ("Red") section using equation #2 (inverted)

Similarly now the "open loop" section is nonsense.

I want to combine these two sections to create the single table shown in the top picture. In other words, I want to be able to use two different conversion equations within the same table item (and visually distinguish which equation is being used in each cell).

[ericruhl]

So if you put the two pieces of the puzzle together, this is what I'd like to see:


Similarly the 3-D plot would display the values from this single "combined" table.

Ideally I could then select a cell, or group of cells, right-click and switch their conversion equation (toggle between blue and red, ie. equation #1 and #2).

PS This is a stock fuel map btw, chosen purely for example.

[Mangus]

Nice image edits.

No, honestly I haven't put any extensive thought into this yet, but it is on my list for version 5. I'll do my best to take care of you Nissan guys.

[ericruhl]

Thanks Mark, don't forget us

IMO this multi-conversion issue is the last "quirky" part of using TunerPro on the Nissan. Linking the column and row lables was another one but you've taken care of that already and I don't mind the inverted rows so much, I'm used to that now. Just wanted to bring this back to the top, address the previous replies, and hopefully clarify the suggestion a bit. Let me know if you need anything Mark and, as always, thanks for your continued efforts!

[ericruhl]

Nissan spark tables use the most significant bit to signify that a cell is "knock enabled". However, TunerPro uses that bit as a sign bit (that is, if that bit is a '1' the number is negative, if it's 0, it's positive).

I'll have to think up a good way to get around that so that the spark table is a bit easier to understand and more cohesive.

Is it possible to add logical statements to the conversion? Something like this (straight from excel):

IF(logical_test,value_if_true,value_if_false)

for a random example:
IF (X>128, (X-128)*20, X*20)

Then all that is missing is 1) the visual identifier (such as cell color) so you can identify which condition (true or false) that cell is using, and 2) the ability to toggle the condition for the cell (ie. change a false cell to a true and vice versa)

This approach would be more powerful than an internal toggle based on the MSB. Just a thought...

Alternatively perhaps a flag in the XDF header could be used to specify if it's a Nissan XDF or otherwise and interpret the MSB accordingly? If the flag exists it's a Nissan, if it's not there then it isn't?

Just tryin' to help brainstorm...

[Mangus]

Damn good idea. I'll look into that.


DAMN good idea.

[deviousKA]

I am very interested in nissan communication support in TunerPro.

I have made some of my own software for use with this protocol and would be glad to help out in any way possible. The documents posted above are valid and complete, a working protocol for a huge range of nissan vehicles.

I would think the most useful and perhaps the most generic nissan consult function to add to tuner pro would be the "rom dump routine"

3.6. Read any ROM BYTE (Internal ROM, program code) (0xc9)
(0xc9)<High byte><low byte>(0xf0) for single byte
(0xc9)<High byte><low byte>(0xc9)<high byte><low byte>(0xf0) for a
multi-byte response. Maximum of 8 bytes.
terminate command with (0xf0) to start data stream, stop with (0x30).
ROM space starts at 8000h and ends at ffffh. RAM addresses can be read by this
method also.
For example, to read 3 bytes at addresses 0x8000...0x8002, send:
c9 80 00 c9 80 01 c9 80 02 f0
ECU response:
36 80 00 36 80 01 36 80 02 FF 03 05 03 08
36 is inverted C9 etc, FF 03 is a header and the record's length, then the three
data bytes.

With this function we can "spy" on anything within the code, such as rpm and load factors. We can use this command routine after initializing ecu communication, simple init-response.

This can also be done with the sensor stream consult function, but compatibility is nonexisent between ecus and code mods are required to stream desired data.

With rpm and load values streaming from ecu to tunerpro, would it be possible to map-trace against row and column header scales/axis index? Im not sure if TunerPro supports something like this with other aldl type communication, but I would think it would be a superb feature.

Sorry about the off-topic, it is nissan related so I figured I would post here.

Edit: Oh and BTW, the protocol streams the data packets starting with FF header and then a record length. What tunerpro would have to do is have a match pattern or start flag for this header and/or record length. The data is then parsed and ready to be used.

It continues to stream untill you stop it with 0x30 command, this does not have to be done often, timeout is not an issue.