July 2018 - OvmsDev - Open Vehicles

Production batch 2 and onwards
by Mark Webb-Johnson 30 Aug '18

30 Aug '18

FYI The order for production batch #2 has just been placed: 50x US kits (module + US 3G modem + Hologram sim) 150x EU kits (module + EU 3G modem + Hologram sim) 20x modules only (board + case, but no modem) 5x EU 3G modems (incl. Hologram sim) 5x US 3G modems (incl. Hologram sim) No change to specification and board layout from the first production batch, except to re-iterate the points that came in from feedback. We are arranging a foam box to ship the modules in, with our logo on it, to avoid the issues with sticky glue on those padded bags. Availability at Fasttech perhaps in about 3 weeks time. Our deadline for firmware is about 10 days. This is a lot of $$$ upfront payment, and the project is pretty tapped financially (I’ve had to pay for most of this myself). Once the money from sales starts to come in, we’ll be better off. I have quotes from certification labs for CE and FCC certs, and it seems possible. They say we may have some small changes to make (ESD primarily), but overall our design seems fine and they are confident we can achieve the certification. The process is expensive, but is just a one off upfront payment. Current plan is to start with that process once we have this production batch built and at Fasttech. We did consider doing this before this production batch #2, but that would have just delayed things several months. So long as this certification process doesn’t drag on, we should be able to keep OVMS v3 in stock and available from now. Regards, Mark.

3 15

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

Porting code from v2 to v3
by Nikolay Shishkov 04 Aug '18

04 Aug '18

