- OvmsDev - Open Vehicles

Higher resolution events
by Tom Parker 09 Jan '18

09 Jan '18

Hi, To implement the Leaf's remote climate control, I need to send a frame, wait 50ms and then repeat another frame every 100ms for 25 repetitions. On the v2 hardware I implemented this with a 50ms delay and the ticker10th function. I wasn't able to find any delay functions in v3 so either I didn't look hard enough, nothing needs one, or busy-waiting isn't the right thing to do. Ticker10th isn't implemented. I could refactor the existing ticker task to fire 10 times a second instead of once per second, or I could register a new task for the climate control and cancel it after the the 25 repetitions. Or maybe something else altogether is appropriate? Thoughts?

4 7

SD CARD
by Mark Webb-Johnson 09 Jan '18

09 Jan '18

Any electronics guys out there can help out with SD CARD? It is frustrating as hell. The last part of the hardware puzzle. Once we solve this, we can hit the button to start making these. China and I have been struggling with this for the last month, with little progress. We are just following the standard Espressif schematics for this. Here is Espressif’s master document on it: https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card <https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card> Our circuit has been built for 4 wire SD mode, using the standard pins and pullups (as documented by Espressif). Result is that it is unreliable. Fails to mount 90% of SD CARDS, and those that do mount fail and corrupt data when writing lots of data out. The core problem (we think) is that the GPIO2 and GPIO12 pins used for SD CARD are also required to be at specific values during boot (to select different boot modes). Espressif suggest to work around this using the transistor logic they have for controlling boot mode pins using the USB-to-serial converter and DTR + RTS async control pins. We want 4-wire, but let’s start with a simple 1-wire diagram on a breadboard (as per Espressif instructions): ESP32 pin SD card pin SPI pin Notes GPIO14 (MTMS) CLK SCK 10k pullup in SD mode GPIO15 (MTDO) CMD MOSI 10k pullup, both in SD and SPI modes GPIO2 D0 MISO 10k pullup in SD mode, pull low to go into download mode (see note below!) GPIO4 D1 N/C not used in 1-line SD mode; 10k pullup in 4-line SD mode GPIO12 (MTDI) D2 N/C not used in 1-line SD mode; 10k pullup in 4-line SD mode (see note below!) GPIO13 (MTCK) D3 CS not used in 1-line SD mode, but card's D3 pin must have a 10k pullup N/C CD optional, not used in the example N/C WP optional, not used in the example Also: Connect GPIO0 and GPIO2 using a jumper (so transistors drive GPIO2 and GPIO0 low when entering download mode (10K pullup otherwise) 3.3V connect to SDCARD GND connect to SDCARD We have a variety of ESP32 development modules to try this with. Espressif said that the original DEVKIT C had a problem with the boot pin control lines and transistor logic (but never said what exactly that problem was). With original (old) ESP32 DEVKIT C, I can’t get it to work reliably at all. Sometimes ok. Sometimes not. With OVMS test code (that writes a lot of data), it never works. With our OVMS boards, all versions, I can’t get it to work reliably at all. Sometimes ok. Sometimes not. With OVMS test code (that writes a lot of data), it never works. I don’t think it ever worked. Just before our test was so simple that it didn’t show the problem. So, I just purchased one of these: https://www.banggood.com/ESP32-Development-Board-WiFiBluetooth-Ultra-Low-Po… <https://www.banggood.com/ESP32-Development-Board-WiFiBluetooth-Ultra-Low-Po…> Geekcreit® ESP32 Development Board WiFi+Bluetooth Ultra Low Power Consumption Dual Cores ESP-32 ESP-32S Board (Very similar to DEVKIT C, but more modern) It works 100%. Although after flashing it cannot boot (waiting for download) - need to disconnect GPIO0 - GPIO2 link, reset, then reconnect GPIO0-GPIO2 link. Then perfect. I think our problem is related to that transistor auto-flash reset circuitry. GPIO2 is the line for data transfer, so if problem will cause data corruption and unreliable (like we are seeing). Espressif SD CARD notes here: https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card <https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card> Schematic for Geekcreit board is here: https://www.dropbox.com/s/jefwxxtufgwg0ex/esp32_Schematic%20Prints.pdf?dl=0 <https://www.dropbox.com/s/jefwxxtufgwg0ex/esp32_Schematic%20Prints.pdf?dl=0> Schematic for latest version of Espressif DEVKIT C board is here: http://espressif.com/sites/default/files/documentation/esp32_hardware_desig… <http://espressif.com/sites/default/files/documentation/esp32_hardware_desig…> The original DEVKIT C (v1) had 1K resistors on that circuit. This is the version I have. The Geekcreit has 10K resistors on that circuit. OVMS has 10K resistors on that circuit. The latest DEVKIT C (v3) has 12K resistors on that circuit. DEVKIT C v1 schematic is here: http://dl.espressif.com/dl/schematics/ESP32-DevKitJ-v1_sch.pdf <http://dl.espressif.com/dl/schematics/ESP32-DevKitJ-v1_sch.pdf> DEVKIT C v2 schematic is here: http://dl.espressif.com/dl/schematics/ESP-WROVER-KIT_SCH-2.pdf <http://dl.espressif.com/dl/schematics/ESP-WROVER-KIT_SCH-2.pdf> The latest Espressif ROVER KIT development board schematic is here: https://dl.espressif.com/dl/schematics/ESP-WROVER-KIT_SCH-3.pdf <https://dl.espressif.com/dl/schematics/ESP-WROVER-KIT_SCH-3.pdf> Note that they are now using 100K resistors, and a separate transistor on IO0 (to allow it to be independently controlled after boot). I am reasonably certain our SD CARD problem concerns the GPIO0-GPIO2 link. Can you look at these, and see if you can find the difference? Apart from resistor sizes (which Espressif keep messing around with), I can’t see the practical difference. Regards, Mark.

