On 2020-09-30 01:42, Chris van der Meijden wrote:

Oh boy ...

Found this one:

http://lists.openvehicles.com/pipermail/ovmsdev/2020-February/006640.html

You indeed have to pull the fuse for a minute and not only for two seconds ...

Very strange, but hey it works now :-)

Network Registration: RegisteredHome Provider: o2 - de+ Signal: -97 dBm State: NetStart

I have not seen this issue since Mark made the change in April described in the attached; he added a uart_flush() call to simcom::PowerCycle(): https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/9de2... Craig -------- Forwarded Message -------- Subject: [Ovmsdev] Modem unable to power cycle successfully Date: Thu, 16 Apr 2020 10:40:20 +0800 From: Mark Webb-Johnson <mark@webb-johnson.net> Reply-To: OVMS Developers <ovmsdev@lists.openvehicles.com> To: OVMS Developers <ovmsdev@lists.openvehicles.com> I’ve seen cases where the modem will not come up correctly, even following a power cycle. But, a reset of the OVMS module (ESP32) solves the problem. This really makes no sense, unless something is getting corrupted inside the UART / EGPIO driver itself. The modem module status is not changed during an ESP32 reset - only the software side of it running in the ESP32. Thomas Heder has reported some success with using uart_flush to flush the UART ring buffer when power cycling the modem. Flushing the buffer would not seem to affect this, as we use ‘AT’ to look for an OK response during power up check anyway; but perhaps something is corrupt in the ring buffer itself, so using uart_flush clears that problem. Note that uart_flush is an alias for uart_flush_input, and the source code does seem to show a complete reset of the ring buffer pointers with interrupts disabled (not just a simple emptying). Anyway, the approach does not seem to do any harm, so I have added it to the latest code and let’s see if it improves the situation. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/354 Regards, Mark.

I'm having trouble getting a multiline OBD message to be read by OVMS. What exactly does error code 31 mean? In the OVMS log I see: D (806212) vehicle: PollerSend(0): send [bus=1, type=22, pid=1821], expecting 713/77d-77d D (806222) vehicle: PollerReceive[77D]: process OBD/UDS error 22(1821) code=31 The only messages with header 713 and 77D in the CAN log are: 1601729078.788373 1T11 713 03 22 18 21 00 00 00 00 1601729078.801032 1R11 77D 03 7f 22 31 aa aa aa aa However, when I log with OVMS what happens when a working third-party OBD-adapter issues the command, I see: 1601721047.201952 1R11 713 03 22 18 21 55 55 55 55 1601721047.210050 1R11 77D 10 2f 62 18 21 01 fe 00 1601721047.210695 1R11 713 30 ff 01 55 55 55 55 55 1601721047.214801 1R11 77D 21 00 16 15 00 00 02 20 1601721047.219865 1R11 77D 22 00 00 00 04 00 00 00 1601721047.224808 1R11 77D 23 00 00 00 15 91 00 00 1601721047.230282 1R11 77D 24 01 66 00 00 00 00 00 1601721047.235039 1R11 77D 25 00 00 00 00 fe c9 c9 1601721047.240117 1R11 77D 26 c9 c9 ff fe ff ff aa Does OVMS even support multiline OBD messages? Are there any settings I should adjust? Any clues? :) I'm guessing the intermediate "713 30 ff 01" an acknowledge for the multiline response, does/can OVMS send that? Thanks for any hints! sharkcow

Michael, thanks for the explanation. Still I'm wondering why the same command works when issued from the third-party OBD adapter... are there any setup commands I could look out for? sharkcow Am 03.10.20 um 20:08 schrieb Michael Balzer:

sharkcow,

0x22 is VEHICLE_POLL_TYPE_OBDIIEXTENDED and well supported, see vehicle module.

See the PDF I just sent you on page 252:

Error code 0x31:  requestOutOfRange

...

This response code indicates that the requested action will not be taken because the server has detected that the request message contains a parameter which attempts to substitute a value beyond its range of authority (e.g. attempting to substitute a data byte of 111 when the data is only defined to 100), or which attempts to access a dataIdentifier/routineIdentifer that is not supported or not supported in active session. This response code shall be implemented for all services which allow the client to read data, write data or adjust functions by data in the server.

Regards, Michael

Am 03.10.20 um 14:59 schrieb sharkcow:

...

I'm having trouble getting a multiline OBD message to be read by OVMS. What exactly does error code 31 mean?

In the OVMS log I see:

D (806212) vehicle: PollerSend(0): send [bus=1, type=22, pid=1821], expecting 713/77d-77d D (806222) vehicle: PollerReceive[77D]: process OBD/UDS error 22(1821) code=31

The only messages with header 713 and 77D in the CAN log are:

1601729078.788373 1T11 713 03 22 18 21 00 00 00 00 1601729078.801032 1R11 77D 03 7f 22 31 aa aa aa aa

However, when I log with OVMS what happens when a working third-party OBD-adapter issues the command, I see:

1601721047.201952 1R11 713 03 22 18 21 55 55 55 55 1601721047.210050 1R11 77D 10 2f 62 18 21 01 fe 00 1601721047.210695 1R11 713 30 ff 01 55 55 55 55 55 1601721047.214801 1R11 77D 21 00 16 15 00 00 02 20 1601721047.219865 1R11 77D 22 00 00 00 04 00 00 00 1601721047.224808 1R11 77D 23 00 00 00 15 91 00 00 1601721047.230282 1R11 77D 24 01 66 00 00 00 00 00 1601721047.235039 1R11 77D 25 00 00 00 00 fe c9 c9 1601721047.240117 1R11 77D 26 c9 c9 ff fe ff ff aa

