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

Michael Balzer dexter at expeedo.de
Fri Jul 31 17:29:27 HKT 2020 

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

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

More information about the OvmsDev mailing list