370Z CAN Bus Proprietary PID's

ZeN

Wah, so many skillfull programmer here.

Gents after a long journey trying to understand why JDM car unable to read the bloody data on torque i can safely say that now with the new Nissan adv plugin on torque we (jdm) ecu can actually read from it, but limited to the custom pid by the plugin only. Im trying to figure out how to read the standard mode 1 pid but so far unsuccessfull.

Can someone teach me how to put the custom pid into torque, maybe it can force torque to read it that way. Maybe the developer just bypass the polling routine for standard pid since requesting for 0000 turning null which mean the ecu did not support any pid.

I would like to suggest that the moderator move this thread to tuning section since it is more related to ecu. TS, if you dont mind, i made a post at torque bhp forum to this thread and your spreadsheet at

http://torque-bhp.com/forums/?wpforu...topic&t=4875.0



Car is 370z 2009 7AT JDM

Brad370

I did a little updating and added new information, plus I put the bits in the proper order. My spreadsheet is now hosted on Dropbox to make it easier for me to keep it synced.

https://www.dropbox.com/s/cfpzb2mpj4...70Z%20CAN.xlsx

So the google spreadsheet listed in your first post has been deleted.

gomer_110

This makes it so much harder to hold off on adding CAN-bus communications to my homemade datalogger. So much useful info I can get from the ecu, especially steering angle, brake position, and throttle position.

__________________
'11 370Z Nismo #528 Fast Intentions | Stillen | Motordyne | Uprev | CSF | Zspeed | Z1 Motorsports | AST | Swift | SPC | SPL | Whiteline | Hotchkis | Bride | Schroth | Robispec | Cusco | Nismo | Volk | Forgestar | Hoosier | RJM
'17 Titan Bone Stock

esfourteen

awesome work! I have been side tracked with other projects but this will save me a bunch of time when i get back to my carputer. I'm using a raspberry pi, bluetooth CAN (STN1110), 10-bit 8 channel ADC and a bunch of 5v analog sensors (boost/vac, oil pressure, fuel pressure etc).

__________________
Build Thread | GTM TT Install Thread | Engine Build Thread

Brad370

That's basically what my ultimate goal is. Maybe add a touch screen display into the cubby above the stereo. Or just show information on my Kenwood stereo display if the resolution is good enough.

esfourteen

yeah mine is going in a modified cubby, 7" pi compatible touchscreens with transflective panels sell for about $120 on ebay. they work great!

__________________
Build Thread | GTM TT Install Thread | Engine Build Thread

Brad370

A somewhat silly use for this also occured to me since we can see the status of various buttons and switches in the car by monitoring the CAN bus. Here are 2 ideas:

This can be used to enter a 'code' to activate something or to identify the driver to the carputer. A code such as tapping the brake 5 times quickly.

