Hi everyone,
I'm considering buying an OLS, as it looks like a great tool, but I have some questions that I couldn't find clear answers to in the documentation.
1. Can it do state-based analysis, or only timing analysis? By state-based, I mean using an external clock, and taking 1 state sample per clock cycle, with the results shown in a list view with one state per line like a spreadsheet. This is the way I'm used to using a logic analyzer. All the screenshots I've seen of the client show a timing-centric view like an oscilloscope, with one channel per row and a waveform graph.
2. How fast can I capture data in real life, with real signals? Is the 100 MHz (or 200 MHz) speed actually obtainable? If I'm using an external clock from the system being debugged, would I have any trouble capturing data at speeds of 50 MHz or 100 MHz?
3. Are channels always treated as 32 separate inputs, or can they be grouped into collections like a bus? For example if I'm debugging an 8-bit data bus, I don't want to see eight separate rows on the graph, I just want to see a single row whose value is between 0 and 255.
4. Is there a free run mode, or just one-shot?
5. How effective is the RLE compression? With "typical" data, how much does it increase the sample depth compared to no compression?
6. Are there any good cases available for purchase? It seems like everybody is making their own, but I don't see any for sale.
7. How's the quality of the mini-grabbers that Seeed recommends for the OLS? Can the grabbers "unplug", so you can put the shaft of the wire directly onto a header pin, like some others I've seen? Any good alternative mini-grabbers from other vendors that will fit the OLS?
Thanks very much!
Responding to myself: I discovered you can use the software with a test device, even if you don't have the OLS hardware. I tried out version 0.9.7 of the "alternative" client, which is the recommended one.
1. Can it do state-based analysis, or only timing analysis? By state-based, I mean using an external clock, and taking 1 state sample per clock cycle, with the results shown in a list view with one state per line like a spreadsheet. This is the way I'm used to using a logic analyzer. All the screenshots I've seen of the client show a timing-centric view like an oscilloscope, with one channel per row and a waveform graph.
It only does timing analysis. Which is too bad - the hardware seems to have everything necessary for state analysis.
2. How fast can I capture data in real life, with real signals? Is the 100 MHz (or 200 MHz) speed actually obtainable? If I'm using an external clock from the system being debugged, would I have any trouble capturing data at speeds of 50 MHz or 100 MHz?
Still looking for an answer to this.
3. Are channels always treated as 32 separate inputs, or can they be grouped into collections like a bus? For example if I'm debugging an 8-bit data bus, I don't want to see eight separate rows on the graph, I just want to see a single row whose value is between 0 and 255.
Basically it's 32 binary inputs. There is a group feature, but it won't show you the combined value of the whole group correctly. That's too bad, as it makes OLS not very useful for working with bus-based systems. The software is really geared towards serial systems only.
4. Is there a free run mode, or just one-shot?
Just one-shot captures.
5. How effective is the RLE compression? With "typical" data, how much does it increase the sample depth compared to no compression?
Still wondering.
6. Are there any good cases available for purchase? It seems like everybody is making their own, but I don't see any for sale.
Still wondering.
7. How's the quality of the mini-grabbers that Seeed recommends for the OLS? Can the grabbers "unplug", so you can put the shaft of the wire directly onto a header pin, like some others I've seen? Any good alternative mini-grabbers from other vendors that will fit the OLS?
It looks like Saleae sells replacement mini-grabbers that should also fit OLS, and everyone seems to love them. But they cost $20 instead of $6.
[quote author="bigmessowires"]1. Can it do state-based analysis, or only timing analysis? By state-based, I mean using an external clock, and taking 1 state sample per clock cycle, with the results shown in a list view with one state per line like a spreadsheet. This is the way I'm used to using a logic analyzer. All the screenshots I've seen of the client show a timing-centric view like an oscilloscope, with one channel per row and a waveform graph.[/quote]
The OBLS does have an external clock input, however the client does not support that yet. Showing a list of states instead of time-based graphs is not very complicated to add. Do you perhaps have any pointers as to what information is shown in the state view?
[quote author="bigmessowires"]2. How fast can I capture data in real life, with real signals? Is the 100 MHz (or 200 MHz) speed actually obtainable? If I'm using an external clock from the system being debugged, would I have any trouble capturing data at speeds of 50 MHz or 100 MHz?[/quote]
The 200MHz (aka DDR) mode takes two samples per clock while still running its timebase at 100MHz. Capturing at 100MHz works well, albeit it fills the limited memory rather quickly ;)
[quote author="bigmessowires"]3. Are channels always treated as 32 separate inputs, or can they be grouped into collections like a bus? For example if I'm debugging an 8-bit data bus, I don't want to see eight separate rows on the graph, I just want to see a single row whose value is between 0 and 255.[/quote]
The client has a somewhat cryptic "group summary" that shows the hex-value of a group of channels. Right-click on the group-label to enable the group-summary. As of 0.9.7, the client can group any set of channels together into any bus configuration you desire.
[quote author="bigmessowires"]4. Is there a free run mode, or just one-shot?[/quote]
I've seen this request quite often, but always wonder what use it has, other than demo-purposes. Allow me to explain: the OBLS buffers all captured samples until it is done, after which it sends it in one batch back to the client. During this, no new samples are captured, so the OBLS is essentially blind during this period. The OBLS does not (yet?) support continuous streaming of bytes (though that would bring a lot of other problems with it as well)...
[quote author="bigmessowires"]5. How effective is the RLE compression? With "typical" data, how much does it increase the sample depth compared to no compression?[/quote]
RLE compression works best for slow changing signals, there is some interesting information about it in this thread (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=2867#p28296). TLDR: it works, but might give only a slight improvement of capture depth, without any guarantees.
[quote author="bigmessowires"]6. Are there any good cases available for purchase? It seems like everybody is making their own, but I don't see any for sale.[/quote]
Most of us on this forum are hardware tinkerers (as are you, I believe), which means that most people have fun in creating their own cases. There are some for sale (http://http://builttospecstore.storenvy.com/products/2107326-open-bench-logic-sniffer-enclosure) though, but you might google around a bit...
[quote author="bigmessowires"]7. How's the quality of the mini-grabbers that Seeed recommends for the OLS? Can the grabbers "unplug", so you can put the shaft of the wire directly onto a header pin, like some others I've seen? Any good alternative mini-grabbers from other vendors that will fit the OLS?[/quote]
The grabbers are ok, but not the best I've seen/had. There are definitely better ones on the market available, but also cost more. I've not used others, but if you've found some good ones, I'd be interested to hear about them.
PS: I'm a longtime reader of your blog, keep those updates coming ;)
[quote author="bigmessowires"]
7. How's the quality of the mini-grabbers that Seeed recommends for the OLS? Can the grabbers "unplug", so you can put the shaft of the wire directly onto a header pin, like some others I've seen? Any good alternative mini-grabbers from other vendors that will fit the OLS?
[/quote]
The miracle of electronics is that it's become so cheap compared to other physical goods. My experience with the recommended grabbers is that they've been cost-reduced right to the limit; in the ones I got, the retractor springs overpowered the finger springs, to the point where after about 5 seconds the probe would jump off the contact. Probably other sets work better.
I got some good looking clips from http://http://www.e-z-hook.com. Because electronics are so cheap compared to physical goods, a set of 16 hooks cost about as much as the OLS, and I still have to connect wire and pin headers. Sadly, the courier messed up the shipment so that I got the hooks a month late and 50km away. They missed the presentation I was going to use them in, and they're waiting till I get back into hardware and need a good set of test clips.
Thanks jawi! I know the OLS client software is a volunteer-built tool, and writing free software for other people to use can be a thankless task. Sorry if these suggestions sound more like complaints. I'm most familiar with using my ancient HP 1631D logic analyzer, and I'd love to see some of the most useful 1631D features added to the OLS client. The problem with the 1631D is that it's a giant boat anchor that weighs a ton, takes up half my desk, and has roaring load fans that will wake the dead. If I could retire it and use the OLS instead, that would be awesome.
[quote author="jawi"]The client has a somewhat cryptic "group summary" that shows the hex-value of a group of channels. Right-click on the group-label to enable the group-summary. As of 0.9.7, the client can group any set of channels together into any bus configuration you desire.[/quote]
I noticed that, but the group summary value doesn't seem to be computed correctly. It appears to use the channel numbers to determine the value of a group, rather than the positions of the channels in the group. An example will hopefully clarify: say I move channels 2, 3, and 4 to a new group. If all three channels are high, the group summary displays 1C (hex) instead of 7 (hex). It's generating a 5-bit summary value even though there are only 3 channels in the group.
I like the way the 1631D defines groups. It's done on a separate screen from the waveform view. Say I take channels 4 through 11 and add them to a group called DATABUS. From then on, all the other view screens will show you a single input called DATABUS with a value between 00 and FF, instead of eight inputs called DATABUS0 through DATABUS7 with values of 0 or 1. This extends into the triggering menus as well, so you can set a trigger on DATABUS = C3, instead of DATABUS0 = 1, DATABUS1 = 1, DATABUS2 = 0, etc.
Here's a really bad image of how the 1631D does group setup:
[attachment=1]
Each row defines a named group, like ADDR, DATA, STAT. You can add as many rows as you want. In each row, you check off which inputs are part of the group. The same input can be part of multiple groups if you want.
[quote author="jawi"]The OBLS does have an external clock input, however the client does not support that yet. Showing a list of states instead of time-based graphs is not very complicated to add. Do you perhaps have any pointers as to what information is shown in the state view?[/quote]
Supporting the external clock input would be very helpful, even if the software doesn't do state listings. With the external clock, you could make most efficient use of the buffer memory, by storing exactly one sample per clock cycle of the circuit being debugged. Without the external clock, you need to oversample the circuit at 2x its clock rate, filling up the buffer twice as fast.
The external clock combined with a state listing mode in software would be awesome. The way my 1631D works, there are three modes for viewing the input data: waveform (like the timing analysis you have now), list (state listing), and chart (graphs a single bus value over time - ignore this for now). You can switch back and forth between these modes any time, viewing the same capture data in different modes.
Here's another really bad image of the 1631D's state listing:
[attachment=0]
Each row is one state (one sample, and one clock cycle if you're using external triggering). The columns show the values of the previously-defined groups for that state. You can scroll the whole list up or down to page through all the states - thousands of them, depending on your buffer size. I think the 1631D also has options to highlight states matching a specific pattern, or only display certain states, but I haven't used those.
I use state listing mode almost exclusively for my projects. It lets me see things like a transition from state XYZ to state ABC on the next line, where I can look at it quickly and say "hey that's not right!". You can theoretically do the same thing in the timing waveform view, but the list view is much more compact and more appropriate for this kind of analysis. The way I see it, the timing waveform view is for analyzing the circuit as a bunch of random time-varying signals, whereas the state listing view is for analyzing the circuit as a series of discrete states that's abstracted from those signals, where the specific timing details don't matter.
[quote author="jawi"]I've seen this request [free run mode] quite often, but always wonder what use it has, other than demo-purposes. Allow me to explain: the OBLS buffers all captured samples until it is done, after which it sends it in one batch back to the client. During this, no new samples are captured, so the OBLS is essentially blind during this period. The OBLS does not (yet?) support continuous streaming of bytes (though that would bring a lot of other problems with it as well)...[/quote]
Continuous streaming isn't necessary or expected. It's not a critical feature, but a free run mode can be very handy for getting a high-level view of what's happening, and catching any variations or anomalies. For example, say you set up the triggers to begin capture whenever a request is sent on some line. Then you put it in free run with timing analysis mode, and sit back and watch the request/response traffic. The client software will be repeatedly triggering, capturing, and displaying new waveforms as fast as it can, refreshing the screen once every couple of seconds (I'm not sure how fast OLS can do this). If all is working normally, you'll see the exact same waveforms every time the screen refreshes. But if there's some variation in how long the response takes, or sometimes you get a different response than others, this will immediately jump out.
[quote author="jawi"]The grabbers are ok, but not the best I've seen/had. There are definitely better ones on the market available, but also cost more. I've not used others, but if you've found some good ones, I'd be interested to hear about them.[/quote]
I haven't used them, but lots of people seem to really like Salae Logic's grabbers, and it looks like they should also fit the OLS. The grabbers are detachable from the female jumper wires, so you can put a jumper directly onto a header pin if your circuit has them. The build quality is also pretty good, from what I've read. But they're not cheap. You can order them here: http://www.saleae.com/accessories (http://www.saleae.com/accessories)
[quote author="jawi"]PS: I'm a longtime reader of your blog, keep those updates coming ;)[/quote]
Thanks!
Hi bigmessowires,
[quote author="bigmessowires"]Hi everyone,
2. How fast can I capture data in real life, with real signals? Is the 100 MHz (or 200 MHz) speed actually obtainable? If I'm using an external clock from the system being debugged, would I have any trouble capturing data at speeds of 50 MHz or 100 MHz?
[/quote]
Here are my two cents.
In the recent past, hence in real life, I had the need to debug a 133MHz data bus who had problems.
While some colleagues of mine were hunting the cause using digital storage oscilloscopes, I had the idea to try to catch it using OBLS.
I knew the OBLS is rated good up 100MHz and it can manage to reach 200MHz (DDR) with some limitations, in that case it would have to reach 266MHz (Shannon): a bit tricky I thought.
Indeed in order to correctly look waveforms in a 133MHz data bus you would need to have a sample rate of at least 266MS/S, but the data lines only switch high or low at the 133MHz rate, so the fastest signal you will see is actually 67MHz.
There is no harm in trying, so I tried it and it works!
Actually the fault was not due a unwanted noise in the data bus, but instead it was phase shift caused by the PCB's layout: I settled it by adding a small capacitor.
Even if it was high speed data bus, OBLS was facilitated to find the fault than the oscilloscopes due its large amount of input compared with them (they were 4 channels DSO, not MSO).
For your information I used asynchronous sampling (internal clock) when I made the discovery.
Using synchronous sampling (external clock) makes things easier, because each sample on the OBLS will contain one word of data from the data bus.
Regards,
sre71
[quote author="bigmessowires"]Thanks jawi! I know the OLS client software is a volunteer-built tool, and writing free software for other people to use can be a thankless task. Sorry if these suggestions sound more like complaints. I'm most familiar with using my ancient HP 1631D logic analyzer, and I'd love to see some of the most useful 1631D features added to the OLS client. The problem with the 1631D is that it's a giant boat anchor that weighs a ton, takes up half my desk, and has roaring load fans that will wake the dead. If I could retire it and use the OLS instead, that would be awesome. [/quote]
You've legitimate questions, so I never saw them as complaints :)
[quote author="bigmessowires"]...
I noticed that, but the group summary value doesn't seem to be computed correctly. It appears to use the channel numbers to determine the value of a group, rather than the positions of the channels in the group. An example will hopefully clarify: say I move channels 2, 3, and 4 to a new group. If all three channels are high, the group summary displays 1C (hex) instead of 7 (hex). It's generating a 5-bit summary value even though there are only 3 channels in the group.[/quote]
I think this is a bug then. I've created an issue (http://https://github.com/jawi/ols/issues/193) for this.
[quote author="bigmessowires"]...
Supporting the external clock input would be very helpful, even if the software doesn't do state listings. With the external clock, you could make most efficient use of the buffer memory, by storing exactly one sample per clock cycle of the circuit being debugged. Without the external clock, you need to oversample the circuit at 2x its clock rate, filling up the buffer twice as fast.[/quote]
The external clock is already supported (haven't used it myself, yet), you need to add an additional header and select the external sampling clock in the UI (see this page for the header location (http://http://dangerousprototypes.com/docs/Hardware_design_overview)).
[quote author="bigmessowires"]The external clock combined with a state listing mode in software would be awesome. The way my 1631D works, there are three modes for viewing the input data: waveform (like the timing analysis you have now), list (state listing), and chart (graphs a single bus value over time - ignore this for now). You can switch back and forth between these modes any time, viewing the same capture data in different modes.
...
Each row is one state (one sample, and one clock cycle if you're using external triggering). The columns show the values of the previously-defined groups for that state. You can scroll the whole list up or down to page through all the states - thousands of them, depending on your buffer size. I think the 1631D also has options to highlight states matching a specific pattern, or only display certain states, but I haven't used those.[/quote]
I see and understand how such a view should work. Should be easy to add, so I've added this issue (http://https://github.com/jawi/ols/issues/194) for adding this feature.
[quote author="bigmessowires"]...
Continuous streaming isn't necessary or expected. It's not a critical feature, but a free run mode can be very handy for getting a high-level view of what's happening, and catching any variations or anomalies. For example, say you set up the triggers to begin capture whenever a request is sent on some line. Then you put it in free run with timing analysis mode, and sit back and watch the request/response traffic. The client software will be repeatedly triggering, capturing, and displaying new waveforms as fast as it can, refreshing the screen once every couple of seconds (I'm not sure how fast OLS can do this). If all is working normally, you'll see the exact same waveforms every time the screen refreshes. But if there's some variation in how long the response takes, or sometimes you get a different response than others, this will immediately jump out.[/quote]
Makes sense, finally a good incentive to implement this feature request (http://https://github.com/jawi/ols/issues/78) ;)
Awesome, thanks jawi!
[quote author="bigmessowires"]Can it do state-based analysis, or only timing analysis? By state-based, I mean using an external clock, and taking 1 state sample per clock cycle, [/quote]
You might like to read this thread, "Ground for External Clock"
viewtopic.php?f=23&t=5508 (http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=5508)