Hi, I am working on the Think City EV code and have some questions.- what is the best way to signal that the charging connector is plugged? ms_v_charge_pilot?previously it was cardoorbits1. - what is the best way to compare OvmsMetricStrings? Or should I dublicate the state in an enum and use that? - what is the best way to compare the OvmsMetricFloat to a literal float? - what is the current way of doing net_req_notification Thanks in advance,Nikolay On Tuesday, July 17, 2018, 3:37:49 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Jacob, > Is there a reason why OVMS bundles three different SSL libraries? I think wolfSSL is there (but WOLFCRYPT_ONLY) because wolfSSH needs it. The ESP-IDF offers mbedtls and openssl libraries, but we don’t currently use either. > Also why is there a custom HTTP implementation when mongoose already has one? Primarily because we wrote those before we included mongoose into the project. But also because the mongoose http_client code sucks. It reads the entire message body into RAM, before passing it on to the client; that just won’t work for something like a firmware image. To complicate the choice further, ESP now includes a esp_http_client in their latest 3.x IDF (which wasn’t there before). I did try to convert our TCP and HTTP client libraries to mongoose a while ago, but failed. Those libraries are blocking (with i/o done in the context of the thread calling them), but the mongoose library is event-based non-blocking (with i/o output in the context of the calling thread, and i/o input in the context of the mongoose thread). Mongoose didn’t use to be thread safe, and that caused us all sorts of issues (now solved, by the work Michael and others did to make it thread safe). > IMO the best way would be to rewrite ovms_net and > ovms_http to use mongoose and configure mongoose to compile with SSL > support (probably mbedtls as the other two don't work). I agree. In general, I prefer the mongoose approach, and we are trying to standardise on that (for good or bad). Probably the best would be to fix the http client in mongoose to work properly (or at least have an option to deliver the body block by block as they arrive), then convert our stuff that uses ovms tcp/http libraries, then drop the tcp and http libraries. Not trivial given the different models (blocking vs non-blocking events). Between openssl vs mbedtls, I don’t really care. I think we’re going to have to manage certificate loading ourselves anyway (as we need to load from a combination of statically defined (in flash using COMPONENT_EMBED_TXTFILES and asm(“_binary_* start/end) and dynamic (in /store/tls/trustedca/* or somewhere like that). Regards, Mark. > On 17 Jul 2018, at 1:02 AM, Jakob Löw <ovms(a)m4gnus.de> wrote: > > Hey, > > I've been playing around a bit with implementing SSL/TLS support. For > starters I wanted to implement an OvmsNetTlsConnection class which > could then be used for https requests. At first I tried using wolfSSL > but it turns out wolfSSL is compiled with WOLFCRYPT_ONLY. OpenSSL also > didn't work as SSL_CTX_load_verify_locations is missing in ESP-IDF's > OpenSSL. I didn't try mbedtls yet. Is there a reason why OVMS bundles > three different SSL libraries? Also why is there a custom HTTP > implementation when mongoose already has one? Speaking of mongoose, it > seems to have an abstraction layer which allows to use one of the three > SSL/TLS libraries. IMO the best way would be to rewrite ovms_net and > ovms_http to use mongoose and configure mongoose to compile with SSL > support (probably mbedtls as the other two don't work). > > - Jakob > > On Mon, 2018-07-16 at 12:47 +0800, Mark Webb-Johnson wrote: >> Drupal authentication is done, and working against mosquitto now on >> the live api.openvehicles.com site. Plain text MQTT only at the >> moment (I still need to get mosquitto and OVMS module firmware >> supporting SSL). >> >> To configure OVMS v3 to use Server V3 protocol: >> >> config set: >> vehicle id <vehicleid> >> server.v3 server api.openvehicles.com >> server.v3 port 1883 >> server.v3 user <openvehicles.com username> >> password server.v3 <openvehicles.com password> >> >> server v3 start >> >> Can also 'config set auto server.v3 yes’ to auto-start at boot >> >> If you have an MQTT client, you can connect to the same server to >> query the metrics, issue commands, etc. The default topic hierarchy >> is ovms/<username>/<vehicleid>. >> >> I think we are close now. Just need SSL support. And then Apps… >> >> Feedback appreciated. >> >> Regards, Mark. >> >>> On 10 Jul 2018, at 2:42 PM, Mark Webb-Johnson <mark(a)webb-johnson.ne >>> t> wrote: >>> >>> I’ve just pushed the support for notifications in OVMS Server v3. >>> >>> With that, the server v3 is functionally complete (at least on the >>> car side). We can: >>> >>> Connect/disconnect >>> Handle lists of apps connecting/disconnecting >>> Send metrics >>> Send events >>> Send notifications (including info, error, alert, and historical >>> data) >>> Receive commands, run them, and return the results >>> >>> I’m still struggling against drupal authentication at the server >>> side; once that is done we can open this up to wider testing. >>> >>> Overall, I’m pretty happy with it. We need SSL/TLS support, but at >>> least functionally now it works and is complete. >>> >>> Regards, Mark >>> >>>> On 6 Jul 2018, at 4:16 PM, Mark Webb-Johnson <mark(a)webb-johnson.n >>>> et> wrote: >>>> >>>>>>> I suppose the following topic names: >>>>>>> metrics: <prefix>/metric/# >>>>>>> events: <prefix>/event/# >>>>>>> notifications: <prefix>/notify/# >>>>>>> config: <prefix>/config/# >>>>>>> logs: <prefix>/log/<tag> >>>>>>> active: <prefix>/client/<clientid>/active >>>>>>> requests: <prefix>/client/<clientid>/request/# >>>>>>> commands: <prefix>/client/<clientid>/command/<command >>>>>>> id> >>>>>>> cmd responses: <prefix>/client/<clientid>/response/<command >>>>>>> id> >>>>>> >>>>>> All ok. I am fine with this, and looks clean. I will make the >>>>>> changes today, as I want to get this into some cars asap so >>>>>> we can get a feel for how it behaves. >>>> >>>> Ok. Now implemented, and tested: >>>> >>>> <prefix>/metric/# >>>> <prefix>/client/<clientid>/active >>>> <prefix>/client/<clientid>/command/<command id> >>>> <prefix>/client/<clientid>/response/<command id> >>>> >>>> I don’t think config, logs, and requests are critical or urgent. >>>> So, I will try to finish events tonight (as that is relatively >>>> simple). Notifications over the weekend (more tricky, especially >>>> for historical data). It can go in my car with tonight’s nightly >>>> ota, for real world testing. >>>> >>>> I’m still trying to get the authentication working for drupal vs >>>> mosquitto. Once that is done, I can open up >>>> api.openvehicles.com MQTT for public use. If I can’t get it done >>>> within the next couple of days, I’ll try another broker (lua >>>> scripting, anyone?). >>>> >>>> P.S. Commands over MQTT are pretty cool: >>>> >>>> <PastedGraphic-2.tiff> >>>> <PastedGraphic-3.tiff> >>>> >>>> Regards, Mark. >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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

