- OvmsDev - Open Vehicles

Re: [Ovmsdev] yacc/lex on component/dbc
by Mark Webb-Johnson 05 Dec '18

05 Dec '18

Craig, I had a look at this, and it doesn’t seem at all easy to resolve. The espressif build system uses component.mk to control the build. In our dbc component, the .hpp and .cpp files in yacclex are dynamically built. Then there is a COMPONENT_SRCDIRS variable that controls which directories the build system will look into for files to compile. I think that what is happening, with concurrent build jobs, is that the component library object is being built at the same time as the yacclex dynamic builds. When the component library build starts, it generates a list of files (.c, .cpp, etc) to compile - but if that is done before the yacclex files are dynamically built, the issue you describe happens. I can see a way to split this into two components (perhaps in the same dbc directory) - the first containing the dynamic content, and the second containing the main dbc component. Then we can set a component dependency for the main component depending on the dynamic content component. But, I can’t see any obvious way of setting an explicit dependency for this dynamic content. Any ‘make’ gurus out there? As an alternative, very hacky, solution, I added this to component.mk: .NOTPARALLEL: :-) Regards, Mark. > On 1 Dec 2018, at 10:28 AM, Craig Leres <leres(a)xse.com> wrote: > > I tried building on FreeBSD and parallel make is broken: > > % make -j8 > [...] > gmake[1]: *** No rule to make target 'yacclex/dbc_parser.o', needed by 'libdbc.a'. Stop. > gmake[1]: *** Waiting for unfinished jobs.... > YACC dbc_parser.y > > If I start a non-parallel build after the above failure it works ok (and probably first builds the things that are missing make dependencies). See appended. > > I flashed it and it runs but this is with my dev module that does not have a modem and is literally on the bench. > > I'm not very experienced with gmake but am willing to try and help if you can't figure out how fix the missing dependency (which might well be in the esp-idf tree). > > Craig > > ice 96 % gmake > LEX dbc_tokeniser.l > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/src/dbc.o > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_tokeniser.o > CXX /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/yacclex/dbc_parser.o > AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/dbc/libdbc.a > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/esp_http_client.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_utils.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_auth.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_tcp.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/transport_ssl.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/lib/http_header.o > AR /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/esp_http_client/libesp_http_client.a > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_main.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/emac_dev.o > CC /home/ice/u0/leres/src/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ethernet/eth_phy/phy_tlk110.o > [...]

1 0

Public Disclosure: Tesla Roadster PIN Vulnerabilities
by Mark Webb-Johnson 03 Dec '18

03 Dec '18

