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

Michael Balzer dexter at expeedo.de
Thu Aug 13 01:57:15 HKT 2020 

Config → Vehicle → Vehicle name

It doesn't have a technical use yet, it won't get filled automatically.
It's just a free vehicle name (as the placeholder says).

Regards,
Michael

Am 12.08.20 um 19:34 schrieb Chris van der Meijden:
> Hey Michael
>
> Thanx.
>
> Does the human readable vehicle ID description ("VW e-Up (Komfort
> CAN)") matter at all, or will it be filled out automaticly by the new
> vehicle ID configuration? If not, how do I set that param?
>
> Regards
>
> Chris
>
> Am Mittwoch, den 12.08.2020, 19:18 +0200 schrieb Michael Balzer:
>> Chris,
>>
>> yes, that would do. But…
>>
>> a) you shouldn't overwrite the vehicle name, that's a user
>> configuration, and
>>
>> b) if you would overwrite the vehicle name, you would set "name" in
>> "vehicle", not "vehicle.name" in "auto" (which doesn't exist).
>>
>> Regards,
>> Michael
>>
>>
>> Am 12.08.20 um 18:59 schrieb Chris van der Meijden:
>>> Hi Michael
>>>
>>> I found some time for the "hanging upgrade" issue since we splitted
>>> the vehicle ID from VWUP to VWUP.T26 and VWUP.OBD.
>>>
>>> Would this code in ovms_config.cpp within OvmsConfig::upgrade()
>>> prevent the "hanging" after an upgrade?
>>>
>>> // Migrate vehicle ID VWUP to VWUP.T26
>>> if (GetParamValue("auto", "vehicle.type") == "VWUP")
>>>    {
>>>    SetParamValue("auto", "vehicle.type", "VWUP.T26");
>>> SetParamValue("auto", "vehicle.name", "VW e-Up (Komfort CAN)");
>>> }
>>>
>>> If so, I would put that in a pull request as soon as we have a new
>>> "release worthy" version?
>>>
>>> Thanx for checking.
>>>
>>> Greetinx
>>>
>>> Chris
>>>
>>> Am Freitag, den 31.07.2020, 11:34 +0200 schrieb Michael Balzer:
>>>> Chris,
>>>>
>>>> the framework shouldn't get stuck if a vehicle cannot be loaded, it
>>>> should fall back to booting without a vehicle. I'll have a look at
>>>> that.
>>>>
>>>> Btw, to automatically update user configurations, you can extend
>>>> OvmsConfig::upgrade(). Users shouldn't need to take care of special
>>>> update preparations.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> Am 31.07.20 um 11:05 schrieb Chris van der Meijden:
>>>>> Welcome to my trial and error T26A world :-))
>>>>>
>>>>> This morning I flashed the new T26A/OBD version to my OVMS. After
>>>>> the OTA flash the device did not come back to the networks. Only
>>>>> USB terminal access was left.
>>>>>
>>>>> The reason was, that I did no remove the old vehicle config "VWUP"
>>>>> before flashing and rebooting. The new image has "VWUP.T26" and
>>>>> "VWUP.OBD" as vehicle config, but no more "VWUP". So the device
>>>>> could not find its vehicle config and got stuck.
>>>>>
>>>>> From the USB terminal I bootet back to OTA_0, said in the vehicle
>>>>> config that my vehicle was a Nissan Leaf and then booted back to
>>>>> OTA_1. The device came up with the new firmware and I could change
>>>>> the vehicle config to "VWUP (Komfort CAN)".
>>>>>
>>>>> Everything is now running fine ...
>>>>>
>>>>> I will write this down in the documentation for the e-Up.
>>>>>
>>>>> Greetinx
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> Am Freitag, den 31.07.2020, 09:50 +0200 schrieb Michael Balzer:
>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 <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 <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/20200812/525c6db1/attachment.htm>

More information about the OvmsDev mailing list