Easiest Way to Migrate From Push-Button to Touch or FingerSlide Ctrl

[martys]

I want to find a simple way to add touch control in C code to a PICC16F886 kitchen timer to replace the push-button SMD switches.

I have a girlfriend that often invites me over for dinner. She usually uses a dime-store twist timer to keep from burning food, but she often can't hear the alarm when in another room(too much rock concerts and she now has the hearing of a brick) and within a few weeks of use, these wind-up timers just stop working!

So I built her my custom Li-Ion battery powered PICC16F886 timer in a cute small 3x3x5cm black box with easy to see and sexy bright .75-in high blood red LED 7-Seg 2-digit time readout. It looks reasonably cool and it has a loud alarm that repeats and in all ways works perfect. It has a "screen-saver" readout when timing to save battery use and so it has very low power consumption for long battery use before using the built-in recharging circuit feature. When timing is up, it gives a loud short beep followed by "The FOOD is BURNING!" from its tiny but powerful speaker.

No burnt food!

The nerdy problem is that it is a little uncool, because it uses 4 MCU pins connected to 4 smd M/C switches for  setting  H/M/S, Start, Reset Alarm, and TurnOn.

The problem is, that although a windup timer is very easy to set for long timing intervals, any MCU-based kitchen timer is not.

It has the capability of setting a timeout delay up to 99H 99Min 99 Secs, but even if just setting timer minutes on the 7-seg readout,  it takes so much longer to setup than just a small twist of a dial. I already have incorporated button holddown repeat code to accelerate incrementing and decrementing the + and - time setting (up/down) buttons so that it is easier to quickly span the 0-99 H/M/S range of settings.

The solution of course, is to find a quick way that is also a clean-looking simple way to setup my kitchen timer for use,

My idea now is switching my design to use touch control buttons or a finger-slide type up/down control for fast and easy up/down timer setting.

Anyone have any experience finding the perfect touch approach and can find just a little time to pen here their suggestions?

[Neomys Sapiens]

How about a quad of small thumbwheel or u/d pushbutton numeric selector switches and an 'enter' button?

[martys]

The idea is to make a timer that can be set to work as quickly as a windup.

Even an hourglass is really so easy to quickly setup(but has serious problems having only one timer setting and only a visual alarm.)

EVB, thanks, and some of your ideas seem fine enough, but there are some disadvantages that overlap the benefits.
1)Rotary encoders that I have found have between 8 steps to 24 steps per 360-deg. and while with some it is possible to feel a weak detent, which is some feedback but offers poor resolution, all of them allow continuous rotation.

Tthe problem with RotEncs is that they have low resolution per 360-deg rotation and so can require more dithering and fiddling-with than the up/down individ sw's i have optimized with code to quickly arrive at any desired setting.
RotEnc good points are:
(1) Only two MCU pins are needed and coding for getting  them to work is easy for me to write in C.
(2) They have a good appearance, some have a silky feel or a detectable detent and can even sport their nice knob.
(3) Low Cost.
(4) Fits easily in the cram space of the smallest practical case I am using.
====================
I don't know where to find a small "touch slider" or how to mount it upon the existing case and what about resolution.
====================
Phone aps are easy to find, but who want's to go through the steps to always have to fetch their smartphone or IPad just to grease it up in the kitchen and what if someone calls or there is a need to call the fire dept or chat about a recipe on Facebook?

Besides, I want my project to get her alarming attention.
====================
 A mouse  is out of the question. She would just say, "EEK!..what's this thing doing in my kitchen!"
====================
A NumKeyPad is out of the question, too big a box required, this timer idea should not look or work like a digital doorlock.
====================
Your "adaptive algorithm" requires a metaphysical psychic's sick sense to work and I have yet to learn to code this in C.
====================
The smoke detect method of kitchen timer has already been demonstrated to me by her cooking to work reliably, but alarm latency seems always greater than optimally desired.
------------------
Thanks Neomys Sapiens, but no room for push button encoders with enter sw's.

I really like the idea of cap touch sw's but I don't have a hardware and C-code solution. I would like to adapt the existing MCU.
I feel there is real plus in small cap touch.
====================
 Size matters inversely in making timers with my girlfriend. A timer should give good heard but not easily seen as my junk when not in use.

[martys]

Thans again EVB for your long reply.