4 12

SD CARD vs 16MB flash
by Mark Webb-Johnson 08 Jan '18

08 Jan '18

Using Espressif standard SD CARD example program, modified to write "Hello\n” 10 million times, and then read it back 10 million times... Here is what I get with OVMS v3 developer-release hardware using release version of ESP IDF v2.1: I (50) boot: ESP-IDF v2.1.1-8-g5ae2c0d0 2nd stage bootloader I (51) boot: compile time 08:28:36 I (83) boot: Enabling RNG early entropy source... I (84) boot: SPI Speed : 40MHz I (84) boot: SPI Mode : DIO I (94) boot: SPI Flash Size : 16MB … I (910) cpu_start: Pro cpu start user code I (967) cpu_start: Starting scheduler on PRO CPU. I (972) example: Initializing SD card I (972) cpu_start: Starting scheduler on APP CPU. E (1112) sdmmc_cmd: sdmmc_card_init: send_scr returned 0x107 E (1112) example: Failed to initialize the card (263). Make sure SD card lines have pull-up resistors in place. Using latest (bleeding edge, not released) ESP IDF v3.1, using 1 line mode: I (31) boot: ESP-IDF v3.1-dev-168-ga1b59679 2nd stage bootloader I (31) boot: compile time 08:35:38 I (42) boot: Enabling RNG early entropy source... I (42) boot: SPI Speed : 40MHz I (42) boot: SPI Mode : DIO I (45) boot: SPI Flash Size : 16MB … I (195) cpu_start: Pro cpu up. I (199) cpu_start: Starting app cpu, entry point is 0x40080e38 I (0) cpu_start: App cpu up. I (209) heap_init: Initializing. RAM available for dynamic allocation: I (216) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (222) heap_init: At 3FFB2A48 len 0002D5B8 (181 KiB): DRAM I (228) heap_init: At 3FFE0440 len 00003BC0 (14 KiB): D/IRAM I (235) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (241) heap_init: At 40089270 len 00016D90 (91 KiB): IRAM I (247) cpu_start: Pro cpu start user code I (265) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (267) example: Initializing SD card I (267) example: Using SDMMC peripheral Name: SB16G Type: SDHC/SDXC Speed: default speed Size: 15193MB CSD: ver=1, sector_size=512, capacity=31116288 read_bl_len=9 SCR: sd_spec=2, bus_width=5 I (347) example: Opening file I (347) example: write count = 0 ... I (25397) example: write count = 1000000 ... I (50417) example: write count = 2000000 ... I (75737) example: write count = 3000000 ... I (101277) example: write count = 4000000 ... I (127417) example: write count = 5000000 ... I (154087) example: write count = 6000000 ... I (180247) example: write count = 7000000 ... I (206977) example: write count = 8000000 ... I (232807) example: write count = 9000000 ... I (259647) example: File written I (259647) example: Renaming file I (259657) example: Reading file I (259657) example: read count = 0 ... I (278507) example: read count = 1000000 ... I (297367) example: read count = 2000000 ... I (316427) example: read count = 3000000 ... I (335347) example: read count = 4000000 ... I (354327) example: read count = 5000000 ... I (373157) example: read count = 6000000 ... I (391637) example: read count = 7000000 ... I (410097) example: read count = 8000000 ... I (428517) example: read count = 9000000 ... I (446807) example: Read from file: 'Hello' I (446807) example: Card unmounted and using v3.1 with 4-line mode: I (247) cpu_start: Pro cpu start user code I (265) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (267) example: Initializing SD card I (267) example: Using SDMMC peripheral Name: SB16G Type: SDHC/SDXC Speed: default speed Size: 15193MB CSD: ver=1, sector_size=512, capacity=31116288 read_bl_len=9 SCR: sd_spec=2, bus_width=5 I (347) example: Opening file I (357) example: write count = 0 ... I (24187) example: write count = 1000000 ... I (47637) example: write count = 2000000 ... I (71277) example: write count = 3000000 ... I (94927) example: write count = 4000000 ... I (119567) example: write count = 5000000 ... I (143517) example: write count = 6000000 ... I (168297) example: write count = 7000000 ... I (192597) example: write count = 8000000 ... I (216847) example: write count = 9000000 ... I (240587) example: File written I (240727) example: Renaming file I (240727) example: Reading file I (240737) example: read count = 0 ... I (257697) example: read count = 1000000 ... I (274507) example: read count = 2000000 ... I (291327) example: read count = 3000000 ... I (308117) example: read count = 4000000 ... I (325157) example: read count = 5000000 ... I (341647) example: read count = 6000000 ... I (358397) example: read count = 7000000 ... I (375097) example: read count = 8000000 ... I (391787) example: read count = 9000000 ... I (408247) example: Read from file: 'Hello' I (408247) example: Card unmounted Smiling so much my face hurts... This has been such a PITA, but it looks like Espressif have finally solved it with their latest pre-release SDK. Very little performance difference between 1 line and 4 line modes (4 line is about 8% faster), so probably not worth using up those GPIO lines for that. I’m working with Espressif to see if this fix can be back-ported to v2.1. I doubt it, but no harm asking… This all, of course, brings into top priority the work Steve and I are doing trying to get OVMS v3 firmware working against ESP IDF v3.x. Here’s a hastily hacked together kludge based on bleeding edge ESP IDF v3.1: OVMS > metrics list m.version m.version 3.0.0/factory/main build (idf v3.1-dev-168-ga1b59679) Jan 8 2018 10:09:53 OVMS > sd mount Name: SB16G Type: SDHC/SDXC Speed: default speed Size: 15193MB CSD: ver=1, sector_size=512, capacity=31116288 read_bl_len=9 SCR: sd_spec=2, bus_width=5 Mounted SD CARD OVMS > vfs ls /sd .Spotlight-V100 .fseventsd component.mk sd_card_example_main.c FOO.TXT OVMS > vfs cp /sd/FOO.txt /sd/FOO2.txt VFS copy complete OVMS > vfs ls /sd .Spotlight-V100 .fseventsd component.mk sd_card_example_main.c FOO2.TXT FOO.TXT That FOO.TXT file is about 60MB in size. Now finalising hardware with the china manufacturer. I think at this point, it is worth: Use 1 line SD CARD (which frees up GPIOs SD_DATA1/SD_DATA2/SD_DATA3, but also avoids the conflict between GPIO12/SD_DATA2 and VDD_SDIO bootstrap pin). Add some capacitors for power line smoothing, as per Espressif’s example in their test board. Double-check power on SIMCOM module, to ensure it is as expected (following issues reported with low-amperage USB ports). Change to use Analog Lamb WROOM-32 module and their 16MB flash + 4MB ram. Change #4 should be the only controversial one. It has the advantages of much more RAM, and no need for external flash, but the disadvantage is that we would have to move GPIOs for simcom async (as those are using by Analog Lamb for their chip). It also depends on Analog Lamb’s lead time, and future plans for this module. Regards, Mark