Vulnerability details: Vulnerability Announcement: Tesla Roadster vulnerable to sniffing of security PIN code via CAN bus <https://www.openvehicles.com/vuln-tr-20181203a> Vulnerability Announcement: Tesla Roadster vulnerable to brute-force unlock via CAN bus <https://www.openvehicles.com/vuln-tr-20181203b> Discussion Forum: https://teslamotorsclub.com/tmc/threads/public-disclosure-tesla-roadster-pi… <https://teslamotorsclub.com/tmc/threads/public-disclosure-tesla-roadster-pi…> Summary: On 3rd May 2017, I reported two vulnerabilities to Tesla regarding the PIN code on Tesla Roadster vehicles. As no fix has been forthcoming from Tesla in the past 18 months, and in accordance with standard industry practice, I now publicly disclose these below. The intent here is to raise awareness of the security issues and to encourage Tesla Roadster owners to take steps in order to avoid exploit and/or loss of their vehicle. Short summary A convertible vehicle such as the Tesla Roadster does not always offer the same physical protections as a fully enclosed vehicle. In particular, access to the vehicle communication networks, and physical interior, may be easier (particularly in the case when the vehicle is parked with the roof off). The communication between the VDS (little display) and VMS (car computer) in the Tesla Roadster is not encrypted. This means that when you enter your PIN on the VDS, any system on the car network can see it in relatively plain text. There is no protection in the Tesla Roadster firmware against multiple PIN access attempts. This means that a malicious actor could brute-force guess the PIN in a relatively short time (less than one minute for a 4 digit PIN code). The same PIN code is used for both valet and car lock/unlock functions. The valet code (if known) can be used to unlock the vehicle. While vehicles outside North America are fitted with an immobiliser that helps mitigate this issue, North American Tesla Roadsters have no such immobiliser and the PIN can be used to both disarm the vehicle alarm and unlock the doors. While the full solution to these issues can only be implemented by Tesla via firmware update, owners can mitigate the impact by: Using a strong 8 digit PIN, rather than the default 4 digit. Ensuring that the vehicle is locked, with the roof on, when parked. Being aware that valet parking attendants will have full unrestricted access to the vehicle, and time to determine the PIN and copy the physical vehicle key. I hope that Tesla will address these issues by implementing firmware protection against multiple PIN access attempts (for example, 3 incorrect PIN attempts results in a 5 minute lock-out would be reasonable), and by encouraging owners to use strong 8 digit PINs. A summary of the vulnerabilities is given below. For full details, refer to the links. Tesla Roadster vulnerable to sniffing of security PIN code via CAN bus <https://www.openvehicles.com/vuln-tr-20181203a> Vulnerability Announcement: Tesla Roadster vulnerable to sniffing of security PIN code via CAN bus | Open Vehicles <https://www.openvehicles.com/vuln-tr-20181203a> The Tesla Roadster instrumentation CAN bus (running at 1MHz) supports a CAN bus message to lock/unlock the car as well as enable/disable valet mode and change the PIN. Authentication on this message is via simple user PIN code which is typically 4 digits (but can be up to 8 digits). This PIN code is usually entered on the VDS by the user, and then transmitted in plain text on the instrumentation CAN bus to the VMS. Using a simple CAN bus tap, the 1MHz instrumentation CAN bus messages can be read. When the user enters the PIN code (for example to enable/disable valet mode), it is transmitted in plain text using a single CAN bus message. The instrumentation CAN bus is available at various points in the car, with the simplest being the engineering diagnostic connector in the passenger footwell of the vehicle. The most likely exploit would come at a valet parking station where a vehicle key could be easily copied and with access to the vehicle, a CAN bus logger installed in the passenger footwell. When the user returns to retrieve their vehicle, they disable the valet mode (via entry of PIN code on the VDS screen). At this point, the valet has a copy of the physical key as well as the PIN code to arm/disarm the vehicle alarm on North American vehicles. Tesla Roadster vulnerable to brute-force unlock via CAN bus <https://www.openvehicles.com/vuln-tr-20181203b> Vulnerability Announcement: Tesla Roadster vulnerable to brute-force unlock via CAN bus | Open Vehicles <https://www.openvehicles.com/vuln-tr-20181203b> The Tesla Roadster instrumentation CAN bus (running at 1MHz) supports a CAN bus message to lock/unlock the car as well as enable/disable valet mode. Authentication on this message is via simple user PIN code which is typically 4 digits (but can be up to 8 digits). It appears that this is vulnerable to brute-force attack as there is no rate limiting on reception/interpretation of that message. Transmitting at 100 messages / second, I tested PIN codes 0000 through 9999 in 100 seconds. Average PIN discovery time was thus approximately 50 seconds at this rate. The CAN-USB adaptor I used was limited to approximately 100 messages / second. A faster adaptor could seemingly brute force this with greater speed. For both vulnerabilities, the PIN code permits the following functions: Enable valet mode Disable valet mode Lock the vehicle Unlock the vehicle Cancel the alarm (via unlocking the vehicle) in North American vehicles Change the PIN code On vehicles outside North America, a separate alarm system and immobiliser is used. That system is not affected by this PIN code, so functions 4 through 5 will have limited impact on these vehicles. There is a separate physical key used to start the vehicle, and unlock the steering wheel, that is not affected by this vulnerability. Once the PIN code has been discovered, the greatest concerns are: Cancelling a sounding alarm on North American vehicles Providing access to the trunk and glove compartment of a locked vehicle Malicious prank to enable valet mode Malicious prank to change the PIN code (possibly after enabling valet mode) While the full solution to these issues can only be implemented by Tesla via firmware update, owners can mitigate the impact by: Using a strong 8 digit PIN, rather than the default 4 digit. Ensuring that the vehicle is locked, with the roof on, when parked. Being aware that valet parking attendants will have full unrestricted access to the vehicle, and time to determine the PIN and copy the physical vehicle key. Reported: 3 May 2017 Classification: Sensitive Data Exposure > Critically Sensitive Data > Password Disclosure Vendor Response: Declined to address, and no fix for more than 1 year, so public release Public Release: 3 Dec 2018 Regards, Mark.

