August 2018 - OvmsDev - Open Vehicles

Lost configuration
by Tom Parker 18 Aug '18

18 Aug '18

Hi, My OVMS v3 prototype appears to have lost it's configuration. It stopped talking to the server a few days ago and power cycling wasn't helping. I had a chance to see what was on the serial console today. The OVMS prompt and command interface is working normally, but there doesn't appear to be anything configured. I'm still using a startup script I wrote before we had the configuration gui, and that doesn't appear to execute at startup. If I do a vfs ls /store then the command line interface hangs and I have to power cycle it to get it back. I don't have the wifi turned on so I don't know if the web interface works after doing this. This behaviour is repeatable, I if I power cycle the module the config is still missing and vfs ls /store still hangs. What is the best way to debug it? Michael appears to have had a similar problem in https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/151 how do I dump the flash to investigate why listing the directory hangs the command line interface?

3 3

Fwd: OVMS Nightly Firmware Build 3.1.009
by Mark Webb-Johnson 15 Aug '18

15 Aug '18

Enjoy > Begin forwarded message: > > From: mark(a)openvehicles.com > Subject: OVMS Nightly Firmware Build 3.1.009 > Date: 15 August 2018 at 8:11:30 PM HKT > To: mark(a)openvehicles.com > > 3.1.009 > Wed Aug 15 12:11:30 UTC 2018 Automated build (markhk8) > > Total sizes: > DRAM .data size: 16452 bytes > DRAM .bss size: 32864 bytes > Used static DRAM: 49316 bytes ( 131420 available, 27.3% used) > Used static IRAM: 107932 bytes ( 23140 available, 82.3% used) > Flash code: 1328694 bytes > Flash rodata: 612052 bytes > Total image size:~2065130 bytes (.bin may be padded larger) > > * 92d8501 (HEAD, tag: 3.1.009, origin/master, origin/HEAD, master) Known Issues, ready for 3.1.009 > * 9dd6131 Changes and TODO, ready for 3.1.009 > * 8724c1d Merge pull request #152 from caederus-ovms/units > |\ > | * e0aa195 Use correct SI unit abbreviations for distance (km), speed (km/h), acceleration (km/h/s - as an alternative to the usual m/s²). > | * 51ce2a2 If converting value to different unit, AsUnitString() should also convert unit name. > |/ > * 3c05772 TeslaModelS: Add support for CAN2 and CAN3, and decode MCU GPS lat, lon, heading, and HDOP > * 0e3c6d4 Twizy: fix missing charge records in RT-PWR-Log > * 7192be1 Minor command description changes to sync with user guide > * 3704933 Wifi: add RSSI level to status output > * 4cf3dba Merge pull request #150 from bobbo3/master > |\

1 0

units
by Robin O'Leary 15 Aug '18

15 Aug '18

I noticed that changing the config option for preferred units caused the display of distance on the status page to show the wrong units. AsUnitString() correctly converted the value to the desired units, but still appended the native unit name. While looking at that code, I also noticed that the metric unit abbreviations don't conform to standard SI notation: - kilometer should be 'km' (not 'Km' because capital-K means Kelvin). - kilometers per hour is better as 'km/h' (not 'Kph' because p means pico-). Here is a pull request to fix both: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/152

2 1

Roadmap and team info
by Robert Sharpe (Electric Vehicle Consultant) 14 Aug '18

14 Aug '18

Hi, In response to a request for a road map there is now an easy to use Google Sheet where people can see the current road map, share what you are doing and what future features you would like to see. While doing that it's also a good opportunity to help new comers by pulling together a summary of the team and any (non feature) tasks people might be working on. Can you please therefore take a few minutes of your time in the next few days to fill in all three sheets below Thanks, Robert Sharpe Electric Vehicle Consultant 07711 252971 Your Plugged-in Partner Evergreen Consulting is the trading name of Sharpe Consultants Ltd

2 1

Tesla Cables
by Mark Webb-Johnson 09 Aug '18

09 Aug '18

