You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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).
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) orBD
(buffer dump) can be used for that purpose.Together with
CF
(ID filter) andCM
(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.
The text was updated successfully, but these errors were encountered: