Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: teensy 3.2 touchRead() range ?

  1. #1

    teensy 3.2 touchRead() range ?

    Hello

    I have a few teensy 3.2 running in an exhibition and am using the touchRead to see if people are touching a pad.
    The touch pad is connected to pin A8 and it's readings are send out over OSC.
    Most of the time things work well but once in a while is seem to get a reading around 65526 and after that things get strange.
    I have a feeling it's either that touchRead outputs something larger than a regular integer, or it outputs a negative value that I did not account for in my code.

    What is the max range of touchRead() ?
    Should I use a long variable? Should I look out for -1?

    thanks,
    stephan

  2. #2
    I learned that the max touchRead value returned is 65535.
    I am still not sure if it might also output -1 during an error; similar to the capacity touch library on the teensy site.

    I did apply constrains to the returned touch value so that a negative number or one larger than 65535 would not effect anything.
    I am still getting this problem of the teensy thinking someone is constantly touching the sensor.

    https://www.dropbox.com/s/1q6hplqlsh...inger.jpg?dl=0
    I basically have a plastic tube that I coated with a conductive paint. when someone touches the tube I want to know that.
    I don't have grounding issues; meaning the wire running from the tube to the teensy is insulated correctly.

    the only thing I can think of call a teensy reset and hope this will also reset the false touch reading.
    like here: https://forum.pjrc.com/threads/44857...l=1#post145990

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,941
    It really should not give negative numbers.

    Quote Originally Posted by stephanschulz View Post
    I am still not sure if it might also output -1 during an error;
    Maybe there's something about your code? Just a blind guess, since I can't see it.

    If the program isn't a proprietary secret, maybe post it here? Or if it a a secret, maybe trim it down to just this measurement (a good idea anyway if the program is large) and show us just a small program that gives the negative numbers? The key to getting good help here is to post a complete program (eg, the "Forum Rule") so any of us can copy & paste it into Arduino and run it on our boards to see the problem happen.

  4. #4
    Thanks Paul for the quick reply.

    I certainly agree that posting code help.
    Right now I only have the full project which has too much meat around the edges.
    https://github.com/antimodular/PulseTank_osc

    But I will try to make a leaner version of it soon.
    Here is the code dealing with the touch sensing https://github.com/antimodular/Pulse...Sensor.ino#L23

    Unfortunately my bug only appears through out the day at the exhibit and I have not yet seen it in my setup in the office.
    Over OSC I am sensing the touchValue which I already constrained. On the osc master I can see that the touchValue is stuck at a value close to 65535 while other things are still running on the teensy.
    As the buggy setup it installed in a museum out of town I am not able to just get serial read outs.

    The basic logic of the touch sensing code goes like this:
    - if touchRead gets added to running average in order to smooth the values
    - if running average is over threshold than we considered it a touch
    - if touch is true then I am actuating a solenoid to pulse at a person's heart rate.
    - only in debug mode gets the touchValue send out via OSC

    So at some point touchValue seems to get stuck and the solenoid keeps on pulsing. Since it is pulsing I know the teensy did not just crash. But OSC receives the same stuck touchValue value.

    I would love to hear any advice.
    Maybe there is a way to clear out / reset the touchRead pin.
    Maybe I can reset the teensy.
    Maybe I have a build up that causes an integer overflow.

  5. #5
    Senior Member pictographer's Avatar
    Join Date
    May 2013
    Location
    San Jose, CA
    Posts
    654
    I've seen spikes like this.

    I'd suggest explicitly clamping the range and discarding any values that are outrageously large. Also, median filtering is very useful for smoothing out the signal.

    Quote Originally Posted by stephanschulz View Post
    Thanks Paul for the quick reply.

    I certainly agree that posting code help.
    Right now I only have the full project which has too much meat around the edges.
    https://github.com/antimodular/PulseTank_osc

    But I will try to make a leaner version of it soon.
    Here is the code dealing with the touch sensing https://github.com/antimodular/Pulse...Sensor.ino#L23

    Unfortunately my bug only appears through out the day at the exhibit and I have not yet seen it in my setup in the office.
    Over OSC I am sensing the touchValue which I already constrained. On the osc master I can see that the touchValue is stuck at a value close to 65535 while other things are still running on the teensy.
    As the buggy setup it installed in a museum out of town I am not able to just get serial read outs.

    The basic logic of the touch sensing code goes like this:
    - if touchRead gets added to running average in order to smooth the values
    - if running average is over threshold than we considered it a touch
    - if touch is true then I am actuating a solenoid to pulse at a person's heart rate.
    - only in debug mode gets the touchValue send out via OSC

    So at some point touchValue seems to get stuck and the solenoid keeps on pulsing. Since it is pulsing I know the teensy did not just crash. But OSC receives the same stuck touchValue value.

    I would love to hear any advice.
    Maybe there is a way to clear out / reset the touchRead pin.
    Maybe I can reset the teensy.
    Maybe I have a build up that causes an integer overflow.

  6. #6
    thanks pictographer.

    I thought I already took care of most clamping via the constrain() function.
    But I will look it over again.

    In addition if move the touch code to processing to look for other problem more quickly and found that processing was complaining a lot of about "Type mismatch, "float" does not match with "long". This was when using float to create a running average. The Arduino IDE did not display the same error but maybe over time the teensy does have problems with not having casted the float back to long.

    Also constrain() in the processing IDE also had the about mismatch error. Again Arduino IDE did not.
    I will just replace it with if( > ) checks.

  7. #7
    I finally have physical access to the problem teensy / PCB setup.

    To re-cap.
    I am using PIN A8 as a capacity touch sensor. I have a 1.5 meter cable running to a 3D printed part that is covered in conductive paint. When a person touches the sensor a solenoid starts pulsing.
    Over time when many people have touch the 3D printed part the teensy continuously pulses the solenoid. It never notices that no-one is touching the sensor pad.
    The touch reading is always near the max integer value 65535.

    What I learned now:
    The teensy IC is very hot.
    Uploading new firmware does not work. There is no arrow message when uploading code. It looked like upload worked but the new code was actually not executed on the teensy. Not even a simple blink example.
    Only after unplugging the teensy / PCB from power did the chip get to it's normal temperature and was exception new code.

    Maybe the static electricity from a person puts the teensy in a state of ???
    It's not crashed as the solenoid pulsing still happens and the serial print work.

    The same code without the touch sensing. Some of those teensys also get hot and can't accept new code unless power get's cycled.

    Here is the touch sensing part of my code:
    https://gist.github.com/antimodular/...c08e59274c3dcd

    Here is the schematic:
    Click image for larger version. 

