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

Chris van der Meijden chris at arachnon.de
Fri Jul 31 17:05:26 HKT 2020


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_d
> > iagnostic_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_logg
> > > ing.html
> > >           
> > >         
> > >         
> > >           
> > > 
> > >           
> > >           
> > >             
> > >               For my work, I personally prefer this arrangement:
> > >               
> > > 
> > >               
> > >             
> > >             
> > >               OVMS# can log start tcpserver transmit gvret-b :23
> > >             
> > >             
> > >               
> > > 
> > >               
> > >             
> > >             And
> > >               then I use SavvyCAN 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>
> > > > 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.going
> > > > > > > > electric.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
> > > > > > 
> > > > > >                     
> > > > > 
> > > > >                     
> > > > > 
> > > > >                     -- 
> > > > > 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
> > > > 
> > > >               
> > > >             
> > > 
> > >           
> > >           
> > > 
> > >         
> > >         
> > > 
> > >         
> > >         _______________________________________________
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200731/52af7304/attachment-0001.html>


More information about the OvmsDev mailing list