Custom PID/Equation Breaks with longer payloads

Hello,
I've got an older GM vehicle with VPW bus instead of CAN. I'm trying to pull some parameters that must come from the ABS module (brake pressure, wheel speed, etc). When I use the custom header for a custom PID, I can get the data, but the bytes I get back is longer than your standard PIDs and the bytesToUint function (or any function for that matter) only returns the same value as raw.

I can't seem to post a picture, but I'll try to explain.

There's a few bugs I've seen with this
1) Once I set a custom header for a custom PID, it breaks every other standard PID, because the header is wrong I'm guessing (they all no data)
2) I have to then create custom PIDs for all the standard PIDs I want, with "custom headers" entered back to default so I can get data again. However, because of these different headers, my data glitches. Sometimes the "corrected" intake temperature PID from the ECU shows the same value as my brake pressure custom PID (different target addresses in VPW, so not sure what's happening here in the back end).


Here's an example of the data back and forth for my custom PID. Note the headers and parity byte are also included (first 3 bytes are header, and last byte is parity).
6C 28 F1 2A 03 41 A6
6C F1 28 6A 41 00 00 05 00 00 1D F5

When I manually type "41 00 00 05 00 00 1D" into the "source data" for my math, it does the math correctly there. However once I test the connection, it shows only the raw data.

I've tried
1: bytesToUint(raw,7,1) / 2.55
2: H/2.55
3: Just to see if the byte function worked at all, I tried just putting 'A' as well.

All of these resulted in the parameter showing "6A4100000500001D" and not being data logged...

I'm on version 6.4.1 on Android.

Also, unrelated, but also a bug i've noticed on Android and iOS. The internal accelerometers show that they are collecting data when viewing the live data during a session, but when I go to view the data after, it's always invalid/flat. Looks like it's just recording random noise around a certain value, definitely not what it showed in the preview window. Maybe a simple bug? It's kind of annoying I can't use my internal phone's sensors. This behavior happens on 2 different android phones and 1 iPhone that i've tried it on personally.
«1

Comments

  • The long responses should work at least on CAN-Bus. but no idea about VPW. Can you send me a log file?

    The usual instructions to generate log file: "Turn on the "Settings > Expert settings > Save device output", and record a session. Once the session is recorded you can share the .rcz file to tracks(at)racechrono.com, and I will take a look at it."

    I've added a task to my TO-DO list about re-testing the internal sensors recording. I guess it might be broken?
  • edited August 2020

    Sure can. I'll grab a quick datalog and send over some screen shots with it for you.


    Car is on jack stands in my garage right now as I've been sniffing the bus looking for certain PIDs.


    Edit: I've sent you some screen shots and the session files you asked for :) Thanks

  • edited August 2020
    Ok, there's several things going on so, let's start clearing them up one by one.

    1) Please update to RaceChrono v7.0. It should fix the accelerometer issue, but on new sessions only. The "distance" channel is broken on your sample session for the accelerometer device. It was known issue on v6.x. On old sessions, you can view the data correctly when you switch the graphs x-axis to "Time".

    2) As your car does not have CAN-Bus, and you are using non-standard headers on your custom channels, RaceChrono is unable revert to the default header (as it uses the default CAN-Bus header...) for the standard channels. To fix the standard channels please remove the custom versions of them, and set the "Default OBD-II header" on the vehicle profile's general settings. Looks like "0x 68 6A F1" is the correct one for you.

    After these changes, try again. If there's some remaining issue, please create another sample session, and I will take a look again. I believe you still might have a problem with the long response.

  • I've done as requested and sent you a new session, since the long responses are still broken.


    Question for you, I've got a friend on iPhone that is also having the accelerameter issue. Can he join beta to fix it or does he have to wait until the official v7 release? For him, he won't need it for a month (our next track event), but I have an event in 6 days I'd like to get everything working for.

  • edited August 2020
    1) v7.0 is released already, just ask your friend to update the app from App Store.

    2) The response you are getting for your custom channels, "6A4100000500001D" is interpreted as an error by RaceChrono. This is the reason why the equations do not work for it. And I believe it really might be an error. Can you make the value change by depressing the brake? It should change if it's not an error, but actually real value.

    3) Did you already check this thread? https://racechrono.com/forum/discussion/1915/custom-pid-help/
    It's for the same bus and an older GM.


  • It is the real value. I'm not sure why the response is so long but the only value I care about is the last byte of the response. Only the last byte changes as I apply pressure.


    It does change as expected when I press the pedal. It's voltage of the brake pressure sensor I'm reading. I verified it's real by sniffing the bus while using a GM Tech 2 to read the sensor.


    I see his comment in that thread about a number of bytes at the end. The command I am sending the abs module does not appear to use a # of bytes value at the end. It simply takes in a list of bytes of the parameters we are requesting (0x41 is brake pressure voltage).


    Why does RC think it's an error? I don't understand that aspect.

  • 6A as the first byte is a positive response from the module. 7F = failure or unknown PID. I see the data change as I press the pedal. Can't upload a video showing it but it does behave as expected, I just can't do math on it to clean the data up.

  • Basically RaceChrono tries to parse the header, and it expects (for request 2A0341) a response starting with 6A03. It would also omit these bytes from the equation calculation ...

    But this does not work for you. It will need a code change to allow the responses you're getting.
  • Yeah the response is 6A (valid response) 41 (PID requested). Not sure what the 03 means for the ABS module but I tried sending other values or omitting it and didn't have any luck.


    Perhaps a flag/checkbox on a per custom PID basis to ignore automatic verification? Also it would be helpful if there was some feedback that let the user know RC believes the reviewed data is an error/invalid response because I was really confused as to why the math wasn't working haha.

  • edited August 2020
    It certainly needs some more configurability to allow this response.

    I see how the error can be confusing. I designed it to just show NO DATA and other textual errors...
  • Also I need to see how RC handles multiple responses to a single request.


    For example: to get steering angle, I have to request 2 PIDs (steering angle voltage 1 and 2) which can be done from a single Request message to ensure they're "read" from the analog values at the same time. However the response is 2 seperate messages in a similar format as what you see above and I have to do some math on the two responses to get the angle. I cannot find a PID that gives me a single angle value for steering on this car but I've only been looking for a few hours.

  • edited August 2020
    Multiple ECUs can respond to one PID request. RaceChrono only takes the first response and throws away the rest. Please describe the request and response, and the required maths.
  • edited August 2020

    Remember this is VPW and not CAN. When I datalog the Tech 2 requesting these parameters, I can see it sends the single request with multiple PIDs


    2A 03 41 (brake) 20 (steering 1) 21 (steering 2)

    Gets me 3 replies from the abs module. I've got a dump when using a serial terminal to the elm device... Let me dig that up for the exact data because my memory isn't the best


    Edit: Here we go. This is a dump WITH the VPW headers and parity, so remember first 3 bytes are header, and last byte is parity.


    6C 28 F1 2A 03 20 21 40 41 A6  (Request to steering angle voltages, brake, and something else. There's 4 PIDs i'm requesting here)

    6C F1 28 6A 20 00 00 00 00 00 00 86 (Response 1)

    6C F1 28 6A 21 00 00 00 C0 52 2E 9C (Response 2)

    6C F1 28 6A 40 83 05 7F 00 00 00 11 (Response 3)

    6C F1 28 6A 41 00 00 05 00 00 1D F5 (Response 4)


    I'm still working through the math needed to convert the two responses to a steering angle. I plan to sit down this evening and figure that one out. This isn't critical right now. Brake pressure is mainly what I'd like to have by the next event if possible. The steering angle stuff it's going to be more work I think because it relies on 2 responses. I'm trying to find a PID where the ABS module does this already and I can just pull the angle directly instead of the raw values and calculating it myself.

  • edited August 2020
    OK, interesting. Right now, I'm really not sure how the multiple responses could be handled in RC, but maybe I will figure something out eventually.
  • Well i'm actually sitting in my car right now and think I was wrong. It actually appears that the two voltages are combined into a single response across multiple bytes. I need to play with it more, but that would be wonderful if true.

    I just explicitly tried dropping the 03 in the request to see if I could get a response that RC was expecting for the brake pressure and the abs module responds with invalid request. Looks like there's no way to get a response with the first few bytes that RC expects. Any work around for that, or it will require an update from you?
  • There's no workaround unfortunately, I will need to do some changes for it.
  • Well, in that case, I will wait patiently. Thanks for the help. Really enjoy using RC.

    If there's anyway I can help you, please let me know.

  • I will try to do it quickly as possible, but I do have backlog of v7.0 bugs that I need to work on before that. But I think you can expect this for v7.1.
  • Interested to see where this goes. I'll also be happy to help/test in any way I can.
  • Yeah. I'll be on track this Tuesday, but I don't think we'll have anything to test haha.

  • I'll also throw out that I've successfully so far figured out the commands on a C5Z for

    1) brake pressure voltage (which we can convert to a rough brake %)

    2) steering angle sensor voltages (need to figure out the math to convert to a degree, but I am successfully reading the data from the abs mobile


    Left to figure out

    1) oil pressure: comes from BCM

    2) oil temperature: BCM as well

    3) trans temp: not positive, but confident this is in the BCM

    The problem is the VPW interface is super slow and already kind of congested with data between the ECU and the cluster. Switching between 3 different modules (VPW headers) to poll data is going to hurt refresh rate. Luckily most of the parameters can be low refresh rate. Would be nice to set how often a parameter is polled.

  • Oil pressure and Trans temp are available on the ECU/PCM side. Oil temp is not.

    Oil Pressure
    OBD Header: 0x 6C 10 F1
    PID: 0x 22 11 5C 01
    Equation: B * 4.326 - 110.313 (this is in kPa, will convert to psi just fine)

    Trans Temp
    OBD Header: 0x 6C 10 F1
    PID: 0x 22 19 40 01
    Equation: B-40 (*C, converts to *F as expected)

    I have a bunch of other ones in Racechrono, wish there was an easy way to export or something. I think I can save/share the car profile, but no other way to really export. 2003 C5Z here. Accel pedal position, equiv ratio, Flex fuel freq, ethanol content, MAF freq, fuel level, EGR V (so you could log wideband AFR or fuel pressure or whatever), Fuel temp, and a few others I can't recall off hand and because I had to name them something generic in the app, lol, I'd have to look at my PID cheat sheet.
  • edited September 2020
    I have nothing new to add, but basically was able to replicate what you saw jlvaldez. The "03 41" was definitely something related to brake pressure. I saw a linear / reasonable / repeatable pattern. But like already discussed, RC doesn't recognize the response as valid.

    I tried the same thing in Torque Pro for fun, and it detected it as a valid response.... With Equation set to "E", it was pulling the right byte.

    For me, min value was 1F, max of 66, or 31-102 in decimal. 66 was basically me stepping on the pedal as hard as i could with both feet.

    Looking at "03 20" and "03 21", I saw no changes in the output to "20". "21" definitely changed with steering wheel movement, but it wasn't changing in a normal linear pattern, so yeah something is definitely missing. Sounds like you have a good setup to hopefully figure it out soon.
  • I was cheating when I was looking for these parameters. I connected a GM Tech2, started datalogging certain parameters while sniffing the bus to find what I was lookign for.

    For me, min value on brake is 1D (~0.5V). I can pull up the conversion from hex to voltage. The sensor is connected to a 5V rail, so one could logically assume that it's a 0-5V range.

    1D assuming FF = 5V gives you 0.566V.
  • Friendly bump to see where we're at for a 7.1 beta. I have a track event this weekend and would love to give some things a try :) Doubt there's anything for this weekend, but figured I'd ask. I've at least 1 event scheduled for every month for the rest of the year.

    Aaronc7,
    Any chance you could share those other parameters with me? I'm curious which ones you've got. Screenshot dumps are fine and I can type them out as a reference here. Seems like a good idea to document these PIDs for the C5, since it's such a popular race platform and the only other way to get some of this data is with analog dataloggers tapped into the sensors (Granted they get much better refresh rates with that approach).
  • Well, I was finally motivated to get this info on a spreadsheet.

    This is my current list of PIDs that I've found useful and have equations defined (for the most part): https://docs.google.com/spreadsheets/d/11Aa-8lQZX1ndwjBxni8ftqF2YdOZT4WiRyc0xsEyuDw/edit?usp=sharing

    Here is a list of "all" PIDs for J1850 VPW GM stuff as far as I know: https://drive.google.com/file/d/1KFJNRdE-LNyEMzU95c54qPjmdnVsgQKt/view?usp=sharing

    And here is a cropped down version of that list, with only the ones that are compatible with my ECM, "P59": https://drive.google.com/file/d/1xTXTTgUnrk5vEt_fR5aE_-zO3b3NQ65K/view?usp=sharing

    I know those lists aren't 100 percent complete, because I came across Ethanol content (FC 22) that works and it's not on the list...but really that is probably good enough for most people.

    I know there's even more that guys have dug up on pcmhacking using direct memory addressing. Maybe that's something we can get implemented here in the future? I know the very basic PCM logger can do it...... kind of out of my realm, but doesn't seem like it's something super complicated to implement.
  • edited October 2020
    @jlvaldez Sorry, 7.1 will take little bit longer. I've been fixing higher proprity bugs, as you might guess from the change log. When it works just about right, I will start with the feature improvements.
  • As a note with the c5, it does not have an ethanol content sensor. It's an assumed value. I don't think you'll ever see it change.


    The oil pressure pid you shared was helpful on track today. So awesome to datalog style of these diagnostic temperatures I never got to before.


    I dug through a few wiring diagrams and found that the temp sensor is connected to the cluster only. Not sure if that's info that can be pulled via serial data. I don't recall seeing it as an option for the tech 2. I'll have to play some more.

  • edited October 2020

    @jlvaldez I did a P59/2004 Corvette PCM swap and running an ethanol sensor on mine with full flex fuel capability. Those params are useful for me so I can check content on the app without spending a couple hundred bucks or whatever on a standalone gauge.

    I did the conversion mostly for fun but also like the cooling benefits on track.

  • I run EFI Live and it has the best scanner/logging capability that I've seen for the platform and it also does not have any sort of oil temp monitor....like you said, it's always been my understanding that the signal is used for IPC display only.
Sign In or Register to comment.