hamster Posted March 21, 2014 Report Share Posted March 21, 2014 I have been testing out the Logic Analyzer on my new Oscope - a Rigol DS1102D. Seems to be good for up to 15ns signals.http://hamsterworks.co.nz/mediawiki/index.php/Logic_Analyser_Test Link to comment Share on other sites More sharing options...
alvieboy Posted March 21, 2014 Report Share Posted March 21, 2014 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 ? Alvie Link to comment Share on other sites More sharing options...
hamster Posted March 22, 2014 Author Report Share Posted March 22, 2014 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 rate01 = seven bits then toggle = 28% of raw bit rate100 = eight bits then toggle = 37.5% of raw bit rate101 = nine bits then toggle = 33.3% of raw bit rate1100 = ten bits the toggle = 40.0% of raw bit rate1101 = eleven bits the toggle = 36.4% of raw bit rate1110 = twelve bits then toggle = 33.3% of raw bit rate1111 = 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 More sharing options...
alvieboy Posted March 23, 2014 Report Share Posted March 23, 2014 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 More sharing options...
whiteimage Posted April 23, 2014 Report Share Posted April 23, 2014 hello, alviewboy, thanks for the advice. it is really wonderful to bring this image compressor RLE-based into digital signal. have you test it yet? will it work? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.