[Ovmsdev] signed 2 byte values in poll
Michael Balzer
dexter at expeedo.de
Sun Aug 5 17:32:32 HKT 2018
Nikolay,
> I am getting correct values in the IncomingFrameCan1 version, while the first version returns completely different values.
> Any idea why?
yes:
> void OvmsVehicleThinkCity::IncomingPollReply(canbus* bus, uint16_t type, uint16_t pid, uint8_t* data, uint8_t length, uint16_t mlremain)
> {
> //ESP_LOGI(TAG,"Poll replay arrived %d", pid);
>
> *uint8_t* value = *data;
Regards,
Michael
> And the following code in IncomingFrameCan1:
> case 0x75B:
> if (d[3] == 0x65)
> {
> StandardMetrics.ms_v_charge_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f);
> }
> else if (d[3] == 0x66)
> {
> StandardMetrics.ms_v_inv_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f);
> }
> else if (d[3] == 0x67)
> {
> StandardMetrics.ms_v_mot_temp->SetValue((float)((short) (d[4] << 8) | d[5]) / 100.0f);
> }
> else if (d[3] == 0x68)
> {
> tc_slibatt_temp = (float)((short) (d[4] << 8) | d[5]) / 100.0f;
> }
>
>
> I am getting correct values in the IncomingFrameCan1 version, while the first version returns completely different values.
> Any idea why?
>
> Thanks again,
> Nikolay
>
>
> On Saturday, August 4, 2018, 1:59:03 AM GMT+2, Nikolay Shishkov <nshishkov at 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 at 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 at yahoo.com> <mailto:nshishkov at 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 at yahoo.com> <mailto:nshishkov at 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 at yahoo.com> <mailto:nshishkov at 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 at yahoo.com> <mailto:nshishkov at 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 at webb-johnson.net> <mailto:mark at 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.elf
>>>
>>>
>>> Regards, Mark.
>>>
>>>> On 27 Jul 2018, at 5:51 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180805/8b974ff5/attachment.htm>
More information about the OvmsDev
mailing list