DigiView™ Logic Analyzer Compression Explained

DigiView™ Hardware Compression Explained

We want two conflicting features in a logic analyzer:

  • High sample Rate (high resolution)
  • High sample Count (a lot of data/time)
Ideally, we would like to have high sample rates AND high sample counts to capture a long time-span with high resolution. However, in a typical Analyzer, it would take gigabytes of Analyzer memory to achieve both if your data transitions are fairly sparse (microsecond or more gaps).

DigiView, unlike other logic analyzers, acheives both goals by utilizing intelligent hardware memory compression techniques. A large hardware buffer alone can not reach these goals and would be cost prohibitive.

DigiView uses multiple real-time, hardware based compression techniques to compact the captured data. This has a much greater impact than increasing the buffer depth.

The data captured in logic analyzer applications is often stable for multiple sample periods (particularly at higher sample rates), making the simpliest compression technique (Transistional) the most effective. DigiView has utilized this technique since the early design stages of model DV1-100 in 2000. Later models added additional compression techniques to further minimize storage while capturing bursts of data or semi-bursting data (Tri-mode).

Our latest models (DV3500, DV509, DV518) utilize additional compression techniques (Multi-mode) providing a 25-50% increase over Tri-mode techniques.

Having multiple techniques decided intelligently in real time, coupled with fast sample times and a very long run-length limit, makes our compression very applicable in real-world applications.
To illustrate the effect of DigiView's compression and also present it in a manner that is more relevant to real-world usage, we have calculated several typical performance benchmarks for each DigiView Model and sampling mode.

You may actually see better performance ratings than the conservative estimates displayed in the table below.

Since we have real-time hardware-based compression, we measure captures in 'number of Transitions' rather than ' number of samples.'

The number of samples captured varies with the data rate, but is always higher than the number of transitions
(#samples ~= #transitions * samplerate / datarate). Note: For storage calculations, it is considered only 1 transition regardless of how many signals changed states when sampled, so you could actually capture more than the transitions indicated.

Typical Transitions captured (USB 3.0)
18ch@250Msps:   100M (@data rates up to 100MTps)  
9ch@500Msps: 100M (@data rates up to 160MTps) 100M (@data rates up to 160MTps)  
4ch@1Gsps: 100M (@data rates beyond full bandwidth) 100M (@data rates beyond full bandwidth)  

Typical Transitions captured (USB 2.0)
36ch@250Msps:   500K (@data rates > 1.0 Tps)
18ch@500Msps:   500K (@data rates > 1.0 Tps)
18ch@250Msps:   100M (@data rates up to 10MTps) 500K (@data rates > 1.0 Tps)
9ch@500Msps: 100M (@data rates up to 14MTps) 100M (@data rates up to 14MTps)  
4ch@1Gsps: 100M (@data rates up to 24MTps) 100M (@data rates up to 24MTps)  

Guaranteed minimum transitions captured (with data rates > 10Tps):

(Ensured by the large store-and-forward buffer, even if the data rate far exceeds the USB bandwidth)
36ch@250Msps:   500K
18ch@500Msps:   500K
18ch@250Msps:   6 Million 500K
9ch@500Msps: 8 Million  
4ch@1Gsps: 10 Million  

Typical Serial captures, USB2 or USB3 at full sample rate
    Asynchronous 18 Million Characters   94,000
    Synchronous 5 Million Characters   24,000
    I²C 4 Million Characters   20,000
    SPI 4 Million Characters   24,000

Compare Hardware Specifications...   more info...

Final note:

The data is compressed in real-time with dedicated hardware and is NEVER fully de-compressed (which could result in data files much larger the available hard-drive capacities). DigiView software transfers the entire compressed data buffer from the hardware to internal PC memory in compressed form. This allows us to transfer the entire buffer in a fraction of a second. The waveform display routines fetch only enough data from the compressed buffer to fill the viewable portion of the display screen and even that is compressed.