<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Soko,<br>
<br>
not sure if the standard cable connects pin 1 on the OBD port side,
but the DB9 connector has GEP_7 on pin 1 (see OVMS schematics). So
you can route that to an EGPIO input (take care to add a voltage
divider on the way). So that would need a simple hardware extension
/ modification, but is an option.<br>
<br>
Sorry, can't help you on the VCDS stuff.<br>
<br>
In my scan example, I initially was going to make an artificial
example, then changed to using my Twizy live responses as an
example. So that should have been 79b instead of 700.<br>
<br>
Regarding typing the command 256 times… you know we've got a
powerful scripting system on board? ;-)<br>
<br>
Of course you can also write a C++ function to do the same by
calling the CAN API directly. You just cannot use the polling
framework, as that's bound to specific rx IDs. But you can simply
read all CAN frames and look for responses without filtering by ID
first.<br>
<br>
A general purpose OBD scanner working that way could well be a
valuable extension to the RE toolkit.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 31.07.20 um 17:40 schrieb Soko:<br>
</div>
<blockquote type="cite"
cite="mid:73ffd3e7-f444-2524-2993-28125aaf6bcf@soko.cc">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Heya,</p>
<p>I'm back from my 2 hr VCDS session... not satisfying at all...</p>
<p><b>Car-off polling issue:</b><br>
VCDS lists me 19 ECUs (with the ignition on) which includes 09
"Zentralelektrik" (which Michael recommended), 19
"Diagnosteinterface" and 61 "Batterieregelung" which stay
responsive for a period of time after ignition is off. All other
are not responsive no more with no ignition...<br>
But: Once the car is locked not a single ECU is responding :( .
So there is nothing to poll which will respond in any state of
the car.<br>
The only option is the +12V on pin 1. <u>Is pin 1 somehow
connected to OVMS via the standard OBD adapter?</u></p>
<p><b>Sniffing VCDS (+CarScanner App) commands:</b><br>
Here I'm somehow confused now. I've tried to sniff the
header/txid of ECU 61 (Betterieregelung) as the list of sharkcow
hasn't it listed yet. It seems that the header is not
transmitted, neither in VCDS nor in CarScanner. Only the PID
goes to the OBD port. To understand the transmissions I've tried
in CarScanner to swap between two dashboards/value-readings. One
for SoC (=22 02 8C) of ECU 8C (header=7E5) outside-temp (=22 F4
46) of ECU 01 (header=7E0).<br>
I couldn't find any 7E5 or 7E0 in the sniffed data!? Why? How is
the ECU addressed then? I've also think of any rule to get from
the ECU number (i.e. 8C, 01) to the header, but couldn't find
any...</p>
<p><b>Scan for OBD devices:</b><br>
Thanks for the info & details Michael. But is there a chance
that I'll find an OBD device which VCDS doesn't know about (or
doesn't list in the software)?<br>
If yes: Can I somehow put this manual request in C++ code
instead of using the shell? Then I don't have to type this
manually 256 times (by using a loop) ;)<br>
Also, is there a typo in your email? You write "...sent to ID
700, type..." but the command says "79b" and later you write
"...there is a device listening at 79b...". So is ID 700 the
device 79b or did you mean ID 79B?</p>
<p>thx for you patience with me</p>
<p>Soko<br>
</p>
<div class="moz-cite-prefix">On 31.07.2020 14:09, Michael Balzer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d632962a-65c8-1083-1569-4c192fdaa71b@expeedo.de">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
Soko,<br>
<br>
you don't need to use the poller to scan for OBD devices. You
can simply do manual transmissions and look for responses.<br>
<br>
To send a manual request, simply use the can tx command.
Example:<br>
<br>
<tt>OVMS# can can1 tx standard 79b 02 01 00 00 00 00 00 00</tt><br>
<br>
This means: 2 byte OBD request sent to ID 700, type 01 = get
current data, from PID 00. PID 00 is supposed (OBD-II) to reply
with a four byte bitset of the device's PIDs 01-20 (hex)
support.<br>
<br>
Send this with can logging enabled without filters, so you can
see all responses. A response could look like this:<br>
<br>
<tt>V (591792) canlog-monitor: 1596194327.716686 1R11 7BB 03 7f
01 11 00 00 00 00</tt><br>
<br>
This tells you:<br>
<ul>
<li>there is a device listening at 79b, which answers at 7bb
-- nice!<br>
</li>
<li>it probably talks ISO-TP -- nice!</li>
<li> it won't allow you to do this request in it's default
session: 7F = serviceNotSupportedInActiveSession<br>
</li>
</ul>
OK, let's try to change the session (command 10) to the ISO
14229 standard "extendedDiagnosticSession" (value 03):<br>
<br>
<tt>V (2085712) canlog-monitor: 1596195821.642256 1T11 79B 02 10
03 00 00 00 00 00</tt><tt><br>
</tt><tt> V (2085722) canlog-monitor: 1596195821.659737 1R11 7BB
03 7f 10 12 00 00 00 00</tt><br>
<br>
No luck. You can now begin trying all possible session codes.
Or, in my case, I already know the device uses C0 ;-)<br>
<br>
<tt>V (2095662) canlog-monitor: 1596195831.598560 1T11 79B 02 10
c0 00 00 00 00 00</tt><tt><br>
</tt><tt> V (2095672) canlog-monitor: 1596195831.609308 1R11 7BB
02 50 c0 00 00 00 00 00</tt><tt><br>
</tt><tt> </tt><br>
We're logged in -- nice! :-)<br>
<br>
Let's try the PID read again (do this within 60 seconds or the
session will log out, unless you send a "tester present" frame):<br>
<br>
<tt>V (2530842) canlog-monitor: 1596196266.780867 1T11 79B 02 01
00 00 00 00 00 00</tt><tt><br>
</tt><tt>V (2530862) canlog-monitor: 1596196266.797961 1R11 7BB
03 7f 01 11 00 00 00 00</tt><br>
<br>
Still no luck. So this tells you, the device does not support
standard OBD-II PIDs. How about a UDS DTC request (19)?<br>
<br>
<tt>V (3034142) canlog-monitor: 1596196770.085839 1T11 79B 02 19
01 ff 00 00 00 00</tt><tt><br>
</tt><tt>V (3034162) canlog-monitor: 1596196770.103517 1R11 7BB
03 7f 19 12 00 00 00 00</tt><br>
<br>
No luck. Let's try command 21 (read enhanced data by 8 bit PID)
at PID 00 next:<br>
<br>
<tt>V (2737632) canlog-monitor: 1596196473.567437 1T11 79B 02 21
00 00 00 00 00 00</tt><tt><br>
</tt><tt>V (2737712) canlog-monitor: 1596196473.649927 1R11 7BB
03 7f 21 12 00 00 00 00</tt><br>
<br>
Nope… maybe PID 01?<br>
<br>
<tt>V (2744182) canlog-monitor: 1596196480.120911 1T11 79B 02 21
01 00 00 00 00 00</tt><tt><br>
</tt><tt>V (2744262) canlog-monitor: 1596196480.203461 1R11 7BB
10 34 61 01 13 88 13 83</tt><br>
<br>
Houston, we've got a response :-)<br>
<br>
You would now check if this response is a single or multi frame
type, then try to get all data and then try to map the data to
something you would expect to be stored in that device.<br>
<br>
For the standard UDF commands, you will need a copy of the ISO
14229 standard.<br>
<br>
Regards,<br>
Michael</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>