March 2018 - OvmsDev - Open Vehicles

Time spent in ticker event handlers / new use for housekeeping task
by Michael Balzer 30 Mar '18

30 Mar '18

A question to the FreeRTOS gurus: How much time may we spend in a ticker event handler, or generally a software timer callback, without risking system stability? The FreeRTOS manual explicitly warns about using any kind of blocking calls within the timer service task, as all software timer callbacks are executed in that context: https://freertos.org/RTOS-software-timer.html /"//Timer callback functions execute in the context of the timer service task. It is therefore// /*/essential/*/ //that timer callback functions never attempt to block. For example, a timer callback function must not call vTaskDelay(), vTaskDelayUntil(), or specify a non zero block time when accessing a queue or a semaphore.//"/ The timer service queue currently has 10 slots. That's tunable, but I'm also worried about other system components possibly relying on regular timer periods of higher frequency. My specific issue: I'm producing the notifications from my ticker1 handler. I now found out a simple standard info notification needs already around 10 ms, and my battery status update (15 data messages) needs 60-70 ms. I thought these would run faster, not sure where the time is spent. I'm using the command notifications, nice to use but with quite some overhead of course. So if for example the wifi or bluetooth stack needs a 50 ms timer, that may already be a problem. But do system components use software timers for time critical tasks? The solution would be moving the notification generator to a separate task. A new task would need RAM, but there's also the housekeeping task, which could generally be made available for such needs. It's basically idle after the init process and already has a large stack. I think about adding a callback execution queue to it, so my ticker handler would simply queue the notification generator call there. Thanks, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 5

Website Migration
by Mark Webb-Johnson 30 Mar '18

30 Mar '18

FYI: I will be moving the main www.openvehicles.com and api.openvehicles.com to a new server, tomorrow (30th March 2018) between 01:00UTC and 11:00UTC. During that time window there may be some short periods of unreachability for both www and api services. I will do what I can to minimise that. Regards, Mark.

1 2

Mongoose crash on wifi disconnect
by Michael Balzer 30 Mar '18

30 Mar '18

