Torque

Forums

Forums

Guest  

Show or hide header
Welcome Guest, posting in this forum require registration.




Torque » Torque OBD ECU Scanner » Torque Discussion / Ideas » Occasional lost frame from multi-frame response

Pages: [1]
Author Topic: Occasional lost frame from multi-frame response
d_mcham
Member
Posts: 13
Post Occasional lost frame from multi-frame response
on: June 10, 2019 (GMT)

Hello!

Apologies up front for the long post!

I have been using TP for years now and love it!

I have been using custom PIDs for a long time as well, but now I’m having my first real problem: a multiframe response sometimes loses the second (which is the last) frame.

When testing in the PID editor, only rarely will I see the 2nd frame disappear, but it occurs much more often on the dashboard where there are other gauges, currently 11 gauges in total. In the PID editor the response it shows when the frame is missing is:
Response:
00B
0:62A0014C4C06

The response with and without headers always looks like a correct response, it is just missing the 2nd frame occasionally. It’s like either the flow control message from the adapter isn’t being sent (or gets corrupted somehow) or the next frame isn’t coming through for some reason. My first guess is TP is “stepping on” the next frame by sending a PID request for another gauge, but then it shouldn’t happen at all in the editor. I’ve tried adjusting the wait time in the flow control message with no change, I’ve tried several different baud rates (adapter and protocol), and I’ve tried various filters to try and block responses without the second frame (but I could have been setting those up wrong, the ELM and ST 1100 documentation doesn’t go into flow control filtering very well unless I’m missing something).

Details:
Obdlink MX BT v2.2 (with latest firmware as of last week)
2017 Ram 3500
15765-4 CAN (11bit, 500kbps)
PID: 22A00A
Header: 7E1
Equation: Signed(N6) *256+N7
(G and H work also, but when the frame is missing, G and H return -1 whereas N6 and N7 return 0.)

Currently not using any diagnostic start/stop commands, but I have tried several in my attempts to fix this.

My custom initialization string is: STSBR 500000 \n AT FC SD 30 00 00 \n AT FC SM 2
I know the flow control string isn’t doing anything non standard, it’s still there as a place holder as I work this issue. I’ve tried different delays in it with no effect.

Let me know if there are any ideas or thoughts, or if I’m going about this the wrong way. Thanks!

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

cintakc
Member
Posts: 1270
Post Re: Occasional lost frame from multi-frame response
on: June 11, 2019 (GMT)

try custom initialization string
atsp6\natsh7e1\natfcsh7e1\natfcsd300000\natfcsm1\natcra7e9

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 11, 2019 (GMT)

Thanks cintakc, I’ll try that. I’ve been trying flow control mode 2 (adapter sets the header automatically) but haven’t tried mode 1.

Most of the other gauges I’m using get their data from 7E0/7E8 so I’ll end up having to put some of that in it string to the diagnostic start/stop lines for this PID, but I’ll start with it in the init string first.

I’ll try this in a few hours when I have a chance to get to the truck.

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 11, 2019 (GMT)

So the custom init string seems to have worked great, but I only had the one gauge on the dashboard. I tried adding more gauges and the problem comes back. I can get only 1 additional gauge on the dashboard before frames start dropping.

Init string:
ATSH7E1 \n ATFCSH7E1 \n ATFCSD300000 \n ATFCSM1

Primary PID:
22a00a
Signed(G)*256+H
Blank header
No diagnostic start/stop commands

Additional PID (EGT bank/sensor 1):
0178
(B*256+C)/10-40
Blank header
Diag start: ATFCSM0 \n ATSH7E0
Diag stop: ATFCSM1 \n ATSH7E1
This is a PID that responds with 2 frames but only the 1st frame is needed. However I had to change the FC mode for this PID to prevent problems/delays.

It works fine just like this, but if I add any additional gauges, I start losing frames for that 1st PID (22A00A). All additional gauges work fine, just this one loses the 2nd frame some of the time.

Thoughts?

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

cintakc
Member
Posts: 1270
Post Re: Occasional lost frame from multi-frame response
on: June 12, 2019 (GMT)

PID: 22A00A
Header: 7E1

PID: 0178
Header: 7E0

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 13, 2019 (GMT)

Cintakc, that didn’t help, still losing frames. It works great as the only gauge, and only maybe once or twice a minute it will lose a frame when I add another gauge. If I add a third gauge it starts dropping frames once or twice a second. And it only gets worse when I add more gauges. I’ve tried adding only gauges that use PIDs on the same ECU (7E1) to see if switching between ECUs is the problem but I get the same results.

The gauges refresh rate changes noticeably when I start adding gauges too. By itself it refreshes several times a second, but when I add just 1 more gauge it slows down to about 1 refresh a second, maybe slightly faster. With a second gauge added it slows to about 1 refresh per second to just a little slower. I know more gauges slows everything down but I don’t normally see this big a change with the other PIDs.

