I have an application where a push button and mechanical grey-code rotary encoder(user inputs) need to mounted away from main pcb. 24" - 48" away. This is for space and packaging reasons.
Is it OK to have the debouncing RC circuit on the PCB and the switches/encoder remotely connected via cable, or does the debouncing circuit need to be with the switches?
Encoder circuit from datasheet:
The debouncing (and any noise filtering, ESD protection circuits) should be on the main PCB.
The switches themselves don't need anything local to them, nor would be be optimal to have additional circuitry there.
Edit: If the Gray code encoder is active (optical or magnetic) some remote circuitry might be useful- certainly supply bypassing, maybe some series resistors on the outputs, perhaps even a local supply regulator.
Since you mentioned "application", I'm going to assume you are running code here which monitors the buttons and contacts. If that is the case I can tell you from my experience that it better to do your de-bouncing programmatically. Consider developing a function that you occasionally call to check for button hits. Without delving into any particular language, what the function would do is this...
Thats all there is too it. You've not only saved yourself at least 2 components per button (the RC network), and have effectively created a "brick wall" filter, much more precise and consistent than the RC network would be. In addition, you have made it very easy to change the all important debounce time without de-soldering parts.
One note on this methodology, it is also possible to call a similar function by interrupt instead of calling it as part of a round-robin sequence in your main program loop. In my opinion this is NOT a good idea, because a defective noisy contact would generate lots of interrupts which could easily bog down your program. Generally in larger systems where an interrupt actually does report button hits (like a keyboard interrupt in a computer), the button hits have already been pre-processed by a small dedicated MCU in the keyboard itself. If you're doing it in a smaller system, and doing ALL the de-bounce yourself, the method I'm suggesting is a better choice.
Whether it's better to handle button debounce programmatically, in hardware, or a combination of the two, depends upon the nature of the bounce. Some kinds of button have a resistance which can change erratically as they are pushed; if they are pushed slowly, this erratic period can be spread over a substantial fraction of a second. If a processor can distinguish between a low resistance, high resistance, and open-circuit, ignoring button presses until low resistance is detected, and ignoring releases until open-circuit is detected, will work well. If a processor cannot make such distinctions, however, there may be a limit to much software alone can do without some extra hardware.
The most robust approach in many cases is to design a system with both normally-open and normally-closed contacts; such an approach can yield near zero quiescent current in both the button-pushed and button-not-pushed states, while suffering from essentially zero bounce of any form. I see no technical impediment to designing a rotary encoder with similar functionality, but I don't know of any such encoders in existence.
