Hi Mathieu
No problem! I like the look of this project a lot, I hope I can contribute something useful even if I don't have the time to help with PCBs/firmware at the moment.
Perhaps there's no getting around the cost issue, though perhaps it can be mitigated in part with a reduction in front panel cost and (in an ideal world at least) increased volume with increased demand due to awesomecool 3d input feature ;-)
If this thing was implemented as an alternative/addon front PCB instead of being a core part of the system then it seems that people who wanted it would understand and be willing to pay the small extra for the coprocessor. If fully integrated then I agree it isn't ideal without a high percentage of potential users who would specifically like this feature.
As the claimed max is 15cm it seems reasonable to expect you could get at least 5.
>> I'm also wondering what would be the influence of our "bottom PCB"
Was thinking you'd have to include a ground plane as layer 3 (where 1 is closest to the user). This would hurt sensor performance but from the datasheet/electrode design docs it seems like it would mitigate any problems from anything behind the board. No idea what impact the slots and traces for the LEDs would have but they're small relative to the overall sensor layout so hopefully would get away with it. Seems like it would be a pretty common requirement for people implementing this the GestIC
Mitigate security problems due to physical fingerprints/smears on front panel
>> That's awesome you took the time to read about the way we'll enter the password. We could improve this indeed
It's a tricky problem! For me I'd ideally like to move my finger in the same sequence from the same starting point each time I enter the PIN to reduce cognitive load and PIN entry time by taking advantage of my "muscle memory", but that automatically causes the fingerprints problem so personally I'd consider it not viable... here's a potential solution which has just sprung to mind using the existing hardware only (apologies if this is what you were going for already but not read anywhere about the random modifiers step):
- The user is about to enter their pin
- The screen shows a random digit from 0-9. They place their finger anywhere (though we can assume probably in the same place every time for most people) on the wheel. As they move their finger around the number goes up/down.
- The user releases their finger when the digit is correct.
- The screen now shows one asterisk (and another asterisk for each subsequently entered digit) and another random number 0-9.
- The user places their finger back on the wheel to enter the next digit. Hopefully (after a bit of practice at least) the fact that it's easier to place the finger back exactly where it lifted off from rather than returning it to some arbitrary "home" position plus the lack of muscle memory will mean that users naturally place the finger straight back down.
- Goto 1, OR
- User presses a button to confirm/cancel the PIN entry (or maybe just delete one digit/cancel if no digits or tap to delete, hold to cancel).
Seems like this would randomise the smudge marks a bit more without overly compromising the usability - what do you think? I guess the smudge patterns would still very much be vulnerable to interpretation but they wouldn't leak as badly so hopefully an attacker would need to capture an impractically large number of distinct smudge patters from the entry of the same PIN in order to shrink the search space usefully. An improvement might be to also randomise the relative direction of increment/decrement of the digit shown on screen (i.e. the digit currently being entered by the user) relative to the direction they spin the wheel. You could provide a hint on screen for this but doesn't sound too annoying that I'd turn it off without this.
Potential for higher security PIN entry in the face of "shoulder surfing" or e.g. hidden camera
>> While that's definitely an advantage, it's also a main drawback for non-informatics familiarized persons :(
Perhaps, although the GestIC can be used in a "touch" mode which works exactly as the current interface or to emulate a keypad as well as anything using the 3d. It could ship in "I-can't-understand-the-concept-of-moving-my-finger-in-3d-because-that's-not-how-my-iPod-works"-mode with the option to enable "high security"- or "3d"- or whatever mode for geeks/hackers/young people. You could also use exactly the same UI paradigm as the currently but just implement it 1cm above the surface - that way it's still a 2d input conceptually but solves the fingerprint problem.
Add lots of value as an Arduino platform
>> We haven't gotten many feedback on the Arduino compatibility thingy yet... what do you think about it? I hope the OLED screen will make users happy
I think it's a great idea - while it does place some limits on your choice of chips (I guess you're pretty much bound to using one of the same chips are official Arduinos) it opens it up to a wider market. While I can see that a sleek looking Arduino-compatible with the OLED screen and touch interface would be an attractive platform for hobbyist projects it would have to be at a competitive price to all the other 'duinos out there to sell in volume - the OLED screen looks awesome, but there's plenty of awesome Arduino compatible screens on the market already, and ditto the touch interface. While reducing cost to compete might seem incompatible with a small cost rise from adding the feature, the 3d interface would be a "killer feature" and would be unique and exciting enough to be attractive at a higher price.
Firmware defined user interface and flexibility of input gestures
>> Agreed but see 3). Moreover, we'd definitely need a more powerful IC.
A bigger µC is an issue for cost and might also cause issues for Arduino compatibility?
Cost: That said, it seems like you might fit glue code on a small micro which served as a co-processor for the GestIC and provided a noob friendly interface over I2C or something so people wishing to hack it in "Arduino mode" could just send commands like "listen for a 3d pin and store an encoded version in a FIFO (for readout on interrupt)" or "capture a number from the virtual number pad and then interrupt" or "trigger an interrupt when a user's hand approaches the front panel". Would make it easy to hack and have a minimal memory footprint.
Non-technical users: On the flipside, this would make it really easy to test out different UI paradigms with a range of users and so you could refine it to be easier to use based on user feedback rather than having to respin the front PCB in order to test a new idea.
As you can see I agree with several of the points you mentionned. The only drawbacks I can see are:
- more expensive
- requires a more powerful uC
- may restrain the final market to geek persons
I've addressed these as best I can but fully agree with you that it isn't clear cut - there are tradeoffs either way but for me, at least, the 3d interface is unique and exciting enough to justify and increase in cost plus it would dramatically broaden the appeal to the hacker/maker crowd. Assuming it would add something like $10-20 to the cost to the consumer assuming 250% of additional BOM cost and the 4-layer board (and generally pulling numbers out of my arse) so I suppose what it comes down to is what proportion of the base cost this would be; if it's going to be pretty damn expensive compared to an Arduino anyway then I'd add it, if it's going to be as dirt cheap as possible then I'd save it for an addon or ditch the idea all together :-)
D