Rigol DS1102D


hamster

Recommended Posts

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).

Link to comment
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 ?

Link to comment
Share on other sites

  • 5 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.