3 3

WiFi mode off reboot
by Greg D. 08 Jan '18

08 Jan '18

Hi folks, Another crash. Not repeatable, but wanted to report it before I head up stairs to end the day. I had booted the module, modem off, obdii ecu started, v2 server enabled but not connected. Wifi was started but the local network is hidden, so it wasn't connected. This is all in the startup event script. OBDWiz dongle running, all fine. The plan was to let it run for the night, to catch any longer-term reboots, so I needed to turn off the wifi in order to keep the screen from filling up with 'incorrect scan type' messages. Hit wifi mode off, and it crashed (see below). Doesn't appear to be a memory issue. Tried it a second time, and wifi stopped as normal. {sigh} Definitely time for bed... Greg OVMS > wifi mode off Stopping wifi station... ESP_ERROR_CHECK failed: esp_err_t 0x3002 at 0x400d6945 0x400d6945: _ZN9esp32wifi17EventWifiScanDoneENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp:462 (discriminator 1) file: "/home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp" line 462 func: void esp32wifi::EventWifiScanDone(std::__cxx11::string, void*) expression: esp_wifi_scan_get_ap_records(&apCount, list) Backtrace: 0x40088810:0x3ffbb580 0x40088b8d:0x3ffbb5a0 0x400d6945:0x3ffbb5c0 0x400d75d8:0x3ffbb690 0x40101965:0x3ffbb6d0 0x40101bbe:0x3ffbb700 0x40101c61:0x3ffbb750 0x40102089:0x3ffbb9a0 0x4013e991:0x3ffbb9c0 0x4013e9d5:0x3ffbb9e0 0x40088810: invoke_abort at /home/greg/esp/esp-idf/components/esp32/./panic.c:519 0x40088b8d: _esp_error_check_failed at /home/greg/esp/esp-idf/components/esp32/./panic.c:531 0x400d6945: _ZN9esp32wifi17EventWifiScanDoneENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/esp32wifi/./esp32wifi.cpp:462 (discriminator 1) 0x400d75d8: _ZNKSt12_Mem_fn_baseIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvELb1EEclIJS6_S7_EvEEvPS0_DpOT_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:600 (inlined by) _ZNSt5_BindIFSt7_Mem_fnIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEPS1_St12_PlaceholderILi1EESD_ILi2EEEE6__callIvJOS7_OS8_EJLj0ELj1ELj2EEEET_OSt5tupleIJDpT0_EESt12_Index_tupleIJXspT1_EEE at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1074 (inlined by) _ZNSt5_BindIFSt7_Mem_fnIM9esp32wifiFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEPS1_St12_PlaceholderILi1EESD_ILi2EEEEclIJS7_S8_EvEET0_DpOT_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1133 (inlined by) _ZNSt17_Function_handlerIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvESt5_BindIFSt7_Mem_fnIM9esp32wifiFvS5_S6_EEPSA_St12_PlaceholderILi1EESF_ILi2EEEEE9_M_invokeERKSt9_Any_dataOS5_OS6_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:1871 0x40101965: _ZNKSt8functionIFvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPvEEclES5_S6_ at /home/greg/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/functional:2271 0x40101bbe: _ZN10OvmsEvents11SignalEventENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPv at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:144 0x40101c61: _ZN10OvmsEvents17SignalSystemEventEP14system_event_t at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:167 0x40102089: _ZN10OvmsEvents18ReceiveSystemEventEPvP14system_event_t at /home/greg/greg/ovms/Open-Vehicle-Monitoring-System-3-master/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_events.cpp:155 0x4013e991: esp_event_post_to_user at /home/greg/esp/esp-idf/components/esp32/./event_loop.c:94 0x4013e9d5: esp_event_loop_task at /home/greg/esp/esp-idf/components/esp32/./event_loop.c:94 Rebooting...