1 0

yacc/lex on component/dbc
by Mark Webb-Johnson 30 Nov '18

30 Nov '18

I am trying to move the hand-crafted dbc parser (which is pretty crappy) to a full featured parser based on yacc/lex. But I’m concerned this will be complex to build (requiring yacc and lex on the build systems). Given that esp idf already uses this (for Kconfig), it should be ok. I have committed a stub for this (into components/dbc). It compiles for me with two warnings: /components/dbc/yacclex/dbc_tokeniser.c:1630:17: warning: 'yyunput' defined but not used [-Wunused-function] static void yyunput (int c, register char * yy_bp ) ^ components/dbc/yacclex/dbc_tokeniser.c:1675:16: warning: 'input' defined but not used [-Wunused-function] static int input (void) ^ Those warnings are acceptable, and will be resolved when the full implementation comes. On my mac it worked fine On Linux, I had to install bison and setup a /usr/bin/yacc wrapper I haven’t tried at all on windows Could you guys check, and let me know if you see any issues? In particular, on windows. If no issues, I’ll proceed and finish up the grammar and implementation. Regards, Mark.

3 9

How do I run candump
by Craig Leres 26 Nov '18

26 Nov '18

I'm starting to look at adding support for my Cadillac but it's not clear to me that I can use a ovms module to capture can frames? Do I need another device to do it? Craig

3 4

Re: [Ovmsdev] Custom metrics
by Henrik Scheel 23 Nov '18

23 Nov '18

