Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement CAN monitor mode / buffer dump #17

Open
thdankert opened this issue Aug 10, 2018 · 2 comments
Open

Implement CAN monitor mode / buffer dump #17

thdankert opened this issue Aug 10, 2018 · 2 comments

Comments

@thdankert
Copy link
Contributor

Even though the ELM327 can't monitor a high-speed CAN bus in real-time, it would be nice to have support for "streaming" all received data to the application.

According to the datasheet, either MA (monitor all) or BD (buffer dump) can be used for that purpose.
Together with CF (ID filter) and CM (mask) only the relevant messages can be filtered, so the chip has a chance to capture all relevant bus traffic.

This won't play nice with the way this library currently works: by definition, the monitor command will never complete (unless the buffer becomes full). But the library will only call the response handler if the command is complete, and the whole response has been received.

My idea is to add special handling when in monitoring mode - each received line is directly forwarded to the application, with no further processing in between.

I'm going to try and implement it in my fork and will send a PR.

@mickeyl
Copy link
Owner

mickeyl commented Aug 10, 2018

Sounds good – I'd definitely like to see this in LTAutomotiveSupport.

With respect to the inner workings, here are some spontaneous ideas:

  • Either we distinguish on the LTCommand level whether we have a oneshot or a streaming command or we come up with a subclass LTStreamingCommand.
  • The command queue / protocol engine then needs to be prepared to handle commands that have the streaming attribute in a slightly different way than before.
  • With respect to the API, currently I would vote for leaving it as it is, i.e., we could just define that for certain commands the response handler may be called multiple times.
  • We can use cancelPendingCommand to stop a currently running streaming command.

These are just directly out of my head without thinking longer about it. Feel free to come up with an alternative proposal, if you think you have a better idea.

Good speed!

@thdankert
Copy link
Contributor Author

Due to time constraints, I have not finished my rework... right now I simply start the monitoring again as soon as a response has been received from the device.
Since bluetooth LE can't transmit very fast, the device quite often responds with "BUFFER FULL", but so far, I was able to sniff CAN traffic at 250kb/s (with filters set, it would be too much without them).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants