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

Soko ovms at soko.cc
Fri Jul 31 18:57:52 HKT 2020 

@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200731/e98503f8/attachment.htm>

More information about the OvmsDev mailing list