Saleae Logic User Manual page 63

active analog channels and reduce the sample rate to the minimum required for the remaining active
channels.
In general, there is no benefit to sampling with lower digital sample rates. Our software run length
encodes the data as it arrives so that memory usage is directly proportional to data density and unrelated
to the sample rate.
Here are several factors to keep in mind when selecting the device capture settings:
•
When recording for long durations, minimize the number of analog channels and reduce analog
sample rates to the minimum to conserve RAM. Analog samples consume considerably more
memory than digital samples and can reduce maximum recording times from hours to mere
seconds. One channel of 50 MSPS analog data will consume 750 MB.
•
You can save memory while recording analog data by disabling the up-sampled pipeline in the
software preferences. That will reduce the memory usage of analog data by about 50%.
•
The "performance" setting in the capture settings limits the maximum USB bandwidth by the device.
It can be used on systems with poor USB performance to increase reliability by sampling at lower
speeds (i.e., reduce the number of "can't keep up" errors). It can also be used to select lower
sample rates.
•
Digital channels only consume memory when their state changes. That makes the memory
consumption of digital channels proportional to the number of transitions and not the sample rate or
number of samples recorded. It makes it possible to record low-speed signals like I2C or serial for
hours, where 10 MHz SPI can only record for several minutes.
•
The memory usage estimator on the capture settings popover shows the estimated memory usage
for a capture as a range. The range covers no digital activity to the maximum digital activity.
•
A capture will consume memory until its tab is closed. When working with long captures, we
recommend keeping only one capture open in the software at a time. Save the capture, move it to a
new tab if it is not already, and then use the tab's menu to close it. That will free up memory for the
next capture.
•
Analyzers will also consume memory directly proportional to the number of generated results. The
software uses about 40 bytes per result. Keep this in mind when recording high-speed parallel, SPI,
or I2S traffic. This memory usage is not reported in our software. We recommend tracking the
software's memory usage in task manager or equivalent.
•
The capture progress dialog, which is displayed when a capture is in progress, can show several
statistics. It will show the number of samples collected as well as the processing backlog and
memory used. That is just the memory used by the analog and digital channels exclusively and does
not include the overhead of the software or the memory used by Analyzers or other tabs.
•
When using a trigger, the capture progress dialog will also show the trigger processing backlog. For
correct operation, it's important that the processing backlog and the trigger search backlog stay as
close to 0 as possible. If either of these numbers steadily increases during a capture, it may cause
the memory usage to increase dramatically, and it also may result in a much longer capture than
requested. That can be solved by lowering the digital sampling rate or removing unused channels.
There is also an issue with version 1.1.34 and older that prevents the trigger from operating properly
when one or more analog channels are used. Until 1.1.35/1.2.0 is released, please disable the
trigger while using analog channels.
•
The current software does not safely handle running out of memory. If the software fails to allocate
additional memory, the current version will crash. We are working on a solution that will be
Page 63 of 69