3 18

3.1.007 OTA
by Mark Webb-Johnson 30 Jul '18

30 Jul '18

On my devices I’m seeing a problem with doing OTA updates when running 3.1.007. I’m seeing: OVMS# ota flash http Current running partition is: factory Target partition is: ota_0 Download firmware from api.openvehicles.com/firmware/ota/v3.1/edge/ovms3.bin to ota_0 Expected file size is 2850336 Preparing flash partition... abort() was called at PC 0x401b8e84 on core 0 0x401b8e84: pm_on_beacon_rx at ??:? Backtrace: 0x40091e6b:0x3ffcc4a0 0x40091fc3:0x3ffcc4c0 0x401b8e84:0x3ffcc4e0 0x401b94ef:0x3ffcc520 0x401b9bd1:0x3ffcc550 0x40089e62:0x3ffcc5a0 0x40091e6b: invoke_abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x40091fc3: abort at /Users/mark/esp/esp-idf/components/esp32/panic.c:669 0x401b8e84: pm_on_beacon_rx at ??:? 0x401b94ef: ppRxProtoProc at ??:? 0x401b9bd1: ppRxPkt at ??:? 0x40089e62: ppTask at ??:? (this is a firmware rebuild so addresses may vary from stock 3.1.007, but the functions are the same) The pm_on_beacon_rx function is in libpp (as are ppRxProtoProc, ppRxPkt, and ppTask. If I comment out the esp_ota_* functions, it does the download and works fine. But if esp_ota_begin is called, then the crash occurs within http.BodyRead. (although I think it is within the ppTask, not in our code). It I reduce the size parameter given to esp_ota_begin, I can get it to work just fine. Around 1.5MB is fine, but above that is starts to get flaky. Espressif say that during flash writes the cache must be disabled, so all access to SPIRAM halted. Sometimes, I get to see a message 'I (20642) wifi: bcn_timout,ap_probe_send_start’ which seems to confirm the wifi task is being starved for cpu time during the esp_ota_begin(). I guess that is triggering a bug within the wifi stack where it doesn’t handle it gracefully. I then tried hacking around the esp_ota_begin() function. The Espressif implementation simply calls esp_partition_erase_range() to erase the partition in one call. For us, that now means blanking 2.8MB of flash and takes about 15 seconds or so. I changed that to call esp_partition_erase_range() multiple times, in 256KB chunks, with a 10ms vTaskDelay between each chunk. Problem solved. OTA works again doing it that way. I’m not sure how to get this fix applied. The issue is in Espressif’s code, related to big partition sizes. I guess they haven’t seen it because with 1MB OTA partitions the delay is only 3 seconds or so and probably not long enough to trigger the issue. I’ll raise a bug report with them, but suspect it will be a while for them to address it. As a temporary workaround for us, I think I’ll bring esp_ota_begin() into our ovms_ota code and customise it there specifically for us. We can always switch back to the normal esp_ota_begin when/if Espressif come up with a permanent solution. I don’t really want to change that core Espressif code, without direction from Espressif as to how to change it (been there, done that, and wasted a lot of time doing it). For safety, I’ve rolled back edge to 3.1.006-15-g14b8eb6. That will stop new deployments of this, while we solve the problem. For existing deployments in the field, I can only think of two solutions: (a) switch ota to factory, reboot, and flash to fixed code, or (b) ota from sdcard, with wifi unused/off. I should have the fix later today. Regards, Mark.

4 8

CAN bus hacking
by Mark Webb-Johnson 27 Jul '18

27 Jul '18

For those of us working on vehicle support, I am concentrating on the last pieces for Tesla Roadster, ongoing work on Tesla Model S, and helping out Chris (in AU) to try to get Volt/Ampera ported (he has the car, I don’t). We have a lot of users waiting for Volt/Ampera support. For all of this, I’m trying to extend the RE tools and CAN frameworks to allow for OVMS to be used for CAN bus analysis and simulation. It is really coming together nicely, and it looks like the system is powerful enough to handle this admirably. I’m trying hard not to plug a USB-CAN adaptor into my car, or use any other desktop tools. This should bring the barrier to entry right down for new vehicle support. A few examples… Using ‘can rx’ to simulate an incoming CAN bus message and see what happens to metrics: OVMS# metrics trace on Metric tracing is now on OVMS# vehicle module VA I (26522) v-voltampera: Volt/Ampera vehicle module I (26522) metrics: Modified metric v.type: VA I (26582) metrics: Modified metric v.e.parktime: 26Sec I (27582) metrics: Modified metric v.e.parktime: 27Sec I (28582) metrics: Modified metric v.e.parktime: 28Sec OVMS# can can1 rx standard 135 01 I (49462) metrics: Modified metric v.e.on: yes I (49462) metrics: Modified metric v.e.awake: yes I (49462) metrics: Modified metric v.e.handbrake: no I (49582) metrics: Modified metric v.e.parktime: 0Sec OVMS# can can1 rx standard 4e1 42 55 31 30 32 36 38 39 OVMS# can can1 rx standard 514 47 31 52 44 36 45 34 36 I (94402) metrics: Modified metric v.vin: 1G1RD6E46BU102689 OVMS# can can1 rx standard 135 00 I (103342) metrics: Modified metric v.e.on: no I (103342) metrics: Modified metric v.e.awake: no I (103342) metrics: Modified metric v.e.handbrake: yes I (103582) metrics: Modified metric v.e.parktime: 1Sec I (104582) metrics: Modified metric v.e.parktime: 2Sec I (105582) metrics: Modified metric v.e.parktime: 3Sec I (106582) metrics: Modified metric v.e.parktime: 4Sec I (107582) metrics: Modified metric v.e.parktime: 5Sec I (108582) metrics: Modified metric v.e.parktime: 6Sec I (109582) metrics: Modified metric v.e.parktime: 7Sec I (110582) metrics: Modified metric v.e.parktime: 8Sec Showing CAN message changes, and discovering new messages (or bytes within that were not previously changing but now are): OVMS# re start OVMS# re mode analyse Now running in analyse mode OVMS# can can1 rx standard 100 01 02 03 04 OVMS# can can1 rx standard 101 01 02 03 04 OVMS# can can1 rx standard 102 01 02 03 04 OVMS# re discover list changed key records ms last can1/100 1 8000 01 02 03 04 | .... can1/101 1 8000 01 02 03 04 | .... can1/102 1 8000 01 02 03 04 | .... OVMS# re discover clear changed Cleared all change flags OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list changed key records ms last can1/102 2 15500 01 02 13 04 | .... OVMS# re mode discover Now running in discover mode OVMS# can can1 rx standard 102 01 02 13 04 OVMS# re discover list discovered key records ms last OVMS# can can1 rx standard 102 01 12 13 04 OVMS# re discover list discovered key records ms last can1/102 4 14500 01 12 13 04 | .... OVMS# can can1 rx standard 110 01 02 03 04 OVMS# re discover list discovered key records ms last can1/102 4 17500 01 12 13 04 | .... can1/110 1 70000 01 02 03 04 | .... A CRTD format can bus dump: I (372613) re: Log service connection from 10.8.8.83 OVMS# can can1 rx standard 120 01 02 03 04 OVMS# can can1 rx standard 121 01 02 03 04 OVMS# can can1 rx standard 121 DE AD BE AT I (466333) re: Log service disconnection from 10.8.8.83 $ telnet devbench.local 3000 Connected to devbench.local. 1524105901.244120 1R11 120 01 02 03 04 1524105905.794094 1R11 121 01 02 03 04 1524105915.194145 1R11 121 de ad be at The TODO list for this is huge, so it will progress as I have time to work on it (and as I hit a requirement for each unfinished part). For example, simulating CAN bus traffic (replaying) would be nice (something like ‘$ cat mylogfile.crtd | nc devbench.local 3000’) - and that is something I need now, so will probably come next (and is pretty trivial - just pickup on data coming in the tcp/3000, decode it, and either simulate reception or transmit it on the actual car bus). The whole decoding/encoding thing (where we use DBC or whatever to say key X byte Y is converted to v.bat.soc using this formula) is of course the holy grain of this; and is built upon all the foundation I’m laying now. The end goal remains for vehicle modules with just a DBC (or whatever) and no actual code. It is all command line at the moment, but this could be very very cool using Michael’s web framework (particularly with real-time websocket updates). Regards, Mark.

2 6

nmc_list and ListConnections
by Mark Webb-Johnson 27 Jul '18

