It may be a stupid question, but I was not able to locate the documentation for the commands that can be used in the shell.
Some commands are trvial but for example the RE enviroment is not that straight forward, at least for me. Is there a place here or on Github where I can find some documentation on commands and their arguments ?
Help on documentation is very welcome.
Most commands try to explain themselves briefly when called with "?". For complex features, a section is meant to be added to the user guide. That can be done very easily by adding RST files to the component, but many developers tend to see that as optional work for technical tools, or as something that should be done later (when all features have been implemented).
The RE toolkit, although without substantial changes lately, is still marked as work in progress. You can find info on the usage in the developer mailing list archives, but you will probably need to read the source to find all details.
Regards,
Michael
Can you give me a link for the developer mailing list archive ?
Connect with us
Connect to other OVMS developers using our mailing list
http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Yeah this is one of my great frustrations too. Typing ? and getting an answer is nice but it's not exactly a look-uppable solution. A simple document with all the commands and all the parameters would be great. I'd be happy to help put that together if someone hands me the 'data'
I think it would be hard to have a single document for this. Even harder to maintain it.
The OVMS system is modular, with each module typically maintained by different developers. The documentation is in RST format and is built into the docs.openvehicles.com site automatically (hooked into the github commit cycle).
Anyone contributing to the project can contribute documentation, and I would be willing to encourage and help with that.
P.S. The RE system is still very experimental and a work-in-progress. There have been some discussions on the developers mailing list, but no formal documentation at the moment (and unlikely to happen until the system matures, stabilises, and gets less experimental). Things like CAN logging are more mature and stable, and are documented.
I hope somebody can tell me what kind of message is actually sent over the canbus when the following tester present command is used: re obdii tester start 1 7df 2
According to the syntax the tester present message is sent over bus 1 every 2 seconds to the broadcast address. What is unclear to me is what message is sent: is it the 0x3e mode? Or is it something else? Is there another way, not using the re framework to send the 0x3e message to a specific ecu or to the broadcast address?
The command sends the tester present message, UDS code 0x3E. Subfunction is fixed to 0x00, the command currently does not support changing the subfunction.
You can send the message manually by using the "obdii canN request" command.
Regards,
Michael
Thanks Dexter, unfortunately I'm in a dead end now. It's a month I'm trying to get in touch with one specific ECU on my new MY21 I-Pace (the TCU unit). In the previuos model all the ECUs where accessible "easily" once you knew the addresses. On the latest model some addresses have been changed but sorted that problem I was able to talk with all the ECU but one, the TCU.
I'm sure about the address thanks to a specific tip I got from a JLR tehcnician, but every poll goes in timeout no matter what. I hoped it could be a problem with "tester present" but based on your answer it looks everything is ok. I tried listening to 1-7ff just to be sure in case the answer was not on standard address but it did not work. I'm sure about the structure or the poll (mode 22) as I also got this tip from the same guy.
I noticed 2 strange things, at least to me:
1) the bus is flooded with messagges from 0x6d0, 0x6d1, 0x6d2, 0x6d3. Just 8 bytes of zeros from each address repeated continously. That was not present in the previous model.
2) I got strange results if using the command "obdii canX request device 0xZZZ 0 22ZZZZ". For any 0xZZZ ecu address, if using "0" for the receiving address I got different answers for the same polled PID address 0xZZZZ. Could it be a bug in the firmware or "0" as the RX address means something special ?
Regarding #2: giving rxid=0 is the same as doing a broadcast, i.e. txid is ignored in that case and substituted by 0x7df. The command will only output the first response it receives. If you want to see all responses, enable CAN logging.
Regarding your other effects: is the TCU possibly using ISO TP extended addressing mode? You can test that by using the -e option on the OBD request command.
ISO TP can also be done via CAN extended frames. That's not yet supported by the OBD poller, but you could test that by manually sending some simple (single frame) requests using the "can canN tx extended" command and watching the CAN log for responses.
Another option is, the TCU is using a totally different protocol. The next guess after ISO TP would be CANopen, which is supported by the "copen" command framework. See https://docs.openvehicles.com/en/latest/components/canopen/docs/index.html
There are more protocols that could be in use. VW for example has developed a custom protocol named "TP 2.0" (which has nothing in common with ISO TP) to transport KWP-2000 via CAN. If something similar is used on the I-Pace, you'll need to get some info on that protocol first.
There's also the option of that TCU being on a separate CAN bus or not being accessable via CAN at all. Quite some devices still need to be accessed by K-Line. Up to three CAN buses can be accessed by the OVMS directly, but you'll need to know the pinout. K-Line needs the K-Line extension board, see https://docs.openvehicles.com/en/latest/userguide/kline.html
Regards,
Michael
I'm not familiar with extended addressing mode. Is it just adding -e to the command or the syntax / structure of the command and of the addresses are different? Is there any doc I can read about that? I tried to google a little bit but I found no help