Hi, I am new here, just received my OVMS device, and started to play with it.I have a couple of questions : 1) Is there anyone around that has started the integration with the Jaguar IPace ? or any JLR products ? 2) I can see that there is multiple CAN bus on the plug (can1, can2, can3). Does the car use the 3 of them, only one, or a mix and we have to listen to all of them ?3) Is there a detailed step-by-step process to start investigating the data on the bus ? I just plug the cable and expected to see "something" in the RE console, in "discover" mode, out of the box, without results. No a good start... :-( Didier
Didier, welcome :-) Am 31.12.20 um 00:52 schrieb didier@ernotte.com:
Hi,
I am new here, just received my OVMS device, and started to play with it. I have a couple of questions : 1) Is there anyone around that has started the integration with the Jaguar IPace ? or any JLR products ?
None that I know of.
2) I can see that there is multiple CAN bus on the plug (can1, can2, can3). Does the car use the 3 of them, only one, or a mix and we have to listen to all of them ?
Please read: https://docs.openvehicles.com/en/latest/crtd/can_logging.html The OBD2 port has only one standard CAN bus (on pins 6+14) which is connected as can1. Manufacturer specific additional buses may be present in your car, it depends on their purposes and your goals if you need to use them. The standard OVMS OBD2 cable connects can2 additionally to pins 12+13, which are used by many manufacturers for a secondary CAN bus. If you need the third CAN bus as well, you'll need to use the DA26 connector. If you need to connect to the K-Line or need a fourth CAN bus, you'll need to add the K-Line or SWCAN extension boards.
3) Is there a detailed step-by-step process to start investigating the data on the bus ? I just plug the cable and expected to see "something" in the RE console, in "discover" mode, out of the box, without results. No a good start... :-(
Sorry, we don't have a reverse engineering guide yet. It's on the list… If you don't know anything about the car, you'll first need to find the right CAN bus and baud rate to access the vehicle (see above). Be aware there may be no regular transmissions on the buses you can access via the OBD port, so simply listening may not be enough. If you can see frames on some buses, using the RE tool is an option. Another is to stream the packets to SavvyCAN for analysis. Both will help you to identify related bits & bytes. Next step is then to find out which metrics and indicators can be read from the frames. Standard procedure is to record changes you see on the bus from actions you do with the car, and to correlate changes you see in the car's displays to those on the bus. Then you need to decode the values, i.e. how to convert the raw values into their respective readings. Next step is checking for OBD2 or CANopen devices on the bus(es). These devices need to be queried actively, so you need to send requests on the bus. For CANopen, read: https://docs.openvehicles.com/en/latest/components/canopen/docs/Howto-detect... We don't have a similar guide for OBD2 yet. Begin by some simple standard broadcasts to see if you get any reaction, for example "obdii can1 request broadcast 0100" asks all broadcast listeners to tell which of the service 01 PIDs in the range 01…20 they support. The responses should give you a hint about the device addresses, so you can investigate specifically. 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": OVMS# re obdii scan start ? Usage: re obdii scan start <bus> <ecu> <start_pid> <end_pid> [-r<rxid>[-<rxid>]] [-t<poll_type>] [-x<timeout>] Give all values except bus and timeout hexadecimal. Options can be positioned anywhere. Default <rxid> is <ecu>+8, try 0-7ff if you don't know the responding ID. Default <poll_type> is 22 (ReadDataByIdentifier, 16 bit PID). Default <timeout> is 3 seconds. Most newer vehicles will support reading 16 bit PIDs by poll type 22. If you're lucky, poll type 24 is supported and gives you info on how to translate the raw values. If not you once again need to monitor the response data, correlate changes to car data updates and actions and find out how to convert the values. Be aware you may need to activate a diagnostic session with a device before actually be able to read data from it. Diagnostic sessions need to be kept alive by either sending the session control request once per minute or activating the "tester present" signal ("re obdii tester"). Once again, you need to find out which session mode you need for a device. You can tell if the device supports a session mode by it's response.
Didier
You'll find more info on CAN reverse engineering and OBD hacking on the web. A good starting point is SavvyCAN. You'll also find more on all of this by browsing the list archives: http://lists.openvehicles.com/pipermail/ovmsdev/ The MG ZS EV team can most probably give you some more valuable hints, as they just recently decoded "their" vehicle. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
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 Feedback is welcome. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, Even if I used to be a good programmer, and I can still read a C++ application even if I did not programmed in C++ since more than 20 years, I've never been a "hacker", so this is quite new to me. I have ran the couple of command you gave me : - the copen scan does not do anything- 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. 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 .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, 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 ?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@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 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
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 ? 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 Didier Le lundi 4 janvier 2021 16 h 07 min 34 s UTC−5, didier@ernotte.com <didier@ernotte.com> a écrit : Hi Michael, Even if I used to be a good programmer, and I can still read a C++ application even if I did not programmed in C++ since more than 20 years, I've never been a "hacker", so this is quite new to me. I have ran the couple of command you gave me : - the copen scan does not do anything- 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. 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 .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, 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 ?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@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 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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Didier, Am 05.01.21 um 21:04 schrieb didier@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@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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
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@expeedo.de> a écrit : Didier, Am 05.01.21 um 21:04 schrieb didier@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@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 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@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
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@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@expeedo.de> a écrit :
Didier,
Am 05.01.21 um 21:04 schrieb didier@ernotte.com <mailto:didier@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@expeedo.de> <mailto:dexter@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@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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 <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 <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)
-
didier＠ernotte.com -
Michael Balzer