<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://e2e.ti.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Data converters</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/</link><description>&lt;p style="display:none;"&gt;blank&lt;/p&gt;</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><item><title>Forum Post: ADS5294: ADC</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697749/ads5294-adc</link><pubDate>Sun, 15 Nov 2026 16:20:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:3f93ccfa-6ecd-4e4d-b79b-115c4f3bc60f</guid><dc:creator>Nishant  Gupta</dc:creator><description>Part Number: ADS5294 Other Parts Discussed in Thread: TINA-TI Hello TI Team, I would like to request the TINA-TI SPICE simulation model for the ADC ADS5294 Could you please clarify the following points? Can this ADC support sampling rates in the range of 5–8 MSPS? What amplifier bandwidth and settling performance are required to achieve 14-bit ENOB at an 8 MSPS sampling rate?Also recommend the cuttoff frequency and values of Filter that to be put between Amplifier and ADC. To perfectly settle and sample correctly to achieve performace My input consists of pixel DC values that settle towards the end of each clock cycle. For a 100 ns pixel period, the signal becomes stable around 90–95 ns. What is the recommended approach to sample at this point while ignoring initial transient values? How should the FPGA sampling trigger and ADC timing be configured to capture the settled pixel value accurately? Does TI offer any MIL-grade or space-grade octal-channel pipeline ADCs? If available, please provide the corresponding SPICE models. I would also appreciate your recommendations on the overall ADC, amplifier and FPGA interface configuration to evaluate the system&amp;#39;s sampling accuracy and performance.</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADS5294">ADS5294</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/tina_2D00_ti">tina-ti</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/Aerospace%2b_2600_amp_3B00_%2bDefense">Aerospace &amp;amp; Defense</category></item><item><title>Forum Post: ADC12QJ1600EVM: ADC12QJ1600 EVM GUI write_register issue Win 11</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697732/adc12qj1600evm-adc12qj1600-evm-gui-write_register-issue-win-11</link><pubDate>Sat, 14 Nov 2026 21:24:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:2f37d836-be26-421d-9153-a44a5c3c275b</guid><dc:creator>Marco Cassinerio</dc:creator><description>Part Number: ADC12QJ1600EVM Other Parts Discussed in Thread: ADC12QJ1600 Hello, I am trying to use the ADC12QJ1600 EVM GUI to configure the respective evaluation board. Software installed without issues but I get this error when I try to program Clocks and ADC: &amp;quot;Error 1379 occurred at ADC12QJ1600 EVM GUI.py, line 57 in write_register LabVIEW_Exception: Open Application Reference in ADC12QJ1600 EMV GUI.lvlib: GetApplication.vi-&amp;gt;ADC12QJ1600 EVM GUI.lvlib:Write Register.vi I tried updating the NI RTE but that didn&amp;#39;t solve the problem. Has anyone been able to use the GUI? If so, how? Thanks, Marco</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC12QJ1600">ADC12QJ1600</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC12QJ1600EVM">ADC12QJ1600EVM</category></item><item><title>Forum Post: RE: ADC121S101-Q1: ADC121S101 - 1.024 MSPS throughput using 16 SCLK cycles at 20 MHz</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697639/adc121s101-q1-adc121s101---1-024-msps-throughput-using-16-sclk-cycles-at-20-mhz/6539072</link><pubDate>Sat, 14 Nov 2026 15:50:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:5874b55b-2be9-450f-b7d2-5ae2b1c6e30d</guid><dc:creator>Stefano Martino</dc:creator><description>Thank you, Rahul. Just one additional clarification: assuming all the timing requirements are satisfied, including the minimum 350 ns acquisition time, do you expect any significant degradation in ADC accuracy (INL, DNL, ENOB) at 1.024 MSPS compared with 1 MSPS? Or is the expected deviation primarily related to power consumption and the fact that 1.024 MSPS is outside the characterized operating range? Best regards. Stefano</description></item><item><title>Forum Post: RE: DAC11001B: TIDA-060031</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697565/dac11001b-tida-060031/6539068</link><pubDate>Sat, 14 Nov 2026 14:32:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:5d437580-1468-4b88-9403-82eab29ab2c0</guid><dc:creator>Dietmar Br&amp;#228;uer</dc:creator><description>Thanks Paul for this simulation file. If you contact me via email I can send you my Simetrix simulation as well. You can download a free version of Simetrix from Renesas.</description></item><item><title>Forum Post: DAC80508-04EVM: EVM GUI not working correctly</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697704/dac80508-04evm-evm-gui-not-working-correctly</link><pubDate>Sat, 14 Nov 2026 00:06:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:76eed4bd-c46a-4161-9612-910bbea1895f</guid><dc:creator>Raymond Yen</dc:creator><description>Part Number: DAC80508-04EVM TI_support_request.txt TI_DAC80508_Bench_Evidence.zip</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/DAC80508">DAC80508</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/Medical%2b_2600_amp_3B00_%2bhealthcare">Medical &amp;amp; healthcare</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/DAC80508_2D00_04EVM">DAC80508-04EVM</category></item><item><title>Forum Post: RE: DAC5574: Replace DAC5574 to DAC6574 or DAC7574 with No Change in firmware?</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697184/dac5574-replace-dac5574-to-dac6574-or-dac7574-with-no-change-in-firmware/6539012</link><pubDate>Fri, 13 Nov 2026 23:38:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:414b03e0-8436-4f95-b64c-f3c6ce13d549</guid><dc:creator>Lucas Burnette</dc:creator><description>Hi Takeshima-san, The same firmware can be used for the DAC5574, DAC6574, and DAC7574 with a small modification. The difference between the devices are the resolution of the DAC and the size of the data field in the register map: DAC5574 is 8-bit, DAC6574 is 10-bit, and DAC7574 is 12-bit An example of this data field difference is shown below (an X is a don&amp;#39;t care bit): DAC5574: (DAC data ranges from 0x0000 - 0xFF00) Index: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Name: MSB7 MSB6 MSB5 MSB4 MSB3 MSB2 MSB1 MSB0 X X X X X X X X DAC6574: (DAC data ranges from 0x0000 - 0xFFC0) Index: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Name: MSB7 MSB6 MSB5 MSB4 MSB3 MSB2 MSB1 MSB0 LSB7 LSB6 X X X X X X DAC7574: (DAC data ranges from 0x0000 - 0xFFF0) Index: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Name: MSB7 MSB6 MSB5 MSB4 MSB3 MSB2 MSB1 MSB0 LSB7 LSB6 LSB5 LSB4 X X X X Thank you, Lucas</description></item><item><title>Forum Post: RE: ADS127L21: ADS127L21: shorted-input noise below 1 Hz (0.01 Hz to 10 Hz)</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1696798/ads127l21-ads127l21-shorted-input-noise-below-1-hz-0-01-hz-to-10-hz/6539010</link><pubDate>Fri, 13 Nov 2026 23:36:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:e47739f1-0857-47a9-9138-37ea15b4fce5</guid><dc:creator>Juraci Mario de Carvalho</dc:creator><description>Thank you, Keith, for the clear answers and the simulation. I will follow your advice and use high-speed mode with the OPA2387.</description></item><item><title>Forum Post: RE: DAC161S997: Temperature dependence of DAC161S997</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1691183/dac161s997-temperature-dependence-of-dac161s997/6539001</link><pubDate>Fri, 13 Nov 2026 23:27:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:3e867b90-ed2a-4fde-b538-6986095c0b53</guid><dc:creator>Joseph Wu</dc:creator><description>Niek, I&amp;#39;m sorry I didn&amp;#39;t have a chance to respond earlier in the week. The only thing that could be a big source of error is the TVS diode at the input of LOOP+ and LOOP-. This would be D4, which is a 824551331 Wurth diode. Any leakage current from this diode would be considered an offset current. Using an ammeter, there&amp;#39;s no change in the voltage drop across the LOOP+ to LOOP-. Changes in temperature would still appear as an offset current, so the contribution would become an offset drift. Looking that the datasheet for the 824551331, the leakage current is listed as 2uA max. That doesn&amp;#39;t seem like it would be enough of a current to change the result (this would be roughly 0.01% of the FS). I wanted to check that the diode wasn&amp;#39;t changed from the schematic. Regardless, it would be simple to remove the diode just to run the test. Beyond that, there aren&amp;#39;t too many external things that would change the offset or gain error for the device. The loop current is set by the ratio of the 80kΩ and 40Ω resistors at the inputs of the output amplifier driving BASE. Certainly, there is some contribution of the mismatch between these two resistors or the offset of the amplifier, but these should be accounted for in the device. I would also look at the capacitances on the board. It is possible that there is a small oscillation that may be affecting the DC measurement of the current. In the DAC161S997 datasheet, there&amp;#39;s a section on stability (9.1.1.5.4 on page 22). It lists some of the capacitances that adversely affect the operation from Figure 18 on page 20 of the datasheet: In particular, I think that CX1 should be smaller (10nF max, but can be larger if there&amp;#39;s a series resistance for RX1 of 40Ω). Look through the stability section, and maybe reduce some of the capacitances to test the operation. I would try to remove C8 and see if that changes anything. One last thing is that if you&amp;#39;ve been using boards that have been going through some soldering rework, you want to make sure you are cleaning the boards between each change. I know I&amp;#39;ve had problems with residue remaining on the board. I know it&amp;#39;s been enough to throw off my linearity measurements when I forget to clean the flux off. Joseph Wu</description></item><item><title>Forum Post: ADC3683EVM: ADC3683EVM Rev E Schemetic</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697703/adc3683evm-adc3683evm-rev-e-schemetic</link><pubDate>Fri, 13 Nov 2026 22:21:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:d2b000f2-0748-4108-9cb5-7ce6833ba5e5</guid><dc:creator>Tim Bartos</dc:creator><description>Part Number: ADC3683EVM Other Parts Discussed in Thread: TSW1418EVM I am also suffering from a similar issue as another poster. I was able to locate the the revision D of the schematic, but it is substantially different to the point of incompatibility. Likewise, I am concerned these differences mean the TSW1418EVM Rev A ADC evaluation board is not compatible with it. Is there any chance the REVE board schematic can be posted anywhere?</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC3683EVM">ADC3683EVM</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/TSW1418EVM">TSW1418EVM</category></item><item><title>Forum Post: RE: DS90UB954-Q1: Converting MIPI-CSI to DSI</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1694365/ds90ub954-q1-converting-mipi-csi-to-dsi/6538950</link><pubDate>Fri, 13 Nov 2026 21:54:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:5c885c1c-87d1-4eae-b46c-6e4682c15da2</guid><dc:creator>Caitlin Behne</dc:creator><description>Hello Neta, Use an unused parallel data bit for DATAEN. The DS90UB914A-Q1 GPIO route will not meet DLPC3421 timing. The GPIO path only runs from the deserializer GPIO to the serializer GPO. The DS90UB913A-Q1 datasheet states its GPOs cannot be configured as inputs for remote communication with the deserializer, so a signal generated on the serializer side cannot reach a 914A GPIO. In the supported direction, GPIO is carried on the low-speed control channel with a 66 kHz maximum switching rate and non-deterministic latency (25 &amp;#181;s maximum delta between links, SNLS443G section 7.3.4). It has no timing relationship to PCLK, HSYNC or VSYNC. With 8-bit monochrome, 4 of the 12 data inputs on the 913A are free. The DS90UB913A/914A datasheets do not document this use, so whether a spare bit can carry DATAEN needs to be verified on your setup. Because the spare bit travels in the same forward-channel frame as the video data, it should stay aligned to PCLK. In the 12-bit modes, HSYNC and VSYNC also pass without the one-transition-per-10-PCLK limit that applies in 10-bit mode. Your SoC needs to generate DATAEN with the DLPC3421 spacing: at least 4 PCLK from HSYNC to DATAEN rising, and at least 8 PCLK from DATAEN falling to the next HSYNC. DATAEN polarity and the final timing margins need to be verified with the DLPC3421 team. Best regards, Caitlin Behne</description></item><item><title>Forum Post: RE: ADS127L21: ADS127L21: shorted-input noise below 1 Hz (0.01 Hz to 10 Hz)</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1696798/ads127l21-ads127l21-shorted-input-noise-below-1-hz-0-01-hz-to-10-hz/6538927</link><pubDate>Fri, 13 Nov 2026 21:24:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:88661766-4ed9-424a-ab68-ce840f89d2ff</guid><dc:creator>Keith Nicholas</dc:creator><description>Hello Juraci, It depends on the maximum input signal frequency. I assume you are considering operation in max-speed mode to allow more oversampling, and reduced noise, with a maximum input signal frequency of 50-100Hz? In this case, you can use a large filter capacitor at the ADC inputs to further average the input ADC input capacitor sampling transients, which should result in good performance using the OPA2387. However, if you needed good AC performance for input signals in the 10&amp;#39;s of kHz range, then you would want to use the higher bandwidth OPA2388. The SNR will likely be very good, but it is hard to predict THD without actual testing of the amplifier in the lab. This is true for either OPA2388 or OPA2387. Also, the ADS127L21 optimal performance will be in high-speed mode, with a maximum clock frequency of 25.6MHz due to internal settling for the modulator. I&amp;#39;m not sure going to max-speed mode with additional over-sampling will buy much in the way of AC performance (SNR or THD). The primary purpose for the max-speed mode is faster settling time for input step functions or wider input signal bandwidth. I did run a spice simulation to check for phase margin and amplifier settling, which all look good and suggest good performance using the OPA2387. However, the simulation results are usually very good to predict noise/SNR performance, but do not always predict accurate THD if that is important. Regards, Keith</description></item><item><title>Forum Post: RE: DAC11001B: TIDA-060031</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697565/dac11001b-tida-060031/6538749</link><pubDate>Fri, 13 Nov 2026 16:56:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:15b0d7cd-2d21-47d3-bb62-8e394a138c3c</guid><dc:creator>Paul_Frost</dc:creator><description>e2e.ti.com/.../I2S-to-SPI-Digital-Logic-_2D00_-daisy-chain-with-straight-binary.TSC</description></item><item><title>Forum Post: RE: ADS7138-Q1: Register value : 0X9</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697528/ads7138-q1-register-value-0x9/6538727</link><pubDate>Fri, 13 Nov 2026 16:33:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:a7e6d7fd-450f-4502-84c3-b5f0dea9d47e</guid><dc:creator>Joel Meraz</dc:creator><description>Hi Alex, Can you help me understand the syntax of the i2c_get command? I am thinking the first argument (0) is the I2C bus number, the second (0x17) is the I2C address, and the third is your desired register address to read from. Is that correct? If so, it is likely that the command to perform a register read or write with the ADS7138-Q1 is not being sent in the correct format. Please see the screenshot below which shows page 33 of the datasheet, and specifies how to perform a register read from the device. The i2c_get command likely needs to be modified or formatted properly so the ADS7138-Q1 can receive it properly. Could you probe the I2C lines to observe what is being sent on SCL and SDA? Regards, Joel</description></item><item><title>Forum Post: RE: ADC121S101-Q1: ADC121S101 - 1.024 MSPS throughput using 16 SCLK cycles at 20 MHz</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697639/adc121s101-q1-adc121s101---1-024-msps-throughput-using-16-sclk-cycles-at-20-mhz/6538726</link><pubDate>Fri, 13 Nov 2026 16:32:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:038aa824-157f-4481-baaa-be3da8018222</guid><dc:creator>RahulVK</dc:creator><description>Hi Stefano, Functionally it should be all right as you are able to meet the timing boundaries specified in the datasheet. The device specifications in the datasheet are for 1MSPS maximum. Operation at 1.024MSPS is outside this spec - expect marginal increase in power consumption and deviation from published specifications. Regards, Rahul</description></item><item><title>Forum Post: RE: DAC11001B: TIDA-060031</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697565/dac11001b-tida-060031/6538682</link><pubDate>Fri, 13 Nov 2026 15:58:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:9f8ca812-36c8-429c-b2bc-05069fa7ec60</guid><dc:creator>Paul_Frost</dc:creator><description>Dietmar, You are correct about the limited time for the CS high pulse. Ultimately, the reference circuit is violating the minimum timing for the CShigh pulse when in 192kSPS mode. Like most specifications, there is some margin in the 50ns number for temperature, voltage, and process variation. In my testing, 18-25ns (there is some propagation delay in the circuit) worked consistently at 192ksps, or a 12.288MHz clock. This is a reference design for the DAC11001B, so the discrete digital circuit was just a means-to-an-end design decision. If you are building a product, here as some alternatives: 1. Using the XMOS or your controller/FPGA, adjust the digital output to already be in the correct SPI format. I am personally not a firmware designer, so that was a bit intimidating for me. That being said, I am working on a new reference design for the DAC82002 which does exactly this. The XMOS image can be overwritten by you if you would like to try to make the change. 2. Operate at a lower sample rate, which lowers the SCLK/BCK frequency, and can enable you to increase the delay circuit. 3. Build a discrete asynchronous buffer. I had considered this for the design - you add a 32-bit double shift register, and clock in the two data frames serially, but clock them out in parallel (one for each DAC). That would enable you to use BCK/2. I have some TINA-TI sims of the discrete digital circuit I can share if you like. Thanks, Paul</description></item><item><title>Forum Post: ADC3910S125: ADC3910S125 SDIO pin stuck to 0 while SPI reading</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697648/adc3910s125-adc3910s125-sdio-pin-stuck-to-0-while-spi-reading</link><pubDate>Fri, 13 Nov 2026 15:22:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:43ae64ab-da84-4edc-b7fd-36daadcd4e4e</guid><dc:creator>Fadong Zou</dc:creator><description>Part Number: ADC3910S125 I am using ADC3910S125 on a design. according to datasheet, MCU need to send HW reset pulse on RESET pin then starts to operating on SPI registers. After I send reset pulse, wait for long enough time. Then i start SPI traffic. the phenomen I see is SPI writing works as expected, but If i tried to read from SPI, SDIO pin is pulled low by ADC3910s125 immediately after 1st CLK rising edge, see the first image below (this image is not reading address 0x00, address is pulled to 0 by ADC). BTW, in order to accomodate the voltage level difference between MCU and ADC SPI, my system is using software SPI to talk to ADC3910, every IO is configured in open drain output with 2.2K pull up to 1.8V. But, if i don&amp;#39;t apply reset pulse before read SPI registers, everything is normal, the below image is my reading operation without sending reset pusle. thansk and regards,</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/Portable%2bElectronics">Portable Electronics</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC3910S125">ADC3910S125</category></item><item><title>Forum Post: RE: DS90UB954-Q1: Converting MIPI-CSI to DSI</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1694365/ds90ub954-q1-converting-mipi-csi-to-dsi/6538612</link><pubDate>Fri, 13 Nov 2026 14:54:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:8e349daa-50bc-446e-9e68-42cfda4faec2</guid><dc:creator>Neta Sherer</dc:creator><description>Hi Caitlin, Would it be possible to use one of the DS90UB914A-Q1 GPIO outputs to carry the DATAEN signal from the serializer side? Specifically, can the GPIO signal be forwarded with deterministic timing and sufficient synchronization to PCLK, HSYNC, and VSYNC to meet the DLPC3421 timing requirements? Alternatively, would you recommend transmitting DATAEN through an unused parallel video data bit?</description></item><item><title>Forum Post: ADC121S101-Q1: ADC121S101 - 1.024 MSPS throughput using 16 SCLK cycles at 20 MHz</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697639/adc121s101-q1-adc121s101---1-024-msps-throughput-using-16-sclk-cycles-at-20-mhz</link><pubDate>Fri, 13 Nov 2026 14:45:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:0cf5fbb1-726b-443b-97a4-cd682214681b</guid><dc:creator>Stefano Martino</dc:creator><description>Part Number: ADC121S101-Q1 Other Parts Discussed in Thread: ADC121S101 We are evaluating the ADC121S101 for an FPGA-based acquisition system requiring exactly 128 samples every 125 &amp;#181;s (1.024 MSPS). Our proposed operating conditions are: SCLK frequency: 20 MHz (within specification) 16 SCLK cycles per conversion Conversion periods: 975 ns and 981.25 ns, distributed to achieve exactly 1.024 MSPS on average Minimum acquisition time (13th SCLK rising edge to next CS falling edge): 350 ns Minimum quiet time: 175 ns All other serial-interface timing requirements satisfied Section 8.3.1 of the datasheet explicitly permits fewer than 20 SCLK cycles if the timing requirements are met. Our question: Is the specified maximum throughput of 1 MSPS a consequence of the conventional 20-clock interface timing, or does the ADC have an additional internal limitation that prevents operation above 1 MSPS, even when the 350 ns acquisition time and all other timing requirements are satisfied? Specifically, can TI confirm whether 1.024 MSPS operation with the timing described above preserves the ADC&amp;#39;s specified accuracy and performance over the full operating temperature range? Thank you.</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC121S101">ADC121S101</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/Hybrid">Hybrid</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/ADC121S101_2D00_Q1">ADC121S101-Q1</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/electric%2b_2600_amp_3B00_%2bpowertrain%2bsystems">electric &amp;amp; powertrain systems</category></item><item><title>Forum Post: RE: TPS62410: Was there a PCN issued for TPS62410DRCR in 2021 specifically related to a change in the internal lead frame structure?”</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697559/tps62410-was-there-a-pcn-issued-for-tps62410drcr-in-2021-specifically-related-to-a-change-in-the-internal-lead-frame-structure/6538500</link><pubDate>Fri, 13 Nov 2026 12:26:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:3ad21a3c-9b63-4315-b35d-4645edce9f29</guid><dc:creator>Josef Marsmann</dc:creator><description>Hi Vadas, Thanks for contacting us. E2E is a forum for Technical and Design support - your questions about PCN documentation will be best addressed by the TI Customer Support team: https://www.ti.com/customer-support/request-form . From there, select the &amp;quot;Product Information&amp;quot; category, which will include any support request about PCN and related documentation. Best regards, Sepp</description></item><item><title>Forum Post: DAC11001B: TIDA-060031</title><link>https://e2e.ti.com/support/data-converters-group/data-converters/f/data-converters-forum/1697565/dac11001b-tida-060031</link><pubDate>Fri, 13 Nov 2026 09:37:00 GMT</pubDate><guid isPermaLink="false">cb01d8b2-d089-468d-babb-77d1d8683490:a6ee844c-9418-4098-b898-d0ccdc05e252</guid><dc:creator>Dietmar Br&amp;#228;uer</dc:creator><description>Part Number: DAC11001B Other Parts Discussed in Thread: TIDA-060031 , DAC82002 , TINA-TI The data sheet of the DAC11001B request a minimum t cshigh &amp;quot;/SYNC high time&amp;quot; of 50ns at VCC=5V The schematic diagram of the demo board TIDA-060031 shows a one-shot circuit triggered by the rising edge of the “I2S_LRCK” signal. The one-shot is implemented using a DS1100LZ-45+ digital delay line, which has a delay of 9 ns per step. The second tap is hardwired and produces a delay of 18 ns. Therefore, the resulting one-shot has a high time of 19 ns, which is far from the required 50 ns. It would be very helpful if you could provide a block diagram of the digital shift register and the associated parallel registers. A picture is worth more than 1,000 words My understanding is that we have a shift register, and its clock input is active only when “SPI_CS_AUD” is low. However, “SPI_CS_AUD” also has another function: a high pulse triggers the parallel transfer of data from the 32bit shift register to a first 32bit parallel register. It is unclear whether the transfer occurs in response to one of the two edge transitions or based on the level of this signal. A second 32bit parallel register then takes the data from the first 32bit parallel register on the falling edge of “SPI_LDAC_AUD.” This means that the falling edge is the one that determines the jitter of the entire system. The “SPI_CS_AUD” has do placed between two falling edges of the &amp;quot;SPI_CLK_AUD&amp;quot;. If the &amp;quot;I2S_BCK&amp;quot; &amp;amp; &amp;quot;SPI_CLK_AUD&amp;quot; is 12.288MHz we have a periode of 81ns. If “I2S_BCK” and “SPI_CLK_AUD” are 12.288 MHz, this results in a period of 81 ns. Precisely placing a 50-ns high pulse within a period of 81 ns is not so easy when you consider that the entire process must be asynchronous. Since your demo board is running I assume that the given value in the data sheet for t cshigh &amp;quot;/SYNC high time&amp;quot; is wrong. If this given time is incorrect, what would be the correct one? Dietmar</description><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/TIDA_2D00_060031">TIDA-060031</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/DAC11001B">DAC11001B</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/DAC82002">DAC82002</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/tina_2D00_ti">tina-ti</category><category domain="https://e2e.ti.com/support/data-converters-group/data-converters/tags/Test%2b_2600_amp_3B00_%2bMeasurement">Test &amp;amp; Measurement</category></item></channel></rss>