Data converters forum - Recent Threads

TUSB322I: Request for Recommended CC Controller and Redriver for USB 3.2 Gen2x2 (20 Gbps) Implementation

SHIVAKUMAR D R — Mon, 24 Aug 2026 13:51:09 GMT

Part Number: TUSB322I

Intel is currently using the implementation below on one of our reference platforms based on the Nova Lake CPU and Intel W980 chipset (Dunlow Entry Server):

TUSB322I CC Controller
USB Redriver (PI3EQX1002E2)

With the current implementation, we are able to achieve 10 Gbps operation in both Type-C cable orientations. However, when connecting a USB 3.2 Gen2x2 (20 Gbps) device, the link falls back to lower speeds and does not maintain 20 Gbps operation.

We would appreciate your recommendations on:

CC controllers that support USB 3.2 Gen2x2 (20 Gbps) Type-C implementations.
Any compatible redriver/retimer solutions that have been validated for 20 Gbps operation.
Estimated pricing for 10 devices (CC controller and associated redriver/retimer), which will help us evaluate the solution for potential implementation.

Any guidance on validated reference designs or recommended configurations would also be greatly appreciated .

Thank you for your support.

Implemnation details:

Best regards,
Shivakumar D R

RE: TUSB322I: Request for Recommended CC Controller and Redriver for USB 3.2 Gen2x2 (20 Gbps) Implementation

SHIVAKUMAR D R — Tue, 25 Aug 2026 03:34:07 GMT

Thanks for the response and your inputs

ADS1260: ADS1260 — selecting AIN0 as an INPMUX input while AIN0/AIN1 is the active external reference

Christopher Hoover — Mon, 24 Aug 2026 10:02:08 GMT

Part Number: ADS1260

We are building a multi-channel temperature instrument with one ADS1260
per galvanically isolated channel (AVDD = 5 V, external ratiometric
reference on AIN0/AIN1 across R_REF = 4.02 kohm). The question below
concerns a single device; the multi-channel topology is only why each
chip does its own cold-junction compensation.

For cold-junction compensation we run a single ratiometric conversion in
this state (schematic attached):

- IDAC1 = 250 uA routed to AINCOM, flowing externally through a PT1000
(RT1) into the reference-top node, then through R_REF to local ground,
so V_REF = I x R_REF = ~1.005 V and the PT1000 sees the same current.
- REF register: RMUXP/RMUXN = 10b (external reference = AIN0/AIN1).
- INPMUX = 0x01: MUXP = 0000b (AINCOM), MUXN = 0001b (AIN0) -- i.e. the
conversion measures AINCOM minus AIN0 while AIN0 is simultaneously
serving as REFP0.
- PGA gain = 2, 20 SPS FIR, pulse-conversion mode. Result:
code = 2 x R_PT1000 / R_REF; IDAC value and drift cancel
ratiometrically.

Questions:

1. Is this a supported and characterized configuration -- an analog
input selected by INPMUX while that same pin is the active external
reference input via the reference mux? We find no restriction in
SBAS760C (INPMUX Table 43; section 9.3.3.2), and the block diagram
shows independent input and reference multiplexers tapping the pins
in parallel -- please confirm there is no internal interlock,
unsupported corner, or erratum for simultaneous selection.
2. What current does the selected PGA input add to the AIN0 node on top
of the specified reference input current, and is it stable during the
conversion? (Our reference chain is 4.02 kohm, so we care at the
nA level.)
3. Any charge-injection or settling concern specific to switching the
input mux onto an active reference node -- beyond the normal practice
of discarding the first conversion after an INPMUX change?
4. With V_REF = ~1.005 V (comfortably above the 0.9 V minimum), is there
any accuracy or noise derating at low external V_REF we should apply
beyond the datasheet tables?

Separate smaller question while we have you:

5. In pulse-conversion mode with chop enabled, what is the exact
first-data conversion latency at 20 SPS (FIR)? We schedule timed
reads and need the chop-doubled latency formula or table reference.

RE: ADS1260: ADS1260 — selecting AIN0 as an INPMUX input while AIN0/AIN1 is the active external reference