Does OVMS even support multiline OBD messages? Are there any settings I should adjust? Any clues? :)

I'm guessing the intermediate "713 30 ff 01" an acknowledge for the multiline response, does/can OVMS send that?

Thanks for any hints!

sharkcow _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

Dear developers, I have just submitted a pull request for (yet another :) module for the VW e-Up. It's nothing really new as I simply combined the two existing VW e-Up modules for access via Comfort CAN and OBD2 into one module. For now it seems like I'm the only one with both connections, but in the long run I think this is the way to go, because write functions like AC are working on C-CAN, while OBD offers a wealth of metrics (when the car is on or charging). I have started adding additional metrics on OBD and will continue mainly on this route. A few words about myself: I'm an electrical engineer who has always been fascinated by programming hardware functions (started using the extension port of a Schneider CPC computer, which only Germans will know... a competitor to the Commodore C64 at the time). I have been dabbling in microcontrollers (mostly Atmel) and Raspberry Pi for the last few years. Since I never really learned modern programming languages, I go by google-paste-and-error :) So please forgive if you see horrible code; I promise I'm always willing to learn! In 2019, I bought a (generation 1) VW e-Up and ever since tried to figure out as much about the OBD metrics as I can. The breakthrough came beginning of this year, when I managed to sniff about 1100 OBD codes by using a commercial OBD adaptor and a Y-cable with a PC to log the codes. At about the same time, devmarxx showed up and brought me to OVMS. Concerning OVMS, I can only thank you guys for a really great hard- and software platform! This is the perfect playing ground for someone like me. Currently, I just keep discovering how matured this system already is... I try to learn from existing code and can't see any limits to the possibilities :) So, I would be very happy if VWEUP.ALL can be included and maybe one or the other of you can give me helpful hints on how to do things the right way :) Have a great (hacking) weekend! sharkcow

Guys, if you all agree on merging both ways to connect now, a single vehicle implementation with some kind of connection configuration is again the right option. Copying the code from the separate vehicles to build a third one will not be acceptable as the general solution. That would become hell for code maintenance and user support. So you first need to agree on working together on this now. You split up because there were some hard to resolve issues in your earlier collaboration. I understand there are some features and metrics available on both buses, but most are available either only on the OBD bus or only on the KCAN bus. Users should be able to decide if they connect either or both of the buses, unless you find a simple option to provide connectivity to both from a convenient mounting place for the module. So for stuff available on both buses the code will need to decide which bus to use at a given time/state, depending on the connections available and the data quality available on each of the buses. That means you need to agree on which bus to prioritize if both are available, you need to collaborate on this with the goal of providing the best solution to the user, regardless of your personal preferences. It seems sharkcow is the perfect choice as a moderator on this. If you can agree on him/her for this role, you should contribute your changes to sharkcow's repository first. Sharkcow would take care to integrate your submissions and then forward the results to the OVMS repository for inclusion. On a first glance into the code I think you should reorganize the modules to separate the bus handling from the general logic / dispatching layer and factor out common utilities. As a side note: I can see there are now two bool configs reserved for this ("con_obd" & "con_t26"), both not actually used yet. This should become a combined config instance, as there are only three valid options. But I won't look further now. If you decide to work together now, I'm sure there will be a much better integration in no time. Regards, Michael Am 09.10.20 um 19:19 schrieb Chris van der Meijden:

Hey sharkcow,

great to see that you are pushing the VW e-Up to the next level :-)

I completely agree that merging the T26A and OBD code is finally the way to go. 

For now we still need a "simple" way to connect the hardware to the comfort can and the OBD port simultanously.

I took a quick look at your index.rst and would like to suggest to document how you connect your OVMS to T26A and OBD. Perhaps with a picture or two?

Also nice to read you started with a "Schneider". My starting point was a "Sinclair ZX81". Z80 assembler rulez :-)

Greetinx

Chris (devmarxx)

Am Freitag, den 09.10.2020, 18:50 +0200 schrieb sharkcow:

...

Dear developers,

I have just submitted a pull request for (yet another :) module for the VW e-Up. It's nothing really new as I simply combined the two existing VW e-Up modules for access via Comfort CAN and OBD2 into one module. For now it seems like I'm the only one with both connections, but in the long run I think this is the way to go, because write functions like AC are working on C-CAN, while OBD offers a wealth of metrics (when the car is on or charging). I have started adding additional metrics on OBD and will continue mainly on this route.

A few words about myself: I'm an electrical engineer who has always been fascinated by programming hardware functions (started using the extension port of a Schneider CPC computer, which only Germans will know... a competitor to the Commodore C64 at the time). I have been dabbling in microcontrollers (mostly Atmel) and Raspberry Pi for the last few years. Since I never really learned modern programming languages, I go by google-paste-and-error :) So please forgive if you see horrible code; I promise I'm always willing to learn!

In 2019, I bought a (generation 1) VW e-Up and ever since tried to figure out as much about the OBD metrics as I can. The breakthrough came beginning of this year, when I managed to sniff about 1100 OBD codes by using a commercial OBD adaptor and a Y-cable with a PC to log the codes. At about the same time, devmarxx showed up and brought me to OVMS.

Concerning OVMS, I can only thank you guys for a really great hard- and software platform! This is the perfect playing ground for someone like me. Currently, I just keep discovering how matured this system already is... I try to learn from existing code and can't see any limits to the possibilities :)

So, I would be very happy if VWEUP.ALL can be included and maybe one or the other of you can give me helpful hints on how to do things the right way :)

Have a great (hacking) weekend!

sharkcow _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

_______________________________________________ OvmsDev mailing list OvmsDev@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