2 2

Kia Soul status.
by Geir Øyvind Vælidalo 08 Jan '18

08 Jan '18

Just a small status update on the Kia Soul porting. My OVMS V3 is now connecting to the V2 server via my WiFi-network at home. I’ve got the first data from the new hardware through to the OVMS app on my iPhone. Fantastic job guys! As soon as my health is ok again, I can start testing the hardware in my car and verify the data and fix the bugs. The Kia Soul should be almost on par with the V2, with a few things added. Just wish I had a case... And I need to get a twin sim-card (I got free SMS and lots of data included 🙂 ) so it can be online away from home. Oh, and a passive GPS-antenna. This is looking good! Geir

3 7

Flip The Fleet - automated data collection
by Dima Ivanov 07 Jan '18

07 Jan '18

Hi everyone, My name is Dima - Tom Parker introduced me to your group. I'm a co-founder of a citizen science project called Flip The Fleet (www.FlipTheFleet.org<http://www.FlipTheFleet.org>) - we are gathering data from hundreds of EV and PHEV owners throughout New Zealand using my benchmarking platform called PowerStats (www.powerstats.co<http://www.powerstats.co>). If you are interested, the first few lines on the Flip The Fleet website talk about the project at a high level (to avoid writing it out here). Currently, all our drivers input their data into the PowerStats portal manually - as in, they look at their dash and their scanner app if they have one (e.g. LeafSpy), and type in the numbers they see into a web page inside our secure portal. They receive automated reminders, and do this data entry each month. For the early adopters and geeks - this is fine, they are happy to do this all day long. However, business owners and fleet managers don't want to spend this time - and we'd like businesses' data. In order for Flip The Fleet to have appeal to business, we need to automate data gathering as much as possible, so fleet managers only enter contextual data like satisfaction levels, maintenance spend etc. I would say that 90-95% of the fields we ask for can be obtained via CANBUS data. This is where your project is very exciting for Henrik and I - the devices and systems you are working on will enable us to pitch to business (and, hopefully, monetise the two years of hard work Henrik and I have put into starting Flip The Fleet!) Here are some immediate questions Tom has suggested I ask you: 1. V3 hardware, when do you think it'll be ready? 2. NQTT protocol support - is anyone working on the v3 server (NQTT) or should we try to integrate with the V2 server, once the hardware is available? Due to the character of a lot of our drivers, I'm sure there will be more than enough guinea pigs for your devices, should you need to have them tested out in the field. You'll see the top-10 makes and models of cars we have registered on the Flip The Fleet homepage, towards the bottom. If we can be of help to you, we would love to assist by shoulder-tapping the right people. Look forward to your reply. Kind regards, Dima Ivanov Managing Director, PowerStats Limited Ph: +64-(0)21-927-346 Address: ecentre, Oaklands Road, Albany 0632, Auckland, New Zealand Skype: d.y.ivanov E-mail: dima(a)powerstats.co<mailto:dima@powerstats.co> Web: www.powerstats.co<http://www.powerstats.co/> P please consider the environment before printing this e-mail

