Tagged: disable channel ble compression
- This topic is empty.
- September 22, 2016 at 5:46 pm #14157AnonymousGuest
It would be useful to add a “disable” (or deactivated) to the mode selection for the channels. A disabled channel should not shown in the grapher mode and not logged to the SD Card when logging was enabled.
- November 9, 2016 at 10:04 am #14768AnonymousGuest
Yes – I think so too. “Disable” would be useful.
- November 14, 2016 at 7:23 pm #14817AnonymousGuest
I agree that a disable mode would be quite useful. The graphing display is needlessly cluttered with the unused channel. It would be acceptable to be able to turn off the display of one of the channels in the options on the graphing page.
- November 15, 2016 at 2:48 am #14819AnonymousInactive
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.
- November 15, 2016 at 10:52 am #14830AnonymousGuest
For me, disabling channels at firmware level it’s not mandatory, because we can easily ignore the unwanted channel from the log. It’s a “nice to have” and it’s more important to save the limited space for other features.
In this case, we can’t add a “DISABLE” to the both pull down menus for the channels at the app level, because the selection will not reflect the state of the mooshimeter. So it seems a better solution to add a small extra “disable” checkbox near to the pull down menus.