[Ovmsdev] i-Miev/C-Zero/iOn
Thomas Bergo
thomas.bergo at gmail.com
Sat Jan 25 04:04:54 HKT 2014
Have tested the new 2.6.2 code since yesterday, and so far it's look good.
Needed to move some of the data converting out of the interrupt routine.
Have also added reading of VIN and corrected some error on cars using miles.
Regards, Thomas
2014/1/24 Mark Webb-Johnson <mark at webb-johnson.net>
> Matt,
>
> From a developer's point of view?
>
> No, I haven't updated the developers guide yet. The best (and only)
> example code that uses it is in vehicle_obdii.c.
>
> Rough description is:
>
> To use the new OBDII polling code, create a rom-based structure detailing
> what PIDs you want to poll. For the base obdii vehicle, it looks like this:
>
> rom vehicle_pid_t vehicle_obdii_polls[]
>
> =
>
> {
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x05, { 0, 30, 30 } }, //
> Engine coolant temp
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0c, { 10, 10, 10 } }, //
> Engine RPM
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0d, { 0, 10, 10 } }, //
> Speed
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x0f, { 0, 30, 30 } }, //
> Engine air intake temp
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x2f, { 0, 30, 30 } }, //
> Fuel level
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x46, { 0, 30, 30 } }, //
> Ambiant temp
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIICURRENT, 0x5c, { 0, 30, 30 } }, //
> Engine oil temp
>
> { 0x7df, VEHICLE_POLL_TYPE_OBDIIVEHICLE, 0x02, {999,999,999 } }, // VIN
>
> { 0, 0x00, 0x00, { 0, 0, 0 } }
>
> };
>
>
> It is an array of arrays. Each row is one PID to be polled, and the last
> row should be all zeros. The columns are:
>
> - moduleid (CAN id of the request message)
> - type (see VEHICLE_POLL_TYPE_* in vehicle.h)
> - pid (the PID to be polled)
> - poll time (in seconds, three entries - one for each poll state)
>
>
> The system supports 3 poll states. You can use these how you want, but a
> typical example would be IDLE, CHARGING, DRIVING. These states are
> completely under your control, and allow you to set different poll times
> for different PIDs in different states. By setting poll time to 0, for a
> particular state, you can disable polling. You set the poll state in the
> global vehicle_poll_state variable via the vehicle_poll_setstate() call.
>
> Once you've got everything setup, you need to start the polling, in your
> initialisation function:
>
> vehicle_fn_poll0 = &vehicle_obdii_poll0;
> vehicle_poll_setpidlist(vehicle_obdii_polls);
> vehicle_poll_setstate(0);
>
>
> You tell the poller about you rom poll list with
> vehicle_poll_setpidlist(), and will be called back with poll results via
> the vehicle_fn_poll0() hook.
>
> You will also need to 'tickle' the vehicle_poll_busactive global variable.
> The polling code will stop polling of vehicle_poll_busactive<=0. Normally,
> you would just set this to 60 (seconds) when you want polling to be active,
> and then decrement it in a ticker function (so it decrements to zero and
> stops polling automatically, unless the ticker is reset). Alternatively,
> you can just use it as an on/off switch (1 or 0).
>
> The poll results will be delivered via the vehicle_fn_poll0() hook, in the
> normal way. It is your responsibility to extract the data from the
> can_databuffer as normal.
>
> In the case of multi-message responses (for some poll types like
> VEHICLE_POLL_TYPE_OBDIIVEHICLE), the system will maintain a
> global vehicle_poll_ml_offset variable, recording the current offset and
> vehicle_poll_ml_remain recording the number of bytes remaining. See the
> example in vehicle_obdii.c for how to handle this:
>
> case 0x02: // VIN (multi-line response)
> for (value1=0;value1<can_datalength;value1++)
> {
> car_vin[value1+(vehicle_poll_ml_offset-can_datalength)] =
> can_databuffer[value1];
> }
> if (vehicle_poll_ml_remain==0)
> car_vin[value1+vehicle_poll_ml_offset] = 0;
>
>
> This is a base framework, that can be extended over time (as different
> vehicles use different polling frameworks). It does remove the majority of
> the tedious polling work from
>
>
> Hope the above helps. I'll use it as the basis for the developer's guide
> update.
>
> Regards, Mark.
>
> On 23 Jan, 2014, at 10:34 pm, Matt Beard OVMS <smvo at mxf.org.uk> wrote:
>
> Is there an simple explanation somewhere of the change to the polling
> system?
>
> Matt Beard
>
>
>
> On 23 January 2014 12:11, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
>> Michael,
>>
>> Yep, that’s it.
>>
>> Problem is OVMS_POLLER is a compile-time definition, so it must be shared
>> by all cars in the configuration. I’ve re-worked it slightly to call the
>> poll0 function even there is no poll list defined:
>>
>> diff --git a/vehicle/OVMS.X/vehicle.c b/vehicle/OVMS.X/vehicle.c
>> index 9c1e9d9..a706bf1 100644
>> --- a/vehicle/OVMS.X/vehicle.c
>> +++ b/vehicle/OVMS.X/vehicle.c
>> @@ -295,15 +295,21 @@ void high_isr(void)
>> can_databuffer[7] = RXB0D7;
>> RXB0CONbits.RXFUL = 0; // All bytes read, Clear flag
>> #ifdef OVMS_POLLER
>> - if ((vehicle_poll_plist != NULL)&&
>> - (can_id >= vehicle_poll_moduleid_low)&&
>> - (can_id <= vehicle_poll_moduleid_high))
>> + if (vehicle_poll_plist != NULL)
>> {
>> - if (vehicle_poll_poll0())
>> + if ((can_id >= vehicle_poll_moduleid_low)&&
>> + (can_id <= vehicle_poll_moduleid_high))
>> {
>> - vehicle_fn_poll0();
>> + if (vehicle_poll_poll0())
>> + {
>> + vehicle_fn_poll0();
>> + }
>> }
>> }
>> + else
>> + {
>> + vehicle_fn_poll0();
>> + }
>> #else // #ifdef OVMS_POLLER
>> vehicle_fn_poll0();
>> #endif //#ifdef OVMS_POLLER
>>
>>
>> I hope this fixes it.
>>
>> Thomas: Can you try to build this version (it is in github master now).
>>
>> Regards, Mark.
>>
>> On 23 Jan, 2014, at 4:29 pm, Michael Balzer <dexter at expeedo.de> wrote:
>>
>> Mark,
>>
>> if the Mitsubishi code does not use the new polling hooks, poll0() will
>> not be called if the polling code is compiled in.
>>
>> I had the same problem for the Twizy, that's why I introduced the
>> OVMS_POLLER compiler switch.
>>
>> Regards,
>> Michael
>>
>>
>> Am 22.01.2014 02:18, schrieb Mark Webb-Johnson:
>>
>> Thomas,
>>
>> Strange. So far, I see 4 cars using 2.6.2, but only one (presumably
>> yours) is showing authentication errors.
>>
>> I also can't see any changes to the vehicle_mitsubishi.c code that
>> would cause poll0 to stop working. It is certainly working in other vehicle
>> modules.
>>
>> I'll keep looking, but would be grateful if you could try to narrow
>> down the poll0 problem.
>>
>> Regards, Mark.
>>
>> On 22 Jan, 2014, at 5:00 am, Thomas Bergo <thomas.bergo at gmail.com>
>> wrote:
>>
>> Mark,
>>
>> Was testing the new 2.6.2 code on i-Miev today.
>>
>> Two observations:
>> - Lots of restarts and "Vehicle authentication failed" messages in the
>> iOS app
>> - No CAN bus messages form PID in poll0, while messages in poll1 is
>> working OK.
>>
>> Programmed the OVMS module with a version, and verified that the module
>> was OK.
>>
>> Regards, Thomas
>>
>>
>> 2013/10/30 Thomas Bergo <thomas.bergo at gmail.com>
>>
>>> Matt,
>>>
>>> Please report back when you have done some testing on the QC.
>>>
>>> If the car report 0A while QC, the current code will not detect that
>>> we are charging. So then we need to rely on the estimated range reported as
>>> 255 to detecting that the car is QC.
>>>
>>> Regards, Thomas
>>>
>>>
>>> 2013/10/30 Matt Beard OVMS <smvo at mxf.org.uk>
>>>
>>>> Hi Thomas,
>>>>
>>>> During QC you don't get valid values reported in 0x389 - it seems to
>>>> be constant 255V, 0A during QC.
>>>>
>>>> My code is relying on the fact that the estimated range only ever
>>>> seems to be reported as 255 during QC (except for the first few messages at
>>>> startup, but those are easy to filter out). In my testing so far this seems
>>>> to work for detecting the start and end of QC. I am going to be doing 3
>>>> more tests today with my latest code and will report back later.
>>>>
>>>> Matt
>>>>
>>>>
>>>>
>>>> On 27 October 2013 20:13, Thomas Bergo <thomas.bergo at gmail.com> wrote:
>>>>
>>>>> Hi Matt
>>>>>
>>>>> I have started to look into the QC code. And i have one concern.
>>>>> Have you seen if the voltage and charging current (PID 0x389) is
>>>>> reported during QC?
>>>>> If not, we are not able to detect that the car is charging during QC
>>>>> with current code.
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>
>>>>
>>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing listOvmsDev at lists.teslaclub.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> --
>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>
>> <dexter.vcf>_______________________________________________
>>
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20140124/1d78746b/attachment.htm>
More information about the OvmsDev
mailing list