Sadly this thing is not available as a DIY kit, but that is just a personal thing. I like to solder. And of course this will not have any negative effect on what comes further down. BTW. I contacted Ian of Dangerous Prototypes regarding that matter and he offered to get me the bare PCB, nice. The huge downside of this: no parts… and I also don’t own a programmer for the PIC chip.
Now back to what the title of this post promised:
The analyzer itself comes without probes and without the mini-USB cable. 2 sets of probes will give you 32 5V tolerant channels and sampling rates up to 200MHz. You can get it at Seeedstudio or Watterott, if you’re in Germany.
The storage capacity per channel is adapted to the sampling rate. It’s got a feature to compress the data (RLE), that will remedy this fact a bit. There’s an add-on board available for a few bucks that will double the number of channels that can tolerate 5V. Without it the other half is only good for 3.3V, but can be used as outputs as well. That is handy for the self-test.
The software client supports decoding of quite a number us useful bus types, such as RS232, SPI and I²C. The java client runs on many operating systems, even on winblows. It supports simple triggering and to some degree also pattern triggering. The PIC’s firmware and the FPGA’s bitstream can be upgraded without additional programmers!
The probe clips are quite OK, the wires are a bit on the weak side (but cheap). Time will tell how long they last. One thing that bugged me right away was the fact that there is a lot of cross talk between signal carrying and floating probes. Also it currently isn’t possible to visually disable unused channels in the software. That may change in the future though.
My first real application:
Quite a while ago I built and successfully tested my BestKitchenLightEver ™ project project. No dedicated blog post yet, as I’m still missing one major component.
Due to size constraints, basically PCB cost, I had opted for ATtiny24 micro-controllers (SOIC-14 package). They have very welcomed ADC ports, but unfortunately no UART. The USI module is just a PEST – and already used for a fast SPI connection to the LED driver (MBI5168). There is only _one_ usable I/O line that is shared between the boards. Currently I encode the commands with pulses of variable length. Per default each board is just a listener, only the board that gets user input (button presses) is promoted to master and sends the info out to the other boards via the shared I/O line. No interrupts are directly involved in this, except for the system ticker for measuring the time.
To make the connection more usable, I’ve decided to implement a simple half duplex UART, triggered by one pin change interrupt. Of course this has been done before gazillions of times, but it is a very good excuse for me for getting a logic analyzer. The timing simply has to be right (HALF_BIT_DELAY…). I could use an oscilloscope for that purpose, but the OLS comes with a nice piece of software that does bus decoding, which is a nice thing ;-)
The upper graph labeled RxD shows some data sent to the DUT by another AVR board that I recklessly re-purposed for this job. The lower graph labeled ISR represents the activity of the pin-change interrupt. It is hard to see in the image, but the first entry to the ISR is marked by a short double-pulse, and the time of sampling the signal is marked by single-cycle pulses. I used an onboard LED to get the signal out. Just recently there was an article on EEWeb about the most important debugging tool in the world, the LED. Can’t find it right now… Always include at least one or two status LEDs to your designs, no make it 3 ;-)
I could have used my old oscilloscope to help me find the right delays for the ISR driven soft-UART receiver, but nowadays it prefers to rest more and not deal with digital signals. A decent digital 4-channel DSO would work as well, but you won’t get bus decoding for 50 bucks, that I can tell you! Speaking about the decoding modules: as seen in the image above, the markings for the data bytes are not always spot on, so don’t turn of your brain completely.
So far the OLS has helped me a lot to find the right timings, to tweak the delays between the data bits that are needed to make it work. It was a very easy process. Just look at the graph and up or down the numbers a bit, until the peaks are dead on the center of the bits.
Now I need to make the existing code live with its new friend happily, which is a different matter and will require more OLS debugging ;-)
I highly recommend it!
Just for sake of completeness, you may also want to have a look at the devices sold by saleae, if you desire a ‘commercial’ product. They cost about 2x for the 8-ch model, but you’ll get a nice case and box and definitely better quality probes. The software runs on non-winblows systems as well.
Sniffing 8MHz SPI traffic (RLE enabled):
By all means, GET ONE !!! You can easily spend a lot more money for ‘professional’ gear and get less than this.