Christopher Hoover — Tue, 25 Aug 2026 02:52:46 GMT

Thank you.

DAC61416: CRC‑8‑CCITT mismatch on DAC61416

Hiromu Susami — Tue, 28 Jul 2026 07:50:28 GMT

Part Number: DAC61416

Hi experts,

We are using the DAC61416 with the CRC‑8‑ATM (CRC‑8‑CCITT) algorithm (initial value 0x00, MSB‑first).
When we send a write command with CRC = 0x00 and SDI = 0x83000000, the device replies with SDO = 0xC3000048.
The bit 30 of the reply (SDO[30] = 1) is correct because we transmitted a zero CRC, but the CRC that the DAC calculated over the data “0xC30000” should be 0x30, whereas the device returns 0x48.
Could anyone explain why the calculated CRC and the DAC‑generated CRC differ? Also, could you share a reference implementation of the CRC calculation that works for this part?

Regards,
Hiromu

RE: DAC61416: CRC‑8‑CCITT mismatch on DAC61416

Hiromu Susami — Tue, 25 Aug 2026 00:32:14 GMT

Hi Joseph,

The customer was able to get correct respond. Thank you.

Based on this, I would like to clarify the following two points:

1. Is the sequence discussed in this previous E2E actually not feasible? (Specifically: a sequence where we continuously write to the DAC registers for each CS descent while simultaneously receiving the CRC from the previous frame.)

Due to the significant latency in the DAC output, we are only considering an operation using continuous Write commands. If we follow the sequence mentioned above, it would take three times longer than continuous Writes, which would prevent us from meeting our required performance specifications.

https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1598103/dac61416-use-sdo-only-on-a-read-command?tisearch=e2e-sitesearch&keymatch=DAC61416%252520CRC#

2. If Write commands are sent continuously (as shown in the below diagram), is it correct to assume that none of the information in the DAC's SDO (32-bit) can be considered reliable?

In our actual hardware testing, the CRC check result (SDO bit[30]) for the data sent to the DAC appears to be correct. Given this observation, I would like to know if there is any part of the SDO data that can be considered valid during a continuous Write operation.

Regerds,
Hiromu

DAC7750: Unable to communicate properly with SPI

naveen Namani — Wed, 19 Aug 2026 10:41:18 GMT

Part Number: DAC7750

Hello TI..

We are working with DAC7750 and EEProm W25Q16JVSSIQ. both are connected to same SPI and intefaced to microcontroller with different CS pins.

As we are trying to read from EEprom

We are not able to read properly.

But when we isolation DAC miso lane then Flash is working properly.

Kindly check this issue and letus know the solution for this if any.

RE: DAC7750: Unable to communicate properly with SPI

Lucas Burnette — Tue, 25 Aug 2026 00:21:06 GMT

Hi Naveen,

Can you capture and provide images of the working and faulty communication?

According to the DAC7750 datasheet, you need to gate SCLK if you have multiple SDOs connected. (Page 31)
This could be creating the communication issues that you are experiencing.

Thank you,
Lucas

ADS114S08: Input impedance with PGA disabled

Joaquin Casanova — Mon, 24 Aug 2026 23:24:22 GMT

Part Number: ADS114S08

What is the input impedance on the ADC channels when the PGA is disabled? Is it possible to use the PGA if te Negative input is tied to ground (a single-ended measurement)?

RE: ADS114S08: Input impedance with PGA disabled

Dale Li — Tue, 25 Aug 2026 00:10:56 GMT

Hi Joaquin,

Please see my colleague's answer about the input impedance in the post below:

ADS124S08: Input impedance of ADS124S08

In order to measure single-ended signals that are referenced to AVSS (AINP = VIN, AINN = AVSS), the PGA must be bypassed as you can see the 9.3.2.3 Bypassing the PGA section in ADS114S08 datasheet. The PGA is bypassed and powered down by setting the PGA_EN[1:0] bits to 00 in the gain setting register (03h).

BR,

Dale

RE: ADS114S08B: REFCOM Configuration with Asymmetric Power Supply

