[Ovmsdev] VW e-Up read/poll via OBD is working

Michael Balzer dexter at expeedo.de
Fri Jul 31 20:09:53 HKT 2020 

Soko,

you don't need to use the poller to scan for OBD devices. You can simply
do manual transmissions and look for responses.

To send a manual request, simply use the can tx command. Example:

OVMS# can can1 tx standard 79b 02 01 00 00 00 00 00 00

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.

Send this with can logging enabled without filters, so you can see all
responses. A response could look like this:

V (591792) canlog-monitor: 1596194327.716686 1R11 7BB 03 7f 01 11 00 00
00 00

This tells you:

  * there is a device listening at 79b, which answers at 7bb -- nice!
  * it probably talks ISO-TP -- nice!
  * it  won't allow you to do this request in it's default session: 7F =
    serviceNotSupportedInActiveSession

OK, let's try to change the session (command 10) to the ISO 14229
standard "extendedDiagnosticSession" (value 03):

V (2085712) canlog-monitor: 1596195821.642256 1T11 79B 02 10 03 00 00 00
00 00
V (2085722) canlog-monitor: 1596195821.659737 1R11 7BB 03 7f 10 12 00 00
00 00

No luck. You can now begin trying all possible session codes. Or, in my
case, I already know the device uses C0 ;-)

V (2095662) canlog-monitor: 1596195831.598560 1T11 79B 02 10 c0 00 00 00
00 00
V (2095672) canlog-monitor: 1596195831.609308 1R11 7BB 02 50 c0 00 00 00
00 00

We're logged in -- nice! :-)

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):

V (2530842) canlog-monitor: 1596196266.780867 1T11 79B 02 01 00 00 00 00
00 00
V (2530862) canlog-monitor: 1596196266.797961 1R11 7BB 03 7f 01 11 00 00
00 00

Still no luck. So this tells you, the device does not support standard
OBD-II PIDs. How about a UDS DTC request (19)?

V (3034142) canlog-monitor: 1596196770.085839 1T11 79B 02 19 01 ff 00 00
00 00
V (3034162) canlog-monitor: 1596196770.103517 1R11 7BB 03 7f 19 12 00 00
00 00

No luck. Let's try command 21 (read enhanced data by 8 bit PID) at PID
00 next:

V (2737632) canlog-monitor: 1596196473.567437 1T11 79B 02 21 00 00 00 00
00 00
V (2737712) canlog-monitor: 1596196473.649927 1R11 7BB 03 7f 21 12 00 00
00 00

Nope… maybe PID 01?

V (2744182) canlog-monitor: 1596196480.120911 1T11 79B 02 21 01 00 00 00
00 00
V (2744262) canlog-monitor: 1596196480.203461 1R11 7BB 10 34 61 01 13 88
13 83

Houston, we've got a response :-)

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.

For the standard UDF commands, you will need a copy of the ISO 14229
standard.

Regards,
Michael


