Ideas Test


Add a 25 MS/s sample rate for analog channels

When the high sample rates were added for the Pro 8 and Pro 16 (thanks - it's awesome!), an intermediate sample rate for digital channels was introduced at 250 MS/s. This sits between the 500 MS/s and 125 MS/s rates. However, a corresponding intermediate sample rate of 25 MS/s between 50 MS/s and 12.5 MS/s was not introduced for the analog channels even though the post ( states that the bandwidth increase applies to both analog and digital channels. The lack of this intermediate sample rate reduces the flexibility of the analog capture.

A quick check of the Logic 1.2.18 software when configuring a Logic Pro 16 shows that (with no digital channels enabled) that the sample rate drops from 50 MS/s to 12.5 MS/s when going from 5 analog channels enabled to 6 analog channels enabled. This 12.5 MS/s rate is then available for up to all 16 analog channels enabled. This suggests that the Pro 16 could support the proposed intermediate sample rate of 25 MS/s on something like 9-11 channels. I'm sure there are considerations with the hardware/software which I'm not aware of, but presumably the proposed 25 MS/s intermediate sample rate would be feasible.

Could this 25 MS/s intermediate sample rate be added to fill in the gap between 50 MS/s and 12.5 MS/s for analog channels and bring them closer to the configuration flexibility of the digital channels?

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jun 26 2018
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:27

    Thanks for the detailed insight, Mark! Got to love the engineering tradeoffs. I'll also throw out that I don't have some burning need for 25 MS/s sampling - just seemed odd that it wasn't available when the "equivalent" rate for digital signals was added. This is very much a low-priority wishlist item (at least for me)!

    I think I recall from somewhere else you (or someone else) mentioned that the FPGA design is somewhere around (or above) 99% utilization. It's honestly impressive that everything works and is crammed in there! I can imagine that Place and Route takes ages. It's also entirely understandable that the solution has to exist on the device itself to keep the USB data rates up.

    Sounds like the answer is "potentially feasible, but our options are limited":
    1. Hardware AA filtering before the ADC is fixed, so no changes available there
    2. The digital AA filter topology doesn't support 2:1 downsampling (ie. 25 MS/s)
    3. Changing the digital AA filter isn't feasible due to space constraints in the FPGA design
    4. Removing the digital AA filter gets configurable downsampling, but introduces aliased signals into the downsampled data
    5. Supporting both approaches is also not feasible due to the FPGA design space constraints which would necessitate software changes (ie. re-flashing the FPGA when the other approach is requested + the code to know when this is necessary)

    Maybe if someone has an epiphany which frees up some FPGA design space, then a different filter topology could support the different sampling rates. Or, if removing the digital AA filter becomes the preferred path forward later on then this could be revisited. Otherwise, keep up the great work and thanks for the response!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:27

    Great question, this is something we struggled to achieve in the hardware & FPGA, but couldn't quite get it to work. That said though we might add it in the future if we decide to remove the downsampling filter from the FPGA.

    Normally, when recording an analog signal with an ADC, the input signal must first be filtered so it does not contain frequency components above half of the sample rate. (Nyquist rate).
    The Pro hardware samples at 50 MS/s, and has a analog AA filter before the ADC with a cutoff at about 10 MHz. The advertised analog bandwidth is 5 MHz, but in reality it's much closer to 10 MHz, depending on where you define the cutoff.

    When sampling slower, normally the analog AA filter needs to be adjusted, to prevent frequency components below the original AA filter's cutoff but above the lower Nyquist rate are removed. However switching linear phase filters that work down to DC is difficult and expensive, so we accomplish the same thing by recording at the original 50 MS/s, and then filtering it in a digital filter, then downsampling that output, to avoid aliasing.

    This has to be done in the FPGA, before the data is sent over USB, to achieve any USB bandwidth saving. (USB bandwidth is what limits the sample rate combinations)

    Unfortunately, I could not create a filter in the FPGA that would support 2:1 downsampling - the topology I'm using only supports power of 2 ratios starting with 4:1. That's why the sample rates look so odd - they follow the pattern 1:1, 4:1, 8:1, 16:1, etc.

    Now, we could just remove the digital anti-aliasing filter from the FPGA. That would let us select any integer decimation option we want, not just the power of 2 options, in addition to allowing the 2:1 rate. The main reason we would consider doing this is that aliasing of small high-frequency components isn't that disruptive in time domain, and in fact it might be what customers want - it's closer to the 'truth' than the filtered version, even if it's not the complete picture.
    One of the factors affecting the decision is that it's not likely we could support both modes without considerably more work. The FPGA is just about out of space, so it's not likely both strategies would fit in a single design. This would result in the need to re-flash the FPGA when switching from one operational mode to another, something that complicates software development, etc.