Hi Oliver,
On 04/06/2019 08:24 PM, Oliver Hartkopp wrote:
is it possible to increase the 38400 bits/s to some higher bitrate
Yes, this is something that a custom attachment tool (in the spirit of slcan_attach) could do. I haven't tried it yet. The problem is that it's either a permanent change that's stored in the ELM's EEPROM, or it has to be done in an automated fashion because of a safeguard in its software.
The kernel driver itself does not care about the baud rate.
May I suggest looking into the ELM manual?
https://www.elmelectronics.com/wp-content/uploads/2017/01/ELM327DS.pdf
The command "AT BRD" allows temporary changes, but needs to be ACKed by a computer program. And "AT PP 0C ..." changes the EEPROM, which I wouldn't want to do in any generic driver code. But as long as you remember how you've configured your own ELM, you are free to use whichever baudrate you like. Again, I haven't tried this, please don't brick your ELM ;)
Also, what may be the limits of the PIC (clone?) and the USB-Serial bridge (clone?) in these adapters...
to be able to capture 500kbit/s CAN traffic load?
Hahahah, unfortunately that will never be possible at full 500kbit/s CAN load, because the RS232 interface will always be slower and the buffer will overflow. The driver will emit an error frame and restart listening, but that's all we can do really.
This is key, and fully expected behaviour. Yes, the ELM does not ACK when in monitoring mode. Unfortunately, we have no choice but to use this mode in long idle periods. The only situation when it will ACK is for about 1-2 seconds immediately after the ELM sends a frame. Afterwards, it goes back into monitoring mode, where it will not ACK any frames (like "listen-only" in the 8devices USB2CAN).
Ugh! That's really a hard limitation. And now I also understand the corresponding line in "Known limitations of the controller" ;-)
Yeah, sorry, I really mean it when I say that I'm making the best of a bad situation :D
The fact that you're surprised about this tells me that there are two possible things that may have gone wrong. Since you've read the documentation, the only remaining explanation is that it sucks and I need to rewrite it. Because this is actually expected behaviour :)
... from the ELM - but how do you think that you can solve that?
Umm... you mean how can I solve hard to understand documentation? I can try to rewrite it... nothing I can do about the ELM though, I'm afraid! You can either buy an OBD adapter with a modern authentic chip (and then you may as well get a USB2CAN), or live with the limitations of the clones.
In fact, do you think I should rewrite the doc, or is it okay as-is?
As for the ACKing. Think of it this way: If you hook it onto an existing CAN bus, you can use it to listen in and send the occasional frame. There will be enough other devices to ACK frames.
Thanks a lot for your feedback, I greatly appreciate you taking the time to look into this! :)
Max