Last thing, how is the adapter benchmark in the Adapter Status work? How is it coming up with the read speeds? It seems much slower now that I’ve changed many of these settings so I’m wondering if this ECU just can’t/won’t respond as quickly as 7E0.

Thanks for the help so far!

**Edited to fix typos.

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 14, 2019 (GMT)

So I removed all of the init string commands, and the diagnostic start/stop commands. Then I turned off the “Faster communication” and turned on “Disable ELM327 auto timing adjust.” Went to the dashboard and it was fine, just slow.

Then I started messing with the ST command to see how short a delay I could get to and avoid the dropped frames. ATST 0B is about the shortest delay (about 44msec) without dropping frames. I ended up putting ATST 02 in the profile init string, but put ATST 0B in the diagnostic start line (and put it back to 02 in the stop line). This is working, just not very fast. With 6 gauges on the screen I’m getting refreshes about once per second. Not bad but faster would be nice.

This made me wonder about the “Faster Comms” and “ELM327 auto timing” and what they do. Do those just send the ATAT 1 and 2 commands? Do they do anything else?

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

cintakc
Member
Posts: 1270
Post Re: Occasional lost frame from multi-frame response
on: June 14, 2019 (GMT)

Torque ->Adapter status -> Adapter PID read speed ?
Start Stop commands slow down the rate of PID reading

piemmm
Administrator
Posts: 6071
Post Re: Occasional lost frame from multi-frame response
on: June 15, 2019 (GMT)

Hi!

Depending on the PIDs you’re reading (which are triggered by the gauge) you could be:

* Using a gauge that requires several PIDs to calculate the value of

* Using a PID that requires the communication mode to the ECU to change (such as setting different addresses, etc, which needs to be done each time that PID is read, then set back to normal)

All of which takes time to send each extra command. If you’re reading 1 PID which requires a mode change, then add a normal OBD2 PID, then you’re going to see a reasonable drop in speed, this is expected and has a bigger impact on bluetooth adapters due to extra latency sending and waiting for responses.

If speed is important, use an OBDLink USB adapter.

Many things can affect the bluetooth adapters and make them slow such as:

* WiFi being active on Samsung devices (it inteferes with bluetooth due to the way it is setup)
* GPS being active (it slows down bluetooth in samsung and other devices due to an OS “bug” causing a 100ms pause about every second)
* Other applications using bluetooth or other bluetooth connections, causing the bluetooth radio to stop servicing the adapter and go do other things

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 15, 2019 (GMT)

Cintakc and Ian, thank you both.

I ended up turning off the “Faster communication” but left the auto timing enabled and removed everything from the init string. Read speeds went up from 10-12pid/sec to about 40, but I was still losing frames. I noticed something else, in the adapter status section I was also getting errors. Only a small number each session, but it seemed to coincide with the dropped frames.

I set the diagnostic start line to ATAT0 \n ATST0B, and set the stop line to put everything back: ATAT1 \n Atst00.

Read speed went up to about 18.8, but that particular gauge doesn’t refresh that fast. I need to log it (and just it with nothing else on the dashboard) to see what kind of speed it’ll actually get, but right now with 5 other gauges on the screen (all custom but with no diag start/stop commands) and only one other using the 7E1 header, it’s working pretty well. About 3 updates per second.

This particular ECU just isn’t as fast to respond as 7E0 is. I get upwards of 40-60 pid/sec with just 7E1.

As for speeding things up, in the ELM327 data sheet it mentions adding an extra character to the end of a PID request telling it how many lines to expect. How does TP handle this, or does it at all? Also what about multiple PIDs (same mode) requested in the same request? I saw that somewhere but haven’t found it again. Using that would only make sense with same mode PIDs from the same ECU like my 7E1.

Thanks again for the help, I have been working on these PIDs for a long time now and I’m finally really getting somewhere with them!

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

piemmm
Administrator
Posts: 6071
Post Re: Occasional lost frame from multi-frame response
on: June 16, 2019 (GMT)

Hi!

