SLLA679 April 2025 TCAN2451-Q1
Twenty years ago, if someone wanted to enter a car wirelessly it required the use of a key fob. While this option is still included in modern vehicle designs, modern vehicles have a higher level of electronic integration that allows for more complex features. One of these features is the inclusion and integration of multiple BLE nodes within the vehicle to perform multiple functions. One can initially think that these BLE nodes are mainly for the use of infotainment systems, but that misunderstanding undersells the potential quality of life features that can be further integrated by utilizing the BLE nodes. One of these quality of life features is to be able to use a phone as a key that can be used to unlock doors and start the engine of the car remotely from a cell phone BLE module. However, with multiple BLE nodes advertising to a phone, the phone can initially connect to a less than preferred BLE node in the wrong portion of the vehicle to be properly utilized. While the system tries to figure out the best BLE node for the task the user experience can be diminished due to connections and disconnections of the phone of the user to various BLE nodes
PaaK applications can generally be broken into two main groups – the main module and the satellite modules. The main module can be thought of as the brain of the PaaK application as all peripheral nodes (called satellites in PaaK applications) are linked back into the main module. The main module is relatively simple: comprising of communication, power, controller, and a BLE SoC and an antenna.
Since this is a vehicle-based application and the data rate is relatively lower a CAN or LIN bus is designed for the communication backbone for the PaaK applications. When looking at the satellite modules, (which are going to exist throughout the vehicle) the overall implementation is very similar.
The main differences are that the BLE SoC is directly connected to the communication interface, but the need for power and CAN and LIN communication remains constant between different subsystems.
So how does a CAN SBC fit here – while it is obvious that a CAN transceiver can be required, the requirement of more integrated SBCs can not be as clear. An SBC combines power regulation with a transceiver – looking at both the main module as well as the satellite nodes as both require a power converter and either a CAN or LIN transceiver. The main modules power block also includes a watchdog timer and voltage supervisors. If looking at SBC options that TI offers, one can find that many SBCs integrate the transceiver, power regulator, watchdog timer, and voltage supervisors – which when used in conjunction with the PaaK main modules and satellite modules can replace everything except the companion controller and BLE SoC + antenna. Using an SBC reduces the elements on the BOM and simplifies the hardware design of a PaaK system.
It must be clear why SBCs can be used in this application in a way that greatly reduces design complexity of these types of systems. This leaves a big question unanswered: what SBC should be used?. In general the answer based on the system can include multiple SBC options offered by TI, but refer back to the main issue with PaaK in relation to the user experience: the phone can connect to a non-ideal node first and without the main system knowing the physical location of each satellite module the process of linking up to the correct node can take enough time to degrade the user experience. There is also the issue that the car battery powers this application when the engine is off , so having lower power draw is critical to extend battery life. The TCAN24xx line of devices use dual use WAKE/ID pins as well as the PFM mode on the buck converter output for lighter loads. There are four ID pins on the TCAN24XX family of devices. These ID pins can be left floating, pulled high, or pulled low, giving three states possible for each ID pin affording a total of 3^4 or 81 different ID options. A designer can assign each TCAN24xx a local external ID that is based on the configuration of the ID pins. This can allow an encoded mapping of the vehicle based on CAN SBC location. This can be beneficial to the architect of the system and this information can be integrated into the PaaK module that links to all satellite module so that the main module knows the location of each ID. Another benefit of this is that beyond the ID pin configuration on every TCAN24xx device can be set up in the same way, so most of the design from the main module can be copied to each satellite node with the primary difference being how ID1 – ID4 are connected (to GND through resistor, to VBAT through resistor, or just left floating). On the other hand, since the CAN module must be on for the soft-handover to occur the VCC1 regulator of the SBC must be turned on. The TCAN24xx family utilizes a buck converter that by default switches to pulse frequency modulation (PFM) for light loads to maintain higher efficiency; as a caveat direct efficiency varies based on system setup and buck converters external components. A BLE node when advertising is going to require less than 100uA of current typically and with the buck converter on the TCAN24xx line of devices – the total battery supply current can be ≤ 100uA even with the buck module running. This highlights two features that can be utilized in PaaK applications allowing for physical location encoding as well as a buck using PFM mode to grant higher efficiencies for lower load currents generally allowing for less than 100uA of sleep current with VCC1 active with a light load (< 100uA).
One major benefit is simplification of the design process when using the TCAN24xx device. Assume there is a vehicle with 10 different BLE satellite nodes throughout the system. That generally requires 10 different node designs, that can be similar, but to verify robust Bluetooth™ connections some type of position encoding is generally included. This causes 10 very similar modules to each need a specified place, for example, module 1 can only go where module 1 was designed to go. If using the TCAN24xx, the design can stay exactly the same for all 10 nodes since the ID pins can be configured at the vehicle assembly stage. This is because the ID pins only need a series resistor, and then can be connected to VBAT, GND, or left floating. This assignment can generally be done at the connector itself so that each ECU for the satellite modules are interchangeable and the only thing that is changing is how the connector is wired. Looking back at the 10-node system each node when using the TCAN24XX device – now instead of each module being locked into a specific position of the car any of the ECUs can be placed at any node as the only thing that is changing is the wiring of the ID pins which can typically be done through a connector. This not only simplifies the assembly by having interchangeable ECUs, but also simplifies design as only one design is needed instead of multiple – and for this example – 10.
As automotive vehicles become more integrated with advanced electronics the feature set embedded within also increase in complexity. With the surge of more features to improve the user experience with respect to automotive systems, applications such as Phone as a Key (PaaK), is more common on newly designed systems. To meet the requirements of the application multiple BLE nodes are interspersed throughout the system communicating to a main host node through CAN or LIN communication. Using a device such as one from the TCAN24xx family, not only can many of the communication, power, and protection requirements of the system be met, but also allows encoding of each nodes position through the ID pins which allow a more seamless transition to the BLE node within the system.