Dale Li — Tue, 25 Aug 2026 00:03:25 GMT

Hi Tomasz,

Understood. Your understanding is correct. I forgot one thing, if the PGA is disabled and bypassed, the input voltage of the ADS114S08 can be as low as 50 mV below AVSS and as large as 50 mV above AVDD. Please see the statement in 10.1.4 Establishing a Proper Input Voltage section in ADS114S08 data sheet. I'm not sure the accuracy you expected, but this feature may fit your requirement.

BR,

Dale

ADS114S08B: REFCOM Configuration with Asymmetric Power Supply

Tomasz Jastrzebski — Sat, 22 Aug 2026 18:18:59 GMT

Part Number: ADS114S08B

What are the requirements for the REFCOM pin? The voltage from this pin is buffered, so I assume it does not necessarily need to be connected to AVSS, as buffering it would otherwise seem unnecessary.

I am designing a system with an asymmetrical power supply because I need to measure voltages from -50 mV to 2.45 V. I would like the chip to operate from -1 V and +3.1 V supplies while keeping REFCOM connected to GND. This would allow me to use the 2.5 V REFOUT voltage relative to ground to generate an ANINCOM voltage of -50 mV using a conventional solution with an additional op-amp.

Is this configuration supported? What is the max AVSS - REFCOM voltage? Can REFCOM exceed ANINCOM? I did not find answers in specs.

Regards,
Thomas

ADS127L18: ADS127L18 Full-Scale Test Error on CH0

Michael Chiasson — Mon, 24 Aug 2026 20:20:20 GMT

Part Number: ADS127L18

Hello,

I am evaluating the ADS127L18 by enabling the internal test multiplexers for all 8 channels (CHn_MUX = 0b111 in CHn_CFG1).

While Channels 1 through 7 reliably report exact full-scale values, Channel 0 displays a consistent inward offset (biased toward zero) by roughly 400 to 500 codes:

FS+ Test Mode (+FS):
- Channels 1–7: Read 8388607 (0x7FFFFF, 2^23 - 1) as expected.
- Channel 0: Reads low, fluctuating around 8388117, 8388112, and 8388108 (~490 codes below positive full scale).
FS– Test Mode (-FS):
- Channels 1–7: Read -8388608 (0x800000, -2^23) as expected.
- Channel 0: Reads high, fluctuating around -8387974 (~634 codes above negative full scale).

Some additional Context:

Clocking & Data Rate: CLKIN = 2.4576MHz, SINC4_OSR_2048 filter setting (effective data rate of 300 SPS).
Data Port Status Byte Enabled: STATUS_EN is active. Channel 0's STATUS_DP byte reads correctly with zero fault flags set, nPWDN set (meaning Normal Operation) and CH_ID properly set to 0, for a value of 0x08.
Daisy-chaining two ADS127L18 devices, but currently ignoring the downstream device's frame data.

Because the STATUS_DP byte and lower bits on Channel 0 are decoding consistently without framing errors, this does not appear to be a single-bit framing or alignment offset.

Is the internal +FS / -FS test signal generated globally for all channels, or is it routed through individual analog front-end switches per channel that could introduce offset on Channel 0?
Should the +FS and -FS digital test outputs on the ADS127L18 strictly yield ideal full-scale saturation values (2^23 - 1 / -2^23), or can analog front-end / modulator offsets affect these readings?
Are there specific register settings, reference pin connections, or startup sequences I should inspect to resolve this discrepancy on Channel 0?

Thank you for your guidance!

Michael Chiasson

RE: ADS127L18: ADS127L18 Full-Scale Test Error on CH0

Michael Chiasson — Mon, 24 Aug 2026 23:50:53 GMT

Awesome, thank you for your response, Keith. Your explanation makes a lot of sense, I think I was just thrown off because I saw it only on one channel but not the others (which probably do have gain error, but any positive gain error would result in the maximum value).

I will resolve the issue. Thanks again.

RE: DAC8742HEVM: DAC8742H HART Modem EVM – IOVDD and MOD_OUT Issue

Joseph Wu — Mon, 24 Aug 2026 23:39:47 GMT

