Gerrit van Niekerk

Just an update: I've downloaded the ELM327 Data Sheet and noticed that only hexadecimal ascii characters should be sent to the Bus. Meaning the STDI was meant for the ELM, but it is an 'undocumented' command. (I've also noticed reference to it on the internet). So the question is, why does CarPort give up when the ELM can't answer the STDI? CarPort doesn't even try to query the bus (with a 0010 or similar). And of course, is there a way to get around it? Some setting to 'not use stdi command'? :) Thanks in advance Gerrit

Best CarPort people, I'm trying to get CarPort to talk to my VW Polo Vivo (a South African polo 9N). According to the StartTab, Carport finds the interface ( ELM 327 v1.5) and happily talks with it. The top-row boxes are all ticked in green, but on the second (Volkswagen) line, I have two red crosses... I decided to take a look with USBPCap (USB add-on for wireshark), and I think I know where it goes wrong: CarPort goes through a fairly long protocol programming sequence (eg atpbc0 01, atpp19svff, atpp19on, etc.) to which the ELM keeps on replying OK. CarPort then writes 'stdi' to which the ELM just replies: '?'. I would assume this 'stdi' should be written to the CAN but ELM just decided it is meant for it and doesn't understand it? (I must confess I have no experience with these car 'modem' protocols ;) ) Anyway, after that, CarPort writes atppi to which ELM dumps a very long summary. After that CarPort just switches off the protocol (atpc) and doesn't try again; just start writing 'ati' every second or so... So I reckon the problem is that ELM handles the 'stdi' incorrectly? Is there any workaround for this? I can also send you the wireshark file if it would help. Kind regards, Gerrit