27 Jul '18

I am seeing quite a few crashes from my modules, like this: # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-76-ga33b30e.ovms3.elf 0x4008fac5 0x40090355 0x4008f23f 0x400914a1 0x40083e6a 0x4020c6b3 0x400f514d 0x400f69cb 0x400f6d95 0x400f705f 0x400f3cba 0x400eafe6 0x400eb035 0x4008fac5: uxPortCompareSet at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:3564 (inlined by) vPortCPUAcquireMutexIntsDisabledInternal at /home/openvehicles/build/esp-idf/components/freertos/portmux_impl.inc.h:86 (inlined by) vPortCPUAcquireMutexIntsDisabled at /home/openvehicles/build/esp-idf/components/freertos/portmux_impl.h:98 (inlined by) vTaskEnterCritical at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:4267 0x40090355: xTaskIncrementTick at /home/openvehicles/build/esp-idf/components/freertos/tasks.c:3564 0x4008f23f: xPortSysTickHandler at /home/openvehicles/build/esp-idf/components/freertos/port.c:406 0x400914a1: _frxt_timer_int at /home/openvehicles/build/esp-idf/components/freertos/portasm.S:303 0x40083e6a: _xt_lowint1 at /home/openvehicles/build/esp-idf/components/freertos/xtensa_vectors.S:1105 0x4020c6b3: esp_vApplicationWaitiHook at /home/openvehicles/build/esp-idf/components/esp32/freertos_hooks.c:66 0x400f514d: mg_sock_addr_to_str at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f69cb: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f6d95: mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f705f: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f3cba: mg_add_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400eafe6: OvmsNetManager::ListConnections(int, OvmsWriter*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:685 0x400eb035: OvmsNetManager::CloseConnection(unsigned int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:702 [root@markhk8 edge]# xtensa-esp32-elf-addr2line -pfiaC -e 3.1.008-76-ga33b30e.ovms3.elf 0x400f6893 0x400f7edc 0x4011e623 0x4011e729 0x4011e9e2 0x400f8306 0x400f514d 0x400f69cb 0x400f6d95 0x400f705f 0x400f3cba 0x400eafe6 0x400eb035 0x400f6893: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f7edc: mg_send_mqtt_handshake_opt at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x4011e623: OvmsServerV3::Ticker1(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:841 0x4011e729: OvmsServerV3::IncomingPubRec(int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:488 0x4011e9e2: OvmsServerV3MongooseCallback(mg_connection*, int, void*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_server_v3/src/ovms_server_v3.cpp:66 0x400f8306: parse_mqtt at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 (inlined by) mqtt_handler at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:10606 0x400f514d: mg_sock_addr_to_str at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f69cb: mg_http_handler2 at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f6d95: mg_mgr_handle_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f705f: mg_socket_if_poll at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400f3cba: mg_add_conn at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701 0x400eafe6: OvmsNetManager::ListConnections(int, OvmsWriter*) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:685 0x400eb035: OvmsNetManager::CloseConnection(unsigned int) at /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:702 Apart from the massive stack, it seems very strange that we would be calling OvmsNetManager::ListConnections() and CloseConnection(). I guess the stack is messed up, or this is some other remnant of a previous call? Any ideas? Mark

2 1

Linker error: uxTaskGetSystemState
by Geir Øyvind Vælidalo 25 Jul '18

25 Jul '18

Hi guys! I got the latest from master and also did pull the latest from esp-idf, but when I run make I get this linker error: ylfest:OVMS.V3 goev$ make LD build/ovms3.elf /Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/main/libmain.a(ovms_utils.o):(.literal._Z13TaskGetHandlePKc+0x4): undefined reference to `uxTaskGetSystemState' /Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/main/libmain.a(ovms_utils.o): In function `TaskGetHandle(char const*)': /Users/goev/esp/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:159: undefined reference to `uxTaskGetSystemState' collect2: error: ld returned 1 exit status make: *** [/Users/goev/git/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf] Error 1 Any ideas? Best regards, Geir

2 1

CAN throughput & latency optimization
by Michael Balzer 23 Jul '18

23 Jul '18

