https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/<p style="display:none;">blank</p>en-USTelligent Community 13https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1697490/tda4al-q1-keys-for-ocotp-key-writing-for-production-environmentFri, 13 Nov 2026 03:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3a5ab1d3-b08c-40f9-9a52-2d870718a292Gururaj BPart Number: TDA4AL-Q1 Hi team, we are from APTIV using TDA4AL, while moving forward for production, are there new set of keys that will be deleivered from TI for the below set of keys for the OCOTP key provisioning in production ?? There are only 3 sets of Keys in the above table that come from TI - MPK, MEK and TI FEK Pub. The MPK and MEK Keys are unique for each Silicon Revision (SR), but otherwise stay the same between pre-production (XJ721S2***) and production (TDA4AL****) parts we need the keys for pre-production (XJ721S2***) and production (TDA4AL****) parts. one more question : we are going ahead with Common SMPK key for all the units in production, is it required to have BMP and SMPK both provisisoned ? only SMPK key is enough ?Infotainment &amp; ClusterTDA4AL-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1696998/cc2652r7-cc2652r7-fem-dtm-test-issue/6537949Thu, 12 Nov 2026 20:58:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:3607b57e-3ab6-43ea-b798-0467e84aad70JanHi, Thank you for reaching out. Let me loop in an expert to assist on this topic. Best Regards, Janhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1697423/tda4al-q1-after-flashing-new-pdk-dummy-keywriter-application-it-does-not-boot-and-halts-after-these-printThu, 12 Nov 2026 16:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:28e85655-8d8f-4f26-ba84-6593ac0bb40aGururaj BPart Number: TDA4AL-Q1 Following is our analysis : Keywriter Version: 02.00.00.00 (Nov 11 2026 - 10:32:24) Keywriter Version: 02.00.00.00 (Nov 11 2026 - 10:32:24) DIAGNOSTIC ONLY: PM-to-TIFS retest; OTP programming disabled Before TIFS boot notification After TIFS boot notification: 0 Before Sciclient_init After Sciclient_init: 0 Before Sciclient_boardCfg: address=0x41c1f800 size=29 After Sciclient_boardCfg: 0 PM TIFS probe: address=0x41c20980 size=2 timeout=10000000 iterations PM TIFS probe result: status=-4 flags=0x0 timeout_code=-4 PM TIFS exchange timed out; local PM init was not calledIn PDK 10.01, Sciclient_direct.c handles TISCI_MSG_BOARD_CONFIG_PM locally through Sciclient_ProcessPmMessage(). That calls the local PM boardcfg handler and pm_init().In PDK 11.02, the TISCI_MSG_BOARD_CONFIG_PM case first calls Sciclient_serviceSecureProxy() to send the PM boardcfg to TIFS, waits for its response, and only then calls local PM processing. Can you please address below questions : 1. Is forwarding TISCI_MSG_BOARD_CONFIG_PM to TIFS before local processing the intended PDK 11.02 behavior for J721S2 Keywriter combined boot? 2. Is the PDK 10.01 Keywriter TIFS firmware expected to handle this forwarded PM-boardcfg request when paired with PDK 11.02 Sciclient? 3. Is using the PDK 10.01 local PM-processing path an approved compatibility workaround for Keywriter on PDK 11.02?Infotainment &amp; ClusterTDA4AL-Q1https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1696998/cc2652r7-cc2652r7-fem-dtm-test-issueWed, 11 Nov 2026 10:25:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:c5b3161a-4abe-45ea-80b5-c176f5559bb3xiang tianPart Number: CC2652R7 Based on the method provided in SWRA720, the sensitivity of the CC2652 (with FEM) was tested as follows: (1) The hex file directly taken from the files (C:\ti\simplelink_cc13xx_26xx_sdk_M_mm_mm_mm\examples\rtos\ \ble5stack\hexfiles) was flashed onto the device under test. Without configuring the FEM&#39;s TX/RX enable pins, the measured sensitivity was -98 dBm. (2) A hex file generated using the simplelink_cc13xx_cc26xx_sdk_5_40_00_40 SDK, with the FEM&#39;s enable pins configured (so that the FEM&#39;s TX and RX are properly enabled), yielded a sensitivity of about -93 dBm. (3) A hex file generated using the same simplelink_cc13xx_cc26xx_sdk_5_40_00_40 SDK, but with the FEM&#39;s enable pins configured so that the FEM remains permanently in receive-enable mode, yielded a sensitivity of only about -30 dBm. How can the above phenomena be explained? Which SDK should be used to configure the FEM&#39;s corresponding enable pins?CC2652R7Test &amp; Measurementhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6530227Wed, 04 Nov 2026 13:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:42357589-63d2-4033-9d01-52468bcc964eAndy RutterHi Alex I made the change to 0x1090303 but I am still not receiving data from a CYRF6936 transmitter. I need to get Smart RF Studio running on my PC. I plan to do that later this week using a Windows install under Virtual Machine Manager. I have also found a guy in Germany working on a very similar project so hope to share expperience. I will close this thread and open a new issue should/when I need further help. Thank you -- Andyhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693175/rf430frl152h-rf430frl152h-stuck-at-55-c-when-the-3adcs-and-3-digital-sensors-are-sampled/6527976Mon, 02 Nov 2026 19:33:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9199b1b5-f87c-44be-9749-1cfeb994dd10Rizwan MurjiHi Roopa, The RF430 has limited support, but I will do my best to help here. The behavior you are experiencing—where the system works flawlessly at room temperature but throws a &quot;Cannot read the device&quot; error at 55&#176;C when multiple digital I2C sensors are active—is almost certainly due to an I 2C bus timeout or lockup caused by inadequate RF power harvesting at elevated temperatures. When your three analog ADCs are sampled alone, the RF430FRL152H completes the read successfully because internal analog conversions require very minimal active-mode power. However, adding multiple external digital I2C sensors pushes the power envelope beyond what the chip can reliably scavenge from the NFC field at high temperatures. [ The primary causes and concrete steps to make your readings consistent up to 67&#176;C include: 1. The Core Temperature Mechanism: RF Harvesting Degradation As temperature rises toward 55&#176;C and 67&#176;C, two major physical shifts occur simultaneously: Higher Current Consumption: The internal leakage current of the RF430FRL152H increases, and the external digital sensors (SHT45, STS40) draw more active current. Lower Scavenged Voltage (\(V_{DDB}\)): The efficiency of the internal RF voltage rectifier decreases at higher temperatures. Because you are powering the tag wirelessly , the scavenged voltage droops under the combined load of the 3 active digital sensors during an I2C transaction. When \(V_{DDB}\) dips below the brownout threshold or the logic high threshold (\(V_{IH}\)), the I2C state machine misses a clock edge. This causes a sensor to hold the SDA line low permanently waiting for a clock pulse, causing an I2C Stuck Bus condition that ultimately crashes the ROM firmware&#39;s sampling scheduler and breaks the NFC GUI communication link. 2. Firmware Workarounds (What to fix in main.c / main.h ) Since you implemented the manual clock-pulsing workarounds from SCPA069 but still see crashes when 2 or 3 digital sensors are active, the firmware is likely recovering the bus only for it to crash again immediately during the next transaction sequence. Introduce Inter-Sensor Delays (Staggered Sampling): Do not sample or communicate with all three digital sensors back-to-back. Give the RF scavenging capacitor time to recharge. After finishing a read from DS1 (SHT45), insert a significant delay (e.g., 20–50 ms) using a low-power timer or delay loop before initiating the I2C start condition for DS2 (STS40_0), and another delay before DS3 . Lower the I2C Clock Speed: If you are running the I2C bus at 400 kHz, reduce it to 100 kHz (Standard Mode). Slower rise times and clock speeds drastically lower transient dynamic current draws and offer better noise immunity when the voltage rail is weak. Increase the Bus Recovery Clock Count: In your main.c bus-clear function (adapted from SCPA069 ), make sure you are actively toggling SCL up to 16 times rather than just 9, and ensure that a strict STOP condition (SDA transitions low-to-high while SCL is high) is executed explicitly right after the toggling finishes. 3. Hardware Modifications (Without SCL/SDA Probing Pads) Since you cannot probe SCL/SDA, focus on optimizing your hardware&#39;s power integrity directly: Stiffen the Pull-Up Resistors: If your I2C lines rely on internal pull-ups or weak external ones (like \(10\text{ k}\Omega\) or \(4.7\text{ k}\Omega\)), the weak pull-up combined with increased parasitic capacitance and leakage at 55&#176;C will slow down rise times. Swap or add external pull-up resistors to ground out at \(2.2\text{ k}\Omega\) to force sharp logic transitions under low-power rails. Beef Up the Storage Capacitor (\(V_{DDB}\)): Increase the value of the decoupling capacitor on the \(V_{DDB}\) rail (scavenged output power). Adding a low-ESR \(4.7\mu\text{F}\) or \(10\mu\text{F}\) ceramic capacitor in parallel with your existing decoupling capacitor provides a larger energy buffer to sustain the tag during active I2C operations. Increase RF Field Strength: If possible, reduce the distance between the NFC reader antenna and your tag, or increase the output power setting on your reader module GUI to maximize the available energy transferred to the tag. I hope this helps. Thanks, Rizhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6527928Mon, 02 Nov 2026 18:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:8676bb86-42ae-4b76-aa1e-ed8e1f450656Alex FagerHello Andy, Please let me know if your tests go ok. Do note in the register I pointed out above it likely only changes the &quot;AAAA&quot; part: 0x1098AAAA, // LRFDPBE.MDMCMDPAR2 IE &quot;AAAA&quot; is what we change Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6526601Fri, 30 Oct 2026 18:34:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:d08cf3e9-6f9c-4e1d-bb17-81257ce038e1Andy RutterSo, I guess that changing LRFDPBE.MDMCMDPAR2 to 0x109803030303 will do it. Again, documentation!! I haven&#39;t used SmartRF Studio as I have no Windows PCs. I shall see if it will run under Wine on Linux. Thanks -- Andyhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6526593Fri, 30 Oct 2026 18:27:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:0c873a56-1f80-4b58-aa18-2bbf817a7c3dAndy RutterAlex Again, thanks for your help. It would be useful if stuff like this was in the documentation - hint TI technical docs team! I don&#39;t has an assigned FAE. I&#39;m just a lonely developer. What is the procedure for accessing FAE resource - I assume call TI sales?https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6526587Fri, 30 Oct 2026 18:23:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:7ddb79c8-0956-493f-a374-45125f4dc5d5Alex FagerHello Andy, I was looking through my emails and found what controls the preamble pattern: LRFDPBE:MDMCMDPAR0.val[15:0] #Preamble config LRFDPBE:MDMCMDPAR2.val[15:0] #Preamble pattern 0xAAAA, which gives you a 0101 pattern IE LRFDPBE:MDMCMDPAR2.val[15:0] = 0xAAAA # preamble pattern to modem So if I am looking at my rf config .c file it would be: 0x1098AAAA, // LRFDPBE.MDMCMDPAR2 I would recommend using SmartRF Studio 8 to modify its low-level files (the one for GFSK 1 mbps PHY) and re-generating the entire rf-config. However, you may be able to get away with just modifying the field above in your existing rf config .c file (I have not confirmed this). Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c/6526561Fri, 30 Oct 2026 17:47:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:b4ed9a73-1fbc-409b-a9fc-6af474beea4dAlex FagerHello Andy, The PHYs that have multiple configurations (such as the 1 mbps, 2 mbps GFSK PHY) should use the &quot;features&quot; config to decide which is used: .common.phyFeatures = 0x0000, (this is in the .c file) and in the .h file it defines: // PHY features #define RCL_PHY_FEATURE_SUB_PHY_1_MBPS 0x0000 #define RCL_PHY_FEATURE_SUB_PHY_2_MBPS 0x0001 #define RCL_PHY_FEATURE_SUB_PHY_CODED 0x0002 #define RCL_PHY_FEATURE_CODED_TX_RATE_S8 0x0000 #define RCL_PHY_FEATURE_CODED_TX_RATE_S2 0x0004 So the 1 mbps GFSK config is used instead of 2 mbps or coded. If you want to change the PHY feature it should just be: rclPacketTxCmdGenericTx.common.phyFeatures = ####; [quote userid=&quot;369807&quot; url=&quot;~/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-c&quot;] Also, the proprietary-rf-users-guide / packet-format.html hints that the preamble can be changed showing an example using rfc_CMD_PROP_RADIO_DIV_SETUP_t. A type definition for this cannot be found in the SDK source. I need to change the preamble from the default 0101... to 0011... -- Andy [/quote] I think we can change the preamble here, but I will likely have to reach out internally to TI RnD to confirm what would need to be updated, and or if the PHY has any issues when modifying it. If you expect other custom changes being needed for the PHY compatibility we would need to take this offline (with your Assigned FAE) and work with TI RnD more closely/directly. Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694274/rf430cl330h-rf432s72fdmwrgzrq1-where-can-i-buy-the-xds200-probes-and-where-can-i-find-the-needed-sw-tools/6526538Fri, 30 Oct 2026 17:29:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:ec4ab9fa-96f4-4295-8c09-874cc3365fbfKatherine OgreanHi, XDS200 purchase: TI&#39;s official tool page is ti.com/tool/xds200 1 . Spectrum Digital and Black Hawk as the vendors manufacturing/supplying the XDS200 standalone probe 2 ; it sits between the lower-cost XDS110 and higher-performance XDS560v2 2 . RF432 SW tools: Program/debug with Code Composer Studio 12.7.1 via the 20-pin TI JTAG interface (Uniflash and MSP-GANG are not supported) 3 . Some RF432 example-project firmware may require direct contact with a TI FAE 3 . RF430CL330H documentation/examples: NDEF example firmware, TIDA-00217 field-powered firmware, and the TIDM-DYNAMICNFCTAG design (hardware + code) are referenced from the datasheet&#39;s NFC/RFID Tools &amp; Software page 4 , along with device errata (SLAZ540) and an NFC Bluetooth-pairing app report (SLOA187) 4 . I will reach out to you with Werners contact information. XDS200 Tool Page Reference XDS200 Vendor/Performance Info RF432 Programming Tools - E2E RF430CL330H Datasheet Best, Katyhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694274/rf430cl330h-rf432s72fdmwrgzrq1-where-can-i-buy-the-xds200-probes-and-where-can-i-find-the-needed-sw-toolsFri, 30 Oct 2026 16:16:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:9dd7ed76-892c-4092-b837-3e7408b1af50Giuseppe PezzicaPart Number: RF430CL330H Other Parts Discussed in Thread: UNIFLASH , , TIDM-DYNAMICNFCTAG , TIDA-00217 Dear all, in our products We are using RF432 since 2022. At the time We developed (2019-20), We received from TI the needed support through a secured web page via specific credentials. In the last year, our group has acquired another pool of companies. Among them there is also an ELN Team, which I need to enable to program and debug autonomously this component. I have then made the access to the TI site trying to read out the &quot;secure access&quot; at which previously all the needed info and tools where shared. But I found empty. Then I have asked to the distributor and then the local TI support, from which I received the indication to write here. In few words, I need Your support for two items: 1) I need to know where I can buy 5 XDS200 probes (needed for programming RF432 on board on a new ELN production equipment) and where to find the related SW tools and documentation to work with the component. 2) Last but not least. At the time I worked with it I was in contact with Mr. Werner Lummer, who was the demo developer of TI car access products (RF432 and TRF4xxx) and gave us the needed support for it. I would really appreciate I You could put me in contact with him or with the person who has replaced him in this job. Thanks, KR G. Pezzica Head Watersport SpA (ex MARES SpA)TIDM-DYNAMICNFCTAGUniFlashRF430CL330HTIDA-00217https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1673024/tms3705-tms3705-and-tms37145---communication-error/6526402Fri, 30 Oct 2026 15:46:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:2c4fd10b-64da-4307-8a18-77fd71d5994fIsaac LarsonHello Hideraldo, I apologize for the delay. One thing I have noticed is the difference in the non-transmitting voltage between the successful and unsuccessful waveforms. There seems to be a DC offset on the unsuccessful waveforms which is concerning. This seems to before and after the charge pulse. Most of the following feedback will refer to figure 14 and figure 8 in SCBA031 and SCBA027 respectively. 1. AC-Couple the receiver tap: Both of the schematics place a capacitor (C5) between R1 resistor and the antenna. This should remove any DC offset before it reaches the sense pin. Do you have a capacitor like this in your design? 2. Are R1 and R2 (see schematics (figure 14/8)) scaled properly for the antenna voltage seen? In theory, for 630vPP this would yield R1 = 160kOhms and R2 = 3.2*160kOhms. 3. Are you preventing any of the bridge current from interfering with the TMS3705? Specifically, if the bridge current flows between the low-side FET and the VSSA, could cause the receiver amplifier to saturate. Let me know. Thanks, Isaachttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1694201/cc2340r5-need-help-customing-generated-lrf_regconfiglist-in-ti_radio_config-cFri, 30 Oct 2026 11:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:903f45ae-7dbc-4cb3-9c99-1b5a3666f701Andy RutterPart Number: CC2340R5 Other Parts Discussed in Thread: SYSCONFIG Selecting Custom-&gt;Proprietary-&gt;1Mbps / 2MBps in sysconfig generates a LRF_RegConfigList with 3 entries: LRF_commonRegConfig, LRF_subPhy1MbpsRegConfig and LRF_subPhy2MbpsRegConfig. I can&#39;t find an explanation in the documentation as to how these entries are used. Is there a document that I failed to find? As I want only 1Mbps, do I comment out the 1st and 3rd entries and set .numEntries=1? Also, the proprietary-rf-users-guide / packet-format.html hints that the preamble can be changed showing an example using rfc_CMD_PROP_RADIO_DIV_SETUP_t. A type definition for this cannot be found in the SDK source. I need to change the preamble from the default 0101... to 0011... -- AndyPortable ElectronicsCC2340R5SYSCONFIGhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6525289Thu, 29 Oct 2026 17:38:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:daac5fdc-435c-41b5-8187-2bf6392ce424Andy RutterAlex Thank you for considerable help. I have the latest sysconfig (1.28.2.4845) and this provides proprietary for CC2755P10 but not the P20 version but I guess the only difference is the memory size so I will experiment with the P10.https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6525179Thu, 29 Oct 2026 15:56:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:05776ff9-977c-4893-bf25-142b5c3a2491Alex FagerHello Andy Rutter, It is correct that today there are no native proprf examples in the SDK for the CC2745/CC2755 device; however, this does not mean that you cannot do proprf with the device today. In the sysconfig to enable proprf and add one of the 3 proprf PHYs (1 mbps GFSK, 2 mbps GFSK, IEEE); also make sure to add an instance of the RCL driver in the TI Driver section in sysconfig. As a next step go to the CC2340R5 in the SDK, find the proprf example folder and copy-paste the rfPacketTx.c or rfPacketRx.c file to your local project or the contents. Other than the specific CC23 definitions the code should work for the CC27; let me know if you have any problems here. You can also play around with sending/receiving packets with SmartRF Studio 8. [quote userid=&quot;369807&quot; url=&quot;~/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6524985&quot;]unencoded 1Mbps GFSK to interface with legacy Cypress CYRF6936[/quote] If the generic 1 mbps GFSK PHY included in the SDK does not fit your needs with the Cypress protocol, please let me know here and also reach out to your assigned FAE to start the process internally to get deeper support. Thanks, Alex Fhttps://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6525012Thu, 29 Oct 2026 14:02:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:69c50c59-a247-4152-9be4-bd9c7ad6ef09Andy RutterIt is not an automative use case, The CC2755 would work for me but there are also no prop_rf examples in the F3 SDK but the R10 and P20 datsheets do claim support for proprietary RF. I have SDK 9.23.0.27 which appears to be the most recent F3 release. Do you know if proprietary support for CC2755 will come in a future release?https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6524992Thu, 29 Oct 2026 13:48:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:63e09500-b585-4eb4-946f-0ccdbfb86253Evan WAndy, Can you confirm this is for an automotive use case? The CC2745-Q1 is meant for auto use cases as designated by the Q1 in the title, but the CC2755R10 does support non-automotive use cases. The confusion here is that the CC2755R10 (similar device family) does support proprietary from what I recall, but the CC2745-Q1 is mainly dedicated to BLE only. The LaunchPad says both because it serves as the foundational evaluation board for both the CC2755 and CC2745-Q1 class devices.https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/1693791/cc2745r10-q1-does-cc2745r10-q1-support-proprietary-rf/6524985Thu, 29 Oct 2026 13:45:00 GMTcb01d8b2-d089-468d-babb-77d1d8683490:50b49c58-e7c1-4354-901c-e4dfef8efb54Andy RutterI wanted to use unencoded 1Mbps GFSK to interface with legacy Cypress CYRF6936. Does your phrasing about &quot;Nativel, the SDK ...&quot; mean that there is no SDK code or that the CC2745 cannot do proprietary?