Or we can repurpose buttons for something else. I found the bit that shows whether the key is inserted into the slot beneath the VDC button (I'll add it to my spreadsheet soon). It's just a button that can be pushed if you insert your finger all the way back. Just monitoring this bit can activate something and it makes for a very stealthy switch.

SouthArk370Z

Not silly at all.

The theft-deterrent idea should be pretty easy to implement with a relay in the push button or starter circuits.

You should be able to come up with a "valet mode", using some switch (or combination) to limit RPM. I'm not sure how one would limit RPM, but you seem to have enough access via CAN to do it, if it's possible.*

The possibilities are endless!



One thing that I've wanted on my 7AT is to have the current gear displayed on the dash in automatic mode, as it does when in manual mode. Not sure how the dash handles it, so it may not be possible.

*Edit: It sounds to me that what you are working on is basically a "dumb" tuner. If you know the right address to poke data into, you should be able to do everything the tuning software does, albeit without the benefit of the reverse-engineering done to identify all the "good" addresses.

__________________
Steering Lock Links - Search The370Z Bookmarklet - FSM @ NICOclub
Mankind has progressed past the need for war but we haven't evolved that far. - NachoMahma

Brad370

The ECM sends the current gear to the dash repeatedly (every 55ms on my manual Z). So the problem is that even though you could send out messages disguised to look like the message from the ECU to trick it into displaying the current gear, it would immediately be replaced with the next message from the actual ECU.

Jordo!

Wouldn't that message be the next gear you are in, or do you mean it would keep cycling between "D" and a numeric gear value?

__________________
Enjoy it. Destroy it.

Brad370

I believe SouthArk370Z wants to be able to replaced the 'D' with the actual numeric gear value. But I think you would be in a tug-of-war with the ECU and the display might be unreadable because it would bounce back and forth between D and the gear number. Or it might cause errors.

Mitco39

One way to find out, lol.

__________________
2007 Chevy Duramax - EFILive Tuned By Me
2010 40th W/ Nav - Boosted Performance - UpRev Tuned By Me
The Mrs. Ride -2012 335XI N55 BMW - Cobb Tuned By Me, Built by her
My Build --> http://www.the370z.com/members-370z-...39s-build.html

Brad370

I've received a couple PMs asking what tools I'm using to sniff the CAN bus. Below is a pic of the VB.net app I wrote to display the info. I took a cue from radensb's screenshots for layout.

The left panel shows the CAN messages. Once the Lock Values button is pushed, all of the current values are saved and if any of them change they are highlighted in red. This makes it easy to see changes.

If you click on a byte, it will show the individual bits in the Show Bits section. Then you can click on a single bit, which will lock the green block to that bit. It will show green for 1 and red for 0. This makes it easy to see changes from far away when messing with the car.

I'm going to work on this some more over the next couple weeks before I let anybody else use it. I still need to add OBD PID polling so that info can be logged too. Just thought I'd share. It only works with a CANUSB adapter.

DIGItonium

Here are some ideas off the top of my head:

• Use an iDictionary to create a list of PIDs <int,class_object>, in which "class_object" defines fields to store the raw value and other properties of the PID.
• Use the iDictionary list of PID objects to populate a checked Listbox control. Each ListBox item stores the ID, which can be used to look it up in the iDictionary. Add options to "Select All" and "Select None." I love LINQ since you can write 3 lines of code to "query" the List of objects without the need to write recursive search.
• Add a search box that filters the list as you type. An "X" button to clear the textbox, which unfilters the list.
• Also, you can add a toolstrip with the standard button layout. The save button can be used to export the data to a comma or tab delimited file.
• Create a database which defines the PIDs and properties. These properties are used to decode the raw values. You'll need to research this part (e.g., data size, data type (int, double, string), resolution, bit range, etc.). You an put it in an MDB, SQLite, or even XML. On startup, you can read the contents to populate the iDictionary, which gets loaded into the ListBox. What you can do is create a table that defines the raw PIDs. The next table can break down the raw PID data into bit fields. For example the PID table can list IDs 000,001,100,200,etc. The next table can define 100-1, 001-1, etc. If the PID contains multiple fields of values in a single byte stream, you can define bit fields from there. You can create a column for the bit field range LSB and MSB. If it is equal, then you're defining a single bit. Then you can define the resolution, in which you do the basic math for the bit field and multiply the resolution to get the final result. Another column can be defined for units as well. If you need me to help you brainstorm the relationships, feel free to contact me.
• Add a control to let users adjust the polling interval.
• Add "playback" controls, which can scroll through the CSV log file. Don't forget to time stamp each row of data, so it can be read back.
• Add scanning capability in which one can create a logic (e.g., when value ==, !=, <, >, etc., some threshold).
• For plotting, I've had good luck with Zedgraph. It does have some issues that require some fiddling with code to workaround them.

The VS project I have at work is a tablet friendly real-time viewer which manipulates HTML displays, so I can flip images to simulate control state, update text values, and even set text colors. One can apply logic so perhaps the text color can indicate out of range values. HTML lets people create screens beyond looking like tables. I can probably port the entire project for ODB. Below is a program I wrote at work that reads XML files which can export the list as comma or tab separated with filtering capability.

__________________

DIGItonium

I'll try to find time to come up with a tablet-friendly .NET application. It's based off the data viewing tool I wrote at work. Design plan:

• Tablet-friendly interface (iPad-like UI)
• Module for ODB communication. It can send commands and retrieve data. That's something you guys can help me with.
• Module for real-time module with recording capability. The sampling rate is user selectable. Once real-time is disabled, the module switches to playback mode. This will allow users to step and scroll through the recorded snapshot. Users will also be able to specify the buffer size by number of samples. Users will also be able to save and load this recorded file for playback.
• Viewing tools: HTML display, editor, Raw PID viewer, Event Search, Event Viewer (scans for out of range values), and an 8-channel plotter. The tools can support real-time and data playback modes. However, Event Search can only scan through the recording buffer.
• ODB Tools: Come up with general tools like diagnostics and commands. This might be database driven.
• For expandability this .NET program will database driven. Depending on how granular we want this to be, we can separate these definitions by make and model, or even down to the model year. A single database keeps track of this list, so it knows which set of definitions to get.

[EDIT] Already started. I copied the project and started deleting non-essential stuff.

__________________