I have a suggested pinout for future Tesla Cables: X437 DB9 Signal -------- -------- -------- 1 7 CAN0-H 2 8 CAN2-H 3 1 K-Line 4 5 CAN1-H 6 2 CAN0-L 7 6 CAN2-L 9 3 GND 10 9 +12V 11 4 CAN1-L This new cable could work for both Roadster and Model S. The previous pinout did not populate DB9 pins 1, 4, 5, 6, or 8 (so only GND, +12V, CAN0-H, and CAN0-L were connected). For Tesla Roadster, that gives us access to all three CAN buses (and opens up a lot of opportunities): CAN0 - Instrumentation (VDS, TPMS, etc) CAN1 - SwitchPack / PEM CAN2 - HVAC and Battery K-Line (OBDII K-Line) For Tesla Model S and X (2014 and before), that gives us access to three of the four CAN buses (of which the PowerTrain and Chassis seem the most useful, and BodyFaultTolerant has remote climate control module on it): CAN0 - PowerTrain CAN bus CAN1 - Chassis CAN bus CAN2 - BodyFaultTolerant CAN bus K-Line (OBDII K-Line) For new Model S and X (with X437A connector), the DB9 side pinouts should be the same. I am currently trying to source a good supplier for the new style vehicle side connectors. I’ve also wired in the K-Line into the unused pin #1 of our DB9 connector (even though that is not currently connected to anything). I am working with China side to see how we can connect that up (either via direct support chip in a future module, or via expansion board). Existing modules would require a mod to work with that (but not too hard to do). As usual, suggestions / comments, and double-checking of the pinouts would be most appreciated. Regards, Mark.

1 1

Android App build issue
by Mark Webb-Johnson 09 Aug '18

09 Aug '18

Michael: Can you help this guy working on the Android App? A google search came up with this: https://stackoverflow.com/questions/24998368/the-import-android-support-v7-… <https://stackoverflow.com/questions/24998368/the-import-android-support-v7-…> which is possibly relevant. Thanks, Mark.

1 1

Re: [Ovmsdev] OVMS v3.1 crashes during boot continuously
by Henrik Scheel 08 Aug '18

08 Aug '18

> welcome :) Thanks :-) > See https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/148 > ?and the new 12V section in the user guide. Ok, I will look into that when I have a functioning module. > So the Soul doesn't top up the 12V battery from the main battery? How much capacity does the 12V battery have on the Soul? Kia Soul EV does not top up the 12 Volt battery when off. The capacity is 50 Ah. If I recall correctly, the original battery had 48 Ah. > See https://github.com/espressif/esptool/wiki/espefuse -- you can try the dump command and send the results to Espressif. If your ESP32 really lost its efuses, > I think that's a warranty issue. I ran the dump. It did not report CRC error, nor all1’s or 0’s. Is there any reason not to share the output from the dump command publicly? I am guessing the current rebooting issue could be an issue with my build. It is my first OVMS build, based on sources pulled Aug 4, and I may have done something wrong, have the wrong version of some tool installed, or something may have changed in the repos since the developer guide was last tested by someone. Can I download bootloader.bin, ovms3.bin and partitions.bin from somewhere, and flash those instead of my build? Henriks-MBP:OVMS.V3 henrik$ make print_flash_cmd --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader/bootloader.bin 0x10000 ovms3.bin 0x8000 partitions.bin Is “make flash” always supposed to bring the device to a functioning state, when configured and built as described in the developer config (i.e. by cp support/sdkconfig.default.hw31 sdkconfig and then make menuconfig)? I seem to get errors when connecting to the device, e.g. when flashing: … AR build/xtensa-debug-module/libxtensa-debug-module.a LD build/ovms3.elf esptool.py v2.3.1 Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )... esptool.py v2.3.1 Traceback (most recent call last): File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2637, in <module> _main() File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2630, in _main main() File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 2355, in main esp = chip_class(args.port, initial_baud, args.trace) File "/Users/henrik/esp/esp-idf/components/esptool_py/esptool/esptool.py", line 193, in __init__ self._port = serial.serial_for_url(port) File "/Library/Python/2.7/site-packages/serial/__init__.py", line 88, in serial_for_url instance.open() File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 272, in open self._reconfigure_port(force_update=True) File "/Library/Python/2.7/site-packages/serial/serialposix.py", line 438, in _reconfigure_port [iflag, oflag, cflag, lflag, ispeed, ospeed, cc]) termios.error: (22, 'Invalid argument') make: *** [flash] Error 1 Henriks-MBP:OVMS.V3 henrik$ make flash Flashing binaries to serial port /dev/tty.SLAB_USBtoUART (app at offset 0x10000 )... esptool.py v2.3.1 Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._____....._____ A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header make: *** [flash] Error 2 Henriks-MBP:OVMS.V3 henrik$ Could all of this conceivably be caused by “bad” USB hardware? I connect the device via a cheap Hama device for converting my thunderbolt port to standard USB. 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/

