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

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?

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.

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

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!

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.

Ian,
Did my debug data make it to you?

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.

Bump

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!