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