[Ovmsdev] ELM327 codes to

[Michael Balzer]

Soko,

you can currently define up to four poll state times, but you don't need
to, if you don't use them (compiler fills remaining with zero).

The poll state to use is under vehicle control, as you already saw. Poll
state numbers do not have fixed framework semantics (the comment in my
example is just an example).

Btw, you also don't need to restrict your polling to just one list, you
can use PollSetPidList() to switch lists as well -- see
OvmsVehicleRenaultTwizy::ObdRequest() for an example of how to use this
to implement a single manual poll for a command.

Regards,
Michael


Am 26.07.20 um 09:22 schrieb Soko:
> Hello,
>
> Thanks heaps. There is now way I could have figured this out by
> myself. I will give your values a try asap.
>
> You did only 3 entries for the polltime though... As far as I could
> see there are 4 which correspond to the possible parameter values for
> PollSetState(...);
>
> Looking at the other vehicles I haven't seen any automatism the
> PollState is set by the framework. One vehicle uses 0-3 for (off, on,
> moving, charging). So I have to change the Poll-State manually in my
> vehicle implementation, correct?
> In different words: When I only call PollSetState(0); (for early stage
> testing) the polling uses only the first polltime-value. Doesn't
> matter if the car os off/on/...?
>
> thx again
>
> Soko
>
> On 25.07.2020 20:45, Michael Balzer wrote:
>> Soko,
>>
>> 0x22028C isn't a PID, it's an OBD2 command (0x22 = poll extended ID) +
>> the actual register address 0x028C to be polled.
>>
>> And 0x7E5 isn't a header, it's probably the address of the OBD2 device
>> you're polling (txmoduleid) OBD2 is a subset of ISO-TP, in ISO-TP
>> devices can be addressed at any ID and respond at any ID. The OBD2 base
>> protocol defines a broadcast address at 0x7DF, and assigned device
>> addresses in the range 0x7E0 - 0x7E7. Replies shall be sent at the
>> device address + 8, so the reply for a poll to 0x7E5 would normally be
>> coming from 0x7ED (rxmoduleid).
>>
>> That are the basic principles of the OBD2 protocol, see
>> https://en.wikipedia.org/wiki/OBD-II_PIDs#CAN_(11-bit)_bus_format .
>>
>> So your poll could for example be defined as:
>>
>> const OvmsVehicle::poll_pid_t vwup_poll[] = {
>>    // Note: poller ticker cycles at 3600 seconds = max period
>>    // { txid, rxid, type, pid, { period_off, period_drive,
>> period_charge } }
>>    { 0x7E5, 0x7ED, VEHICLE_POLL_TYPE_OBDIIEXTENDED, 0x028C, { 0, 10,
>> 60 } },
>>    { 0, 0, 0, 0, { 0, 0, 0 } }
>> };
>>
>> See vehicle.h for OBD2 commands (poll types) currently supported. See
>> the other vehicles for examples of complex poll definitions.
>>
>> Regards,
>> Michael
>>
>>
>> Am 25.07.20 um 20:09 schrieb Soko:
>>> Heya,
>>>
>>> Another thing I can't figure out at the moment. I have to poll the
>>> VWeUp and I figured out (hopefully) how to do that. But I have no clue
>>> how to translate the "usual" ELM327 Header+PID to one entry for the
>>> OvmsVehicle::poll_pid_t
>>>
>>> The only value I've understood is the polltime. On my OBD2 interfaces
>>> I use a PID of 0x22028C for SoC. But PID is here only 16 bit! Where do
>>> I put the header 7E5? What is txmoduleid and rxmoduleid?
>>>
>>> I can't believe that I'm the first one with this issue ;) Couldn't
>>> find any doc though :(
>>>
>>> So I'm very thankful for any pointing in the correct
>>> direction/doc/example.
>>>
>>> thanks
>>>
>>> Soko
>>>
>>>
>>>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> 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