Implement CAN monitor mode / buffer dump about ltsupportautomotive HOT 2 OPEN

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!

from ltsupportautomotive.

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).

from ltsupportautomotive.