e-paper woes
-
Disclaimer: I'm not sure where to put this. It's not a programming question, but it is a technical question involving an interactive gadget, having to do with usability. I've been trying to create a low power controller with an e-ink/e-paper display. Since they retain their image when the device is idle I can deep sleep the MCU and take just 10uA of power, waiting for a wakeup signal. The trouble comes when you hit a button on the controller. I need to update a number you can increase or decrease by pressing the appropriate button. Even on my prototype device with super fast partial refresh the display updates terribly slowly relative to what is needed for this feature. I'm not in a position where I can necessarily move away from e-paper. I am too far into the project and I don't have complete control over it anyway. There are e-paper displays, like those used for Nooks and Kindles that have virtually instant refresh rates but they are cost prohibitive for this application, and too large besides. What I was thinking was I could give you an audible cue when you hit a button, and only update if you stop pressing the buttons for say, 2 seconds. That way you can rapidly click the numbers up and down. You won't get a visual cue right away, but at least you'll have audible feedback whenever you hit a button. Does this seem too counterintuitive? Anyone have any other ideas?
To err is human. Fortune favors the monsters.
-
Yes, putting anything on the display is slow, even a dot. :sigh: I could add vibration to the remotes. A beep would use less power, which is a win, but if vibration were to add significant value in terms of usability it would be worth it.
To err is human. Fortune favors the monsters.
Is the device likely to be used in a noisy environment where your audible tone would be hard to hear?
-
Is the device likely to be used in a noisy environment where your audible tone would be hard to hear?
No. Or at least, I don't think it typically will.
To err is human. Fortune favors the monsters.
-
Disclaimer: I'm not sure where to put this. It's not a programming question, but it is a technical question involving an interactive gadget, having to do with usability. I've been trying to create a low power controller with an e-ink/e-paper display. Since they retain their image when the device is idle I can deep sleep the MCU and take just 10uA of power, waiting for a wakeup signal. The trouble comes when you hit a button on the controller. I need to update a number you can increase or decrease by pressing the appropriate button. Even on my prototype device with super fast partial refresh the display updates terribly slowly relative to what is needed for this feature. I'm not in a position where I can necessarily move away from e-paper. I am too far into the project and I don't have complete control over it anyway. There are e-paper displays, like those used for Nooks and Kindles that have virtually instant refresh rates but they are cost prohibitive for this application, and too large besides. What I was thinking was I could give you an audible cue when you hit a button, and only update if you stop pressing the buttons for say, 2 seconds. That way you can rapidly click the numbers up and down. You won't get a visual cue right away, but at least you'll have audible feedback whenever you hit a button. Does this seem too counterintuitive? Anyone have any other ideas?
To err is human. Fortune favors the monsters.
Or an LED you flash alongside the beep... Or even a seven-seg display that just lights up for a while when the button is pressed.
-
Disclaimer: I'm not sure where to put this. It's not a programming question, but it is a technical question involving an interactive gadget, having to do with usability. I've been trying to create a low power controller with an e-ink/e-paper display. Since they retain their image when the device is idle I can deep sleep the MCU and take just 10uA of power, waiting for a wakeup signal. The trouble comes when you hit a button on the controller. I need to update a number you can increase or decrease by pressing the appropriate button. Even on my prototype device with super fast partial refresh the display updates terribly slowly relative to what is needed for this feature. I'm not in a position where I can necessarily move away from e-paper. I am too far into the project and I don't have complete control over it anyway. There are e-paper displays, like those used for Nooks and Kindles that have virtually instant refresh rates but they are cost prohibitive for this application, and too large besides. What I was thinking was I could give you an audible cue when you hit a button, and only update if you stop pressing the buttons for say, 2 seconds. That way you can rapidly click the numbers up and down. You won't get a visual cue right away, but at least you'll have audible feedback whenever you hit a button. Does this seem too counterintuitive? Anyone have any other ideas?
To err is human. Fortune favors the monsters.
I like stormblades answer. some little light that lets them know you know and are doing something. Lots of people are hard of hearing. Also giving more than one indicator (both a vibration/beep and a light led flash) would probably be beneficial. Just my .02
To err is human to really elephant it up you need a computer
-
Disclaimer: I'm not sure where to put this. It's not a programming question, but it is a technical question involving an interactive gadget, having to do with usability. I've been trying to create a low power controller with an e-ink/e-paper display. Since they retain their image when the device is idle I can deep sleep the MCU and take just 10uA of power, waiting for a wakeup signal. The trouble comes when you hit a button on the controller. I need to update a number you can increase or decrease by pressing the appropriate button. Even on my prototype device with super fast partial refresh the display updates terribly slowly relative to what is needed for this feature. I'm not in a position where I can necessarily move away from e-paper. I am too far into the project and I don't have complete control over it anyway. There are e-paper displays, like those used for Nooks and Kindles that have virtually instant refresh rates but they are cost prohibitive for this application, and too large besides. What I was thinking was I could give you an audible cue when you hit a button, and only update if you stop pressing the buttons for say, 2 seconds. That way you can rapidly click the numbers up and down. You won't get a visual cue right away, but at least you'll have audible feedback whenever you hit a button. Does this seem too counterintuitive? Anyone have any other ideas?
To err is human. Fortune favors the monsters.
I like storm blade’s idea. A lot of ppl have hearing issues, so some simple visual feedback is a good idea. Probably better than audio as the client is already reading a display. For the audio tone, it seems like you could 1. Leave the audio tone /LED active until the last refresh is done. Change pitch/volume/tune during different phases. 2. Initial beep, the final beep on last refresh. 3. What are the chances of simple spoken feedback? I know C64 had a decent spoken SAM engine in under 32kb, with a decent sound chip. I am assuming multiple refreshes will likely happen due to impatience.
-
I like storm blade’s idea. A lot of ppl have hearing issues, so some simple visual feedback is a good idea. Probably better than audio as the client is already reading a display. For the audio tone, it seems like you could 1. Leave the audio tone /LED active until the last refresh is done. Change pitch/volume/tune during different phases. 2. Initial beep, the final beep on last refresh. 3. What are the chances of simple spoken feedback? I know C64 had a decent spoken SAM engine in under 32kb, with a decent sound chip. I am assuming multiple refreshes will likely happen due to impatience.
Voice recognition is a problem with this device for three reasons. 1. there is audio input but it's through a garbage ADC - which may not be adequate for this 2. I can't seem to initialize audio in and audio out on the same I2S bus unless all the stars are aligned. This can be solved for the most part with more hardware, but I'm trying to keep the remote devices minimal. 3. i have to wake the device to accept input and I can't wake on sound I totally misread your post. Whoops.
To err is human. Fortune favors the monsters.
-
Disclaimer: I'm not sure where to put this. It's not a programming question, but it is a technical question involving an interactive gadget, having to do with usability. I've been trying to create a low power controller with an e-ink/e-paper display. Since they retain their image when the device is idle I can deep sleep the MCU and take just 10uA of power, waiting for a wakeup signal. The trouble comes when you hit a button on the controller. I need to update a number you can increase or decrease by pressing the appropriate button. Even on my prototype device with super fast partial refresh the display updates terribly slowly relative to what is needed for this feature. I'm not in a position where I can necessarily move away from e-paper. I am too far into the project and I don't have complete control over it anyway. There are e-paper displays, like those used for Nooks and Kindles that have virtually instant refresh rates but they are cost prohibitive for this application, and too large besides. What I was thinking was I could give you an audible cue when you hit a button, and only update if you stop pressing the buttons for say, 2 seconds. That way you can rapidly click the numbers up and down. You won't get a visual cue right away, but at least you'll have audible feedback whenever you hit a button. Does this seem too counterintuitive? Anyone have any other ideas?
To err is human. Fortune favors the monsters.
A 19th century war game used a "sounding board" that clicked when you rotated a dial where each click was proportional to the previous. It was used to calculate scoring multipliers and meant you didn't have to "look" while calculating using some 10+ factors. You're in good company.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
A 19th century war game used a "sounding board" that clicked when you rotated a dial where each click was proportional to the previous. It was used to calculate scoring multipliers and meant you didn't have to "look" while calculating using some 10+ factors. You're in good company.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
using an encoder knob is a really great idea. thanks! that just might be the ticket.
To err is human. Fortune favors the monsters.
-
using an encoder knob is a really great idea. thanks! that just might be the ticket.
To err is human. Fortune favors the monsters.
And "encoder knob" sounds so much better than button!
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
Voice recognition is a problem with this device for three reasons. 1. there is audio input but it's through a garbage ADC - which may not be adequate for this 2. I can't seem to initialize audio in and audio out on the same I2S bus unless all the stars are aligned. This can be solved for the most part with more hardware, but I'm trying to keep the remote devices minimal. 3. i have to wake the device to accept input and I can't wake on sound I totally misread your post. Whoops.
To err is human. Fortune favors the monsters.
-
using an encoder knob is a really great idea. thanks! that just might be the ticket.
To err is human. Fortune favors the monsters.