Shardul,

MOD_IN and MOD_OUT aren't going to be on opposite sides of the sense resistor similar to a probe across the terminals. I'll refer you back to the schematic I clipped out from TIDA-060020 where the HART_IN and MOD_OUT are connected to one point of the resistor through capacitors:

In your circuit, you have MODIN going to the +24V point. This will only sense 24V. Both MODOUT and MODIN should be between the resistor and the transmitter to send and receive the signal.

Again, you should use an oscilloscope to measure the input and output signals. If you had an oscilloscope measuring both MODIN and MODOUT, you'd be able to see that there's no AC HART signal at MODIN.

Joseph Wu

DAC8742HEVM: DAC8742H HART Modem EVM – IOVDD and MOD_OUT Issue

Shardul Gogate — Wed, 15 Jul 2026 13:05:13 GMT

Part Number: DAC8742HEVM

Dear Support Team,

We are using the TI DAC8742H HART Modem EVM for our application and are currently facing an issue during evaluation.

After connecting the EVM to the USB2ANY, we observe that the IOVDD pin remains at 0 V instead of the expected 3.3 V. Additionally, there is no waveform present at the MOD_OUT pin.

Could you kindly verify whether our jumper settings are correct, or let us know if there are any mismatches in the jumper configuration that could cause this issue?

We would appreciate your guidance in resolving this problem.

Thank you for your support.

Best regards,
Shardul Gogate

RE: ADS127L18: ADS127L18 Full-Scale Test Error on CH0

Keith Nicholas — Mon, 24 Aug 2026 22:23:42 GMT

Hi Michael,

Welcome to the TI E2E community.

This is normal behavior, and I have observed this behavior as well. Each ADC channel has an individual multiplexor that connects the reference voltage to the ADC input, and each ADC modulator can have different offset and gain errors. In your case, it appears the gain error is about -67ppm for channel 0. (typical is +/-200ppm) Actually, there is also offset error as well, but this is primarily gain error that you are measuring.

For debug purposes, if you want to force +/-FS ideal codes, you can adjust the gain register value for each channel to always ensure a gain greater than 1. I normally set the gain register value to 0x800000h for a gain of 2, but any value to compensate for the worst case gain and offset errors will also work.

Also, since you are daisy-chaining devices, the following application note may be useful.

Design Considerations for Multiple Wide Bandwidth Delta- Sigma ADCs in Simultaneous-Sampling Systems (Rev. A)

Regards,
Keith Nicholas
Precision ADC Applications

ADS127L14: ADS127L14: Tem Project Schematic validation

Avijeet Mondal — Thu, 06 Aug 2026 11:24:41 GMT

Part Number: ADS127L14

Dear Keith Nicholas

Thanks for your review. We have updated the changes as per your recommendation.

Please check and help us to review the same.
as if you need anything else very specific to let me know

I have also added some set of question in the docs file please do check and let me know the same

Best regards
Avijeet Mondal

RX_Board_Rev_02.pdf (this master RX board file)

RX_Board_Slave.pdf (this salve Rx Board File , only check ADC section as the chnage is in that part only)

Reply_to_Keith_TI_E2E_V1.docx

RE: ADS127L14: ADS127L14: Tem Project Schematic validation

Keith Nicholas — Mon, 24 Aug 2026 22:00:01 GMT

Hello Avijeet,

See attached. Thank you for confirming the ground architecture of your system.

e2e.ti.com/.../Reply_5F00_to_5F00_Keith_5F00_Q1_2D00_Q8_5F00_Answers_5F00_Comments.docx

Regards,
Keith

TPS65982: TPS65982 USB3.0 only application

remco poelstra — Tue, 28 Jul 2026 11:36:36 GMT

Part Number: TPS65982

I'm using the TPS65982 in combination with the TUSB1146. With my configuration, 2-lanes DP/USB3.0 and 4-lanes DP work. When I try to use USB3.0 only, I can see that my USB3_event doesn't trigger. I want this to work correct. Is there any way to fix this problem?

usb3.0 only: DP mode event = 0V USB3 event = 0V