2 2

Emergency alert
by Geir Øyvind Vælidalo 07 Jan '18

07 Jan '18

Hi guys, I’ve been thinking of adding an emergency alert to the Kia Soul module that kicks in when the hazard lights are turned on, airbags are deployed or in other situations that might be a reason for concern. These alerts would be sent as SMS to a list of recipients that the user specifies. Typically I would include my own number, my wife’s and a few of my closest family. The alert can contain location, type of alert (airbag deployment, hazard light or other), number of passengers (by keeping track of the seat belt sensors), maybe using BT to see which phones are in the car. That way, we can call in to see if everything is ok and act if needed. What do you think? Is this functionality that could/should be general and added to vehicle? Geir

4 5

How to start supporting a new vehicle
by Thomas Stinner 06 Jan '18

06 Jan '18

Hi Guys, first i would like to thank you for all the work you have already done and the progress you’ve made so far. I would like to add support for a new vehicle, the Hyundai Ioniq. Since the car has no support for BlueLink in Europe i would like to start with some basic things, such as checking SoC etc. Since v3 of OVMS is around the corner it probably does not make sense to add support in v2 and get the required hardware for that. However, information about v3 is still very limited - in principal it is the github repo and this mailing list. It is also unclear to me if the hardware has already been finalized and available (at least as developer kit) or not. Any hints on where i should start digging into it? Grüße / Greetings Thomas

