I am using AT42QT1070 touch IC in comms mode with I2C communication.I have used 10k pullups with SDA and SCL line and 47k pullup with CHANGE line(active low) as mentioned in datasheet.

The CHANGE line is open-drain and should be connected via a 47 k resistor to Vdd. It is necessary for minimum power operation as it ensures that the QT1070 can sleep for as long as possible. Communications wake up the QT1070 from sleep causing a higher power consumption if the part is randomly polled.

but my change line is always low even when no key is touched.I have used 10k resistance with input keys.

One note in datasheet reads as:

The CHANGE line is pulled low 100 ms after power-up or reset.

but the time for which i will remain low is not mentioned anywhere... is it through normal status read by host.If so it will be hell of a task for host to read after power up if a number of devices are connected.

I cannot figure out why CHANGE line is always low.


Data sheet says:

The CHANGE line is active low and signals when there is a change of state in the Detection or Input key status bytes. It is cleared (allowed to float high) when the host reads the status bytes. If the status bytes change back to their original state before the host has read the status bytes (for example, a touch followed by a release), the CHANGE line will be held low. In this case, a read to any memory location will clear the CHANGE line

So even though the power-up situation is not covered explicitly, I'd say it's a safe bet that you need to read the device to clear the power-up /CHANGE setting.

Why do you believe it to be a "hell of a task" for the host to do this?

  • \$\begingroup\$ i tried doing that also but it remains high for a few milli seconds and goes back to low level again.....with no key in touch state (touched key generates a low on CHANGE) i find it little bit messy reading all the i2c devices after power up... \$\endgroup\$ – Nirmala Apr 20 '14 at 6:31
  • \$\begingroup\$ Then it seems that the read-after-power-up is needed, and there's some additional problem that needs addressing. Any chance there's something that is repeatedly reseting the chip, either software or on the RESET line? Have you explored commanding the chip to do the calibration process, which the datasheet says can be needed to free a stuck key? Indeed, after you read, and the chip asserts CHANGE, what data are you actually reading from it -- is it consistently a particular key or keys? Seems like there a few troubleshooting avenues here. \$\endgroup\$ – gwideman Apr 20 '14 at 6:47
  • \$\begingroup\$ I have connected the reset pin to Vdd using a 10k resistance...in software my code just reads a location from its memory.I am reading a status byte from location 3 which stores the status of all pins( touched(1) or not touched(0)).I will try doing recalibration once i am sure that the problem is not from circuit side. \$\endgroup\$ – Nirmala Apr 20 '14 at 7:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.