Name:	Screen Shot 2018-12-13 at 1.01.18 PM.jpg 
Views:	10 
Size:	90.7 KB 
ID:	15348
    Last edited by stephanschulz; 12-13-2018 at 05:15 PM.

  8. #8
    Just a quick thought. The NXP touch documents recommend no more than 300 mm (a foot) of lead wire/trace from the chip to the sensor. Your long 1.5 meter cable is way over that limit. Perhaps the touch circuitry is being overloaded by that long a cable. Perhaps it has way too much capacitance. Perhaps it provides too much exposure to potential static electricity, stray EMI, etc.

    Like you, I've tried using long wires (like three or four feet) between a touch pad and the teensy in past experiments. It sort of works, if you control the noise (with perhaps a non-touching grounding pad beneath the sensors that are grounded to your circuit ground) and/or shielded cable. The problem is, you'll get the symptoms you've described (or at least I have seen them), where the values are going along okay, being fairly normal, and then boom! Large spikes to near 65535 which happen for a while and then eventually settle down.

    Long cables connected to Teensy's appear to be a problem. I've heard similar problems with long cables hooked to Raspberry Pi's.


    Perhaps you want to consider dedicating a Teensy LC to the touch sensing and place it near the actual touch pads. NXP documents recommends trying to keep the leads as short as 50mm (a couple of inches) and for sure not over a foot. Then communicate to your other devices via serial connections, for the sensor values. TBH I've never done this, but it's something I'm likely to do in the future for some projects I have in mind.

  9. #9
    Senior Member+ Theremingenieur's Avatar
    Join Date
    Feb 2014
    Location
    Colmar, France
    Posts
    2,385
    The 1.5m cable might be a problem (but for sure not the only responsible for what does actually happen). Since the touch sensor engine of the Teensy works by period measurement of the external pin capacitance, charged and discharged from a constant current source, each single pF of parasitic capacitance (like the one from the cable which might add 150pF for 1.5m) makes the TSI less sensitive and increases the load for the internal oscillator. Thus, the wiring between the Teensy's touch pins and whatever touch sensors should be as short and as airy as possible to reduce parasitic capacitance and thus to prevent overload of the TSI. A human grasping an electrode represents between 150 and 200pF of static capacitance. To detect this in a precise manner, the parasitic capacitance (wiring etc.) should remain below about 1/10 of that.

  10. #10
    Thank you both for your valuable input.
    For now I will unplug the touch sensor and see if the teensy still overheats at points.
    But even went not doing touchRead() did it heat up to the point of not being able to upload new code. (power cycle solved that problem)
    Though I still had the long wire connected to the teensy. So maybe that can mess up things for the teensy.

    Anyway. New test: no long wire attached, no touchRead(), same code.

    Thanks.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •