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
Hi all!
I was thinking of a mode that allows the user to turn off all the slot LEDs. When Chameleon is connected (to the App/CLI) the user could choose to activate it.
Why?
This would allow to reduce energy consumption a little (especially when connected with BLE, without USB) but also (or mainly for me) to have a sort of stealth mode in order to be more discreet.
The user could activated it when using Chameleon as a reader or to find keys, etc while in BLE.
The only information that he would lose in this mode is the active slot when looking at the device, but he can easily find it out from the App or CLI. Furthermore, during these operations it's not important to know which is the active slot.
How?
It could be a button in the App and a command in the CLI, which turns off all the slot LEDs.
This mode should NOT be saved as a setting in the flash, so the next time you turn on Chameleon it returns to "normal" mode. By doing so, there is no risk of having a dark Chameleon that could cause confusion for the less experienced.
I don't know if it makes sense for you and, above all, if it's difficult to implement due to how the current firmware is written.
I ask you not to trash this idea for the sole reason that there is a lot of work to do at the moment. If that's the only reason, let's save it for the future. Personally I find it useful.
Thank you for your time
The text was updated successfully, but these errors were encountered:
While browsing through the settings, I've seen the animation settings:
[USB] chameleon --> hw settings animation set -h
usage: hw settings animation set [-h] -m {0,1,2}
Please enter correct parameters
options:
-h, --help show this help message and exit
-m {0,1,2}, --mode {0,1,2}
0 is full (default), 1 is minimal (only single pass
on button wakeup), 2 is none
It should be hw settings animation set -m 2. But to be honest, I don't know if this only reduce the blinking or shut down the disco mode.
I like your concerns, that a fully silent Chameleon can easily confused with an offline one or empty battery.
It should be hw settings animation set -m 2. But to be honest, I don't know if this only reduce the blinking or shut down the disco mode. I like your concerns, that a fully silent Chameleon can easily confused with an offline one or empty battery.
Yes, this refers to the animations after wake-up and before sleep, while I would activate this mode when Chameleon is on and connected to a smartphone/pc
Hi all!
I was thinking of a mode that allows the user to turn off all the slot LEDs. When Chameleon is connected (to the App/CLI) the user could choose to activate it.
Why?
This would allow to reduce energy consumption a little (especially when connected with BLE, without USB) but also (or mainly for me) to have a sort of stealth mode in order to be more discreet.
The user could activated it when using Chameleon as a reader or to find keys, etc while in BLE.
The only information that he would lose in this mode is the active slot when looking at the device, but he can easily find it out from the App or CLI. Furthermore, during these operations it's not important to know which is the active slot.
How?
It could be a button in the App and a command in the CLI, which turns off all the slot LEDs.
This mode should NOT be saved as a setting in the flash, so the next time you turn on Chameleon it returns to "normal" mode. By doing so, there is no risk of having a dark Chameleon that could cause confusion for the less experienced.
I don't know if it makes sense for you and, above all, if it's difficult to implement due to how the current firmware is written.
I ask you not to trash this idea for the sole reason that there is a lot of work to do at the moment. If that's the only reason, let's save it for the future. Personally I find it useful.
Thank you for your time
The text was updated successfully, but these errors were encountered: