December 2017 - OvmsDev - Open Vehicles

GPS / NMEA integration
by Michael Balzer 11 Jul '18

11 Jul '18

I'm currently working on the NMEA module. The MUX channel is working, but I don't get a GPS fix. I've tried all GPS commands and now suspect my SIMCOM module having a hardware issue. I'm doing this: OVMS > level debug OVMS > power simcom on …wait for the MUX to be ready, then issue… OVMS > simcom muxtx 4 AT+CGPSNMEA=1 OVMS > simcom muxtx 4 AT+CGPS=1,1 …now the SIMCOM begins sending NMEA $GPGGA lines once per second looking like this: D (2937174) SIMCOM rx: f9 05 ff 35 24 47 50 47 47 41 2c 2c 2c 2c 2c 2c ...5*$GPGGA,,,,,,* D (2937174) SIMCOM rx: 30 2c 2c 2c 2c 2c 2c 2c 2c 2a 36 36 0d 0a 60 f9 *0,,,,,,,,*66*..`. Normally the modem should get a GPS fix within about 1-2 minutes and begin filling data in the $GPGGA record. But my modem won't, it just keeps sending empty fields. Can someone please try this with his/her module? To disable the GPS receiver, issue: OVMS > simcom muxtx 4 AT+CGPS=0 Thanks & regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

7 30

Stack sizes
by Mark Webb-Johnson 13 Jan '18

13 Jan '18

It seems that we are continuously having to increase stack sizes. So, I went on a hunt to try to find out why… I put a abort() in the metrics_list() function. Spun up a wifi connection, an ovms_server_v2 connection, and then 'cmd.pl 7 'metric list’. Here are the stack frame details: (gdb) bt #0 0x40088dac in invoke_abort () at /Users/mark/esp/esp-idf/components/esp32/./panic.c:125 #1 0x40088e7a in abort () at /Users/mark/esp/esp-idf/components/esp32/./panic.c:134 #2 0x40123765 in metrics_list (verbosity=1024, writer=0x3fff6b94, cmd=0x3ffb6584, argc=0, argv=0x0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:49 #3 0x4011e1a9 in OvmsCommand::Execute (this=0x3ffb6584, verbosity=1024, writer=0x3fff6b94, argc=0, argv=0x0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:257 #4 0x4011e29d in OvmsCommand::Execute (this=0x3ffb64f0, verbosity=1024, writer=0x3fff6b94, argc=1, argv=0x3fff54d4) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:302 #5 0x4011e290 in OvmsCommand::Execute (this=0x3ffc3cc4 <MyCommandApp+4>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d4) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:298 #6 0x4011e2c4 in OvmsCommandApp::Execute (this=0x3ffc3cc0 <MyCommandApp>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:507 #7 0x401292a8 in Execute (rl=0x3fff6b9c, argc=2, argv=0x3fff54d0) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47 #8 0x400db2cd in new_line_handler (pThis=0x3fff6b9c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:626 #9 0x400db333 in microrl_insert_char (pThis=0x3fff6b9c, ch=10) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:674 #10 0x401292f7 in OvmsShell::ProcessChar (this=0x3fff6b94, c=10 '\n') at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:62 #11 0x400f57d8 in OvmsServerV2::ProcessCommand (this=0x3fff433c, payload=<optimized out>) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411 #12 0x400f9b54 in OvmsServerV2::ProcessServerMsg (this=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336 #13 0x400fa263 in OvmsServerV2::ServerTask (this=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:244 #14 0x400f4325 in OvmsServer_task (pvParameters=0x3fff433c) at /Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:43 Stack level 0, frame at 0x3fff53f0: pc = 0x40088dac in invoke_abort (/Users/mark/esp/esp-idf/components/esp32/./panic.c:125); saved pc = 0x40088e7a called by frame at 0x3fff5410 source language c. Arglist at 0x3fff53d0, args: Locals at 0x3fff53d0, Previous frame's sp is 0x3fff53f0 Saved registers: ar56 at 0x3fff53c0, ar57 at 0x3fff53c4, ar58 at 0x3fff53c8, ar59 at 0x3fff53cc, ar60 at 0x3fff53f0, ar61 at 0x3fff53f4, ar62 at 0x3fff53f8, ar63 at 0x3fff53fc, a0 at 0x3fff53c0, a2 at 0x3fff53c8, a3 at 0x3fff53cc, a4 at 0x3fff53f0, a5 at 0x3fff53f4, a6 at 0x3fff53f8, a7 at 0x3fff53fc Stack level 1, frame at 0x3fff5410: pc = 0x40088e7a in abort (/Users/mark/esp/esp-idf/components/esp32/./panic.c:134); saved pc = 0x40123765 called by frame at 0x3fff5430, caller of frame at 0x3fff53f0 source language c. Arglist at 0x3fff53f0, args: Locals at 0x3fff53f0, Previous frame's sp is 0x3fff5410 Saved registers: ar48 at 0x3fff53e0, ar49 at 0x3fff53e4, ar50 at 0x3fff53e8, ar51 at 0x3fff53ec, ar52 at 0x3fff5410, ar53 at 0x3fff5414, ar54 at 0x3fff5418, ar55 at 0x3fff541c, a0 at 0x3fff53e0, a2 at 0x3fff53e8, a3 at 0x3fff53ec, a4 at 0x3fff5410, a5 at 0x3fff5414, a6 at 0x3fff5418, a7 at 0x3fff541c Stack level 2, frame at 0x3fff5430: pc = 0x40123765 in metrics_list (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_metrics.cpp:49); saved pc = 0x4011e1a9 called by frame at 0x3fff5450, caller of frame at 0x3fff5410 source language c++. Arglist at 0x3fff5410, args: verbosity=1024, writer=0x3fff6b94, cmd=0x3ffb6584, argc=0, argv=0x0 Locals at 0x3fff5410, Previous frame's sp is 0x3fff5430 Saved registers: ar40 at 0x3fff5400, ar41 at 0x3fff5404, ar42 at 0x3fff5408, ar43 at 0x3fff540c, ar44 at 0x3fff5430, ar45 at 0x3fff5434, ar46 at 0x3fff5438, ar47 at 0x3fff543c, a0 at 0x3fff5400, a2 at 0x3fff5408, a3 at 0x3fff540c, a4 at 0x3fff5430, a5 at 0x3fff5434, a6 at 0x3fff5438, a7 at 0x3fff543c Stack level 3, frame at 0x3fff5450: pc = 0x4011e1a9 in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:257); saved pc = 0x4011e29d called by frame at 0x3fff5470, caller of frame at 0x3fff5430 source language c++. Arglist at 0x3fff5430, args: this=0x3ffb6584, verbosity=1024, writer=0x3fff6b94, argc=0, argv=0x0 Locals at 0x3fff5430, Previous frame's sp is 0x3fff5450 Saved registers: ar32 at 0x3fff5420, ar33 at 0x3fff5424, ar34 at 0x3fff5428, ar35 at 0x3fff542c, ar36 at 0x3fff5450, ar37 at 0x3fff5454, ar38 at 0x3fff5458, ar39 at 0x3fff545c, a0 at 0x3fff5420, a2 at 0x3fff5428, a3 at 0x3fff542c, a4 at 0x3fff5450, a5 at 0x3fff5454, a6 at 0x3fff5458, a7 at 0x3fff545c Stack level 4, frame at 0x3fff5470: pc = 0x4011e29d in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:302); saved pc = 0x4011e290 called by frame at 0x3fff5490, caller of frame at 0x3fff5450 source language c++. Arglist at 0x3fff5450, args: this=0x3ffb64f0, verbosity=1024, writer=0x3fff6b94, argc=1, argv=0x3fff54d4 Locals at 0x3fff5450, Previous frame's sp is 0x3fff5470 Saved registers: ar24 at 0x3fff5440, ar25 at 0x3fff5444, ar26 at 0x3fff5448, ar27 at 0x3fff544c, ar28 at 0x3fff5470, ar29 at 0x3fff5474, ar30 at 0x3fff5478, ar31 at 0x3fff547c, a0 at 0x3fff5440, a2 at 0x3fff5448, a3 at 0x3fff544c, a4 at 0x3fff5470, a5 at 0x3fff5474, a6 at 0x3fff5478, a7 at 0x3fff547c Stack level 5, frame at 0x3fff5490: pc = 0x4011e290 in OvmsCommand::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:298); saved pc = 0x4011e2c4 called by frame at 0x3fff54b0, caller of frame at 0x3fff5470 source language c++. Arglist at 0x3fff5470, args: this=0x3ffc3cc4 <MyCommandApp+4>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d4 Locals at 0x3fff5470, Previous frame's sp is 0x3fff5490 Saved registers: ar16 at 0x3fff5460, ar17 at 0x3fff5464, ar18 at 0x3fff5468, ar19 at 0x3fff546c, ar20 at 0x3fff5490, ar21 at 0x3fff5494, ar22 at 0x3fff5498, ar23 at 0x3fff549c, a0 at 0x3fff5460, a2 at 0x3fff5468, a3 at 0x3fff546c, a4 at 0x3fff5490, a5 at 0x3fff5494, a6 at 0x3fff5498, a7 at 0x3fff549c Stack level 6, frame at 0x3fff54b0: pc = 0x4011e2c4 in OvmsCommandApp::Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_command.cpp:507); saved pc = 0x401292a8 called by frame at 0x3fff54d0, caller of frame at 0x3fff5490 source language c++. Arglist at 0x3fff5490, args: this=0x3ffc3cc0 <MyCommandApp>, verbosity=1024, writer=0x3fff6b94, argc=2, argv=0x3fff54d0 Locals at 0x3fff5490, Previous frame's sp is 0x3fff54b0 Saved registers: ar8 at 0x3fff5480, ar9 at 0x3fff5484, ar10 at 0x3fff5488, ar11 at 0x3fff548c, ar12 at 0x3fff54b0, ar13 at 0x3fff54b4, ar14 at 0x3fff54b8, ar15 at 0x3fff54bc, a0 at 0x3fff5480, a2 at 0x3fff5488, a3 at 0x3fff548c, a4 at 0x3fff54b0, a5 at 0x3fff54b4, a6 at 0x3fff54b8, a7 at 0x3fff54bc Stack level 7, frame at 0x3fff54d0: pc = 0x401292a8 in Execute (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:47); saved pc = 0x400db2cd called by frame at 0x3fff5530, caller of frame at 0x3fff54b0 source language c++. Arglist at 0x3fff54b0, args: rl=0x3fff6b9c, argc=2, argv=0x3fff54d0 Locals at 0x3fff54b0, Previous frame's sp is 0x3fff54d0 Saved registers: ar0 at 0x3fff54a0, ar1 at 0x3fff54a4, ar2 at 0x3fff54a8, ar3 at 0x3fff54ac, ar4 at 0x3fff5510, ar5 at 0x3fff5514, ar6 at 0x3fff5518, ar7 at 0x3fff551c, a0 at 0x3fff54a0, a2 at 0x3fff54a8, a3 at 0x3fff54ac, a4 at 0x3fff5510, a5 at 0x3fff5514, a6 at 0x3fff5518, a7 at 0x3fff551c Stack level 8, frame at 0x3fff5530: pc = 0x400db2cd in new_line_handler (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:626); saved pc = 0x400db333 called by frame at 0x3fff5560, caller of frame at 0x3fff54d0 source language c. Arglist at 0x3fff54d0, args: pThis=0x3fff6b9c Locals at 0x3fff54d0, Previous frame's sp is 0x3fff5530 Saved registers: ar56 at 0x3fff54c0, ar57 at 0x3fff54c4, ar58 at 0x3fff54c8, ar59 at 0x3fff54cc, ar60 at 0x3fff5540, ar61 at 0x3fff5544, ar62 at 0x3fff5548, ar63 at 0x3fff554c, a0 at 0x3fff54c0, a2 at 0x3fff54c8, a3 at 0x3fff54cc, a4 at 0x3fff5540, a5 at 0x3fff5544, a6 at 0x3fff5548, a7 at 0x3fff554c Stack level 9, frame at 0x3fff5560: pc = 0x400db333 in microrl_insert_char (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/microrl/./microrl.c:674); saved pc = 0x401292f7 called by frame at 0x3fff5580, caller of frame at 0x3fff5530 source language c. Arglist at 0x3fff5530, args: pThis=0x3fff6b9c, ch=10 Locals at 0x3fff5530, Previous frame's sp is 0x3fff5560 Saved registers: ar48 at 0x3fff5520, ar49 at 0x3fff5524, ar50 at 0x3fff5528, ar51 at 0x3fff552c, ar52 at 0x3fff5560, ar53 at 0x3fff5564, ar54 at 0x3fff5568, ar55 at 0x3fff556c, a0 at 0x3fff5520, a2 at 0x3fff5528, a3 at 0x3fff552c, a4 at 0x3fff5560, a5 at 0x3fff5564, a6 at 0x3fff5568, a7 at 0x3fff556c Stack level 10, frame at 0x3fff5580: pc = 0x401292f7 in OvmsShell::ProcessChar (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_shell.cpp:62); saved pc = 0x400f57d8 called by frame at 0x3fff5e20, caller of frame at 0x3fff5560 source language c++. Arglist at 0x3fff5560, args: this=0x3fff6b94, c=10 '\n' Locals at 0x3fff5560, Previous frame's sp is 0x3fff5580 Saved registers: ar40 at 0x3fff5550, ar41 at 0x3fff5554, ar42 at 0x3fff5558, ar43 at 0x3fff555c, ar44 at 0x3fff5e00, ar45 at 0x3fff5e04, ar46 at 0x3fff5e08, ar47 at 0x3fff5e0c, a0 at 0x3fff5550, a2 at 0x3fff5558, a3 at 0x3fff555c, a4 at 0x3fff5e00, a5 at 0x3fff5e04, a6 at 0x3fff5e08, a7 at 0x3fff5e0c Stack level 11, frame at 0x3fff5e20: pc = 0x400f57d8 in OvmsServerV2::ProcessCommand (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411); saved pc = 0x400f9b54 called by frame at 0x3fff5ee0, caller of frame at 0x3fff5580 source language c++. Arglist at 0x3fff5580, args: this=0x3fff433c, payload=<optimized out> Locals at 0x3fff5580, Previous frame's sp is 0x3fff5e20 Saved registers: ar32 at 0x3fff5570, ar33 at 0x3fff5574, ar34 at 0x3fff5578, ar35 at 0x3fff557c, ar36 at 0x3fff5ec0, ar37 at 0x3fff5ec4, ar38 at 0x3fff5ec8, ar39 at 0x3fff5ecc, a0 at 0x3fff5570, a2 at 0x3fff5578, a3 at 0x3fff557c, a4 at 0x3fff5ec0, a5 at 0x3fff5ec4, a6 at 0x3fff5ec8, a7 at 0x3fff5ecc Stack level 12, frame at 0x3fff5ee0: pc = 0x400f9b54 in OvmsServerV2::ProcessServerMsg (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336); saved pc = 0x400fa263 called by frame at 0x3fff5f80, caller of frame at 0x3fff5e20 source language c++. Arglist at 0x3fff5e40, args: this=0x3fff433c Locals at 0x3fff5e40, Previous frame's sp is 0x3fff5ee0 Saved registers: ar24 at 0x3fff5e10, ar25 at 0x3fff5e14, ar26 at 0x3fff5e18, ar27 at 0x3fff5e1c, ar28 at 0x3fff5f60, ar29 at 0x3fff5f64, ar30 at 0x3fff5f68, ar31 at 0x3fff5f6c, a0 at 0x3fff5e10, a2 at 0x3fff5e18, a3 at 0x3fff5e1c, a4 at 0x3fff5f60, a5 at 0x3fff5f64, a6 at 0x3fff5f68, a7 at 0x3fff5f6c Stack level 13, frame at 0x3fff5f80: pc = 0x400fa263 in OvmsServerV2::ServerTask (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:244); saved pc = 0x400f4325 called by frame at 0x0, caller of frame at 0x3fff5ee0 source language c++. Arglist at 0x3fff5ee0, args: this=0x3fff433c Locals at 0x3fff5ee0, Previous frame's sp is 0x3fff5f80 Saved registers: ar16 at 0x3fff5ed0, ar17 at 0x3fff5ed4, ar18 at 0x3fff5ed8, ar19 at 0x3fff5edc, ar20 at 0x3fff5f80, ar21 at 0x3fff5f84, ar22 at 0x3fff5f88, ar23 at 0x3fff5f8c, a0 at 0x3fff5ed0, a2 at 0x3fff5ed8, a3 at 0x3fff5edc, a4 at 0x3fff5f80, a5 at 0x3fff5f84, a6 at 0x3fff5f88, a7 at 0x3fff5f8c Stack level 14, frame at 0x0: pc = 0x400f4325 in OvmsServer_task (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server/./ovms_server.cpp:43); saved pc = 0x40000000 Outermost frame: outermost caller of frame at 0x3fff5f80 source language c++. Arglist at 0x3fff5f80, args: pvParameters=0x3fff433c Locals at 0x3fff5f80, Previous frame's sp is 0x0 Saved registers: ar16 at 0x3fff5f70, ar17 at 0x3fff5f74, ar18 at 0x3fff5f78, ar19 at 0x3fff5f7c, a0 at 0x3fff5f70, a2 at 0x3fff5f78, a3 at 0x3fff5f7c Here are the stack frame pointers: OvmsServer_task Stack level 14, frame at 0x0: OvmsServerV2::ServerTask Stack level 13, frame at 0x3fff5f80: 160 bytes OvmsServerV2::ProcessServerMsg Stack level 12, frame at 0x3fff5ee0: 192 bytes OvmsServerV2::ProcessCommand Stack level 11, frame at 0x3fff5e20: 2208 bytes OvmsShell::ProcessChar Stack level 10, frame at 0x3fff5580: 32 bytes microrl_insert_char Stack level 9, frame at 0x3fff5560: 48 bytes new_line_handler Stack level 8, frame at 0x3fff5530: 92 bytes Execute Stack level 7, frame at 0x3fff54d0: 32 bytes OvmsCommandApp::ExecuteStack level 6, frame at 0x3fff54b0: 32 bytes OvmsCommand::Execute Stack level 5, frame at 0x3fff5490: 32 bytes OvmsCommand::Execute Stack level 4, frame at 0x3fff5470: 32 bytes OvmsCommand::Execute Stack level 3, frame at 0x3fff5450: 32 bytes metrics_list Stack level 2, frame at 0x3fff5430: 32 bytes abort Stack level 1, frame at 0x3fff5410: 32 bytes invoke_abort Stack level 0, frame at 0x3fff53f0 That frame #11 stands out like a sore thumb. Here are the details: (gdb) info frame Stack level 11, frame at 0x3fff5e20: pc = 0x400f57d8 in OvmsServerV2::ProcessCommand (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:411); saved pc = 0x400f9b54 called by frame at 0x3fff5ee0, caller of frame at 0x3fff5580 source language c++. Arglist at 0x3fff5580, args: this=0x3fff433c, payload=<optimized out> Locals at 0x3fff5580, Previous frame's sp is 0x3fff5e20 Saved registers: ar32 at 0x3fff5570, ar33 at 0x3fff5574, ar34 at 0x3fff5578, ar35 at 0x3fff557c, ar36 at 0x3fff5ec0, ar37 at 0x3fff5ec4, ar38 at 0x3fff5ec8, ar39 at 0x3fff5ecc, a0 at 0x3fff5570, a2 at 0x3fff5578, a3 at 0x3fff557c, a4 at 0x3fff5ec0, a5 at 0x3fff5ec4, a6 at 0x3fff5ec8, a7 at 0x3fff5ecc (gdb) info locals bs = 0x3fff6b94 val = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x9c85f1ef '\377' <repeats 200 times>...}, _M_string_length = 2512534878, {_M_local_buf = "\377\377\377\377\063\234\351\347W\243\303*\242\004\000\017", _M_allocated_capacity = 4294967295}} command = <optimized out> sep = 1 vehicle = 0x0 buffer = {<std::basic_ostream<char, std::char_traits<char> >> = {<std::basic_ios<char, std::char_traits<char> >> = {<std::ios_base> = { _vptr$ios_base = 0x3f4168bc <vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >+32>, static boolalpha = std::_S_boolalpha, static dec = std::_S_dec, static fixed = std::_S_fixed, static hex = std::_S_hex, static internal = std::_S_internal, static left = std::_S_left, static oct = std::_S_oct, static right = std::_S_right, static scientific = std::_S_scientific, static showbase = std::_S_showbase, static showpoint = std::_S_showpoint, static showpos = std::_S_showpos, static skipws = std::_S_skipws, static unitbuf = std::_S_unitbuf, static uppercase = std::_S_uppercase, static adjustfield = std::_S_adjustfield, static basefield = std::_S_basefield, static floatfield = std::_S_floatfield, static badbit = std::_S_badbit, static eofbit = std::_S_eofbit, static failbit = std::_S_failbit, static goodbit = std::_S_goodbit, static app = std::_S_app, static ate = std::_S_ate, static binary = std::_S_bin, static in = std::_S_in, static out = std::_S_out, static trunc = std::_S_trunc, static beg = std::_S_beg, static cur = std::_S_cur, static end = std::_S_end, _M_precision = 6, _M_width = 0, _M_flags = 4098, _M_exception = std::_S_goodbit, _M_streambuf_state = std::_S_goodbit, _M_callbacks = 0x0, _M_word_zero = {_M_pword = 0x0, _M_iword = 0}, _M_local_word = {{_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, { _M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}, {_M_pword = 0x0, _M_iword = 0}}, _M_word_size = 8, _M_word = 0x3fff5c84, _M_ios_locale = { static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_classic = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_categories = <optimized out>, static _S_twinned_facets = 0x3f415488 <std::locale::_S_twinned_facets>}}, _M_tie = 0x0, _M_fill = 0 '\000', _M_fill_init = false, _M_streambuf = 0x3fff5c24, _M_ctype = 0x3ffc4878 <(anonymous namespace)::ctype_c>, _M_num_put = 0x3ffc4850 <(anonymous namespace)::num_put_c>, _M_num_get = 0x3ffc4858 <(anonymous namespace)::num_get_c>}, _vptr$basic_ostream = 0x3f4168a8 <vtable for std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >+12>}, _M_stringbuf = {<std::basic_streambuf<char, std::char_traits<char> >> = { _vptr$basic_streambuf = 0x3f4167cc <vtable for std::__cxx11::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >+8>, _M_in_beg = 0x0, _M_in_cur = 0x0, _M_in_end = 0x0, _M_out_beg = 0x0, _M_out_cur = 0x0, _M_out_end = 0x0, _M_buf_locale = {static none = 0, static ctype = 1, static numeric = 2, static collate = 4, static time = 8, static monetary = 16, static messages = 32, static all = 63, _M_impl = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_classic = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_global = 0x3ffc4c2c <(anonymous namespace)::c_locale_impl>, static _S_categories = <optimized out>, static _S_twinned_facets = 0x3f415488 <std::locale::_S_twinned_facets>}}, _M_mode = std::_S_out, _M_string = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff5c50 ""}, _M_string_length = 0, {_M_local_buf = "\000\377\377\377y\031\b@\000\000\000\000\250\177\b@", _M_allocated_capacity = 4294967040}}}} (gdb) info args this = 0x3fff433c payload = <optimized out> Also frame #12: (gdb) info frame Stack level 12, frame at 0x3fff5ee0: pc = 0x400f9b54 in OvmsServerV2::ProcessServerMsg (/Users/mark/Documents/ovms/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/ovms_server_v2/src/ovms_server_v2.cpp:336); saved pc = 0x400fa263 called by frame at 0x3fff5f80, caller of frame at 0x3fff5e20 source language c++. Arglist at 0x3fff5e40, args: this=0x3fff433c Locals at 0x3fff5e40, Previous frame's sp is 0x3fff5ee0 Saved registers: ar24 at 0x3fff5e10, ar25 at 0x3fff5e14, ar26 at 0x3fff5e18, ar27 at 0x3fff5e1c, ar28 at 0x3fff5f60, ar29 at 0x3fff5f64, ar30 at 0x3fff5f68, ar31 at 0x3fff5f6c, a0 at 0x3fff5e10, a2 at 0x3fff5e18, a3 at 0x3fff5e1c, a4 at 0x3fff5f60, a5 at 0x3fff5f64, a6 at 0x3fff5f68, a7 at 0x3fff5f6c (gdb) info locals line = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff68a8 "MP-0 C7,metric list"}, _M_string_length = 19, {_M_local_buf = "\023\000\000\000\000\000\000\000\270^\377?\270^\377?", _M_allocated_capacity = 19}} b = 0x3fff5e20 "MP-0 C7,metric list" len = <optimized out> code = 67 'C' payload = {static npos = <optimized out>, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x3fff5ea8 "7,metric list"}, _M_string_length = 13, {_M_local_buf = "7,metric list\000\000", _M_allocated_capacity = 1701653559}} (gdb) info args this = 0x3fff433c Here is the size of that std::ostringstream: std::ostringstream buffer; ESP_LOGI(TAG,"std::ostringstream buffer is %d bytes",sizeof(buffer)); I (41478) ovms-server-v2: std::ostringstream buffer is 200 bytes 200 bytes, not 2,000 bytes, so something else is going on here. Anyway, changing it to a dynamically (new/delete) allocated buffer, drops stack usage of that frame to 1,824 bytes (was 2,208 so that is 384 bytes saved). That uint8_t b[line.length()+1] in OvmsServerV2::ProcessServerMsg() is also nasty - it will grow stack usage depending on line length. So, we’ll fix that as well. 192 bytes -> 160 bytes. Things to note: Each stack call is a minimum of 32 bytes. Not so bad, really - we’d need to nest calls 32 deep to get 1KB stack usage. Local variables are scary. They can be unexpectedly large. Best to new/free them, to guarantee just 4 bytes each. The OvmsCommand::Execute recursion I was worried about is not so bad. Probably 100 bytes of stack, or so, for most commands. We could improve that by getting rid of the recursion (it is elegant, but not strictly necessary), but it doesn’t seem to be a big win. I’m still looking for 150+ bytes in OvmsServerV2::ProcessServerMsg(), and 1,900+ bytes in OvmsServerV2::ProcessCommand(). Those would be big. Regards, Mark.

3 5

Higher resolution events
by Tom Parker 10 Jan '18

10 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 10 Jan '18

10 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

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

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

04 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

Console logging / CAN tracing
by Michael Balzer 01 Jan '18

01 Jan '18

I've found a strange issue with console logging and/or especially CAN tracing: If CAN tracing is enabled and a command that sends CAN frames and runs longer than about a second (?) (i.e. "co can1 scan"), the trace output first becomes garbled, the command will need much longer than usual to finish, and after returning to the prompt, the hex and single char output of the trace is split into separate outputs, coming one per second (running for a while), intermixing with the shell prompt. Also trace output gets garbled especially on a parallel telnet session. I suspect that's due to the UART queue becoming full, and the console logger doing xQueueSendToBack() with 1000 ms timeouts. Every hex dump byte is logged by a separate call to MyCommandApp.Log(). If the queue is full, every single call gets delayed for a second …adding up to block the console for as many seconds as there are calls…? (unverified theory) > As proposed, I will change the script code to use BufferedShell and > also change how console_logger() is done so I can remove the > problematic OvmsConsole::Log() function. Then puts() will work again, > too. > -- Steve Is this related? I.e. should the CAN trace output be done using ESP_LOG instead of MyCommandApp.Log()? If so I can take care of that… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

3 8

Modem link-drop crash
by Greg D. 01 Jan '18

01 Jan '18

Hi folks, I left my module running with the modem connected (WiFi client off) for a couple of days. V2 server configured and connected, but the phone client was not running. The module was sitting on my desk (not in a car), powered from the high-power USB port on my laptop. It was blinking happily last night when I went to bed, but dark this morning. Apparently had crashed and rebooted during the night. Here's the trace-back from the screen. Looks like a link drop was the trigger, or perhaps the result of something else. Hope this helps, Greg I (129194054) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129194064) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129191,0,0,0,0,0,0,0,0,0,0 I (129795064) ovms-server-v2: Send MP-0 S47,K,0,0,stopped,standard,0,0,0,0,0,0,0,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,0.00,0 I (129795074) ovms-server-v2: Send MP-0 D0,0,5,0,0,0,0,0,0,129792,0,0,0,0,0,0,0,0,0,0 I (130030624) simcom: CREG Network Registration: Searching I (130031414) simcom: Lost network connection (NetworkRegistration in NetMode) I (130031414) simcom: State: Enter NetLosGuru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled. Register dump: PC : 0x4018f959 PS : 0x00060830 A0 : 0x8018a5d8 A1 : 0x3ffd80f0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2) A2 : 0x0000f01d A3 : 0x00000000 A4 : 0x00000000 A5 : 0xfffffffc A6 : 0x3fff2c8c A7 : 0x00000014 A8 : 0x00000000 A9 : 0x00000001 A10 : 0x502b34ca A11 : 0x00000001 A12 : 0x3f42ea90 A13 : 0x3f42eaa4 A14 : 0x3ffda120 A15 : 0x00000000 SAR : 0x0000000b EXCCAUSE: 0x0000001c EXCVADDR: 0x0000f0d2 LBEG : 0x4000c2e0 LEND : 0x4000c2f6 LCOUNT : 0xffffffff Backtrace: 0x4018f959:0x3ffd80f0 0x4018a5d5:0x3ffd8110 0x4018d3eb:0x3ffd8150 0x4018d40d:0x3ffd8180 0x4018d4ae:0x3ffd81a0 0x4018d90c:0x3ffd81c0 0x4018e46a:0x3ffd81e0 0x4018e4ab:0x3ffd8200 0x40196261:0x3ffd8220 0x4019882d:0x3ffd8240 0x40198874:0x3ffd8260 0x40199e9d:0x3ffd8280 0x40198764:0x3ffd82a0 0x4019a8f2:0x3ffd82c0 0x4019a92e:0x3ffd82e0 0x40196f25:0x3ffd8300 0x40199e9d:0x3ffd8320 0x40197e68:0x3ffd8340 0x40196149:0x3ffd8360 0x401b470c:0x3ffd8380 0x401825ad:0x3ffd83a0 0x4018f959: ip4_route at /home/greg/esp/esp-idf/components/lwip/core/ipv4/ip4.c:223 (discriminator 2) 0x4018a5d5: tcp_rst at /home/greg/esp/esp-idf/components/lwip/core/tcp_out.c:1336 (discriminator 4) 0x4018d3eb: tcp_abandon at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d40d: tcp_abort at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d4ae: tcp_netif_ipv4_addr_changed_pcblist at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1630 0x4018d90c: tcp_netif_ipv4_addr_changed at /home/greg/esp/esp-idf/components/lwip/core/tcp.c:1947 0x4018e46a: netif_set_ipaddr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:452 0x4018e4ab: netif_set_addr at /home/greg/esp/esp-idf/components/lwip/core/netif.c:330 0x40196261: cifaddr at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704 0x4019882d: ipcp_clear_addrs at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2192 0x40198874: ipcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:2156 0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146 0x40198764: ipcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ipcp.c:687 0x4019a8f2: upper_layers_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:715 0x4019a92e: link_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/auth.c:701 0x40196f25: lcp_down at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:2341 0x40199e9d: fsm_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/fsm.c:146 0x40197e68: lcp_lowerdown at /home/greg/esp/esp-idf/components/lwip/netif/ppp/lcp.c:485 0x40196149: ppp_close at /home/greg/esp/esp-idf/components/lwip/netif/ppp/ppp.c:704 0x401b470c: pppapi_do_ppp_close at /home/greg/esp/esp-idf/components/lwip/api/pppapi.c:355 0x401825ad: tcpip_thread at /home/greg/esp/esp-idf/components/lwip/api/tcpip.c:474 Rebooting...

7 21

Re: [Ovmsdev] Problems with IncomingFrameCan when registering two can buses.
by Tom Parker 31 Dec '17

31 Dec '17

I am successfully using can2 to transmit commands to the Nissan Leaf (the 2016 model year moved those functions to a different can bus). I'm not trying to listen on that bus yet, but I will soon. I'll check if the receive counters stop later today.

1 0

CANopen master framework
by Michael Balzer 30 Dec '17

30 Dec '17

Hi everyone, I've extended my CANopen master implementation from the Twizy module to become a general service on v3. I've had some looks at existing other open source CANopen frameworks, but neither of them fulfilled my wishes regarding API, FreeRTOS integration and IPC. As framework integration was about to be the largest part of the v3 adaptation anyway I decided to do this from scratch. It's only been tested on my Twizy (SEVCON Gen4) yet. It's the only CANopen device I have access to, so I'd appreciate some more tests with other CANopen devices. Some first documentation is under canopen/doc, I'll add to this as necessary and also will add some section to the developer manual. https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/tree/maste… Audits & comments are welcome. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0