Self-calibrating Touch on M2

cpedw

Senior Member
I am developing a project that may use 4 touch inputs on a 14M2. Reading about touch, it seems that people have trouble with drift due to changing environmental conditions.

I found a couple of descriptions of auto calibration but they use the same inputs that may or may not be touched. I'm wondering about using a spare input as a touch reference level. Has any work been done already comparing different touch inputs and how their levels change? On the 14M2, I can use 4 port B pins as touch inputs and there's a 5th touch input to use as the reference.

Should the reference changes be applied as differences or proportions to the in-use input levels?

The application is for a Dawn Simulator alarm clock using an MSF clock input, OLED display and PWM output for dawn simulation.. There's also an ambient light detector to adjust display brightness to suit the light level.

Are any of these, in particular the PWM, likely to upset the touch inputs?

I realise there's lots of scope for my own experiments here but the project is intended as a present due in 2 weeks so there's not much time for in-depth background work!

Does this approach have a reasonable prospect of success or should I stick with push buttons as before?

Derek
 

hippy

Technical Support
Staff member
Does this approach have a reasonable prospect of success or should I stick with push buttons as before?
I was also going to suggest that push buttons may be a better bet given the time frame you are working to.

McDonalds had a Nerf promotion a few years back which included a 2" or so button which lit up when struck. Those are quite handy for repurposing as a flashing LED alert and 'shut-up!" button on a length of cable.

You might be able to find something similar, right-hand side. The logo rubs off with a bit of bicarb and light elbow grease -

http://i1.wp.com/ytimg.googleusercontent.com/vi/Zk0XPNc_Itk/hqdefault.jpg
 

AllyCat

Senior Member
Hi,

If you use quite large touch pads covered with a thin layer of insulator AND employ a continuous self-compensation scheme, then I think you've a reasonably good chance of it working. Bear in mind that the value returned is not really an "input level" but a frequency count (from a variable-capacitance oscillator). As such, I would expect to use "proportional" compensation rather than "differential" compensation. Also, it might be wise to turn off any PWM whilst measuring the buttons.

However, as hippy said, for a project with a short timescale, there's a lot to be said for a familiar and KISS mechanical push-button method. ;)

Cheers, Alan.
 

erco

Senior Member
Aw, that's depressing that tech support advises against trying such a great feature!

It is true that the touch pins are drifty & finicky but periodic self-calibration should make them usable. I'll add that to my to-do list, whenever I can find the time.
 

hippy

Technical Support
Staff member
Aw, that's depressing that tech support advises against trying such a great feature!
It's not so much that anyone would advise against trying it, just that when up against a hard deadline, when unexpected issues cannot be entirely discounted, tried and tested is usually best.

Perhaps the best approach would be to get it working with traditional buttons and, when done, move to getting it to work with touch. That provides a back-out escape route if there are unexpected problems.
 

inglewoodpete

Senior Member
I agree with Alan and hippy. I developed a game that used a 28X2, with 9 touch pads and 9 LEDS. The sensitivity and thresholds of the individual touch input pins varied greatly and varied depending on the current being sourced or sunk on the same port (Eg. A, B or C) as the touch pin. Also, there was some interference between some inputs. The results also differed when free standing as opposed to when the programming lead was connected. This could prove to be trying on your patience if you are pressed for time.

I suspect that the behaviour has little to do with the PICAXE firmware but is the nature of the native PIC's silicon.

I have attached a chart created in MS Excel, using data logged from the PICAXE. Areas A, B and C show the interference between inputs. D shows the gradual change in threshold levels (readings from idle inputs) on some inputs as some outputs were turned on. The chart also shows the diverse range of idle and active values of different inputs. Your software will need to compensate for all of these quirks to produce a reasonably reliable result.

As AllyCat and hippy have said, it can be done but you need considerable time to develop and test both your hardware layout and software.
 

Attachments

erco

Senior Member
The results also differed when free standing as opposed to when the programming lead was connected.
That is definitely the case. Improves the case for regular self-califragilisticexpialidocious. Well, self-calibrating at a minimum.
 

inglewoodpete

Senior Member
That is definitely the case. Improves the case for regular self-califragilisticexpialidocious. Well, self-calibrating at a minimum.
Yes, I did that but I never learned how to pronounce it!

I used the background timer interrupting every 100mS to monitor and determine the (moving) average "not-touched" state of each of the 9 pins.
 

hippy

Technical Support
Staff member
I used the background timer interrupting every 100mS to monitor and determine the (moving) average "not-touched" state of each of the 9 pins.
An alternative, though effectively the same thing, is to just read the TOUCH value every loop, form an average and then determine it has been touched when the input is 'significantly greater than the average'.

That 'higher', 'much higher', and 'lower' can be tracked to give some hysteresis and determine when a new touch has occurred which the rest of the program can use.

It's the same technique used for noisy analogue inputs ( or digitised analogue inputs ) where there is no stable baseline and that has to be determined and may need dynamically adjusting.
 

inglewoodpete

Senior Member
An alternative, though effectively the same thing, is to just read the TOUCH value every loop, form an average and then determine it has been touched when the input is 'significantly greater than the average'.
Of course that is an option, particularly on M2s, where the background timer is limited to 1-second ticks at clock speeds of 4 or 16MHz (0.5s @ 32MHz). I was using an X2 PICAXE and, being a game, I needed some reliable form of time supervision. (The game, proposed for a primary school, required players to tap a series of touch pads in sequence within a set time period).

You can also see from my logged data from a Touch16 statement that some inputs give a better response than others while some interfere with other inputs. Careful selection of inputs can make the software much easier to develop too.
 

mikeyBoo

Senior Member
Geez… didn’t know the touch switch function was so tricky on Picaxe chips. Anyhow, I found an old drawing where I made some touch switches “old school” style. The 555 outputs a pulse when a finger is placed across 2 wires/pads at the 555 input (just like a momentary switch). If the pulse output is taken into the clock input on the 4013, then it toggles on/off with each touch. Seems like it was pretty reliable.
You could use a 558 (quad 555) to make 4 switches (4013 only needed for on/off toggle function).
 

Attachments

cpedw

Senior Member
I was prompted by Mortifyu's resurrection of a very old thread on Touch to report back on my findings. For the original project, I used TTPxxx switches as described by Erco in post 5. They were excellent.

I tried to investigate how 5 touch inputs on port B of a 14M2 varied over time and temperature. It took me a long time to get to grips with I2C and external EEPROM for datalogging but, once that was sorted, it became apparent that the touch inputs were prone to substantial jumps in recorded reading.

I concluded that the TTP switches are the way to go in future. I'm still interested in Ktarke/Mortifyu's application for contents gauges using touch but I'm not optimistic!

Derek
 
Top