Am 31.07.20 um 12:57 schrieb Soko:
>
> @Chris: Thanks for taking care of the upgrade process for the new
> vehicle IDs
>
> @Mark: I will have a 1 hour session with VCDS today to find any other
> ECU/PIDs we can maybe use to see if the car is on/off/charging/etc. So
> maybe I find the ID of the gateway as well
>
> @Michael:
> I had the ignition off because I wanted to see if there is anything I
> can query in that state. I've measured the voltages again with
> ignition on: No change besides pin 1 becoming +12V (as already
> mentioned @ wikipedia).
> I've tried to find (via Google) any (e)Up, or even general-VW,
> specific pin schematics of the OBD connector... no luck. Maybe there
> are some special gateway commands to put a specific CAN directly to
> i.e. pin 3+11. But without getting hands on VW internal docs I don't
> see how to get this info with try&error.
> I will give the CANopen scan a try.
>
> On how to to a range scan (700-7FF): A little bit of more input would
> be great. You can find my current class here:
> https://github.com/devmarxx/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/vehicle_vweup/src/obd_eup.cpp
>
> I thought of generating one entry for each of the txids (700-7FF) in
> the vwup_polls[] array. But how do I tell the poller to accept any
> respond Id? And which type and PID should I try?
>
> Imho the most promising approach is to log what VCDS is doing and
> which ECUs are in there and which PIDs each has. VCDS should know all
> possible ECUs+PIDs for the new eUp. It has the newest USB-interface
> and the software was just updated 2 weeks ago.
>
> Soko
>
>
> On 31.07.2020 11:29, Michael Balzer wrote:
>> You can first try to scan the ID range 700 - 7FF, as all currently
>> known e-Up devices are in that range.
>>
>> If you scan for unknown devices, you need to try different standard
>> requests and check for responses on all CAN IDs, as ISO-TP allows
>> devices to respond with arbitrary IDs.
>>
>> In case of no unknown OBD/ISO-TP responses you may also try doing a
>> CANopen scan:
>> https://docs.openvehicles.com/en/latest/components/canopen/docs/Howto-detect-CANopen-nodes.html
>>
>> …but chances are possibly low VW mixes ISO-TP with CANopen devices
>> (Renault does).
>>
>> Regards,
>> Michael
>>
>>
>> Am 31.07.20 um 10:54 schrieb Mark Webb-Johnson:
>>> The other suggestion I have is to see if the gateway itself is alive
>>> for query. If you know the gateway ECU can bus arbitration ID
>>> (assuming you are not already doing that for polling). Perhaps it
>>> responds to a normal OBDII standard poll (for things like speed,
>>> etc), or a UDS style diagnostic query.
>>>
>>> Regards, Mark.
>>>
>>>> On 31 Jul 2020, at 3:50 PM, Michael Balzer <dexter at expeedo.de
>>>> <mailto:dexter at expeedo.de>> wrote:
>>>>
>>>> Soko,
>>>>
>>>> you only had the door open, but not turned on the car? If there are
>>>> additional buses, they may be switched off until the car is turned on…
>>>>
>>>> The OBD connector scheme is the general pin assignment, I meant the
>>>> specific VW e-Up schematics. But if you don't see any voltages with
>>>> the car turned on, that's bad news.
>>>>
>>>> There may still be some command interface for the OBD gateway to
>>>> enable live data, but without any info about the gateway, it will
>>>> be hard to even find out how to address it.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 31.07.20 um 09:06 schrieb Soko:
>>>>>
>>>>> Hey guys,
>>>>>
>>>>> If I did nothing wrong I have bad news:
>>>>>
>>>>> @Michael:
>>>>> With OBD port schematics I think you mean this
>>>>> https://en.wikipedia.org/wiki/On-board_diagnostics#OBD-II_diagnostic_connector
>>>>> Specifically if there are some other pins used than the standard
>>>>> CAN pins 6 and 14.
>>>>> So I had the drivers door open, no key in ignition and measured
>>>>> the voltages of all pins in relation to pin 5 (signal ground).
>>>>> There is no voltage on any pin besides 2.5V on 6 and 14, and 12V
>>>>> on 16 of course. So there are no hidden CAN buses (or any other
>>>>> signals) afaict.
>>>>>
>>>>> @Mark:
>>>>> Thanks for the hint with the can log. It's way easier than RE
>>>>> Tools for just checking if there is any traffic.
>>>>> Having said that... there is no traffic whatsoever besides what I
>>>>> am polling and the reply. Even when ignition is on I only see the
>>>>> poll and the reply on the can log
>>>>>
>>>>> So it seems devmarxx was right: The gateway shields everything and
>>>>> there are even no other hidden signals on the OBD port.
>>>>>
>>>>> I'm happy to try any other ideas you guys have. Just let me know!
>>>>>
>>>>> Soko
>>>>>
>>>>>
>>>>> On 31.07.2020 02:11, Mark Webb-Johnson wrote:
>>>>>> If you are just looking for traffic on the CAN bus, a simple can
>>>>>> log would be the easiest. Assuming you are on USB console, it is:
>>>>>>
>>>>>>     OVMS# log level verbose canlog-monitor
>>>>>>     OVMS# can log start monitor crtd
>>>>>>
>>>>>>
>>>>>> If you are using ssh, you need to add a:
>>>>>>
>>>>>>     OVMS# log monitor yes
>>>>>>
>>>>>>
>>>>>> To stop the logging:
>>>>>>
>>>>>>     OVMS# can log stop
>>>>>>
>>>>>>
>>>>>> Documentation here:
>>>>>>
>>>>>>     https://docs.openvehicles.com/en/latest/crtd/can_logging.html
>>>>>>
>>>>>>
>>>>>> For my work, I personally prefer this arrangement:
>>>>>>
>>>>>>     OVMS# can log start tcpserver transmit gvret-b :23
>>>>>>
>>>>>>
>>>>>> And then I use SavvyCAN <https://www.savvycan.com/> on a laptop
>>>>>> to connect over wifi and work.
>>>>>>
>>>>>> Regarding the ‘re’ system, it is a work-in-progress, and not
>>>>>> currently documented. It is still kind of a mess at the moment
>>>>>> (particularly for multiplexed message IDs), as I continue to work
>>>>>> on DBC integration. That said, it is basically functional.
>>>>>>
>>>>>> To start it:
>>>>>>
>>>>>>     OVMS# re start
>>>>>>
>>>>>>
>>>>>> To stop it:
>>>>>>
>>>>>>     OVMS# re stop
>>>>>>
>>>>>>
>>>>>> To see discovered IDs:
>>>>>>
>>>>>>     OVMS# re list
>>>>>>
>>>>>>
>>>>>> It will (by default) listen on all open CAN buses, and show you
>>>>>> the discovered ID, message count, interval (in ms), and last
>>>>>> message seen.
>>>>>>
>>>>>> It has some rudimentary ability to monitor active polling
>>>>>> protocols with ‘re obdii extended <min> <max>’ (or standard),
>>>>>> specifying the range of IDs used by the ECUs.
>>>>>>
>>>>>> Regards, Mark
>>>>>>
>>>>>>> On 30 Jul 2020, at 11:56 PM, Soko <ovms at soko.cc
>>>>>>> <mailto:ovms at soko.cc>> wrote:
>>>>>>>
>>>>>>> @devmarxx: Is there any doc/guide on how to use this RE Tools?
>>>>>>>
>>>>>>> @Michael: Yeah, I know. You would have done my 1-day work in 5
>>>>>>> mins. I know C++ but I don't know the OVMS framework. But its
>>>>>>> like with any project: The issue is not the language, its the
>>>>>>> framework.
>>>>>>>
>>>>>>> Until you have yours you have to settle with me unfortunately ;)
>>>>>>>
>>>>>>> My cousin has a working VCDS HEX interface and I have an
>>>>>>> y-adapter so I can listen with an ELM327 adapter to the commands
>>>>>>> VCDS is sending. Maybe I can find any car status there. Device
>>>>>>> 09 is a good hint.
>>>>>>>
>>>>>>> But as you said: I have still have to poll this, even if I find
>>>>>>> a status.
>>>>>>>
>>>>>>> I can't say (of course) if there's another CAN bus @ OBD port.
>>>>>>> All this CAN/OBD/Bus stuff is completely new to me.. ModBus
>>>>>>> RTU/TCP, MBus etc. I would know ;)
>>>>>>>
>>>>>>> So if you can point me in any direction what to try - or what
>>>>>>> you would do - I happy to dig into it.
>>>>>>>
>>>>>>> Soko
>>>>>>>
>>>>>>> PS: Any idea when you'll get your Mii?
>>>>>>>
>>>>>>> On 30.07.2020 17:14, Michael Balzer wrote:
>>>>>>>> If only I had my Mii already…
>>>>>>>>
>>>>>>>> If the OBD port is shielded from the CAN traffic, you need to
>>>>>>>> poll some device. ECU = Engine Control Unit = device 01.
>>>>>>>>
>>>>>>>> I would suspect the basic car status info to be available from
>>>>>>>> device 09 (central electrics), but it seems no PIDs have been
>>>>>>>> RE'd from there yet. So maybe you need to derive the info from
>>>>>>>> some other mode/status register.
>>>>>>>>
>>>>>>>> It's bad needing to continuosly poll to get the live status
>>>>>>>> data. Is possibly another, unfiltered CAN bus available at the
>>>>>>>> OBD port?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 30.07.20 um 16:43 schrieb Soko:
>>>>>>>>>
>>>>>>>>> Ahhh OK, I've found OvmsVehicle::virtual void
>>>>>>>>> TickerXXX(uint32_t ticker);
>>>>>>>>> Got it! This was exactly my issue as I didn't know about any
>>>>>>>>> function which gets called regularly so I could check
>>>>>>>>> something like this...
>>>>>>>>> It's not an ideal situation though: I just can slow down the
>>>>>>>>> poll after my fail-counter gets too high as I need to check
>>>>>>>>> when the car gets powered again. So all I can do is polling,
>>>>>>>>> lets say every 60 secs when the car is off, and increase it
>>>>>>>>> once its on. But there is now way around this 60-sec polling
>>>>>>>>> if the only thing I can do is poll :(
>>>>>>>>>
>>>>>>>>> Afaik there is only the sharkcow's list below, reverse
>>>>>>>>> engineered by him from ODBeleven.
>>>>>>>>>
>>>>>>>>> (dev)marxx exlpained to me: There is a gateway between the
>>>>>>>>> CAN-Buses and the OBD Connector in all VW-AG vehicles which
>>>>>>>>> only replies to polls and also acts as security gateway if you
>>>>>>>>> want to write to the buses.
>>>>>>>>>
>>>>>>>>> So I think I cannot really do a can log or use re tool as the
>>>>>>>>> OBD interface stays quiet if I'm not polling it...
>>>>>>>>>
>>>>>>>>> And as there is no other vehicle from VW,Seat,Skoda,Audi,etc.
>>>>>>>>> in OVMS. So I have no cheat-sheet :(
>>>>>>>>>
>>>>>>>>> Anyhow... I would need to poll one ECU (is this the correct
>>>>>>>>> therm?) which doesn't shuts down... or maybe the issue is the
>>>>>>>>> OBD-gateway shutting down.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Soko
>>>>>>>>>
>>>>>>>>> On 30.07.2020 16:17, Michael Balzer wrote:
>>>>>>>>>> Soko,
>>>>>>>>>>
>>>>>>>>>> nice progress :-)
>>>>>>>>>>
>>>>>>>>>> If you can't detect vehicle state by listening to regular
>>>>>>>>>> status CAN frames, you can check the time since the last poll
>>>>>>>>>> reply in the per second ticker.
>>>>>>>>>>
>>>>>>>>>> As poll replies normally come in fast, you should be able to
>>>>>>>>>> detect a switch-off by a small timeout, say 3 seconds…
>>>>>>>>>> probably need to add a counter, as a single poll may get lost
>>>>>>>>>> / ignored.
>>>>>>>>>>
>>>>>>>>>> CAN tx errors can be caused by other issues as well, so
>>>>>>>>>> should generally not be interpreted that way.
>>>>>>>>>>
>>>>>>>>>> But… are you sure there are no status frames on the bus? Have
>>>>>>>>>> you done a can log or tried the re tool?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Michael
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Am 30.07.20 um 14:43 schrieb Soko:
>>>>>>>>>>> Hi guys,
>>>>>>>>>>>
>>>>>>>>>>> Want to report success on connecting and reading my VW e-Up
>>>>>>>>>>> via OBD cable using the Poller. As you can see in the
>>>>>>>>>>> screenshot of the log attached I get an
>>>>>>>>>>> IncomingPollReply(..) call and an SoC value of 33.333%
>>>>>>>>>>>
>>>>>>>>>>> Once I turn of the ignition and lock the car though I don't
>>>>>>>>>>> get any replies no more (line D 793813) and then I get can1
>>>>>>>>>>> errors... I'm polling with 10 seconds intervall.
>>>>>>>>>>>
>>>>>>>>>>> I know that this is as it should be... but my issue is: I
>>>>>>>>>>> don't have any way to know if the ignition is on, the key is
>>>>>>>>>>> in, the car is running, the car is charging as the PIDs are
>>>>>>>>>>> not known for such values (afaik by the lists of sharkcow
>>>>>>>>>>> https://www.goingelectric.de/wiki/Liste-der-OBD2-Codes/).
>>>>>>>>>>>
>>>>>>>>>>> So what would be the best approach to change the different
>>>>>>>>>>> polling states? Can I somehow get called (in my
>>>>>>>>>>> vehicle-class) if an can-error is thrown? Then I would
>>>>>>>>>>> increase the poll frequency.
>>>>>>>>>>>
>>>>>>>>>>> Any suggestions?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>>
>>>>>>>>>>> Soko
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OvmsDev mailing list
>>>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OvmsDev mailing list
>>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OvmsDev mailing list
>>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> OvmsDev mailing list
>>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.openvehicles.com
>>>>>>> <mailto:OvmsDev at lists.openvehicles.com>
>>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.openvehicles.com
>>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.openvehicles.com
>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>>
>>>> -- 
>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>
>> -- 
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200731/74920d07/attachment.htm>

More information about the OvmsDev mailing list