Ideas Test


Separate sample rate for analog and digital

Sometimes it is difficult to find the right settings for the sample rate.
For example: I have a Logic Pro 8 connected to a USB 2.0 port. I can choose 50MS/s for 5 digital channel and 125kS/s for one analog channel, but it isn't possible to have 50MS/s for 5 digital channel if I have 2 analog channels. Why? I don't mind to have 1kHz sample rate for analog, but I need 50MHz for digital to decode USB FS. The best would be sample rate adjustable for every channel. Thanks, Petr

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Aug 2 2018
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 17:00

    Hey CoreyMac, you have a good point. Although analog captures at a higher sample rate will take up more memory, higher digital sample rates have no effect on memory usage.

    This is because we save samples into memory only when transitions occur, so if you have a long idle data line, no memory will be used until the next rising/falling edge occurs.

    This is not the case for analog, unfortunately.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    August 2, 2018 17:00

    While this has very few votes, for many of the memory size/capture size issues, being able to reduce the required data to capture per channel and by type would be a huge benefit I would think.

    For example, if I am watching what is effectively a digital signal with a low effective clock rate, (slow serial bus-type things), I can live with a very low capture rate. For 9600bps RS-232, I do not need to know much more than the level changed and approximately when so the serial data can be decided. Also, if I am looking at an analog signal that is traced long term for a signal/level event, again, a few kHz of sample rate is sufficient.

    When I am looking for hours or longer between events, I am willing to trade resolution for capture size. The lack of capture edit capabilities and captures limited to memory size makes these even more useful additions when they can greatly reduce the "saved" capture size.

    In the network capture world, this is sometimes call "slicing" the frame where only the first 128 bytes of an Ethernet packet are captured. In a perfect world, you would like to save everything in great detail, but in the real world getting something is better than nothing (or an out of memory crash)...

    For low resolution data, it is more important to know THAT it changed instead of which fraction of microsecond it did change. The Logic units are not really state analyzers anyway, so maybe this can be an advantage feature.

    Even if the hardware limitation are restricting the scaling of the actual physical measurement, then just dropping the uninteresting parts as you are describing whether by sample count or lack of state change would seem to massively reduce the RAM required...

    Thank you,