The response counts are handled automatically by the app – though if you send a debug (enable debugging in the general settings, quit and restart, connect to the car with the displays showing you’re having speed issues with, then in the dashboard screen (after about 20 seconds of it pulling data) press menu->send debugging log and write your forum name in the box that pops up then press ‘send’ , I’ll have a look at the comms session to see if anything sticks out – the error count should be 0 and those adapters (the OBD Link ones are good) so there may be something that can be done in there to fix things

The only thing I can think of is that the atat and reply wait settings in the adapter are slightly too long for the dropped frame (or there is some canbus collision happening that’s preventing the frame being received, but you generally get a error when that happens – the debug will sort this out)

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 16, 2019 (GMT)

Thanks, I’ll run a debugging session either today or tomorrow. I’ve been wondering if it could be bus collision, but it seems like the dropped frames disappear (or are reduced to the point I don’t notice them) when I force the ST timing to be longer and turn off the AT timing. I’m very interested to see what you find in the debug log.

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 17, 2019 (GMT)

Ian,

I sent you an error log this morning, and I also just sent you an email.

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 21, 2019 (GMT)

Ian,
Did my debug data make it to you?

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

piemmm
Administrator
Posts: 6071
Post Re: Occasional lost frame from multi-frame response
on: June 21, 2019 (GMT)

Hi yes, apologies for not replying sooner – a little swamped at the moment! will email/reply here back in a bit once I’ve had a better look

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: June 26, 2019 (GMT)

Long post…sorry!

Here’s an update for anyone who may come across this thread. Ian didn’t find what was causing the reported errors in the debug log I sent him…the log is fairly short and just didn’t capture the error event I had when I ran that log.

However he did see that I had headers listed in some of the custom PIDs I was using that had a mix of all caps or all lower case. He recommended keeping all custom PIDs the same for the header, either keep them all caps or all lower case. He said that can make a difference in read speeds.

The last thing he found that can slow things down is I apparently had a carriage return at the end of one of my custom PID’s header fields. Not sure how it got there and I wasn’t even able to see it. So I just recreated that custom PID and deleted the old one.

Neither of these two things should cause the dropped frames, though, according to Ian. And that makes sense to me. See below for my thoughts on the cause.

I have since sent Ian 2 more debug logs trying to figure out what is/are generating the errors that show up in the adaptor status page.

I’m not sure if he agrees with me or not on my assumption of what’s causing the dropped frames though, I haven’t heard back from him since the first debug log (he is a busy guy after all) but here’s what I’ve come up with: the 7E1 ecu (trans) just responds to requests slower than the 7E0 (engine) ecu. Not normally slow enough to cause problems with single-frame responses with the “Faster communication” (ATAT2) enabled, but the timing determined and set by ATAT2 ends up being too short for this ecu sometimes on multi-frame responses, so that 2nd frame just gets missed because the timeout set by atat2 is too short for it. So my work around for now is to have a diagnostic start of ATAT0 (disables faster comms) and then a stop of ATAT2 (turns them back on). In the profile, I have a ATST0b command in the custom init line, to force the timeout to something I know works for the 7E1 ecu when the faster communication gets turned off. Setting the ATST0b in the custom init string removes that command from the diagnostic lines in the PID and reduces the number of commands sent each time the PID is requested, and therefore speeds up read speeds. At best with nothing else being monitored, and no custom start/stop/init strings, I get 12-18 responses per second on that particular PID. It slows all the other PIDs down because of the slowness of the ecu and the extra commands, but I’m up to a refresh rate of 1-2 times per second with 3-5 other gauges being monitored. Not great but acceptable for now.

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: July 5, 2019 (GMT)

Ian,

Did you get my last couple debug logs?

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: July 10, 2019 (GMT)

Bump

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

piemmm
Administrator
Posts: 6071
Post Re: Occasional lost frame from multi-frame response
on: July 11, 2019 (GMT)

Hi!

Had another look at the newest debugs – for the pid 22A001, I can see that the ECU isn’t sending consistent data to the request (this may be due to the adpater, ecu, or something like the response changes when condition X is met in the management software calling for a different/truncated/etc response)

(Here’s the first request)
1561158707961 {– AT SH 7E1
1561158707963 –} OK
1561158707963 {– 22A0012
1561158707979 –} 7E9100B62A001000002
1561158708002 {– AT SH 7DF

(Here’s the same request, but more data was returned)
1561158708359 {– AT SH 7E1
1561158708362 –} OK
1561158708362 {– 22A0012
1561158708375 –} 7E9100B62A001000002
1561158708398 –} +7E921B602AD00090002
1561158708399 {– AT SH 7DF

This is about the only thing I can see that sticks out in the debug logs you’ve sent

d_mcham
Member
Posts: 13
Post Re: Occasional lost frame from multi-frame response
on: July 19, 2019 (GMT)

Thanks, Ian, for taking another look. I’m sure you are correct. Like I said before though, it does work consistently with the delay set at 0B for that PID, and the read rate with that isn’t horrible and is just acceptable.

Thanks for the help, both Ian and Cintakc!

2017 Ram 3500, 6.7L Cummins; OBDLink MX BT and an OBDLink SX

Pages: [1]
WP-Forum by: Fredrik Fahlstad, Version: 2.4
Page loaded in: 0.425 seconds.

  Follow me on twitter