RoadTest: Seeking an Engineer to Evaluate Infineon's PSOC 4100T Plus Prototyping Kit
Author: AngelSoto
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: No direct comparison with other capacitive sensing products was performed in this evaluation.
What were the biggest problems encountered?: .
Detailed Review:
on the PSoC 4100T Plus Prototyping Kit| Document Information | |
|---|---|
| Author | Ángel Soto Boullosa |
| Date | March 2026 |
| Revision | v1.0 |
A hands-on evaluation of the kit, development workflow under Linux, and real-time CAPSENSE signal analysis using ModusToolbox.
The Infineon CY8CPROTO-041TP PSoC 4100T Plus CAPSENSE Prototyping Kit is designed to demonstrate capacitive sensing capabilities while providing a compact development platform for embedded applications.
This review evaluates the out-of-the-box experience, the installation of the development environment under Linux, and the initial functional behaviour of the capacitive sensing features included in the kit. Particular attention is given to ease of setup, hardware design quality, and the practical usability of the provided demonstration firmware.
The goal of this review is to assess how quickly a developer can move from unboxing the board to interacting with the capacitive sensing features and preparing the development environment for further experimentation.
The evaluation started with the unboxing of the CY8CPROTO-041TP PSoC 4100T Plus CAPSENSE Prototyping Kit.
The packaging is compact and well protected, ensuring that the development board and accessories arrive in good condition. The first inspection revealed a clean and carefully packaged kit containing the development board and the required USB-C cable for immediate operation.
Figure 1 : Kit packaging (closed)
Figure 2 : Kit package (alternate view)
Figure 3 : Kit contents overview
Following the CY8CPROTO-041TP PSoC 4100T Plus CAPSENSE Prototyping Kit Guide, the kit was powered using the provided USB-C cable to run the pre-programmed Out-of-Box example CE240380.
The experience of running the example firmware was immediately positive. The demonstration starts automatically after powering the board, with the LEDs reacting to the capacitive sensing inputs. The behaviour is intuitive and encourages curiosity about the internal implementation and potential integration into real projects.
Figure 4 : PCB overview
The PCB layout is clean and well organized. Component placement follows a consistent orientation, and the silkscreen markings are clear and readable, which makes component identification easy during inspection and debugging.
Pin headers are easily accessible and sufficiently separated from other components, facilitating the connection of external circuits during prototyping.
Figure 5 : Capacitive touchpad and proximity sensor
Figure 6 : Capacitive buttons area
A particularly interesting aspect of the board design is its modular layout. The MCU section, sensing modules, and programmer are integrated in a way that suggests that the main MCU board could potentially be separated if required, allowing developers to reuse only the necessary section in a custom prototype.
Figure 7 : USB-C connector and onboard programmer
Video 1 : Power-up sequence showing the time from board startup to demo activation
From a usability perspective, the time from power-up to visible operation of the demo firmware was essentially instantaneous. The board began responding to touch inputs in less than 0.3 seconds, without requiring any manual calibration.
Initial functional testing of the capacitive sensors showed stable and reliable behaviour in a typical domestic environment.
Overall, the out-of-the-box experience is excellent. The board can be powered and tested within seconds, which makes the kit particularly suitable for rapid evaluation and educational demonstrations of capacitive sensing technology.
The next step was installing the ModusToolbox development environment.
Since the development machine runs Linux, the .deb installation package was downloaded and installed following the instructions provided in the official documentation.
Figure 8 : ModusToolbox installation process
Installation was performed using:
sudo apt install ./ModusToolboxSetupInstaller_1.5.0.<build>_linux_x64.debAfter launching the ModusToolbox Setup utility, the installer guided the process of selecting and installing the required toolchains and software components.
Figure 9 : ModusToolbox Setup initial screen
Figure 10 : Package selection screen
Figure 11 : Package installation progress
During installation, the Setup Tool reported a crash while installing the Programming Tools package. However, further inspection confirmed that the required binaries were successfully installed under:
/opt/Tools/ModusToolboxProgtools-1.7/This suggests that the installer reported an ambiguous status rather than an actual installation failure.
Once the installation was completed, the kit was connected to the system. The board was automatically recognized by Linux as a KitProg3 CMSIS-DAP debugging interface.
Figure 12 : USB device detection using lsusb
USB enumeration confirmed the device with:
Vendor ID: 04b4
Product ID: f155
Figure 13 : Kernel detection using dmesg
Kernel messages confirmed the successful detection of the device and the creation of a USB CDC serial interface:
usb 1-8: New USB device found, idVendor=04b4, idProduct=f155
Product: KitProg3 CMSIS-DAP
Manufacturer: Cypress Semiconductor
cdc_acm 1-8:1.2: ttyACM0: USB ACM device
Figure 14 : Serial interface exposed as /dev/ttyACM0
The presence of the /dev/ttyACM0 device confirms that the onboard programmer and serial communication interface are functioning correctly, allowing both firmware programming and runtime communication with the board.
Overall, the development environment installation under Linux was straightforward and the hardware was detected correctly without requiring additional drivers.
While functional, the installation workflow could benefit from clearer error reporting and more robust package validation, particularly when handling partial installation failures.
To evaluate the CAPSENSE functionality in more detail, a new project was created using the ModusToolbox Project Creator utility.
Figure 15 : Launching the Project Creator tool from the terminal
The Project Creator graphical interface allows selecting the target board and example firmware.
Figure 16 : ModusToolbox Project Creator interface
The CY8CPROTO-041TP board was selected as the hardware platform.
Figure 17 : Board selection inside the Project Creator
The example project corresponding to the board demonstration firmware was then selected.
Figure 18 : Selecting the CY8CPROTO-041TP demonstration project
The tool generated the workspace and project files required for development.
Figure 19 : Project creation log
The generated project workspace was opened in Visual Studio Code, which is the default development environment used by ModusToolbox.
Figure 20 : Opening the ModusToolbox workspace in Visual Studio Code
The firmware was compiled using the integrated ModusToolbox build system.
Figure 21 : Selecting the build command
Figure 22 : Compilation command executed by the build system
Figure 23 : Firmware compilation log
After compilation, the firmware was programmed to the board using the onboard KitProg3 debugger.
Figure 24 : Programming command executed from the development environment
The programming process detected the target device correctly as CY8C4147AZQ-T495, belonging to the PSoC 4100T Plus family.
Figure 25 : Programming log showing device detection and flashing process
The flashing process completed successfully and the firmware verification step confirmed the correct upload.
During the programming process, the tool also reported that the onboard KitProg3 firmware was not at the latest available version and suggested an update using the fw-loader utility.
However, this did not prevent device detection, flashing or verification. For the purposes of this evaluation step, no programmer firmware update was required, since the complete programming flow executed successfully.
This warning is worth noting for completeness, but it had no practical impact on the evaluation.
Figure 26 : Firmware verification after programming
The CY8CPROTO-041TP kit integrates two capacitive sensing interfaces directly on the PCB: a touchpad and a proximity sensor. Both are exercised by the factory demonstration firmware and represent the core human-machine interaction features evaluated in this stage of the RoadTest.
The first objective of this step was to verify the practical behaviour of these sensing elements under normal indoor conditions. The second objective was to inspect the project structure, configuration and application code provided by Infineon in order to understand how these sensing functions are implemented within the ModusToolbox environment.
Several simple repeatability tests were carried out using the pre-programmed demonstration firmware.
Number of attempts: 50
| Metric | Result |
|---|---|
| Correct detections | 50 |
| False triggers | 0 |
| Missed inputs | 0 |
The touchpad responded reliably during all attempts, with no missed activations and no unintended triggers observed during the test sequence. Directional interaction was immediate and intuitive, making the interface easy to understand even without prior knowledge of the firmware implementation.
Number of attempts: 50
| Metric | Result |
|---|---|
| Correct detections | 50 |
| False triggers | 0 |
| Approximate detection distance | ~2.4 cm |
The proximity sensing area consistently detected the presence of a hand within the expected range. Detection remained stable and predictable throughout the measurement sequence, with no spurious activations recorded during the test.
To evaluate robustness over time, the system was left running for a 15-minute observation period.
During this period:
These results suggest that the capacitive sensing implementation used in the demonstration firmware is robust and appropriately calibrated for normal indoor operation.
The touchpad exhibited immediate response to finger contact and released detection as soon as the finger was removed. No noticeable latency or hysteresis was observed during use.
The proximity sensor detected a hand at approximately 2–3 cm above the sensing area. In practical terms, this produced a responsive but controlled interaction zone, which is suitable for simple contactless interaction.
An important practical observation during the evaluation was that the proximity sensor could remain active when the board was placed directly on a table surface. This behaviour is consistent with the operating principle of capacitive sensing, since nearby materials and mounting conditions can affect the electric field around the sensing electrode.
Rather than being a defect of the kit, this is a useful real-world demonstration of an important design consideration: capacitive sensors must always be evaluated together with their mechanical placement, surrounding materials and enclosure geometry.
For final applications, this means that proximity performance should not be judged only from firmware parameters, but also from the intended mounting environment.
For the next stage of the review, a conceptual mapping was defined to translate capacitive inputs into robot-control actions.
| Sensor Input | Control Command | Intended Action |
|---|---|---|
| Touchpad Up | Forward | Move robot forward |
| Touchpad Down | Backward | Move robot backward |
| Touchpad Left | Turn Left | Rotate robot left |
| Touchpad Right | Turn Right | Rotate robot right |
| Proximity Sensor | Speed control | Increase speed when the hand approaches |
This mapping has not yet been implemented in custom firmware, but it provides a simple and intuitive basis for the robotic integration stage of the evaluation.
To better understand the sensor implementation, the provided project configuration was inspected within the ModusToolbox-generated design files.
The project defines a dedicated capacitive sensing subsystem that includes:
Inspection of the design configuration confirmed that the touchpad is implemented as a matrix structure with multiple rows and columns, while the proximity function is implemented as a dedicated sensor node. The design file explicitly defines signals such as:
Touchpad0_Row0 to Touchpad0_Row3Touchpad0_Col0 to Touchpad0_Col4Proximity0_Sns0These definitions are fully consistent with the behaviour observed during functional testing.
Key characteristics observed from the configuration are summarized below:
| Parameter | Description |
|---|---|
| Sensor type | Self-capacitance based sensing structure |
| Scan method | Dedicated hardware-assisted capacitive scanning |
| Widgets / sensor groups | Touchpad + Proximity |
| Signal routing | Explicit row/column and sensor-node assignment in the design |
| Integration | Native support within the PSoC hardware and ModusToolbox flow |
The use of hardware-assisted capacitive scanning reduces software overhead and helps maintain reliable operation even when multiple sensing elements are present.
<Personality template="m0s8mscv3lp" version="3.0">
<Block location="msclp[0].msclp[0]" locked="true">
<Aliases>
<Alias value="CYBSP_MSC"/>
</Aliases>
</Block>
<Parameters>
<Param id="SensorCount" value="15"/>
<Param id="SensorName10" value="Touchpad0_Row0"/>
<Param id="SensorName11" value="Touchpad0_Row1"/>
<Param id="SensorName12" value="Touchpad0_Row2"/>
<Param id="SensorName13" value="Touchpad0_Row3"/>
<Param id="SensorName14" value="Proximity0_Sns0"/>
<Param id="SensorName5" value="Touchpad0_Col0"/>
<Param id="SensorName6" value="Touchpad0_Col1"/>
<Param id="SensorName7" value="Touchpad0_Col2"/>
<Param id="SensorName8" value="Touchpad0_Col3"/>
<Param id="SensorName9" value="Touchpad0_Col4"/>
</Parameters>
</Personality>
<Personality template="m0s8mscv3lpsuperblock" version="1.0">
<Block location="msclp[0].msclp_superblock[0]" locked="true">
<Aliases>
<Alias value="CYBSP_CAPSENSE"/>
</Aliases>
</Block>
</Personality>Listing 1 – Extract from the ModusToolbox design file showing the CAPSENSE touchpad matrix and proximity sensor definitions
This configuration extract confirms that the example project defines a matrix touchpad with four rows and five columns, together with a dedicated proximity sensing channel.
The application source code confirms that the CAPSENSE subsystem is not only statically defined in the configuration files, but also actively managed in firmware through a clear scan-and-process sequence.
The main loop performs the following operations:
This behaviour is implemented through functions such as:
Cy_CapSense_ScanAllSlots(&cy_capsense_context);
Cy_CapSense_ProcessAllWidgets(&cy_capsense_context);
Cy_CapSense_IsWidgetActive(CY_CAPSENSE_TOUCHPAD0_WDGT_ID, &cy_capsense_context);
Cy_CapSense_IsWidgetActive(CY_CAPSENSE_PROXIMITY0_WDGT_ID, &cy_capsense_context);
Cy_CapSense_GetTouchInfo(CY_CAPSENSE_TOUCHPAD0_WDGT_ID, &cy_capsense_context);Listing 2 – CAPSENSE firmware scan and processing sequence
This is particularly relevant because it shows that the touchpad is handled as a positional widget rather than as a simple binary button. The firmware reads touch coordinates and uses them to modulate LED behaviour. Likewise, the proximity widget is not treated only as an ON/OFF event, but is also used to generate proportional visual feedback based on the measured signal level.
Another interesting aspect is that the example firmware integrates CAPSENSE operation with a low-power state machine. The code transitions between ACTIVE, ALR (Active-Low Refresh Rate) and WOT (Wake-on-Touch) modes, which demonstrates how capacitive sensing can be combined with power-aware embedded design.
Overall, the firmware structure reinforces the impression that this is not a minimal demonstration, but a reasonably complete reference example showing sensing, processing, feedback and low-power operation together.
Capacitive sensing provides an attractive alternative to traditional mechanical buttons, particularly in systems where:
In this kit, the combination of a directional touchpad and a proximity sensor provides a practical demonstration of how an embedded system can expose intuitive control functions with minimal external hardware.
This makes the approach especially suitable for:
Overall, the capacitive sensing implementation on the CY8CPROTO-041TP proved to be stable, responsive and technically well integrated into both the hardware platform and the development flow.
To further analyse the behaviour of the capacitive sensors, the CAPSENSE Tuner tool included with ModusToolbox was used. This tool allows real-time inspection of internal CAPSENSE signals such as raw counts, baseline levels, signal strength and widget status.
The tuner provides direct access to the internal sensor data structures used by the firmware, making it possible to observe how the touchpad and proximity sensors respond during interaction.
Within the ModusToolbox environment, the CAPSENSE subsystem appears under the System configuration panel.
Figure 27 : CAPSENSE configuration within the Device Configurator
The configuration interface exposes both the CAPSENSE Configurator and the CAPSENSE Tuner, which are used respectively for sensor configuration and real-time signal analysis.
Additional inspection of the device configurator also reveals the presence of the analog subsystem used by the capacitive sensing hardware.
Figure 28 : Analog subsystem related to the CAPSENSE hardware
The CAPSENSE subsystem itself is visible as a dedicated configuration block.
Figure 29 : CAPSENSE subsystem inside the device configuration
When the CAPSENSE Tuner is launched for the first time, communication parameters must be configured before connecting to the device.
Figure 30 : CAPSENSE Tuner communication configuration
During initial testing, the connection briefly reported a successful link before a timeout occurred.
Figure 31 : Initial CAPSENSE Tuner timeout during connection
Further inspection of the firmware revealed the reason for this behaviour. The example firmware does not use UART for tuner communication, but instead exposes the CAPSENSE data structure through the SCB peripheral configured in EZI2C mode.
This can be observed directly in the application source code:
Cy_SCB_EZI2C_Init(CYBSP_EZI2C_HW, &CYBSP_EZI2C_config, &ezi2c_context);
Cy_SCB_EZI2C_SetBuffer1(CYBSP_EZI2C_HW,
(uint8_t *)&cy_capsense_tuner,
sizeof(cy_capsense_tuner),
sizeof(cy_capsense_tuner),
&ezi2c_context);Listing 3 – EZI2C-based CAPSENSE Tuner communication configuration
These calls configure the SCB peripheral as an I²C slave interface, exposing the CAPSENSE tuner data structure (cy_capsense_tuner) to external tools.
In this architecture, the KitProg3 programmer acts as a USB-to-I²C bridge, allowing the CAPSENSE Tuner application to read sensor data directly from the device memory.
The communication path can therefore be summarized as:
Figure 32 : Communication path diagram in the CAPSENSE Tuner
Once the correct communication settings were selected, the tuner connected successfully to the board.
Figure 33 : Successful connection between CAPSENSE Tuner and the board
After connecting, the CAPSENSE Tuner displays the available widgets defined in the project.
Figure 34 : CAPSENSE widgets detected by the tuner
The example project exposes several sensing elements, including:
The tool allows observation of raw sensor data, baseline values and processed signals in real time.
When interacting with the touchpad, the tuner shows the positional widget response and signal variation.
Figure 35 : Touchpad activity observed in the CAPSENSE Tuner
Note: The X-axis position reported by the touchpad is inverted with respect to the physical left-to-right orientation of the printed text on the board. For example, touching the right-hand side of the touchpad corresponds to a low X-column index in the widget view.
The tuner confirms that the touchpad is implemented as a positional widget, reporting X and Y coordinates corresponding to the touch location.
This behaviour matches the firmware implementation, which retrieves positional information through:
Listing 4 – CAPSENSE touchpad information retrieval using Cy_CapSense_GetTouchInfo()
The positional data is then used by the firmware to modulate LED brightness according to touch position.
The proximity sensor can also be observed in real time using the tuner.
Figure 36 : Proximity sensor response observed in the CAPSENSE Tuner
As the hand approaches the sensing area, the signal level increases proportionally. This confirms that the proximity sensor is not treated only as a binary ON/OFF input, but rather as a continuous signal whose amplitude depends on the distance of the object from the sensing electrode.
Using the CAPSENSE Tuner provided several useful insights:
The tuner proved to be a powerful debugging and learning tool, allowing developers to inspect the internal behaviour of the capacitive sensing subsystem without modifying the firmware.
In order to evaluate the CAPSENSE interface in a practical scenario, a small robotic control platform was used as the target system.
Before introducing the capacitive interface, an existing control architecture based on a traditional digital joystick was used as the reference implementation. This baseline system provides a working communication pipeline between a human input device and the robot controller.
The objective of the next stage is therefore not to design a completely new control system, but rather to replace the joystick input stage with the capacitive sensing interface provided by the PSoC kit.
The current control setup is composed of three main elements:
The joystick controller reads directional inputs and transmits movement commands through a UART interface connected to a Bluetooth module.
The communication flow is therefore:
Figure 37 : Communication flow diagram
This architecture separates the human interface layer from the robot actuation layer, which makes it straightforward to replace the input device without modifying the robot control firmware.
The reference implementation uses a digital joystick with four directional switches:
Each switch is connected to a digital input configured with internal pull-up resistors.
When a direction is pressed, the controller sends a simple textual command over UART:
| Direction | Transmitted command |
|---|---|
| Up | UP |
| Down | DOWN |
| Left | LEFT |
| Right | RIGHT |
| No input | STOP |
This approach intentionally keeps the communication protocol extremely simple, which simplifies debugging and makes the signal easy to observe using external instrumentation.
The joystick firmware implements a simple directional state machine.
A direction is transmitted only when the detected input state changes, which avoids unnecessary serial traffic.
static void send_direction(joystick_direction_t dir)
{
switch (dir)
{
case DIR_UP:
Serial1.println("UP");
Serial.println("UP");
break;
case DIR_DOWN:
Serial1.println("DOWN");
Serial.println("DOWN");
break;
case DIR_LEFT:
Serial1.println("LEFT");
Serial.println("LEFT");
break;
case DIR_RIGHT:
Serial1.println("RIGHT");
Serial.println("RIGHT");
break;
default:
Serial1.println("STOP");
Serial.println("STOP");
break;
}
}Listing 5 – Joystick command transmission routine implemented on the Arduino Leonardo
This simple protocol provides a reliable and easy-to-debug interface between the input controller and the robot firmware.
To verify correct operation of the communication system, the joystick controller was instrumented using external measurement tools.
The setup included:
Figure 38 : Digital joystick controller connected to measurement instruments
This setup allowed direct observation of the digital signals generated by the controller while interacting with the joystick.
To better understand the behaviour of the mechanical joystick interface, the signals were analyzed using external measurement instruments.
The objective of this step was to evaluate one important aspect:
During testing, the transmitted commands were monitored through the serial interface.
Figure 40 : UART output showing transmitted movement commands
Each directional input generates a corresponding command (UP, DOWN, LEFT, RIGHT) followed by a STOP message when the joystick button is released.
The observed sequence confirms correct operation of the firmware state machine and proper serial communication between the controller and the robot platform.
To inspect the electrical behaviour of the joystick switches, the input signals were captured using a digital oscilloscope.
Figure 41 : General view of joystick signal activity
The captured waveform shows the transition of the digital signal when the joystick switch is pressed.
Additional measurements were performed on individual axes.
Figure 42 : Oscilloscope capture of the signal rise time
Figure 43 : Oscilloscope capture of the signal amplitude
The measurements show that the joystick behaves as a typical mechanical switch input, where the signal transitions from a pull-up idle state to ground when pressed.
Thanks to the firmware debounce mechanism implemented in the controller, no unstable transitions or repeated command transmissions were observed during normal operation.
From the measurements performed, several observations can be made:
direction → STOP sequence)These measurements confirm that the joystick interface provides a reliable baseline for the control system.
This baseline behaviour is particularly useful, as it establishes a measurable reference point before introducing the capacitive sensing interface.
…
In the following section, the mechanical joystick will be replaced by the CAPSENSE touchpad interface provided by the CY8CPROTO-041TP kit, while keeping the same UART command protocol.
With the baseline joystick interface fully characterized, the next step of the evaluation consisted of replacing the mechanical joystick with the capacitive sensing interface provided by the CY8CPROTO-041TP CAPSENSE Prototyping Kit.
The objective of this stage was to determine whether the CAPSENSE touchpad could reproduce the same directional control behaviour while simplifying the hardware interface.
Rather than modifying the robot firmware, the same UART command protocol used by the joystick controller was preserved.
This ensures that only the human input subsystem is replaced, while the rest of the robotic platform remains unchanged.
In the new configuration, the PSoC device acts as the human-machine interface controller.
The communication path became:
Figure 44 : Communication path diagram
This architecture kept the overall system structure identical to the original joystick implementation.
Only the input device was replaced.
The intended architecture for the migration was to keep the same command path previously used by the joystick controller, replacing only the human input device with the CAPSENSE touchpad.
In that target configuration, the CY8CPROTO-041TP kit would generate the same motion commands as the joystick subsystem and forward them to the rest of the robotic platform without requiring changes in the downstream control chain.
However, in this evaluation, the validation was simplified at firmware level. Instead of completing the full UART/Bluetooth integration, the processed touchpad output was observed on an instrumented LED control pin already available on the board.
This approach made it possible to validate the most critical part of the migration: the conversion of touch interaction into discrete control states. Since the Bluetooth bridge and robot-side command handling remain unchanged from the baseline implementation, confirming correct command generation at the PSoC output stage is sufficient to evaluate the feasibility of the migration.
Figure 45 : Experimental setup used for CAPSENSE integration tests
Figure 46 : Instrumented LED-related output used for oscilloscope observation
To observe the internal behaviour of the CAPSENSE processing logic during touch detection, the example firmware provided with the kit was slightly modified.
In the original firmware, the touchpad widget controls LED brightness using PWM to visually represent the finger position on the pad. For measurement purposes, this behaviour was repurposed so that the PWM output encodes the detected directional command.
Each detected direction is translated into a distinct PWM compare value. This allows the oscilloscope to identify the generated command by simply observing the output signal level.
This instrumentation provides a convenient method to externally monitor the firmware decision process without altering the CAPSENSE acquisition or processing pipeline.
The modified LED control routine used to perform this mapping is shown in the following section.
The CAPSENSE touchpad provides a two-dimensional input surface whose position coordinates can be interpreted as directional commands.
The firmware reads the touch position (X,Y) reported by the CAPSENSE touchpad widget and converts it into discrete directional states by dividing the touch surface into four regions.
The following mapping was implemented:
| Touchpad Region | Command | Robot Action |
|---|---|---|
| Upper area | UP |
Move robot forward |
| Lower area | DOWN |
Move robot backward |
| Left area | LEFT |
Rotate robot left |
| Right area | RIGHT |
Rotate robot right |
| No touch | STOP |
Stop robot |
This mapping allowed the touchpad to behave similarly to the previous digital joystick interface.
Because the command protocol remains unchanged, the robot controller firmware does not require modification.
The CAPSENSE firmware processes the touchpad widget and converts detected touch positions into directional commands.
The touch coordinates (X,Y) provided by the CAPSENSE middleware are interpreted by the get_touch_direction() function, which classifies the touch position into one of the predefined directional states.
In the intended final architecture, these directional states would be translated into the same UART messages previously used by the joystick controller:
UP
DOWN
LEFT
RIGHT
STOPHowever, in this implementation, the commands are encoded using different PWM output levels on an available LED control pin. Each direction corresponds to a specific PWM compare value, allowing the generated command to be easily identified using an oscilloscope.
This approach provided a simple and non-intrusive way to observe the firmware behaviour while keeping the CAPSENSE acquisition and processing pipeline unchanged.
The modified LED control function used for this instrumentation is shown below.
/*******************************************************************************
* Function Name: led_control
********************************************************************************
* Summary:
* Control LED2, LED3, LED5 and LED6 in the kit to show the CSD button, CSX button,
* Touchpad , Proximity and Ambient Light Sensor status:
* -----------------------------------------------------------------------------------------------------------------------
* | Widget | LED 2 | LED 3 | LED 5 | LED 6 |
* | CSD Button | OFF | ON | OFF | OFF |
* | CSX Button | ON | OFF | OFF | OFF |
* | Touchpad | ON with brightness | ON with brightness | OFF | OFF |
* | | corresponding to touch | corresponding to touch | | |
* | | position on touchpad | position on touchpad | | |
* | Proximity | OFF | OFF | ON with brightness | OFF |
* | | | | corresponding to | |
* | | | | proximity distance | |
| ALS | OFF | OFF | OFF | ON with brightness |
| | | | | corresponding to ambient|
| | | | | light present |
* -----------------------------------------------------------------------------------------------------------------------
*
*******************************************************************************/
void led_control()
{
cy_stc_capsense_touch_t *touchpad_touch_info;
uint16_t x;
uint16_t y;
touch_direction_t dir;
/* Clear unused LED output */
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM0_HW, CYBSP_PWM0_NUM, 0);
if(Cy_CapSense_IsWidgetActive(CY_CAPSENSE_TOUCHPAD0_WDGT_ID, &cy_capsense_context))
{
touchpad_touch_info = Cy_CapSense_GetTouchInfo(CY_CAPSENSE_TOUCHPAD0_WDGT_ID, &cy_capsense_context);
x = touchpad_touch_info->ptrPosition->x;
y = touchpad_touch_info->ptrPosition->y;
dir = get_touch_direction(x,y);
}
else
{
dir = DIR_STOP;
}
/* Convert direction to PWM level */
switch(dir)
{
case DIR_UP:
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, 64);
break;
case DIR_DOWN:
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, 128);
break;
case DIR_LEFT:
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, 192);
break;
case DIR_RIGHT:
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, 255);
break;
default:
Cy_TCPWM_PWM_SetCompare0(CYBSP_PWM1_HW, CYBSP_PWM1_NUM, 0);
break;
}
}Listing 6 – Modified led_control() routine used for CAPSENSE directional signal encoding
To validate the correct operation of the CAPSENSE interface, a series of functional checks were performed.
First, the touchpad behaviour was verified using the CAPSENSE Tuner tool to confirm that the widget correctly detected finger position across the sensing surface.
Once correct touch detection was confirmed, the firmware output corresponding to each directional command was observed using an oscilloscope connected to the instrumented LED output pin.
The following checks were performed:
These measurements allow the internal firmware decisions to be externally verified, ensuring that the capacitive interface produces consistent and reproducible control signals.
The experimental results confirmed that the CAPSENSE touchpad could successfully reproduce the directional behaviour of the original mechanical joystick.
The oscilloscope measurements show clearly distinguishable output levels corresponding to each directional command. These levels match the PWM encoding implemented in the firmware and provide a clear electrical representation of the detected touch direction.
Observations made with the CAPSENSE Tuner also confirm stable detection of finger position across the touchpad surface, allowing reliable classification of directional inputs.
Compared to the mechanical joystick, the capacitive interface offers several advantages:
Because the command protocol remains unchanged, the robotic platform can interpret the generated commands exactly as in the original joystick implementation. This demonstrates that the CAPSENSE touchpad can act as a drop-in replacement for traditional mechanical input devices in embedded control systems.
This result confirms that capacitive sensing is not only a viable alternative to mechanical inputs, but also provides additional flexibility in interface design without increasing system complexity. In addition, the absence of mechanical components eliminates switch wear and simplifies long-term reliability considerations.
The following figures show the processed CAPSENSE output signal observed on the LED pin for the idle state and the four directional positions.
Figure 47 : CAPSENSE signal rise edge
Figure 48 : CAPSENSE signal rise time
Figure 49 : CAPSENSE signal amplitude
Center position:
Figure 50 : CAPSENSE widget center position detected
Figure 51 : CAPSENSE center position PWM value observed in the oscilloscope
Up direction:
Figure 52 : CAPSENSE widget up position detected
Figure 53 : CAPSENSE up position PWM value observed in the oscilloscope
Down direction:
Figure 54 : CAPSENSE widget down position detected
Figure 55 : CAPSENSE down position PWM value observed in the oscilloscope
Right direction:
Note: see Section 5.4 regarding X-axis inversion.
Figure 56 : CAPSENSE widget right position detected
Figure 57 : CAPSENSE right position PWM value observed in the oscilloscope
Left direction:
Note: see Section 5.4 regarding X-axis inversion.
Figure 58 : CAPSENSE widget left position detected
Figure 59 : CAPSENSE left position PWM value observed in the oscilloscope
In order to replace the mechanical joystick with a capacitive interface, the PSoC firmware was extended to support UART-based command transmission over a Bluetooth serial link.
Figure 60 : PSoC CAPSENSE kit with Bluetooth module connected for UART communication
In the initial validation stage, directional information was encoded as PWM signals and observed using an oscilloscope. While this approach was useful for early verification, it was not suitable for direct integration with the robotic platform.
To address this, one of the SCB peripherals was configured in UART mode (9600 baud), enabling direct transmission of control commands. The CAPSENSE touchpad position is processed in real time to determine the dominant movement direction based on displacement from the center. A dead zone was introduced to prevent noise and unintended movements.
The detected direction is mapped to textual commands:
UPDOWNLEFTRIGHTSTOPNote: The LEFT and RIGHT commands are included for compatibility with a different robotic platform featuring omnidirectional (holonomic) wheels. However, for the purposes of this validation, a standard differential-drive robot with forward and backward motion was sufficient to demonstrate the system functionality.
To optimize communication efficiency, commands are transmitted only when a change in direction is detected, implementing a lightweight state-machine approach. This minimizes UART traffic while maintaining responsiveness.
The UART output is connected to a Bluetooth serial module, enabling wireless communication with the robot controller. This design preserves compatibility with the original command protocol used by the joystick-based system.
Figure 61 : 4WD robot platform with Arduino motor shield and Bluetooth module
On the receiver side, the Arduino-based robot controller was already implemented.
The system was originally designed to operate with a simple command interface (UP, DOWN, etc.), independent of the input device used to generate those commands.
By implementing the CAPSENSE interface on the PSoC side and adhering strictly to the same communication protocol, the integration was effectively plug-and-play. The robot responded immediately to the new input method without requiring any modifications to the existing control firmware.
This demonstrates a clean separation between the input layer and the control logic, enabling seamless substitution of the original mechanical joystick with the capacitive touch interface.
Figure 62 : Robot movements controlled via CAPSENSE touchpad over Bluetooth
A complete end-to-end validation was performed, demonstrating the full system from capacitive input to robotic actuation.
In this demonstration, the CAPSENSE touchpad replaces the mechanical joystick as the control interface. User interaction is detected by the PSoC device, translated into directional commands, and transmitted wirelessly via Bluetooth to the robot.
The robot responds in real time, executing movements with smooth acceleration profiles. The system demonstrates stable and responsive behaviour despite the event-based communication model.
This confirms that capacitive sensing interfaces can effectively replace traditional input devices while maintaining compatibility with existing control architectures.
The transition from the initial PWM-based validation setup to the final implementation represents a shift from signal-level verification to complete system integration.
Instead of relying on low-level signal observation, the system now operates through a well-defined high-level command interface (UP, DOWN, etc.), enabling direct and meaningful interaction between the user input and the robotic platform.
The key result is the validation of a modular architecture, where the control system is decoupled from the input method. By adhering to the existing communication interface, the CAPSENSE-based controller was integrated seamlessly and operated as expected from the first test, without requiring any changes on the receiver side.
This confirms that a properly defined command layer enables true plug-and-play behaviour, simplifying system evolution and allowing alternative input technologies to be incorporated with minimal effort.
Overall, this approach demonstrates how capacitive sensing interfaces can be effectively integrated into existing embedded systems through a clear and stable communication abstraction.
In addition to the capacitive touchpad and proximity sensor integrated on the main development board, the CY8CPROTO-041TP kit includes support for additional sensing demonstrations through expansion boards and example projects.
These demonstrations extend the capabilities of the CAPSENSE subsystem and illustrate how capacitive sensing can be adapted to a wide range of human-machine interaction scenarios beyond simple touch buttons.
Three sensing techniques were selected for evaluation in this stage of the RoadTest:
The objective of this evaluation was to verify the practical feasibility of these sensing methods and to observe their behaviour using the ModusToolbox CAPSENSE framework, rather than performing a full quantitative characterization.
Hover sensing extends capacitive touch detection by enabling the system to detect a finger without direct contact with the sensing surface.
Instead of requiring a physical touch event, the sensor reacts to variations in the electric field produced by a nearby object such as a hand.
The hover sensing experiment was performed using the MSCLP CAPSENSE Hover Touch example provided within the ModusToolbox environment, targeting the CY8CPROTO-040T-MS board with the CAPSENSE hover expansion board attached.
The sensor was configured as a high-sensitivity proximity channel, using the default tuning parameters provided by the example project.
Figure 63 : Hover sensing experimental setup
Figure 64 : Hover sensing experimental setup (alternate view)
The sensing surface was left without additional shielding or enclosure in order to evaluate the raw behaviour under typical laboratory conditions.
During testing, the sensor detected the presence of a hand at a distance of approximately 4–5 cm from the sensing surface.
However, the observed behaviour differed from an ideal continuous proximity sensor. Instead of a fully linear or gradual response, the system exhibited a threshold-based detection profile.
At distances near the detection limit, the output was unstable, with intermittent transitions between detected and non-detected states. Small variations in hand position or orientation produced noticeable changes in the signal.
As the hand moved closer to the sensor (~2–3 cm), the signal amplitude increased significantly and detection became stable, maintaining a continuous active state without flickering.
Figure 65 : Threshold-based hover detection behaviour observed in the CAPSENSE Tuner
When direct contact was made with the plastic overlay of the expansion board, the sensor exhibited a strong and stable response with a high signal level and continuous detection.
This confirms effective capacitive coupling through the dielectric layer, enabling reliable touch-through-overlay operation.
From a design perspective, hover sensing introduces several constraints due to its sensitivity to small variations in the electric field.
The system was observed to be influenced by:
Additionally, the transition region between detection and non-detection was relatively narrow, requiring careful tuning of thresholds to avoid false triggering or missed detection.
These observations indicate that, while hover sensing is effective, its most reliable operation occurs in near-field proximity or direct interaction scenarios, rather than precise distance measurement.
Despite these constraints, the technique is well suited for:
Capacitive sensing can also be applied to liquid level detection, leveraging the variation in dielectric properties when a liquid is present near the sensing electrode.
Unlike touch sensing, where a conductive object directly perturbs the electric field, liquid sensing relies on gradual changes in permittivity, enabling continuous measurement rather than binary detection.
The experiment was performed using the CAPSENSE hover touch expansion board configured in liquid level sensing mode.
A plastic container filled with water was positioned adjacent to the sensing electrode, ensuring no direct electrical contact between the sensor and the liquid.
The system was calibrated using empty and full reference points to enable proper level estimation.
Figure 66 : Liquid level sensing experimental setup
Liquid level sensing requires an explicit calibration step to define the measurement range.
This was performed using the built-in calibration wizard available in the CAPSENSE Tuner under the Liquid Level Measurement tab.
The calibration process consisted of:
The wizard automatically computed the normalization parameters, allowing the system to map the raw sensor response to a relative liquid level.
Without this calibration step, the system only provides raw signal variation and cannot estimate the actual liquid level.
After calibration, the system provided a continuous and stable estimation of the liquid level.
To evaluate the behaviour, multiple measurements were taken at different fill levels.
Figure 67 : Empty container and corresponding CAPSENSE output
At empty state, only the lowest electrodes showed minimal response, and the system correctly reported a near-zero level.
Figure 68 : Liquid level detection at approximately 30% fill
As the liquid level increased, the lower sensors became active, and the system estimated a proportional level. The response was smooth and continuous.
Figure 69 : Liquid level detection at approximately 65% fill
At intermediate levels, a clear transition of active sensing regions was observed, with the system accurately tracking the liquid height.
Figure 70 - Full container and corresponding CAPSENSE output
At full level, most sensing electrodes were activated, and the system correctly reported maximum level.
Overall, the response was monotonic, continuous and repeatable, demonstrating that capacitive sensing can effectively reconstruct liquid level based on distributed electrode measurements.
Although the results were consistent, several practical aspects were identified during testing:
Additionally, small signal fluctuations were observed during rapid liquid movement, indicating sensitivity to dynamic conditions such as turbulence.
These observations confirm that capacitive liquid sensing is a powerful technique, but requires careful system integration and calibration for reliable real-world deployment.
Despite these constraints, the approach offers significant advantages:
Typical application areas include:
Capacitive sensing can also detect interactions through metal surfaces, enabling fully sealed and mechanically robust user interfaces for industrial and consumer applications.
Instead of directly exposing the sensing electrode, the capacitive field couples through a conductive layer, such as a metal panel.
The metal touch experiment was performed using the CAPSENSE hover touch expansion board.
A conductive metal surface integrated in the board was used to emulate a real-world metallic front panel, with the sensing electrode located beneath it.
The system was configured using the default CAPSENSE example provided in ModusToolbox, with no additional tuning applied.
Figure 71 : Metal touch sensing experimental setup
Touch interaction through the metal surface was successfully detected.
However, compared to direct touch or plastic overlay sensing, the signal amplitude was significantly reduced and the detection behaviour was more sensitive to the applied force.
During testing, it was observed that:
The CAPSENSE Tuner showed a clear transition from idle to active state when sufficient pressure was applied, with a stable DiffCount plateau and continuous status activation.
Figure 72 : Stable metal touch detection under applied pressure observed in the CAPSENSE Tuner
These results confirm that metal touch sensing is feasible, but its performance is highly dependent on mechanical interaction and system tuning.
Metal touch sensing introduces additional design challenges compared to standard capacitive interfaces:
In the default configuration, the system required firm contact to ensure reliable detection, highlighting the importance of parameter tuning for production-ready designs.
Despite these constraints, the approach enables highly robust interfaces with several advantages:
Typical applications include:
The expansion sensing demonstrations illustrate how the CAPSENSE subsystem can be adapted to different sensing scenarios beyond simple button inputs.
| Demonstration | Observed behaviour | Potential applications |
|---|---|---|
| Hover sensing | Contactless detection at several centimetres distance | Gesture interfaces, automatic activation |
| Liquid level sensing | Continuous signal variation with liquid proximity | Smart appliances, water tanks |
| Metal touch sensing | Reliable detection through conductive panels | Industrial and appliance interfaces |
These experiments highlight an important aspect of capacitive sensing: the same underlying hardware can be adapted to multiple sensing modalities with minimal changes in configuration.
This flexibility makes the CAPSENSE subsystem particularly valuable for rapid prototyping, where different interaction concepts can be evaluated without redesigning the hardware platform.
These results confirm that the CAPSENSE hardware integrated in the CY8CPROTO-041TP kit provides a versatile and scalable foundation for advanced human-machine interfaces, supported by a well-integrated software and configuration ecosystem.
The performance of the CY8CPROTO-041TP kit was evaluated based on responsiveness, sensing reliability, system stability and development workflow integration.
| Feature | Result |
|---|---|
| Boot time to visible demo activity | <0.3 s |
| Touchpad detection accuracy | 100% (50/50) |
| Proximity detection accuracy | 100% (50/50) |
| False triggers during direct testing | 0 |
| Approximate proximity distance | ~2.4 cm |
| Stability observation | 15 min stable |
| Linux USB detection | Automatic |
| Firmware programming | Successful |
| Verification after programming | Verified OK |
From a practical perspective, the system demonstrates excellent responsiveness and stability, with immediate feedback and no observable drift during extended operation.
The capacitive sensing performance is particularly notable for its repeatability and immunity to false triggering under normal indoor conditions, which is often a challenge in capacitive-based interfaces.
Additionally, the seamless integration between hardware, firmware and development tools contributes to a smooth evaluation workflow, reducing setup time and allowing rapid iteration.
From an engineering standpoint, the identified weaknesses are not critical limitations of the hardware itself, but rather aspects of the tooling and learning curve associated with the ecosystem.
The core sensing performance and hardware integration remain robust, and the observed limitations are typical of advanced configurable sensing systems rather than fundamental design flaws.
The CY8CPROTO-041TP PSoC 4100T Plus CAPSENSE Prototyping Kit delivers a highly capable and well-integrated platform for evaluating capacitive sensing technologies.
The out-of-the-box experience is outstanding, allowing immediate interaction with the sensing hardware without any configuration overhead. The capacitive touchpad and proximity sensor demonstrate stable, responsive and repeatable behaviour, confirming the maturity of the CAPSENSE implementation.
From a development perspective, the combination of ModusToolbox, integrated configurators and real-time visualization tools such as the CAPSENSE Tuner provides a complete and professional workflow for both evaluation and prototyping.
The expansion demonstrations further highlight the flexibility of the CAPSENSE subsystem, showing how the same hardware can be adapted to multiple sensing modalities such as hover detection, liquid level measurement and metal touch interfaces.
Although the software ecosystem introduces an initial learning curve, it also enables a high level of configurability and control, which is essential for real-world embedded applications.
Overall, this kit stands out as a powerful and versatile platform for engineers working on human-machine interfaces, offering a strong balance between ease of use, flexibility and technical depth.
It is particularly well suited for:
For developers looking to explore Infineon’s CAPSENSE ecosystem, this kit provides a fast, practical and technically robust entry point, with clear potential for extension into production-level designs.
Top Comments
Hi DAB
Thanks for your feedback, I really appreciate you taking the time to go through the review.
I had a similar impression during the RoadTest, the hardware feels solid and well designed, and overall…