I agree, too. Some thoughts on that:

James stated somewhere that a disable option would be redundant, as one can also turn off autoranging of the unwanted channel and then shift its graph out of the visible screen. Okay, that works, but then we have still the confusing lines and captions of the unwanted channel, so it’s only a makeshift and not really the same as a true turn-off.

By the way, I see at least two potential levels of implementing a disable option:

a) Only at app level, primarily to remove unwanted clutter from graph display. In this case, Andreas’ request couldn’t be fulfilled entirely.

b) At app AND firmware level. If we don’t want an unwanted channel to be logged, then firmware changes would also be necessary, I think.

The latter would probably conflict with the limited and almost exhausted controller’s program memory. In competition with other desirable firmware enhancements (such as compressed log streaming and maybe the option to delete CSV files from SD card also via BLE), it doesn’t seem to have a very high priority.

So to be realistic, we should be prepared to live with log data of a (sometimes) unwanted channel for a long time, if not forever. But I can’t imagine a use case where this would be a real problem.

For these reasons, I would like to plead for a disable option only at app level.