Hi Mark. Good idea with a generic array type metric, and standard metrics for common EV features! Just a quick note: The Kia Soul EV vehicle module will be able to utilize these metric-arrays. However, on the Soul, the voltages are for each physical pair of cells connected in parallel, and the temperatures are for 6 battery modules, and for the battery cooling air inlet. So, for the Kia Soul EV, the name “v.b.cell.temp” would be misleading, as each measured module temperature is representing the state for 16 pairs of cells. Aside from that, I am all for mapping the values in these new standardized metric types. Currently, the temperature average is calculated and mapped to a metric, and the 96 cell voltages are unmapped for Kia Soul EV. Best regards, Henrik -- Venlig hilsen / best regards Henrik R. Scheel Spjeldager Consult ApS Spjeldager 9 DK-2630 Taastrup CVR: 34491399 T: +45 2720 9828 http://www.spjeldager.dk/ > Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request(a)lists.openvehicles.com: > > Send OvmsDev mailing list submissions to > ovmsdev(a)lists.openvehicles.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openvehicles.com/mailman/listinfo/ovmsdev > or, via email, send a message with subject or body 'help' to > ovmsdev-request(a)lists.openvehicles.com > > You can reach the person managing the list at > ovmsdev-owner(a)lists.openvehicles.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OvmsDev digest..." > > > Today's Topics: > > 1. Re: Custom metrics (Mark Webb-Johnson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 10 Nov 2018 22:34:46 +0800 > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > To: OVMS Developers <ovmsdev(a)lists.openvehicles.com> > Subject: Re: [Ovmsdev] Custom metrics > Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11(a)webb-johnson.net> > Content-Type: text/plain; charset="utf-8" > > I?ve added UnregisterCommand() methods to ovms_command.{h, cpp}. I?ve also updated the vehicle_teslamodels code to UnregisterCommand in the destructor. I think that is cleaner. The unregistering of CAN buses already seems to be working properly, config parameters should persist (even without vehicle module loaded). I am still considering the situation with metrics (but tend to think that they should disappear when the vehicle module is unloaded). > > I?ve also changed the vehicle_teslamodels code to use single voltage and temperate metric arrays (I think my previous dual voltage temperature arrangement was incorrect). I think these can now become standard metrics (one for battery voltage, and another for temperature). How about v.b.cell.voltage and v.b.cell.temp? The interpretation of those vectors (how many modules primarily - with the calculation of voltages and temperatures per module being dependent on the realtime size of each array) will still be vehicle dependent, and I guess the vehicle module can provide hints to our standard component for this. Perhaps we can just implement it in vehicle.{h, cpp}? I think this standard module can deal with: > > An interface for specific vehicle module to specify the number of modules, number of voltage measurements, and number of temperature measurements available. > Internal storage of cell voltages and temperatures. > Tracking of when all voltages and temperatures have been set, and these should be written to metrics (as a transaction). > Standardised command to display on terminal (like ?xts bms?). > Web interface extensions (including the charting you have, a textual display, etc). > > I can handle all of the above, except the web interface. What do you think? Can these be standardised? Certainly for Tesla Roadster and Tesla Model S they appear to be able to be unified under one standard framework. > > Regards, Mark. > >> On 8 Nov 2018, at 6:49 AM, Michael Balzer <dexter(a)expeedo.de> wrote: >> >> Mark, >> >> 1) yes, we're approaching a generic form now. The chart currently displays actual, min & max values from the arrays, and derives the overall average value. It automatically adapts to the number of voltages and temperatures stored in the arrays. >> >> It still lacks: >> a) Displaying max deviations, current standard deviation and max standard deviation recorded. >> b) Displaying cell/module warn & alert status. These are currently set metrics on the Twizy, could better be generalized as arrays as well, i.e. 0=normal, 1=warn, 2=alert. >> c) SOH / capacity and internal resistance should be generally available per cell as well (no data on these yet on the Twizy). >> >> And as this will visually overload the chart it will need some buttons to show/hide the parts. >> >> A general vehicle base support for these metrics could automatically keep min & max values, calculate deviations and derive warn/alert status from these. So basically a vehicle adapter only needs to provide voltages and temperatures (+ SOH and internal resistance as available). The reset command then can also normally just be a generalized version. >> >> 2) I should add some basic documentation on this to the developer manual (lacking time). For the RE tools I've got an API to inject arbitrary data into the websocket stream on my todo list, so live updates can be transported without polling. >> >> 4) Interesting idea, similar to a reverse proxy. As the channel will be very slow we will need to reduce the websocket update frequency, make it configurable or maybe auto-adapt to the current speed. Also, the proxy should cache static assets to speed up first time connects. >> >> The v2 protocol using RC4 encryption is a bad base for this. What's the current encryption on v3/MQTT? >> >> Regards, >> Michael >> >> >> Am 07.11.18 um 01:50 schrieb Mark Webb-Johnson: >>> Some questions/comments: >>> >>> I guess this is fairly generic. Voltages and temperatures, with possibly a different number of readings for each. Model S has two temperatures, but I guess we can just treat those as interleaved. Could it be put into a reusable component? Or could we have standard metrics for this now (battery module voltages and temperatures)? Maybe a single component that does all this (functions to set individual voltages and temperatures, define the layout for display, include web interface for chart and table, etc)? >>> >>> I really need to look at integration of extensions to the web interface. See how that is done. For my work on DBC and RE tools, it seems easiest to just create a web interface (rather than messing around with command line). >>> >>> Regarding the registration of commands and metrics, I am not sure if that is done correctly at the moment. In particular in the case a vehicle module is loaded, unloaded, then loaded again. It seems that RegisterCommand doesn?t do it right, and the metric object creation needs a guard to make sure the metric doesn?t already exist. I will try to tidy this up in Model S code, as a reference, before moving on to Roadster. >>> >>> I really haven?t used the web interface much, as it is not available over cellular. I was wondering if it could be encapsulated somehow within the v2/v3 protocol, and made available via the server? Something like https://api.openvehicles.com:8080/VEHICLEID <https://api.openvehicles.com:8080/VEHICLEID> tunnelled through (with authentication at the server level using the normal web server user account). Similarly for SSH access. These are both simple tcp/ip connections, so presumably could be injected into mongoose as fake connections. One possible approach would be SOCKS, and there is some reference code for LWIP <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP, again with reference code for LWIP <https://github.com/russdill/lwip/commit/47ca42f8>. And then there is the standard PPP (although that would technically then be PPP within tcp/ip over PPP within async within GSM, which is a bit freaky). >>> >>> Regards, Mark. >>> >>>> On 7 Nov 2018, at 4:52 AM, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>> >>>> Mark, Tam?s, >>>> >>>> I've prepared a more or less generalized array version of my Twizy battery chart (OvmsVehicleRenaultTwizy::WebBattMon) for you. Easier to collect the data from actual arrays than separate metrics. >>>> >>>> This ZIP? >>>> >>>> https://dexters-web.de/f/ovms-dev/ovms.zip <https://dexters-web.de/f/ovms-dev/ovms.zip> >>>> >>>> ?contains my local ovms web test/development folder. Unzip it into some local web server (needs to be run via http for javascript), then open the folder from a browser. You should see an OVMS web UI lookalike. >>>> >>>> Config ? CellChart loads "cellchart.htm". The blue button generates and injects test data. Should look like this: >>>> >>>> <eoibkbnkbpofdlab.png> >>>> >>>> Assuming you'll add some min/max records as well I left that code including the reset button in there. If you can't provide that yet, you can simply set min & max = act in the get_xxx_data functions. Other than that you should basically just need to change the metrics names. >>>> >>>> To generate C/C++ syntax from the file, use the script bin/mksrc: "bin/mksrc cellchart.htm >cellchart.cpp". The chart init URL needs to be changed for the production environment (see comment), and the test data generator can be removed. See OvmsVehicleRenaultTwizy::WebBattMon for reference. >>>> >>>> Maybe I should add that stuff to the repository as well? >>>> >>>> Regards, >>>> Michael >>>> >>>> >>>> Am 06.11.18 um 15:56 schrieb Mark Webb-Johnson: >>>>> Nice. I just implemented this for Model S using your new metric type. >>>>> >>>>> 96 individual brick voltages for each of the bricks, plus two temperatures for each of the 16 modules. >>>>> >>>>> Works well. >>>>> >>>>> >>>>> >>>>> >>>>> On 1 Nov 2018, at 5:58 PM, Michael Balzer <dexter(a)expeedo.de <mailto:dexter@expeedo.de>> wrote: >>>>> >>>>>> Tam?s, >>>>>> >>>>>> I've been creating separate metrics for all cell values on the Twizy, but that only has 14 cells. >>>>>> >>>>>> We discussed this before, a better approach is introducing a new metric class for arrays. I have just done that for you, please pull. >>>>>> >>>>>> Usage example: >>>>>> OvmsMetricVector<float>* vf = new OvmsMetricVector<float>("test.volts", SM_STALE_MIN, Volts); >>>>>> vf->SetElemValue(3, 1.23); >>>>>> vf->SetElemValue(17, 2.34); >>>>>> float myvals[3] = { 5.5, 6.6, 7.7 }; >>>>>> vf->SetElemValues(10, 3, myvals); >>>>>> With this data set, you get: >>>>>> OVMS# met lis test >>>>>> test.volts 0,0,0,1.23,0,0,0,0,0,0,5.5,6.6,7.7,0,0,0,0,2.34V >>>>>> ?and in the web framework: >>>>>> metrics["test.volts"] >>>>>> (18) [0, 0, 0, 1.23, 0, 0, 0, 0, 0, 0, 5.5, 6.6, 7.7, 0, 0, 0, 0, 2.34] >>>>>> metrics["test.volts"][11] >>>>>> 6.6 >>>>>> See template definition in ovms_metrics.h for more. >>>>>> >>>>>> Regards, >>>>>> Michael >>>>>> >>>>>> >>>>>> Am 31.10.18 um 20:08 schrieb Tam?s Kov?cs: >>>>>>> I have a Peugeot iOn, and i wan't to create own metrics for battery temp (66 piece) and voltage (88 (old) or 80(new) piece) for all cell (and show on web interface), and i don't understand how can i create it. Now my data in array-s from can messages 6E1-6E4. >>>>>>> My git fork: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot <https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot> >>>>>>> vehicle_mitsubishi >>>>>>> >>>>>> >>>>>> -- >>>>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal >>>>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 >>>>>> _______________________________________________ >>>>>> OvmsDev mailing list >>>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OvmsDev mailing list >>>>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev> >>> >>> >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> >>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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(a)lists.openvehicles.com >> http://lists.openvehicles.com/mailman/listinfo/ovmsdev > >

5 26

Add version strings to the boot partitions on the firmware page
by Craig Leres 23 Nov '18

23 Nov '18

I though it would be useful to show what version each boot partition contains; here's what I came up with today: https://github.com/leres/Open-Vehicle-Monitoring-System-3/commit/39a32b0a5f… I've also attached a screen grab. Comments? Craig

2 8

Nissan Leaf support question
by Mark Webb-Johnson 16 Nov '18

16 Nov '18

This question came in: https://www.openvehicles.com/node/2107 <https://www.openvehicles.com/node/2107> I know there is a timeout where if I remotely turn on the A/C and don't get to the car in that time, it will turn the A/C off automatically. It seems that if this happens my A/C won't function at all for something like 5 to 10 minutes. Are there any commands I can issue to verify this and better yet to make the A/C operable right away? Any ideas? Regards, Mark.

3 2

Kia Soul PIDs
by Mark Webb-Johnson 16 Nov '18

16 Nov '18

These any use? https://github.com/JejuSoul/OBD-PIDs-for-HKMC-EVs <https://github.com/JejuSoul/OBD-PIDs-for-HKMC-EVs> Regards, Mark.

1 0

Custom metrics
by Tamás Kovács 10 Nov '18

10 Nov '18

I have a Peugeot iOn, and i wan't to create own metrics for battery temp (66 piece) and voltage (88 (old) or 80(new) piece) for all cell (and show on web interface), and i don't understand how can i create it. Now my data in array-s from can messages 6E1-6E4. My git fork: https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot vehicle_mitsubishi