2 2

Macros MIN and MAX
by Stephen Casner 05 Jan '18

05 Jan '18

Michael and Geir, Can you please see whether the definitions of MIN and MAX in your files are needed? These macros are defined in: esp-idf/components/newlib/include/sys/param.h which gets included from ovms_config.h and perhaps other places. When I'm compiling with release v3.0 the redefinition of these macros shows up as a warning. It would be possible to ignore the warning and it might also be possible to turn off the warnings by changing the configuration, but if the definitions are not needed this would be cleaner. -- Steve

4 5

Problems with IncomingFrameCan when registering two can buses.
by Geir Øyvind Vælidalo 03 Jan '18

03 Jan '18

I’m having problems with IncomingFrameCan when reading from two can buses from the Kia Soul. One of the can buses dies prematurely, and quite fast, with no visible errors. Most of the time it is Can2 that dies, however that is not always the case. I tried with an almost empty IncomingFrameCan2, containing just a counter to see how many times it is called, and it varied from 15 to almost 200 before it dies. This is the code: RegisterCanBus(1, CAN_MODE_ACTIVE, CAN_SPEED_500KBPS); RegisterCanBus(2, CAN_MODE_ACTIVE, CAN_SPEED_100KBPS); … void OvmsVehicleKiaSoulEv::IncomingFrameCan2(CAN_frame_t* p_frame) { uint8_t *d = p_frame->data.u8; m_counter->SetValue( m_counter->AsInt()+1 ); } IncomingFrameCan1 is quite verbose, but should not take too long time to process. But I have a lot of Polls on Can1: static const OvmsVehicle::poll_pid_t vehicle_kiasoulev_polls[] = { { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 0x02, { 30, 30, 30 } }, // VIN { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 30, 10, 10 } }, // BMC Diag page 01 { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 30, 10 } }, // BMC Diag page 02 { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x03, { 30, 30, 10 } }, // BMC Diag page 03 { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x04, { 30, 30, 10 } }, // BMC Diag page 04 { 0x7e4, 0x7ec, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x05, { 30, 30, 10 } }, // BMC Diag page 05 { 0x794, 0x79c, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 30, 10 } }, // OBC - On board charger { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x00, { 30, 10, 10 } }, // VMCU Shift-stick { 0x7e2, 0x7ea, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x02, { 30, 10, 0 } }, // VMCU Motor temp++ { 0x7df, 0x7de, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x06, { 30, 10, 0 } }, // TMPS { 0x7c5, 0x7cd, VEHICLE_POLL_TYPE_OBDIIGROUP, 0x01, { 30, 10, 0 } }, // LDC - Low voltage DC-DC { 0, 0, 0, 0, { 0, 0, 0 } } }; The few times that Can2 is the one that lives on, I can’t see any metrics from Can1. Current source can be seen here: https://github.com/goev/Open-Vehicle-Monitoring-System-3 <https://github.com/goev/Open-Vehicle-Monitoring-System-3> in case someone can take a look. Any pointers to where I can start looking, or tips to what I can try? Best regards, Geir

4 44