I just had a wifi disconnect resulting in a mongoose crash. Not sure what disconnect reason 200 is, I don't recall having seen this before. I (724433) wifi: bcn_timout,ap_probe_send_start I (726943) wifi: ap_probe_send over, resett wifi status to disassoc I (726943) wifi: state: run -> init (1) I (726943) wifi: n:1 0, o:1 1, ap:1 1, sta:1 0, prof:1 I (726943) netmanager: Interface priority is pp3 (10.170.195.13/255.255.255.255 gateway 10.64.64.64) I (726953) netmanager: WIFI client down (with MODEM up): reconfigured for MODEM priority I (726953) time: Network was reconfigured: restarting SNTP client I (726953) ovms-server-v2: Network was reconfigured: disconnect, and reconnect in 10 seconds I (726953) ovms-server-v2: Status: Network was reconfigured: disconnect, and reconnect in 10 seconds I (726963) esp32wifi: STA disconnected with reason 200 I (726963) ovms-server-v2: Status: Disconnected I (746153) ovms-server-v2: Connection is ovms.dexters-web.de:6867 test1 I (746153) ovms-server-v2: Status: Connecting...Guru Meditation Error: Core 1 panic'ed (StoreProhibited) . Exception was unhandled. Core 1 register dump: PC : 0x400f7ee6 PS : 0x00060330 A0 : 0x800f8090 A1 : 0x3ffe8a00 0x400f7ee6: mg_send_dns_query at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 A2 : 0x3fff55a8 A3 : 0x3fffbb90 A4 : 0x00000001 A5 : 0x00000000 A6 : 0x00000014 A7 : 0x3ffb10b0 A8 : 0x000000a2 A9 : 0x3ffe89e0 A10 : 0x3ffe8a00 A11 : 0x00000040 A12 : 0x3f40c298 A13 : 0x081d0000 A14 : 0x87725000 A15 : 0x00000000 SAR : 0x00000001 EXCCAUSE: 0x0000001d EXCVADDR: 0x0000000a LBEG : 0x40145ccc LEND : 0x40145ceb LCOUNT : 0x00000000 0x40145ccc: __divdf3 at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S:1454 0x40145ceb: __divdf3 at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libgcc/config/xtensa/ieee754-df.S:1481 Backtrace: 0x400f7ee6:0x3ffe8a00 0x400f808d:0x3ffe8a30 0x400f5eff:0x3ffe8a70 0x400f61c6:0x3ffe8aa0 0x400f74b1:0x3ffe8ad0 0x400f775d:0x3ffe8b10 0x400f3f25:0x3ffe8b60 0x400eb47a:0x3ffe8b80 0x400eb4b9:0x3ffe8bd0 0x400f7ee6: mg_send_dns_query at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f808d: mg_resolve_async_eh at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f5eff: mg_call at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f61c6: mg_if_connect_cb at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f74b1: mg_mgr_handle_conn at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f775d: mg_socket_if_poll at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400f3f25: mg_mgr_poll at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11373 0x400eb47a: OvmsNetManager::MongooseTask() at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:382 0x400eb4b9: MongooseRawTask(void*) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:370 Entering gdb stub now. $T0b#e6GNU gdb (crosstool-NG crosstool-ng-1.22.0-80-g6c4433a) 7.10 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=xtensa-esp32-elf". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/ovms3.elf...done. Remote debugging using /dev/ttyUSB0 0x400f7ee6 in mg_send_dns_query (nc=0x3fff55a8, name=0x3fffbb90 "ovms.dexters-web.de", query_type=1) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11172 11172 msg->transaction_id = ++mg_dns_tid; (gdb) bt #0 0x400f7ee6 in mg_send_dns_query (nc=0x3fff55a8, name=0x3fffbb90 "ovms.dexters-web.de", query_type=1) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11172 #1 0x400f8090 in mg_resolve_async_eh (nc=0x3fff55a8, ev=<optimized out>, data=<optimized out>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:11629 #2 0x400f5f02 in mg_call (nc=0x3fff55a8, ev_handler=0x400f800c <mg_resolve_async_eh>, user_data=<optimized out>, ev=2, ev_data=0x3ffe8aa0) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2285 #3 0x400f61c9 in mg_if_connect_cb (nc=0x3fff55a8, err=0) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2824 #4 0x400f74b4 in mg_mgr_handle_conn (nc=0x3fff55a8, fd_flags=2, now=1522337922.4471409) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3705 #5 0x400f7760 in mg_socket_if_poll (iface=<optimized out>, timeout_ms=250) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3922 #6 0x400f3f28 in mg_mgr_poll (m=0x3ffb411c <MyNetManager+12>, timeout_ms=250) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:2451 #7 0x400eb47d in OvmsNetManager::MongooseTask (this=0x3ffb4110 <MyNetManager>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:382 #8 0x400eb4bc in MongooseRawTask (pvParameters=0x3ffb4110 <MyNetManager>) at /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_netmanager.cpp:370 (gdb) -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Duktape handling of blank metrics?
by Greg D. 29 Mar '18

29 Mar '18

Hi folks, Does anyone know how DukTape scripting handles math with a metric that hasn't been updated yet? I have a short example script in the OBDII ECU documentation which (should) calculate a power-per-speed metric for display on a HUD. Seems like it would be a useful example, and wanted to verify that it actually works. OVMS> vfs cat /store/obd2ecu/10 ret1=OvmsMetricFloat("v.p.speed"); ret2=OvmsMetricFloat("v.b.power"); out = 0.0; if(ret1 > 0) { out=ret2/ret1; } out; I have the module in the my Roadster, and the v.p.speed metric comes up as 0 kph (that's good - it's parked), but the power metric isn't provided by the car, so is blank when listing the metrics. I expected the code to return zero. Instead, executing the script by asking for 'obdii ecu list' causes an immediate crash with a stack overflow in task AsyncConsole. If I initialize the power metric by hand (metric set v.b.power 0), the script runs just fine, returning 0 for the metric. Oddly, when I first set it up on the desk (sans vehicle), so both of the metrics were blank, executing the script didn't cause crash. Is there a way to make the code "Roadster safe", without dummying up the metric in, say, a startup script? Better, is there a fix for DukTape to handle this, or should I just increase the stack size in AsyncConsole? Thanks, Greg

2 9

Hologram Promo Code
by Mark Webb-Johnson 28 Mar '18

28 Mar '18

I’m pleased to announce that Hologram have provided us a promo code, for the OVMS community. It doesn’t require a new account to use (so open for existing users as well as new). Code: OVMS Enter it at checkout to get US$5 of usage free. Please feel free to share this within the OVMS community (I have added it to the www.openvehicles.com <http://www.openvehicles.com/> site, under Account/Vehicles just next to the Fasttech coupon code), but as usual don’t publicly post it. Thanks, Hologram! Regards, Mark.

1 0

v3 hardware disconnecting from v2 server
by Tom Parker 27 Mar '18

27 Mar '18

Hi, I've been struggling for some time with intermittent disconnections from the v2 server. I've switched from hologram to a local cellular provider's sim card, to match my v2 hardware which is very stable and the problem persists. With the car stationary, the connection seems very solid, but on the move, it usually disconnects within half an hour. I'm running 98169d8862db2bbc4bea14d013883f26ee6afb4e (from 2018-01-19) with idf 5bf85d06d8c402fe30ecb1bf9c09d5e69b923b2f and xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz. I tried logging to the sdcard and on my desk powered by USB that seemed to work well, but it didn't work very well (only a few lines logged to the sdcard and then the whole system seemed to crash) when powered from the OBD2 port. I haven't tried to debug that. With the sdcard logging turned off, and logging with minicom I can get good diagnostics. It would appear that the v3 hardware thinks it is still connected and continues to send data, but the v2 server thinks the client has disconnected. I've got ovms logs which have regular lines quoting the local time from the modem, and server logs from the dexters-web server which I think are not UTC. Anyway, 05:47 in the server log corresponds to 17:47 in the ovms v3 log. The relevant lines of the logs are below. On the server log the ovms v3 hardware client is #72 and then #94. We can see the client sent and the server received S messages at :47:15 and :47:32. The client sent more messages that were not received by the server, more than I've transcribed here (full log attached). The server recorded a disconnect at :48:29, but the client recorded the transmission of messages in it's log for minutes after that. I did a simcom status command which reports that everything is connected, and then I pressed the button to reboot the module. The server records a new connection at :54:07 and the messages logged as transmitted on the client start to correspond with the messages logged as received on the server start again. Thoughts on how to proceed? Another oddity not shown here but included in the full logs is that the client sent a lot of D messages shortly after reconnecting. Server Log: 2018-01-26 05:47:15,36664,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96' 2018-01-26 05:47:15,36665,'#72 C rx msg D 128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0' 2018-01-26 05:47:15,36666,'#72 C rx msg L 0,0,0,0,0,0,0,0,0,0,0' 2018-01-26 05:47:15,36667,'#72 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees' 2018-01-26 05:47:32,36717,'#72 C rx msg S 90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96' 2018-01-26 05:48:29,36926,'#72 C got error: Connection reset by peer' 2018-01-26 05:50:08,37206,'#93 A got login' 2018-01-26 05:51:24,37485,'#36 A rx msg A ' 2018-01-26 05:52:53,37742,'#93 A got error: Broken pipe' 2018-01-26 05:52:54,37745,'#72 A got login' 2018-01-26 05:54:07,37937,'#94 C got login' 2018-01-26 05:54:13,37957,'#94 C rx msg S 87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0' 2018-01-26 05:54:13,37958,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,59,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:13,37959,'#94 C rx msg L 0,0,0,0,0,0,104,0,0,0,0' 2018-01-26 05:54:13,37960,'#94 C rx msg W 0,0,0,0,0,0,0,0,0' 2018-01-26 05:54:13,37961,'#94 C rx msg F 3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,1,1,NL,2degrees' 2018-01-26 05:54:15,37964,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,60,28,1,0,0,13.011,0,0,128,0,0' 2018-01-26 05:54:15,37965,'#94 C rx msg D 128,0,5,0,0,33,0,0,104,61,28,1,0,0,13.011,0,0,128,0,0' Serial Console Log: OVMS > I (79663340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79663340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,0,79663,32,1,1,1,12.9231,0,0,128,0,0 I (79663340) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,0,0,0,0,0 I (79663350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,6,1,NL,2degrees OVMS > D (79665360) simcom: rx line ch=3 len=11 : +CSQ: 10,99 D (79665360) simcom: rx line ch=4 len=11 : +CSQ: 10,99 OVMS > D (79674380) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79674390) simcom: rx line ch=4 len=11 : +CSQ: 13,99 OVMS > D (79678420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79678420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:26+52" D (79678420) simcom: rx line ch=3 len=11 : +CSQ: 13,99 D (79678420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79678420) simcom: rx line ch=3 len=2 : OK OVMS > I (79681340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,387.00,96 OVMS > D (79683370) simcom: rx line ch=3 len=10 : +CSQ: 9,99 D (79683370) simcom: rx line ch=4 len=10 : +CSQ: 9,99 OVMS > D (79692410) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79692420) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79708420) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79708420) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:47:56+52" D (79708420) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79708420) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79708420) simcom: rx line ch=3 len=2 : OK OVMS > D (79713470) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79713470) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79716420) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79716420) simcom: rx line ch=4 len=10 : +CSQ: 0,99 OVMS > I (79724340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,392.00,96 I (79724340) ovms-server-v2: Send MP-0 D128,0,5,0,0,33,0,0,55,79724,30,1,1,1,13.022,0,0,128,0,0 I (79724350) ovms-server-v2: Send MP-0 L0,0,0,0,0,0,55,0,0,0,0 I (79724350) ovms-server-v2: Send MP-0 F3.0.0/factory/main build (idf v3.1-dev-217-g5bf85d0) Jan 20 2018 00:49:15,,0,1,NL,2degrees OVMS > D (79738360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79738360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:26+52" D (79738360) simcom: rx line ch=3 len=10 : +CSQ: 0,99 D (79738360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79738360) simcom: rx line ch=3 len=2 : OK OVMS > D (79740490) simcom: rx line ch=3 len=10 : +CSQ: 4,99 D (79740500) simcom: rx line ch=4 len=10 : +CSQ: 4,99 OVMS > I (79741340) ovms-server-v2: Send MP-0 S90,K,0,0,stopped,standard,76,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,388.50,96 OVMS > D (79764490) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79764490) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > D (79768360) simcom: rx line ch=3 len=10 : +CREG: 1,1 D (79768360) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:48:56+52" D (79768360) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79768360) simcom: rx line ch=3 len=23 : +COPS: 0,0,"2degrees",2 D (79768360) simcom: rx line ch=3 len=2 : OK OVMS > D (79773490) simcom: rx line ch=3 len=10 : +CSQ: 3,99 D (79773500) simcom: rx line ch=4 len=10 : +CSQ: 3,99 OVMS > D (79779500) simcom: rx line ch=3 len=10 : +CSQ: 7,99 D (79779500) simcom: rx line ch=4 len=10 : +CSQ: 7,99 OVMS > I (79785340) ovms-server-v2: Send MP-0 S89,K,0,0,stopped,standard,75,0,0,0,0,0,13,21,0,0,0,0,63.36,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,378.00,96 ... OVMS > simcom status SIMCOM Network Registration: RegisteredHome State: NetMode Ticker: 25111 User Data: 0 Mux Open Channels: 4 PPP Connected on channel: #2 PPP Last Error: None GPS: disabled GPS time: disabled NMEA (GPS/GLONASS) Not Connected ... I rebooted the module and it did the normal connection dance ... D (48359) simcom: rx line ch=3 len=29 : +CCLK: "18/01/26,17:53:57+52" ... I (57609) ovms-server-v2: Status: Connecting... OVMS > I (58219) ovms-server-v2: Connection successful I (58219) ovms-server-v2: Status: Logging in... I (58219) ovms-server-v2: Sending server login: MP-C 0 pwLSijW/3qAZ6z0LOBHbGS rnkkhqHUA6zeZqLx1q1Tow== NZLV3 OVMS > I (58889) ovms-server-v2: Got server response: MP-S 0 QTjRAp8ZQPJQV1UXnepldQ w1vWpIrRR9+eot9z3uslgw== I (58889) ovms-server-v2: Server token is QTjRAp8ZQPJQV1UXnepldQ and digest is w1vWpIrRR9+eot9z3uslgw== I (58899) ovms-server-v2: Status: Server auth ok. Now priming crypto. I (58899) ovms-server-v2: Shared secret key is QTjRAp8ZQPJQV1UXnepldQpwLSijW/3qAZ6z0LOBHbGS (44 bytes) I (58899) ovms-server-v2: Status: OVMS V2 login successful, and crypto channel established OVMS > I (59189) ovms-server-v2: Incoming Msg: MP-0 Z4 I (59189) ovms-server-v2: One or more peers have connected I (59339) ovms-server-v2: Send MP-0 S87,K,0,0,stopped,standard,73,0,0,0,0,0,13,21,0,0,0,0,0.00,0,0,0,0,-1,0,0,0,0,0,0,0,0.00,385.50,0

6 72

Size limit on scp
by Mark Webb-Johnson 26 Mar '18

26 Mar '18

@Steve Is there any particular reason for this: $ scp build/ovms3.bin mark@ev914.local:/sd/ovms3.new scp: size unacceptable: 1841760 Can we increase to allow firmware copies to SD? Regards, Mark.

2 3

Leaf Range Calculations
by Tom Parker 25 Mar '18

25 Mar '18

Hi all, I'm looking to rearrange the leaf range calculations in v3 to use Wh per Gid and km/kWh as inputs to the calculations in order to mirror leaf spy. The v2 code used a simpler mile per gid calculation which is basically the same but didn't separate the two constants. LeafSpy appears to have a temperature compensation as well which I haven't yet tried to reproduce. The constants are configurable but question is, what should the default values be? v2's range calculation was based on 84 miles using 281 gids, or 218/135 = 2.08 gids per km. If one gid is 80Wh, then that's 166Wh/km or 6.01km/kWh. 80Wh per Gid and 6.01km/kWh is in the right ballpark, although Nissan's dashboard trip meter says 7.1km/kWh on my car. Does anyone have a reference to a better way to calculate range, or an opinion on what the default values should be in this calculation?

1 0

v3 at fasttech.com
by Michael Balzer 25 Mar '18

25 Mar '18

The v3.1 modules are listed at www.fasttech.com now. Mark, please mail me the coupon code when you get it, users begin asking for it. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

5 9

New Zealand Cellular Frequencies
by Tom Parker 25 Mar '18

25 Mar '18

Hi, In New Zealand we have 3 3G cell phone networks: 2degrees & Vodafone use 900MHz with 2100MHz infill. Spark uses 850MHz with 2100MHz infill. The European v3 modem supports 900MHz & 2100MHz while the US modem supports 850MHz & 1900MHz. I can confirm the European OVMS v3 does not work at all well on Spark's network in Auckland. It works well on 2degrees and I'm assuming also on Vodafone (but I haven't tested). The US OVMS v3 might work on Spark, but I don't know how many places Spark have holes in their 850MHz network that are filled by 2100MHz (possibly no such hole exists). The US model will probably also on Vodafone's 900MHz 2G network (which they say they are keeping up until 2025), but I haven't tested either of these. If you're in New Zealand, you might be able to get away with the US modem on Spark 3G or on Vodafone 2G. Otherwise you'll have to wait for the EU modem to be in stock again.

1 0