2-lanes dp/usb3.0: DP mode event = 3.3V USB3 event = 3.3V

4-lanes dp : DP mode event = 3.3V USB3 event = 0V

RE: TPS65982: TPS65982 USB3.0 only application

Elijah Orozco — Mon, 24 Aug 2026 21:24:50 GMT

Hi Remco,

I will get back to you either tomorrow or in a couple of days.

Best,

Elijah

RE: TUSB322I: Request for Recommended CC Controller and Redriver for USB 3.2 Gen2x2 (20 Gbps) Implementation

Ryan Kitto — Mon, 24 Aug 2026 21:22:30 GMT

Hi Shivakumar,

USB3.2X2 support is determined by the USB connection rather than the type-C connection. Because of this, any of our CC controllers should be able to support USB3.2X2 functionality. I would recommend the TUSB321AI or the TUSB322I.

For USB3 redrivers, our closest device to the PI3EQX1002E2 would be the TUSB1002A in terms of pinout.

However, we also have the TUSB1044A, which was made with USB Type-C USB3.2 Gen2X2 in mind. This device would consolidate the number over redrivers needed to support USB3.2 Gen2X2 to one device. This may be a better solutions for the customer, so I would also recommend this solution.

[quote userid="714776" url="~/support/data-converters-group/data-converters/f/data-converters-forum/1675988/tusb322i-request-for-recommended-cc-controller-and-redriver-for-usb-3-2-gen2x2-20-gbps-implementation"]Any compatible redriver/retimer solutions that have been validated for 20 Gbps operation.[/quote]

These redrivers do not necessarily need to support 20Gbps, just 10Gbps over four USB3 lanes. The above redrivers can support this.

[quote userid="714776" url="~/support/data-converters-group/data-converters/f/data-converters-forum/1675988/tusb322i-request-for-recommended-cc-controller-and-redriver-for-usb-3-2-gen2x2-20-gbps-implementation"]Estimated pricing for 10 devices (CC controller and associated redriver/retimer), which will help us evaluate the solution for potential implementation.[/quote]

Prices for these can be found in TI.com. Which customer is this for? Do you have an FAE you can reach out to for further pricing options?

Thanks,

Ryan

DAC38J84EVM: sys_clk, sysref and sync_n not working

Marvn Arcangel — Tue, 21 Jul 2026 12:44:33 GMT

Part Number: DAC38J84EVM

Hi Experts,

Can you help with the issue below?

A customer is trying to bring up a DAC38J84EVM with a Xilinx ZCU102 using the TI JESD204 8b/10b ZCU102 reference design. The current goal is to establish the JESD204B link and output a simple square-wave test pattern from the DAC.

The intended JESD configuration is:

Device: DAC38J84 / DAC3XJ8XEVM
FPGA board: Xilinx ZCU102, FMC HPC1
JESD mode: 8b/10b, subclass 1
L = 8
M = 4
F = 1
S = 1
K = 32
N = 16
N' = 16
HD = 1
Scrambling = disabled
Input data rate = 368.64 MSPS
Interpolation = 4x
Line rate = 3.6864 Gbps
FPGA/MGT reference clock = 92.16 MHz
TX user clock / tx_sys_clock = 46.08 MHz

From the TI zcu102_8b10b reference design. The design can build, but the link does not come up. The main issue seems to be clock/SYSREF/SYNC routing between the DAC3XJ8XEVM FMC connector and the ZCU102 FMC HPC connector.

Current observations

In DAC GUI onboard clocking mode, after programming the LMK04828 and DAC, the GUI still reports DAC clock/link alarms, including DAC PLL / SERDES PLL0/1 out-of-lock.
When I use the original TI design clocking, the Vivado debug cores are not detected. If I replace the design debug/system clock with the ZCU102 onboard clock, the debug cores appear, but this does not solve the DAC/LMK clocking issue.
I tried routing the FPGA sys_clock to a ZCU102 LED. With the original LMK/FMC clock input, the LED does not toggle, suggesting that the expected LMK clock is not reaching the FPGA clock input used by the design.
Based on the DAC3XJ8XEVM schematic, the LMK clock to the FPGA seems to be routed as CLK_LAO_0P/M to FMC G6/G7, while the original XDC appears to use sys_clk_p/n on another FMC clock pair. Could you confirm the correct ZCU102 HPC1 package pins for the DAC3XJ8XEVM FPGA fabric clock?
For the GTH/MGT reference clock, I believe the path should be GTX_CLKP/M / FMC D4/D5 into the ZCU102 GTH reference clock pins. Please confirm whether this is the correct clock source for the ZCU102 GTH transceiver in this setup.

