Harry's GPS Suite Forum

Dear Harry,

i've tried very hard getting the carly adapter to work and went through the board to find some useful information, unfortunately nothing helped.

The result was: Unfortunately i didn't recognise that as a first connection and kept fiddling with the setting and ever since i haven't been able to reproduce that.

The adapter works like a charm with (iPhone) Carly for BMW, iOBD2, OBDCarDoctor.

My car is a 2006 BMW e87 130i which should support ISO 9141-2 & ISO 14230-4.

ISO 14230-4 fast init is used by iOBD2.

The ip settings are standard 192.168.0.10:35000 which always triggers kiwi 3 in HLT so i tried using 35001 as port and used the custom OBD setting (also when above picture was created).

App is Grand Prix now, since it wouldn't work with rookie, i kept upgrading since i thought it might not have been implemented below, didn't bring any success either.

Unfortunately i'm a little bit stuck now and don't know how to proceed any further. Have you got any tip for me how to start the debug in this case?

I believe it would be a big gain for the BMW community to get this one running. According the the manufacturer it is ELM327 compatible.

Kind regards from Flensburg

Sven

Hi,

At least it is speaking ELM. I suggest to remove the custom OBD settings, there is nothing special about the Kiwi slot, it will work with any adapter using the same IP/port.

From the snapshots it looks like the adapter reports most relevant PIDs are not available. Please check if PIDs like RPM are excluded in LapTimer's Expert Settings / OBD Tweaks. Clear the exclusion field altogether and make sure auto exclude is not ticked.

Once this is done, we can run the OBD Debugging session described here on the forum (see FAQs).

Please understand I cannot investigate every adapter available. I support adapters adapters adding unique features making LapTimer a better tool. But I support them only if the manufacturer is keen to get support and supports me.

Harry

Hi Harry,

i've kept digging ... using a logfile from gps buddy and a console i followed step by step through your initialisation ELM327 commands and found the issue here:

OBDSENSORS 0014158672@main 02 --> request timeout set to: ATSTFF (from 1.02)

for whatever reason that timeout which is standard value causes 0100 to not reply with data.

Entering ATST0 in the console brought 0100 back to normal.

I then set the timeout to 0 in the app and there it connects... For now the live view is showing 2.3Hz but I haven't spent much time optimizing.
The settings are as follows:
Can you tell me if ATST set to 0 has any negative influence now or can i just leave it as is?

I'd much appreciate any hint in howto increase the performance... I've seen that by altering settings slightly the rate reduced to 1.5hz, so i hope there might be half a Hz to optimize up

If you like a logfile with the running Carly Adapter just let me know, I'll send you one across.

Thanks

Sven

ATST defines the time the adapter is waiting at max until it stops listening to replies from the bus. It is a timeout defined by ELM as follows:

ST hh [ Set Timeout to hh ]
After sending a request, the ELM327 waits a preset time for a response before it can declare that there was ‘NO DATA’ received from the vehicle. The same timer setting is also used after a response has been received, while waiting to see if more are coming. The AT ST command allows this timer to be adjusted, in increments of 4 msec.
When Adaptive Timing is enabled, the AT ST time sets the maximum time that is to be allowed, even if the adaptive algorithm determines that the setting should be higher. In most circumstances, it is best to leave the AT ST time at the default setting when using adaptive timing.
The ST timer is set to 32 by default (giving a time of approximately 200 msec), but this value can be adjusted by changing PP 03. Note that a value of 00 does not result in a time of 0 msec – it will restore the timer to the default value.

ATST00 resets the timer to the default and has no negative impact.

Some background on this: when a PID is requested, it is probably delivered by more than one ECU. This means the adapter needs some idea how long to wait for replies until it returns anything received to the caller (LapTimer) and ask for the next request. Or more illustrative: LapTimer asks for RPM, the adapter sends this request to the bus, it returns after 50ms with the reply from one ECU. What now, there are probably other ECUs responding, how long should it wait.

Leaving an adapter in standard mode, makes it running its own guess on whether further replies can be expected. You can force this behavior by setting Expert Settings ‣ OBD Tweaks / Adaptive Timing to "Enabled". This will restore ATST to the default and leave the whole optimization to the adapter.

The alternative approach is to let LapTimer do the optimization. This mode is activated by setting Expert Settings ‣ OBD Tweaks / Adaptive Timing to "Optimized". And here is how it works: LapTimer raises the timeout period to the max (ATSTFF). For any initial PID request, it is waiting for any replies coming in. It memorizes the number of results. This number is typically 1, 2, or 3. Any following request will be augmented by the number of expected replies. So if e.g. RPM is answered by one ECU only, LapTimer asks to retrieve this PID and to return immediately once 1 PID is available. This renders any timeout setting unused and will usually result in higher update rates.

The downside is this second approach is not well handled by every car bus, in particular by older busses.

If you want, you can try the following: benchmark update rates for both "Optimized" and "Adaptive". Select whatever is faster. Setting the Reply Timeout to 0.2 or 0.3 instead of 1.02 (default) will probably work for both although a higher setting is favorable for the "Optimized" approach to not miss replies during the initial negotiation. Needless to say, for your car, the highest setting does not work.

As a last - although bad - message: you will not get more than 2 or 3 Hz (which means 10 to 15 PIDs / s) for a ISO 14230 bus. They are just slow.

- Harry

Hi Harry,

many thanks for your comprehensive answer.

When i'll find some time i'll run gps buddy to get another log of the now working adapter.

I have 2.3 hz now, thats Ok for me, I need to try if the refresh rate increases when i monitor RPM & throttle positiom only and exclude all others.

Regards

Sven