3 8

esp32can issue
by Michael Balzer 04 Nov '18

04 Nov '18

Frank Demes reported a very strange CAN behaviour. He managed to get a CRTD log of one incident. The effect is triggered by an unknown cause freezing the CAN rx task for short periods of time, i.e. 70 - 120 ms. This alone should be no problem, the RXFIFO will probaly overflow, but that is handled by our driver, so except some messages lost this should not be an issue. Unfortunately, something goes completely wrong: a) on the overrun event, the last valid message is delivered multiple times (i.e. 5 times) b) after resolving the overrun, a garbled message is received. The garbled message contains a valid byte sequence in the wrong place, i.e. bytes 5-8 would be valid if they were bytes 1-4. Bytes 1-4 cannot have been read from the bus, so something is going very wrong here. I have walked through the esp32can driver and checked the SJA1000 documentation but have no clue what is going wrong. Any ideas? CRTD excerpt below. (Frame 155 is reflected by the module with byte 1 changed from 07 to 01 to limit the charge current. The problem is, it also reflects the garbled message, which causes the charger to stop.) Regards, Michael ---------------------------------------------------------------------------------------- … 274.341 1R11 155 07 97 E4 54 4B A8 00 6C 274.341 1T11 155 01 97 E4 54 4B A8 00 6C 274.351 1R11 155 07 97 E5 54 4B A8 00 6C 274.351 1T11 155 01 97 E5 54 4B A8 00 6C 274.361 1R11 155 07 97 E5 54 4B A8 00 6C 274.361 1T11 155 01 97 E5 54 4B A8 00 6C 274.371 1R11 423 03 22 FF FF 00 E0 00 DB 274.371 1R11 426 00 38 01 00 4D 7E 00 274.371 1R11 597 20 A4 03 B1 2F 00 01 53 274.371 1R11 627 00 00 00 274.371 1R11 155 07 97 E5 54 4B A8 00 6C 274.371 1T11 155 01 97 E5 54 4B A8 00 6C 274.381 1R11 155 07 97 E5 54 4B A8 00 6C 274.381 1T11 155 01 97 E5 54 4B A8 00 6C 274.391 1R11 5D7 FF FF 01 E4 53 80 00 - normal up to here !!! CAN RX is blocked here for ~70 ms !!! … interrupts disabled? by whom? 274.461 1R11 599 00 00 4D 7E 1E 26 FF FF 274.461 1R11 436 00 0E 3C B2 00 00 274.461 1R11 155 07 97 E5 54 4B A8 00 6C 274.461 1R11 424 11 40 15 26 47 64 00 48 274.461 1R11 425 0A 1D 44 FF FE 40 01 1F 274.461 1R11 556 30 63 07 30 73 07 30 7A 274.461 1T11 155 01 97 E5 54 4B A8 00 6C ← reflection for 155 still works here !!! next RX pause, ~90 ms this time !!! !!! ID 599 has a period of 100 ms, but we now get it 5 times: 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1CEV Error intr=58445 rxpkt=27132 txpkt=528128 errflags=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 crtd fprintf bug compensation: 274.551 1CEV Error rxpkt=58445 txpkt=27132 errflags=528128 intr=0x15433 rxerr=0 txerr=0 rxovr=2 txovr=0 txdelay=17 errflags=528128 = 08 0F 00 0x08 = IR: Data overrun 0x0F = SR: Bus OK, error limit not yet reached, RX & TX idle, RXFIFO overrun, RX buffer full 0x00 = ECC: - 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 599 00 00 4D 7E 1E 26 FF FF 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "A" 274.551 1R11 155 07 97 E6 54 4B A8 00 6C RX "B" 274.551 1R11 155 07 97 E7 54 4B A8 00 6C RX "C" 274.551 1R11 423 03 22 FF FF 00 E0 00 DB 274.551 1R11 426 00 38 01 00 4D 7E 00 274.551 1R11 597 20 A4 03 B1 2F 00 01 53 274.551 1R11 627 00 00 00 274.551 1T11 155 01 97 E6 54 4B A8 00 6C reflection "A" 274.551 1CEV TX_Queue T11 155 01 97 E6 54 4B A8 00 6C reflection "B" 274.551 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C reflection "C" 274.551 1T11 155 01 97 E8 54 4B A8 00 6C reflection "D" !!! 120 ms pause !!! 274.671 1R11 155 07 97 E8 54 4B A8 00 6C RX "D" → "D" was sent to the listeners & reflected by vehicle::IncomingFrame() then, before the LogFrame() call was processed, the CAN task was paused for 120 ms and now it's getting really weird: 274.671 1R11 155 07 08 2A A0 07 97 E7 54 RX "E": invalid frame / garbled message! … this frame certainly was not on the bus! bytes 2-4 (08 2A A0) = complete nonsense, not matching any frame on the bus bytes 5-8 (07 97 E7 54) = normally bytes 1-4 (!) of ID 155 - copy / memory error? … very unlikely - CAN RX handling error? … doesn't seem so - RXFIFO message window bug? 274.671 1CEV Error intr=58458 rxpkt=27134 txpkt=528128 errflags=0x15456 rxerr=0 txerr=0 rxovr=3 txovr=0 txdelay=19 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 97 E6 54 4B A8 00 6C 274.671 1CEV TX_Queue T11 155 01 97 E7 54 4B A8 00 6C 274.671 1R11 155 07 97 F2 54 4B A8 00 6C 274.671 1R11 155 07 97 F3 54 4B A8 00 6C 274.671 1R11 423 03 22 FF FF 00 E0 00 DB 274.671 1R11 426 00 38 01 00 4D 7E 00 274.671 1R11 597 20 A4 03 B1 2F 00 01 53 274.671 1R11 627 00 00 00 274.671 1R11 155 07 97 F5 54 4B A8 00 6C 274.671 1R11 155 07 97 F6 54 4B A8 00 6C 274.671 1R11 5D7 FF FF 01 E4 53 80 00 274.671 1R11 599 00 00 4D 7E 1E 26 FF FF 274.671 1R11 155 07 97 F7 54 4B A8 00 6C 274.671 1R11 436 00 0E 3C B2 00 00 274.671 1R11 041 A0 07 97 F5 54 4B A8 00 274.671 1T11 155 01 97 E7 54 4B A8 00 6C 274.671 1T11 155 01 08 2A A0 07 97 E7 54 reflection of invalid msg "E" → charge terminates due to error -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 19