SYSREF is also unclear. I believe DAC3XJ8XEVM routes CAR_SYSREFP/M to FMC G9/G10, but I do not see a valid SYSREF at the FPGA side. The SYSREF LED on the DAC EVM is also not active.

A major concern is JESD SYNC. From the DAC3XJ8XEVM schematic, the DAC SYNC signal appears to be routed to the TSW14J56-style FMC SYNC pins, for example F10/F11 or related SYNC pins. However, on the ZCU102 FMC HPC connector these pins appear to be NC. If this is true, the DAC cannot drive SYNC_N back to the FPGA, so the normal JESD204B CGS/ILAS sequence cannot complete.

Could you please help confirm the following?

Is the TI zcu102_8b10b reference design intended to work directly with DAC3XJ8XEVM + ZCU102, or was it designed only as a generic loopback/reference design?

What are the correct ZCU102 HPC1 FMC pin mappings for:

FPGA fabric/system clock from LMK04828
GTH/MGT reference clock
SYSREF
DAC SYNC_N
8 JESD TX lanes

Is there a known issue that the DAC3XJ8XEVM SYNC_N pins are not connected on ZCU102 HPC1?

I select DAC38J84EVM because I saw it supports xilinx fpga and in the refdesign there is folders for zcu102. If the ZCU102 FMC connector does not receive the DAC SYNC_N, is there a supported workaround, such as:

manual SYNC override in the FPGA JESD TX IP,
a different FMC connector/pin route,
a required board modification,
or an FMC adapter/interposer?

For my target line rate of 3.6864 Gbps and FPGA reference clock 92.16 MHz, what are the correct GTH Transceiver Wizard settings? In my Vivado setup, the QPLL requested reference clock field tends to revert to 156.25 MHz, although the actual clock calculation can show 92.16 MHz.

Could TI provide a known-working XDC / Vivado project / reference configuration for ZCU102 + DAC38J84EVM at 368.64 MSPS, LMFS = 8411, 8 lanes?

Thanks!

Marvin

RE: DAC38J84EVM: sys_clk, sysref and sync_n not working

Matthew Kramer — Mon, 24 Aug 2026 21:11:08 GMT

Hey Marvin,

See attached. Note this is designed to be used with the new unreleased JESD Controller software that pairs with the TSW14J58 capture card. When the top level script mentions the clocks being setup you should go to your FPGA ILA and try to get a link up. Once the FPGA starts sending data you can continue the script and hopefully should get a link up. This script can both get you an optimized sequence (in order) as well as print the full dac/lmk register state once the device is running.

Regards,

Matt

e2e.ti.com/.../examples_5F00_dac3xj8x.zip

AFE4432: AFE4432 Documentation access denied.

Hermano Guimaraes — Mon, 24 Aug 2026 17:11:28 GMT

Part Number: AFE4432

Hello,

I am starting the development of a new optical heart-rate monitoring product and I am interested in using the AFE4432 as the analog front-end for the project.

I requested access to the complete AFE4432 design documentation through the TI website, but unfortunately my request was denied. Since the publicly available datasheet does not include essential information such as the complete pinout and detailed device documentation, I am unable to begin the hardware design without access to these resources.

My company has been operating legally and actively in the electronics market for five years, developing and commercializing electronic products. This is a legitimate commercial development project, and we intend to evaluate the AFE4432 for use in a production product.

Could you please review my request and advise me on how I can obtain access to the AFE4432 full datasheet and design resources?

I am happy to provide additional information about my company or the project if required.

Thank you for your assistance.

Best regards,
Hermano Guimarães