Rigol DS1102D

Recommended Posts

I will assume that you were using 50 ohm terminations. No way you can sample such speedy signals with the "usual" 1Mohm.


What are the probe characteristics ? Are they passive or active ?



Share this post

Link to post
Share on other sites

Hi Alvie,


The Setup is Scope => approx 1m ribbon => "Active Logic Head" (by all accounts an Altera FPGA + SDRAM, with adjustable voltage on the input) => 30cm fly leads => test clips.


The Active Logic Head says the inputs are "Input Z 100k Ohm".  I'm not using any termination at all at either end - which most likely explains why the 100+ MHz signals gave bad readings when drive current was not set to 2mA. However I think capturing a 15 ns signal is pretty good for such a low-end setup - although a lot of micro-controllers are now hitting 80MHz...



Playing around with it has also strengthened my idea that if you have a choice between greater accuracy in time, or wider frequency response then what you want is the former - if you have more one transition every three samples then the display get hard to interpret. So if you have a OB Logic Sniffer that samples at 100 M Sa/s, it is good for debugging systems running at up to 33 MHz, and give a timing accuracy of 10.0 ns (1/3rd of a cycle) .


However if this super Open Bench Logic Sniffer used the serializers were used to capture at 250Mhz, then compressed/coded assuming at least seven bits in a run are the same, then the data can be compressed to 100Mb/s using the following coding scheme:


00  = seven bits without toggle = 28% of raw bit rate

01 = seven bits then toggle = 28% of raw bit rate

100 = eight bits then toggle = 37.5% of raw bit rate

101 =  nine bits then toggle = 33.3% of raw bit rate

1100 =  ten bits the toggle   =  40.0% of raw bit rate

1101 = eleven bits the toggle = 36.4% of raw bit rate

1110 = twelve bits then toggle = 33.3% of raw bit rate

1111 = thirteen bits then toggle = 30.7% of raw bit rate


(of course you need to add the state of the bit on at the first clock cycle, so it is just one bit over 40%).


This would give an upper useful limit of 35.7MHz (about the same), but allow you see timing differences of as little as 4.0 ns (1/7th of a cycle).

Share this post

Link to post
Share on other sites

You know, I've been thinking about compression lately. I came up with a pretty good and simple compressor/decompressor for images, RLE-based, which gives pretty good results. I wonder if this can be applied to digital signals as well.


The principle is to use a start bitmap which depicts if a certain block is or is not repeated. For images, this is accomplished with a 8-bit bitmap, where a "1" depicts that data is RLE-encoded, or 0 if not. This gives a 8-bit overhead for 8-word image sequences.


Since with digital binary streams we don't actually have sequences of words (i.e., word is a single bit), this might not make sense except if we add another counter.


Do you have any captured stream that I can use for testing this ?

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now