You are reading a single comment by @Oscar and its replies. Click here to read the full conversation.
  • Yes, I tested the touch sensor with a multimeter. When touched, the voltage between OUT and GND is just slightly lower than between VCC and GND (all around 3.3, 3.2V). And that appears to be the problem!

    I've also tried the same wiring replacing the touch sensor with a regular mechanical push button and the initial code works.

  • Thr 2020.01.02

    from #3 '3.3V input test: I connect D28 to the 3.3V pin of the board or the input pin of the touch sensor (the sensor is fed by the 3.3V pin of the board).'

    Shouldn't this be the 'output' pin of the sensor? Which 'board' is feeding the 3.3v? Are both boards securely grounded to each other?

    'When touched, the voltage between OUT and GND is just slightly lower than between VCC and GND (all around 3.3, 3.2V)'

    As I look over the schematic and datasheet, that is what should be seen. What is the voltage between OUT and GND when no object is on the sensor pad?

    'replacing the touch sensor with a regular mechanical push button and the initial code works.'

    By initial code, are we still referring to the snippet in #1 post?

    There is only one usage L1 of the digitalRead() statement, which really isn't needed, except maybe to test. Is the test then, . . . placing a finger on the sensor, then upload the code to the MDBT42Q? Looking for a 'rising' edge when a pull down is specified inside the setWatch() most likely won't work as the pin is always grounded. How is the mechanical switch connected and what value of external resistor is used?

    Replacing the input with a mechnical switch, when used as described in the last sentence, may provide a false observation. Just shorting the the input pin, will force the use of the internal pull-up/down, depending on the pinMode() setting, which was mentioned to have changed.

    Also, L2 setting the pinMode() after, actually should occur before the read event.

    Your idea #3 post of using a setInterval() has merit, but use a digitalRead() inside. Call pinMode() with 'input' as pointed out in #4 post. The 100K pull down on the cap sensor output won't have an effect on the 13K input pull up (p.151 Rpu nRF52 datasheet) as that output is sourcing high.

About

Avatar for Oscar @Oscar started