The real problem is this:
(1) Although a source for Rotary encoders like those found in inkjet printers are very accurate and give excellent resolution and I even have salvaged a few from discarded inkjets, they are not practical when spun by a spinner like my girlfriend and there is no room in little box for a precision large plastic encoder disk on a precision bearing coupled to a IFR  resolving detector.
(2) With a twist timer, it is always possible to visually think you've set a desired time quickly and the real error is hidden from you.
(3) With a digital timer, there is always the visual proof you've not precised the desired time wanted and people with the slightest OCD seem to obey a need to set time to a greater (exact) Xtal-perfect timed accuracy than was offered by the old windup.

(4)Using a pot to set time is also problematic. There is usually to 270-deg of rotation possible and a 250+ deg available for setting, but a precision linear single-turn cermet pot is expensive, big, and the use of a multi-turn pot or dial is out of the question.

(5) There is always some compromise in pot resolution near the end of rotation points, but my experience has shown that trying to resolve a timer setting want exactly takes very careful tiny dithering around the correct time desired and so takes too much time. If I have offered 1-sec/1-min/1-Hr resolution on the device readout, then the user might feel a need to carefully play around within +/- <3-deg rotation to exact a setting.

4) Using a pot as a plus-minus inc/dec input device means that a person can paint themselves into a setting corner if the pot is not initially reset to the center position before attempting to set time. This is unacceptable because it takes an extra setup twist before the control will be returned to its center position before use.

BTW, I was hoping to find someone who has tackled dealing with the immense options using chips and/or just software out there to offer their experience on whats best!

I have achieved some less than perfect results using the A2D functions on a pin using a 1-meg pullup resistor and attempting to center the non-touched 10-bit reading to mid-range by changing the A2D start delay before the S/H cap is disconnected by the A2D to then complete an A2D conversion.

Anyone have luck with at software A2D approach to get a reliable touch button press using software alone on the 18F886 or similar?

[alm]

How about enforcing logarithmic like steps in software? So you might have 5 or 10 minute steps for times above 30 minutes. Yes, this would not allow 1h3m51s, but how often are cook times that accurate? That would reduce the required resolution, give round values for the OCD inclined, and you could map whatever linear control (pot, encoder) to a non-linear scale in software.

[martys]

You seem to make too good sense alm. The only problem with your suggestion is that your method is reasonable, practical, simple, cheap, and even boringly mimics the time setting algorithm used on her nuke.

But where is the bling in this??

 I have carefully made a timer that can condemn some turkey to a precise 5h 23m 33Secs ride on the rotisserie, but with your suggestion I can't dazzle her with my custom one-of-a-kind unique timer that has X-tal perfect precision settings and instead now must cowardly offer her a compromised device that deprecates the ungodly timing precision she has admittedly been marveling at? Anyone elses' timer can't do that.

No No!, can't someone just give me an easy SW or  SW/HW touching solution they have found to best work to allow me  to keep the bling I now have?

[KL27x]

IMO, push buttons rule, here. Just fix your resolution.

You don't need 99 hours. And you don't need 29 seconds.


Button 1 :ADD 10 minutes per press
Button 2 :ADD 5 minute per press
Button 3: ADD 1 minute per press
Button 4: clear and turn off timer
Timer starts automatically, after the first button is pressed.
Each press increments, only. If you go too far, clear and start over. Takes a few seconds, and is very intuitive. If you're gonna cook a turkey, pressing a button 9 or 10 times is not too bad, really. It's the thinking that sucks. Watching the numbers go up when you hit a button, is very much not like thinking and is much more like doing. Setting an 80's alarm clock sucks. It's not just about how long it takes to set. It's also important to minimize how much attention/learned skill/dedicated memory it requires.

Plus when you go check and it looks like it is going to need another minute or two.. just press the button. Don't have to stop and recalculate, subtracting the time it takes you to set your 80's alarm clock. This gives you much more ability to undershoot if in question, and modify later, if/when needed. Cuz no one knows down to the second how long anything will take to cook, unless they cook dinner with lab scales and thermometers.

Just make the debouncing invisibly fast and use a nice tactile button.

Personally, cap/slider annoys me. Esp with acceleration. They are cool to whoever wrote it to work just as they want it. But they are biased. IMO, not too many people want a cap/slider interface for a kitchen timer. That's a solution looking for a problem. There's no way you would ever swipe a surface and trust you got it right, without looking. Pressing a button, you can do that with your eyes closed. They are best left for very tiny devices for cost and longevity reasons, where custom molded buttons will be expensive and or can crap out. Esp for things where you get instant feedback... e.g. volume control.

[rstofer]

STM32F746G-DISCO board:

[james_s]

I hate those touch controls, they never work worth a crap for me. I like the encoder idea, encoders feel nice and are easy to use.

We have one of those Amazon Echo things we got as a gift, generally find it to be a useless gimmick although I have discovered it makes a nice kitchen timer. You can probably find a used one of those pretty cheap when the novelty wears off.

[C]

first think of a small change that could be nice. Don't stop the clock when it gets to 0. Count down to 0 then count up until counter is reset.

I hate buttons to set a value. Best I have seen is slow presses = one count press and hold down button = fast change. Need up and down buttons or you are working like the pain to set clocks of 80's.

Think that the best idea is to change how you set the clock. Think of an analog joy stick, A resistor that is spring loaded to center position. The further you move it the faster clock changes. Gas pedal of car with speedometer as feedback. The car's cruise control is even better.

Using above for rotary encoder you want no detents as that takes away from looking at clock display for feedback.

With some really good software, you might even get a standard pot to work in this method. You would need a large dead band for slow moves to stop 

Now if you think clock timer, initial encoder turn is to get clock changing.   The faster the turn, the more the clock needs to change. More of change in same direction says clock not changing fast  enough. When the turn is in other direction, It's slow down rate of change and does not have to decrease the rate same as speed up.

So rotary encoder with good software makes clock easy to set. People catch on how to work it quick just like that  dime-store twist timer.

This is a case where touch control would be a poorer interface. To use cap touch you would need a different processor or add on control board.

[JPortici]

if you WANT to have one or more touch inputs, if you HAVE at least one analog input plus N other pins (for a mux) or an analog input per touch button and you WANT to keep using PICs, why not upgrade the 886 for any one of the pin to pin compatible pics? most if all not new pic16 have a capacitive touch sensor module

[Jeroen3]

I just yell: "Hey siri, set the timer for 14 minutes". Maybe you can make an IoT Homekit compatible kitchen timer?
Don't forget the kickstarter!

[CM800]

I just use my mobile phone and call out. "Ok google, timer, 30 minutes."

[rob2630]

It sounds like you should check out the Nextion touch display, it is very cheap and does work well and will easily meet your requirements, the only limit is your imagination. You can get them in a variety of sizes from about 2.5" to 7" and they communicate serially with the controller. They can be programmed either serially or with a micro HD card (much quicker) and operate at 5v.

However, a few words of warning - if, like me, you are not an Arduino user then you are on your own with regards to learning to use it. I spent weeks looking at Youtube videos and searching the net to understand how to  get mine working with a PIC. I have now succeeded in getting them to talk to each other and my project is advancing apart from one (code related) oddity which I might post here sometime for suggestions. You will need to download their IDE which is basic but does the job and also a drawing/image handling software to produce the images and buttons you need. I use Inkscape. Whatever drawing package you use it must be able to produce files in .png format and should also be able to work in units of pixels as this will make the design very easy.

The manufacturer, Itead, is Chinese and refuses to publish a comprehensive user manual relying on a brief description of the functions, of which there are many, and a large Arduino library. The forum will not be much help either if you are not using an Arduino despite the expertise there. It seems that controllers begin and end with Arduino and if you use anything else they don't want to know. However,  a 44 pin chip, two capacitors and a crystal do the job nicely!

But, as I say, if you persevere they are a terrific display and I have the 4.3" model in my HF transceiver project. If you do choose this route I will be happy to offer what assistance I can.

[martys]

Thanks for the many suggestions! 

Thanks JPortici, but some clever coding allows me to just use the existing 16F886 chip!

C argues,"This is a case where touch control would be a poorer interface. To use cap touch you would need a different processor or add on control board."

One should be always careful not to throw out the baby with the bathwater.

I have been working on C-code and have now have a most simple  H/W S/W solution to get the PIC16F886  to create excellent touch switch action, replacing the four m/c switches with a thumbtack touch switch, just as I originally asked for when I posted this topic to get help. I am now using common brass thumbtacks, flush-mounted on the plastic case as through hole mounted  touch buttons. The only hardware required is two tiny resistors/button, one for ESD protection and the other for pull-up charging the A2D input cap.

