This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LDC1614: Improved baseline tracking for button panel applications

Part Number: LDC1614
Other Parts Discussed in Thread: LDC3114,

Hello,

I am working on inductive button sensing based on LDC1614. LDC3114 was not chosen because of much lower sample rate.

The final button panel will have about 33 buttons (metallic snap-domes), and for environmental compensation of component aging

and temperature shift, a button baseline tracking algorithm should run in firmware, similar to the algorithm as described in Ti's application

notes on keypad applications. One constrain is that there can be quick temperature shifts in the environment, so baseline tracking must be

fast enough for compensation purposes.

After a while of thinking about it, I came up with following algorithm- but wondering where the weak points could with such approach because it

seems simplistic:

1.) Initialize the baseline algorithm, so that produced output code settles about zero +/- 1.

2.) Apply fast tracking all the time, without "pause" feature when a button is pressed. Fast enough to compensate for worst case temperature shifts.

3.) When a button is pressed, baseline value jumps over a certain threshold. This event will cause a new state of a button state machine.

4.) Immediately after step as in 3.), reset the baseline value to zero ( in fact overriding continues tracking running somewhat slower in the background).

     At this point, output state of the FSM is still "ON".

5.) Now, when the button is depressed, a negative baseline value is produced about the same magnitude as was seen for button press. This event

     will cause button FSM state change to "OFF". Immediately after that, reset baseline value to zero. Then the system will be ready to accept a 

     new button press.

  • Hello, 

    Your overall method seems like it will work fine but there are a few things you will want to keep in mind when building the algorithm.

    • Depending on how you set the threshold for your button press, you could have a scenario where the baseline is reset before the full force of the button press. This will cause your press to still be offset from your baseline. Since you would be looking for a negative change in this portion of your button state machine, it won't trigger the button release, but it will cause your baseline tracking to shift for an extended button press and possibly cause a 'stuck' state where the release doesn't give enough change to trigger your threshold. 
    • You may be implementing hysteresis naturally by setting your threshold based on the change from each baseline but it would be something to keep in mind when creating the algorithm 
    • The snap domes should force a quick jump in data for the button press so I don't think you will have issues where a user pushes on the button slowly enough for the fast tracking to keep up. This would also be dependent on how fast you need to compensate for temperature so it is worth keeping in mind if the temperature change would occur in roughly the same amount of time for a button press. 

    Best Regards, 

    Justin Beigel

  • Hello,

    Thank you- appreciate your hint on the possibility of a software-locked button. Button timeouts come to mind to deal with it as a safety net, but better of course

    if the timeout would never occur.

    The quick shift in temperature could happen, when the keypad was heated up in direct sunlight, and then submerged in cold water for example. I dont have a thermal
    simulation on this, so best setup will be a bit experimental.

    Regards,

    Jo

  • Hello Justin,

    So I did some testing with proposed method- no production code of course.

    As you have predicted, is is possible to tamper the solution, by actuation the a snap dome extremely gentle (somehow outside the "click-region" )
    and then a button can get locked indeed.

    When this happens, the user can still unlock the button by simply pressing it again because this will set baseline code to zero. Certainly
    not the complete solution to the problem,  but at least the button will not be locked out until next system power cycle.

    Regards,

    Jo

  • Hello Jo, 

    It is good to have the ability to unlock through a new button press. If you need to get rid of the lock scenario all together, your best method would be to change the tracking rate of change or use a lower button press threshold. It may take some testing in your end application to determine the optimal settings for your algorithm. 

    Best Regards, 

    Justin Beigel

  • Hello Justin,

    Appreciate your feedback. After 1 day of testing, I have to admit that it is tricky to implement my idea in a reliable way. So what about this idea: 2 tracking regions, button OFF region and button ON region. Button OFF region will produce baseline code zero, and when button is pressed, baseline code will have an offset eqaual to the to button stroke difference. So during the time a button is hold down, it is still temperature compensated without diverging to zero. Our users are required to press a button for prolonged time, where a sudden temperature shift could happen as well.

  • Hello Jo, 

    I think this implementation would give you a similar result to the first one but you could use the difference as a set threshold instead of dynamically resetting the baseline each press. Since the fast tracking implementation is the main thing that will cause the button to be tricked by a slow press. 

    What is the temperature change and time of change that you are seeing in your application? Also, what sample rate are you using for the buttons? 

    Best Regards, 

    Justin Beigel

  • Hello Justin,

    Agree, the results will be similar to first approach.

    The keyboard is not ready yet, I don't have practical observations on thermal behavior and also no simulation results. A main shift in board (coil)
    temperature and subsequent LC tank frequency is expected when it was warmed up in air under direct sunlight and the submerged in relatively cold water.. 

    Limiting factor of possible sample rate will be I2C comm (400Khz) together with required multiplexing of 13 LDC1614's. With 33 buttons it should still be possible to avoid user notable delays. I did not always take advantage of all 4 provided channels per device, to keep traces to the coils as short as possible.
    This keyboard has no matrix style, the coils are unevenly distributed all over the place because it is a highly specialized application.

    Regards,

    Jo

  • Hello Justin,

    Since at least 2 channels per ldc device are used, and multiple button activation is not required, there is always a free coil which coud be used as a differential channel- maybe not perfect, but could be used to improve temperature drift handling.

    Regards,

    Jo

  • Hello Jo, 

    Once you know your expected temperature change rate, you should have a better idea on how fast you need to keep your baseline tracking and hopefully can find a sweet spot that prevents the slow button press from occurring as easily. The temperature compensation from a reference channel is also a great method for this and can be used in combination with the baseline tracking to give you more information as long as the additional channel does not impact your sample rate or space constraints. 

    Best Regards, 

    Justin Beigel

  • Thank you Justin- Problem solved with your support