[Ovmsdev] Hi from a new comer

Mon Jan 18 02:52:08 HKT 2021

Didier,

great progress, congratulations! Glad I could help :-)

Btw: there's a special UDS request type for a minimal documentation on 
PIDs. The devices of course need to support that request, most don't, 
but maybe you're lucky there on your high end vehicle. To check, pick 
some PID you found, and request the same PID from the same device with 
poll type 24 (ReadScalingDataByIdentifier) instead of type 22 
(ReadDataByIdentifier). If you get some response, I'll help you with 
decoding it.

Regarding VIN and version / device identification data, these are often 
provided by multiple or all devices. Sometimes even in slightly 
different form at multiple PIDs on the same device.

ECU IDs may be using IDs below 700, but that's very rare for OBD/ISO-TP 
devices. The ID encodes the message priority on the bus, the higher the 
ID, the lower the priority. IDs below 700 are normally reserved for high 
priority frames like process data broadcasted regularly by devices (i.e. 
not needing to be requested). CANopen uses IDs in the range 5xx - 6xx 
for their flavor of PIDs (SDOs), and reserves IDs below 500 for process 
data, emergency and synchronisation messages.

You may also have devices using CAN extended frames, or ISO-TP extended 
addressing, or special protocols other than CANopen & OBD/ISO-TP. We 
recently added support for ISO-TP extended addressing, but not yet for 
the RE OBD tools. I just recently learned from the e-Up team, that VW 
vehicles use a proprietary protocol by VW to transport KWP2000 via CAN, 
named "TP2.0" (but having nothing in common with ISO-TP). Oh yes, and of 
course there may still be devices that simply don't speak CAN, but need 
a real K-Line to access.

But chances are you'll find what you need using standard OBD/ISO-TP 
requests, as you already have found thousands of PIDs that way.

Regards,
Michael

Am 17.01.21 um 19:16 schrieb didier at ernotte.com:
> Hi Michael,
>
> Thanks for the info.
>
> SavvyCan was helpful to discover ECU rx/tx ID, and your recent 
> front-end on RE obdii scan is very helpful to discover PID for a 
> specific ECU. I have now thousands of PID and data to decode.
> I found that most of the ECU have a PID for the VIN Number of the car. 
> Is that standard on all car ?
> Are all ECU ID in the 700-7FF range , or it could be outside this range ?
>
> Didier
> Le mardi 5 janvier 2021 16 h 00 min 05 s UTC−5, Michael Balzer 
> <dexter at expeedo.de> a écrit :
>
>
> Didier,
>
> Am 05.01.21 um 21:04 schrieb didier at ernotte.com 
> <mailto:didier at ernotte.com>:
> Hi,
>
> I have found a lot of info like this in the tech doc I have
>
> "
> Using the Jaguar Land Rover approved diagnostic equipment, check 
> datalogger signal – Vehicle Speed (0xDD09) Ensure that vehicle speed 
> is transmitted and updated correctly. Clear the DTCs and retest. If 
> fault persist using the Jaguar Land Rover Approved Diagnostic 
> Equipment, reconfigure the door module with the latest level software. 
> Clear the DTCs and retest
>
> "
>
> What do you think I can do with the info "0xDD09" ? a PID ?
>
> Presumably. Try it. As it's a 16 bit PID, you'll probably need poll 
> type 22, so that would be:
>
> obdii can1 request broadcast 22dd09
>
>
>> The communications networks available on the vehicle are shown below:
>> - High Speed (HS) CAN chassis systems bus

>> - HS CAN body systems bus

>> - HS CAN Human Machine Interface (HMI) systems bus
>> - HS CAN power mode zero systems bus

>> - Flexray

>> - Local Interconnect Network (LIN)

>> - Private bus
>
> That's a log of networks. You probably won't be able to access all of 
> them at the ODB port.
>
>> - the copen scan does not do anything
>
> If it doesn't _do_ anything, you didn't do it right. If it doesn't 
> _find_ anything, you don't have CANopen nodes, so can concentrate on 
> OBD/UDS.
>
>> - the "obdii can1 request broadcast 0100", (and 0120, 0140, 0160, 
>> 0180...) returned a 32 bits that I can decode to identify which PID 
>> is supported, but only one ECU (7df) answered to the broadcast. I 
>> guess there is many other, but they don't respond to the broadcast.
>
> 7DF isn't an ECU, it's the broadcast address. You currently need to 
> enable the CAN logger to see the origin address. It's normal only one 
> device responds to broadcasts. You need to find the other devices by 
> scanning for them.
>
>> I don't understand why the "re obdii scan start 1 7df 0 20" does not 
>> give me an anser for the identifyed PID of the previous "broadcast" 
>> command .
>
> Because you need to specify the RX ID range you're expecting, the PID 
> scanner doesn't set that automatically. In this case, you'd do:
>
> re obdii scan start 1 7df 0 20 -r7e8-7ef
>
> …or…
>
> re obdii scan start 1 7df 0 20 -r600-7ff
>
> …to check for responses outside the standard.
>
>> In the broadcast command, when we send "0100", the first byte seems 
>> to be a "mode", and the second the PID, is it correct ? (as described 
>> in the vehicle.h).
>> I still don't see how I can have a full list of ECU ID, and a full 
>> list of PID for each ECU. Maybe that is why retro engineering is 
>> complex,
>
> That is correct, and you get a full list by scanning.
>
>> I don't also understand the impact of selecting a vehicle in the web 
>> session. Since my Jaguar is not supported yet, I select the OBDII car 
>> , but if I select the nissan leaf, I can see more data, which does 
>> not make sense, unless we ned to "wake up" some ECU in order to pull 
>> some info. Is the OVMS device masking some data in the bus? how can I 
>> see everything on the bus ?
>
> Selecting a vehicle activates the special CAN & OBD handling that is 
> implemented for that vehicle already. Since your car isn't supported, 
> you should select the empty vehicle (code NONE). The OBD vehicle polls 
> some standard PIDs, which can interfere with RE scans.
>
> You can see everything on the bus with the CAN logging & monitoring & 
> streaming commands. See the documentation links I gave you in my first 
> post.
>
> Regards,
> Michael
>
>
>> Thanks for your help.
>> I will definitively take a look at your new page.
>>
>> Didier
>>
>>
>> Le lundi 4 janvier 2021 15 h 28 min 10 s UTC−5, Michael Balzer 
>> <dexter at expeedo.de> <mailto:dexter at expeedo.de> a écrit :
>>
>>
>> Didier,
>>
>> Am 31.12.20 um 10:47 schrieb Michael Balzer:
>> > Most OBD2 devices won't respond to broadcasts though. To identify
>> > them, you need to send a test request to all CAN IDs in your assumed
>> > ID range. The scan tools for this are below "re obdii scan":
>>
>> I've just added a first UI for that scanner:
>> https://docs.openvehicles.com/en/latest/plugin/repidscan/README.html 
>> <https://docs.openvehicles.com/en/latest/plugin/repidscan/README.html>
>>
>> Feedback is welcome.
>>
>>
>> Regards,
>> Michael
>>
>> -- 
>> 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 
>> <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 
>> <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  <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 
> <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/20210117/abccbea0/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210117/abccbea0/attachment-0001.sig>