Thanks, rob2630.
I have played around with the Nextion Resistive Touch Displays and they are a real PITA to work with.
(1)They require a lot of power and so are not suitable for a small battery operated device.
(2)They are too big for my box.
(3)They require an enormous amount of code/data memory because they need to be  programmed in ASCII.
(4)They are not as easy to see at an obtuse viewing angle as a bright .75-in tall RED 7-Seg display.
(5)The programming language is ASCII and full of gotchas and bugs and very poorly implemented and documented.
(6)They are excessively priced for small projects.
(7)The online manuals are written in low-grade Chinglish.
(8)The Windows development IDE is buggy and crash-prone.
(9)The language syntax to implement conditional code is primitive, buggy, requires a most careful use of blanks (space chars) to work at all.
(10)The programming language requires strict adherence to only the simplest of coding constructs to work at all.
(11)Because they use a glass display and otherwise can be easily damaged, they are not a good choice to be used in spill hazard area(such as in a kitchen.)
(12)Well working touch buttons are far easier to use to control the operation of the timer.
(13)If the power supply droops it will cause the display to issue forth smoke.
(14)I have many years programming H/W to S/W experience, but the combined limitations of coding robustness, so many IDE and programming bugs, very poor documentation, etc. caused me to spend tens of hours to write some code to accomplish a quite simple display job.

Otherwise, they are fine.

[martys]

Thanks KL27X and alm.

I have thought carefully about your suggestions, but come up with the same question:
Where is the bling?

Why make setup a compromising problem? Why force the user to adopt to the instrument and force the user to create a strategy to achieve a simple original intent?

The idea in making any device user interface, IMHO, is to make using it not some problematical frustrating puzzle to figure out.

It should be as easy and quick and simple  to setup as possible, yet robust in capability, and must never frustrate the user and force them to change or compromise their ideas so to adapt to the limitations of the device's user interface  to get it to work,

Only if  user interface succeeds to meet these considerations do you create a  device that is a pleasure to setup and  fun to use!

Think Hour Glass, but with nuclear bling!

[martys]

ames_S."We have one of those Amazon Echo things".

Sure, there are fanciful enough timers to be bought on Ebay or Amazon, but this topic is not about buying cheap timers on Amazon, but about coding and user interfaces.

I wanted to build my girlfriend a durable, useful, easy to use, my one-of-a-kind custom, hand-crafted well-working timer. You can't get one on Amazon.

[rob2630]

I agree with all you say Martys and I am still struggling with my Nextion. For my application it is ideal and I have made allowances for all the bugs in the IDE etc so I can use it. The problem is I am now struggling to convert a 9 digit integer to an ASCII string so I can dislpay it.

I cannot for the life of me understand why ITEAD, after all these years of producing the displays, still flatly refuse to produce anything that resembles a comprehensive, bug free instruction manual that can be downloaded. I am surprised they are still in business.

[Elf]

Where I don't want to (or can't) use microcontroller pins that support capacitive touch sensing, I find the Microchip CAP1XXX chips handy. They present button state as a register over I2C and are pretty much ready to go out of the box, almost no setup necessary.

I find myself using the CAP1293 a lot for a "Left, Right, Enter" type 3-button interface, although you may want more for your timer. For example, the CAP1296.

[martys]

Thanks Elf, worth looking at for some other project..

Fortunately I've found an easy way to use 16F886 pins for touch sensing that were  not intentioned for use as touch pins but can do A2D.

An alternative for having an extra touch sensor chip, which would be so simple to implement is to use a 16F887 or similar 40pin packaged MCU device if I needed many touch pins and still keep the entire touch process code very simple and within a single low-cost MCU, as well as using up too much more PCB area.
I need at least 4 touch pins plus a m/c switch reset pin for turning on the timer. and fortunately, I have 4 pins available in this design.
What adds to the code complexity of using the uChip sensor is that I am already using the i2c pins for getting an uninterruptible digitized sound byte stream from an i2c interfaced 512kx8 SEEPROM but with your suggestion I would also need to poll the recommended discrete touch sensor for a alarm reset button press at the same time.  I have to continuously get one unbuffered sound data byte during per each TMR0 ISR  for a glitch-free "The FOOD is BURNING!" alarm.