3 4

Extending the information shown in the app and on dashboard
by Nikolay Shishkov 08 Aug '18

08 Aug '18

I am looking at ways to communicated some status data that would be helpful to the driver of the Think.Stuff like: - estimated time to charge to 100% - average kwh/km for a trip (or maybe even lifetime?) - min, avg, max cell values for cars with lithium packs - maybe even a bar graphs that show all cell voltages and temperatures - possibility to run simple diagnostics - like show error codes, send error codes to e-mail, reset error codes - producing/sharing a log of trips with essential data (distance, kwh used, and some stats - speed, kW, temperatures) I can see some very interesting stuff in the dashboard, and some of the pages for Twizy and Kia... and would appreciate some ideas on how to implement some of these. For example estimated time to end of charge is something I would like to be visible in the app, while diagnostics could be enough to be a web page. What is the easiest or the best way to extend the information shown in the app? In the simplest possible way - no graphics, just a list a name and value? Nikolay

2 1

signed 2 byte values in poll
by Nikolay Shishkov 07 Aug '18

07 Aug '18

So this is another thing that took more time than I can spare for it... and I am still curious to see what would be the correct way of doing it. I have configured the polling to ask an ecu about couple of values of temperatures. The response message can be received both in the IncomingFrameCan1 and IncomingPollReply. The code for reading the values in the respective functions is as follows: void OvmsVehicleThinkCity::IncomingPollReply(canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain) { //ESP_LOGI(TAG,"Poll replay arrived %d", pid); uint8_t value = *data; switch (pid) { case 0x4965: StandardMetrics.ms_v_charge_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4966: StandardMetrics.ms_v_inv_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4967: StandardMetrics.ms_v_mot_temp->SetValue((float)((short)value) / 100.0f); break; case 0x4968: tc_slibatt_temp =(float)((short)value) / 100.0f; break; default: break; } } And the following code in IncomingFrameCan1: case 0x75B: if (d[3] == 0x65) { StandardMetrics.ms_v_charge_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x66) { StandardMetrics.ms_v_inv_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x67) { StandardMetrics.ms_v_mot_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f); } else if (d[3] == 0x68) { tc_slibatt_temp = (float)((short) (d[4] << 8) | d[5]) / 100.0f; } I am getting correct values in the IncomingFrameCan1 version, while the first version returns completely different values. Any idea why? Thanks again,Nikolay On Saturday, August 4, 2018, 1:59:03 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Fixed some stuff and added some for the Think City. There is still more to be done but here is the status so far. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/150 On Wednesday, August 1, 2018, 9:46:12 PM GMT+2, Michael Balzer <dexter(a)expeedo.de> wrote: Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer: Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov: That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Quick question. How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms… Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter(a)expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2ltmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" evalxtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- 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 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)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(a)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(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

2 2

App thinks the car is not charging while it is charging
by Nikolay Shishkov 05 Aug '18

05 Aug '18

I am having trouble with the ported code where the app does not want to show the stick with info on charging current and voltage.I connected to the ovms and in the serial console I could see that the S message was stating "charging", while the P was stating "not charging" (see the log at the end of the message)... so I did dig and found a piece of code in the vehicle.cpp that uses ms_v_door_chargeport metric to determine if charging or not. bool chargeport_open = StdMetrics.ms_v_door_chargeport->AsBool(); if (chargeport_open) I am planning to add this to my code, but am wondering if this is the ok? Is this what the app uses to show the stick with the info from the AC outlet?Think City does not have a chargeport message, but even if it did, is this really the way? Here is the relevant part of the log:I (7316) ovms-server-v2: Incoming Msg: MP-0 Z1I (7316) ovms-server-v2: One or more peers have connectedI (7496) ovms-server-v2: Send MP-0 S62.0,K,207,9,charging,standard,69,57,9,0,0,0,3,1,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,1.43,367.40,0I (7506) ovms-server-v2: Send MP-0 D24,0,5,0.1,0.09,29,0,0,0,5,23,1,0,0,14.46,0,12.6,0,0.1,0I (7506) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,-1.4,0,0I (7506) ovms-server-v2: Send MP-0 W0,0,0,0,0,0,0,0,0I (7506) ovms-server-v2: Send MP-0 F3.1.008-85-g9365b341-dirty/factory/edge (build idf v3.1-dev-1583-g0fb2019f Aug 4 2018 12:26:37),,0,1,TGTC,VirusnetI (7506) ovms-server-v2: Send MP-0 PINot charging|SOC: 62.0%|Ideal range: 69Km|Est. range: 58Km|I (8486) simcom: State: Enter PoweredOn stateI (10496) housekeeping: System considered stable (RAM: 8b=113788-154004 32b=10236)I (27506) simcom: State: Enter MuxStart state Thanks again,Nikolay On Saturday, August 4, 2018, 1:59:03 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Fixed some stuff and added some for the Think City. There is still more to be done but here is the status so far. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/150 On Wednesday, August 1, 2018, 9:46:12 PM GMT+2, Michael Balzer <dexter(a)expeedo.de> wrote: Forgot: the streaming mode (feature #8 / config vehicle stream) is an option to raise the location update frequency when the car is on. It's now interpreted as the interval in seconds, so "1" will give you per second updates. Regards, Michael Am 01.08.2018 um 21:40 schrieb Michael Balzer: Nikolay, see config → server v2 → update intervals. Regarding speed, you do provide it: StandardMetrics.ms_v_pos_speed->SetValue(((unsigned char) d[5]) / 2); …that's line 65 of the thinkcity module. There is no fallback to GPS speed. Regards, Michael Am 01.08.2018 um 21:10 schrieb Nikolay Shishkov: That same module has not crashed in almost a week now. So maybe there was something that was not connected to Think City code and got fixed by some of the library fixes. I noticed that it takes almost half a minute for the gps location to update in the app. The same goes for the speed and other parameters. Is there a setting to make that more frequent? Also - I can see speed, but I am not providing it - is it coming from the GPS? Thanks again! On Wednesday, August 1, 2018, 1:11:49 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thanks Michael, I did not refresh the mail thread and saw you answer after I posted my solution. I see about the states and the timing now... I may need to adjust this accordingly. I thought it was in milliseconds... These are all temperatures that are changing quite slow. So every 1 second or 4 seconds is perfectly fine. Hopefully I will have access to a car tomorrow and can test this. Thanks again, Nikolay On Wednesday, August 1, 2018, 1:06:32 AM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: I think I found a solution. Have not tested it yet. static const OvmsVehicle::poll_pid_t obdii_polls[] = { // 0x753 03 22 49 65 - charger temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4965, { 0, 999, 999 } }, // 0x753 03 22 49 66 - pcu heat sink temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4966, { 0, 999, 999 } }, // 0x753 03 22 49 67 - motor temp { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4967, { 0, 999, 999 } }, // 0x753 03 22 49 68 - sli batt temp and volts { 0x753, 0x75B,VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x4968, { 0, 200, 200 } }, { 0, 0, 0x00, 0x00, { 0, 0, 0 } } }; On Tuesday, July 31, 2018, 8:57:51 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Quick question. How do I convert this: while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x65; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x66; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x67; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) while (TXB0CONbits.TXREQ) {} // Loop until TX is done TXB0CON = 0; TXB0SIDL = 0b01100000; TXB0SIDH = 0b11101010; TXB0D0 = 0x03; TXB0D1 = 0x22; TXB0D2 = 0x49; TXB0D3 = 0x68; TXB0DLC = 0b00000100; // data length (4) TXB0CON = 0b00001000; // mark for transmission delay100b(); // Delay a little... (100ms, approx) To the new polling framework? I took a look at the leaf code, but the configuration is a mystery to me. What are the input parameters? Maybe there is a document that I am missing? Thanks in advance, Nikolay On Saturday, July 28, 2018, 11:42:13 PM GMT+2, Nikolay Shishkov <nshishkov(a)yahoo.com> wrote: Thank you! Yes the carid is TC003. I was not running anything extraordinary - just followed the developer tutorial, but never flashed directly - always flashed from edge branch OTA. I will run the commands and provide output, but it will be with the newer firmware. I will need to see if updating will have same problems. On Friday, July 27, 2018, 3:07:09 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Note that I store the .elf files alongside the .bin, for edge/eap/main builds. For example: http://api.openvehicles.com/firmware/ota/v3.1/edge/3.1.008-29-gaf41242.ovms… Regards, Mark. On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter(a)expeedo.de> wrote: Nikolay, you need to keep the .elf files for your builds to be able to analyze a backtrace. Do not use addr2line, it shows wrong line numbers. Use the script "a2l" I posted previously (I'll include it again below). Just feed it the .elf file and the backtrace. Example: a2ltmp/3.1.008-32-g2fa3ab8-elf/ovms3.elf 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 (I don't have the -28- version, so my output doesn't make sense) @Mark: spurious task WDT crashes and heap corruption crashes still occur, but it seems they have become less often with the internal RAM rework. How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Extending Mark's answer: It's normally OK to directly set metrics from IncomingFrameCan1(), but be aware metrics listeners will be executed synchronously in the context that changes the metric. Standard metrics listeners are now for example the automatic notification generators in the vehicle base class. These may need quite some stack and time. If you spend too much time handling frames on a high volume bus, your vehicle task may lose frames. It's possible to raise the queue size (currently 20 frames) and the vehicle task stack size, but it's better to keep the CAN processing simple. TL;DR: if you need to handle many CAN frames, I recommend changing metrics that trigger notifications or other complex actions from the ticker. If you encounter crashes on some CAN frames that may be due to the vehicle task stack being too small (CONFIG_OVMS_VEHICLE_RXTASK_STACK=6144). Regards, Michael Script a2l: #!/bin/bash elf=~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf for adr in $* ; do if [[ "$adr" =~ "elf" ]] ; then elf="$adr" else cmd+=" -ex 'l *$adr'" fi done cmd+=" -ex 'q'" echo "Using elf file: $elf" evalxtensa-esp32-elf-gdb -batch $elf $cmd 2>/dev/null #| grep "^0x.* is in " Am 26.07.2018 um 09:59 schrieb Nikolay Shishkov: Quick update: I managed to do a not so quick update on one of the ovms v.3 boxes that sits in a Think and can confirm that the porting seems to work. I could see speed, parking time, ambient temperature. I had very strange problems doing the OTA update. The firmware start download and I can see the messages progressing, but it would halt in between 700kB and 1600kB and then stay there until I refresh the browser. And when I refresh the browser I am asked of my password which leads me to that there must have been a crash in the meantime. I was finally able to get the OTA update work by disconnecting the box from the car and powering it via USB. This is a single data point but it kind of points to a problem with the code that communicates with the car. I was not able to get a laptop connected to checkout the console, but managed to get the following log - not sure how to interpret it. Last boot was 87 second(s) ago Time at boot: 2018-07-25 18:07:43 GMT This is reset #3 since last power cycle Detected boot reason: Crash (12/12) Crash counters: 3 total, 0 early Last crash: Alloca exception on core 0 Registers: PC : 0x400dc8ec PS : 0x00060234 A0 : 0x8008f440 A1 : 0x3ffc45b0 A2 : 0x00000020 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffb44b8 A6 : 0x3ffb47e4 A7 : 0x3ffb458c A8 : 0x3ffb44d4 A9 : 0x3ffc4590 A10 : 0x00000000 A11 : 0x7fffffff A12 : 0x8008e65b A13 : 0x3ffcc450 A14 : 0x00000003 A15 : 0x00060023 SAR : 0x00000000 EXCCAUSE: 0x00000005 EXCVADDR: 0x00000000 LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000 Backtrace: 0x400dc8ec 0x4008f43d 0x4008e181 0x400818cc 0x40082163 0x40083c4d 0x400dc8e9 Version:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) Running partition: ota_1 Boot partition: ota_1 Firmware:3.1.008-29-gaf41242/ota_1/edge (build idf v3.1-dev-987-g55d915e Jul 6 2018 00:14:59) How is performance and power usage affected when using StandardMetrics.xxxxx->SetValue in the IncomingFrameCan1 method? Most of the messages update value every 100ms, and except maybe speed, battery current and voltage, most of the parameters are not changing that often. And even for the speed, current and voltage, it is probably enough to update StandardMetrics in the 1 second ticker... does this make sense or is the difference non-existing. Thanks for all the hand holding and help, Nikolay -- 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 _______________________________________________ OvmsDev mailing list OvmsDev(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev(a)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(a)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(a)lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev

2 1