I've pushed my latest changes to optimize CAN throughput & latency, which had problems before and have become worse with aggressive SPIRAM usage. There especially were too many RX overflows and TX delays now. The Twizy module needs to respond to some frames as fast as possible, and the delays added up to over 120 ms in some circumstances. I first moved the esp32can ISR and instance into internal RAM, then applied that change to all peripheral objects. To allocate objects of some class in internal RAM, simply add the super class InternalRamAllocated to it (counterpart to ExternalRamAllocated), i.e. class SevconClient : public InternalRamAllocated This eliminated RX overflows (except some on init when starting the module/bus with running transmissions on the bus -- don't know yet if we can avoid them), and helped a bit with TX delays. Moving the vehicle instance into internal RAM also helped a bit with TX latency, but together only reduced it by about 10%. So I also added a synchronous callback mechanism to the CAN system to be able to run a CAN responder directly within the CAN rxtask context. See the Twizy CanResponder() in module rt_can for an example: void OvmsVehicleRenaultTwizy::CanResponder(const CAN_frame_t* p_frame); MyCan.RegisterCallback(TAG, std::bind(&OvmsVehicleRenaultTwizy::CanResponder, this, _1)); This reduced TX delays to zero most of the time. From time to time some delays still occurred, not continously but in chunks and only every few minutes. I think they were caused by the Wifi stack, because they seem to have disappeared after rearranging the CAN rxtask to be running at priority 23 and reducing the Wifi task priority to 22, but I need to collect some more data on this. The new build is in my "edge" directory. Placing the peripherals in internal RAM potentially solves other issues as well -- it's certainly not good if a peripheral component has to wait for an SPIRAM page-in operation. But I've had no reproducable issues before I could test now. We need to test this in the field. Regarding the issues with can2 & can3: I don't think they are related to this, but it's worth a try. The mcp2515 instances are in internal RAM now as well. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

UDS/ISO-TP Query
by Fran Terry 19 Jul '18

19 Jul '18

Hello One & All, I am in the process of getting the smart ED (451) working on v3, have not had an issue getting data out via normal PID requests. However I am having issues with talking to the BMS & Charger, it might me being a noob, but I can't work out the best way to do UDS/ISO-TP. For instance I need to send the following packet to: 0x7E7 03 22 02 08 FF FF FF FF I need to then pick up the following from 0x7EF: 11 93 62 02 08 0E A7 0E I also need to send flow control frames, basically speak ISO-TP. I can see in the TR code how to send a frame via CAN, however not sure how to pick up the response and talk ISO-TP Hope that makes sense, Thanks Fran

2 1

Module passwords shorter than 8 characters
by Nikolay Shishkov 12 Jul '18

12 Jul '18

Hi all, I have managed to install 2 V.3 boxes on two Think City A306 and the basic functionality works great - I am able to see the SOC, position, battery temperature. I will be measuring power consumption and look at logging and adding more parameters in near future. I had a few wows that came from me not reading documentation and one that I could not find in the documentation. The undocumented one was that I was able to set password to "test" - it was just for testing on the bench, and I was no longer able to find the access point... when I connected via usb cable and terminal I could see that the process for the AC was complaining that the module password was too short and aborted startup. I haven't tested this in the latest update, but wanted to put it out there in case any of you run in to it. Nikolay On Thursday, July 12, 2018, 11:40:49 AM GMT+2, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: Just seems wasteful to have a dozen metrics for this. Expensive in ram, bandwidth, and mqtt. Every vehicle module would have to set the unused ones to ‘no’ (due to the way mqtt retained topics work). If we add a new capability, all the vehicle modules would have to be changed to set it to ’no'. Your suggestion is cleaner, but more expensive. Regards, Mark. > On 12 Jul 2018, at 5:34 PM, Robin O'Leary <ovmsdev(a)caederus.org> wrote: > > On Thu, Jul 12, 2018 at 08:56:25AM +0800, Mark Webb-Johnson wrote: >> I think the capabilities are useful, but need to be done in a better, more future-proof, way. Relying on protocol v2 commands is limited. > ... >> My suggestion is: >> >> Create a standard metric ‘v.capabilities’. >> Have the vehicle modules set that metric with their capabilities, as a comma-separated list of the commands supported: > > Mapping things to strings seems rather roundabout. > Would it not be better to have individual boolean capabilities? > > v.capability.chargemode = yes/no > ... > v.capability.climate = yes/no > _______________________________________________ > 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

2 2