Dangerous Prototypes Open Source Hardware

banshee: ~ rsdio$ cd ~/Documents/Circuits/Dangerous Prototypes/OpenBench Logic Sniffer/ols-0.8.3
banshee: .../ols-0.8.3 rsdio$ chmod +x run.sh
banshee: .../ols-0.8.3 rsdio$ ./run.sh

• You don't have Java6 installed, but Java5 (or even lower). The run scripts use a new feature of Java6 that allows you to use wildcards in its classpath. Can you verify which Java version you're running? Issue a java -version should be enough to get a clear answer on that;
• Somehow the shell script isn't correctly expanding the current directory and its derived properties. For this, you can edit the run.sh script and echo the contents of these three variables: BASEDIR, PLUGINDIR and CLASSPATH.

java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-306)
Java HotSpot(TM) Client VM (build 1.5.0_19-138, mixed mode, sharing)

java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-306)
Java HotSpot(TM) Client VM (build 1.5.0_19-138, mixed mode, sharing)

• After I've done an I2C analysis, two channels are labeled SCL and SDA. These labels remain there as long as the program continues to run, even after a UART or SPI analysis. The prettiest thing to do is to make these labels user editable, if possible.
• This is a minor OSX issue: the program doesn't respond to CMD+W
• Another small (OSX-only?) issue: sometimes when I open a dropdown list, the options don't come on the right places. (ie somewhere else then beneath the dropdown menu)
• Maybe there's a bit to much info in the labels on top of the data: now it's Read/Write data: Hex (ASCII). Maybe a sober color-scheme to point out the nature of a label (read/write ack/nack) and the raw data inside the label in one format; either hex, ASCII, binary, octal, whatever, ... (but easy to change trough a menu behind a right click on the labels) would be clearer? This would would also allow to zoom further out and still see relevant data.
• Another nice thing, is that the user would be able to drag and drop the channels in a more convenient order. I know you could physically change the probes, but sometimes its convenient to place them as the user for whatever reason did, or the user saw afterwards that a channel isn't where it belongs, or he/she is just plain lazy
• I find protocol analysis a pretty handy feature, don't these analyzers deserve their own button? Their settings can remain in a settings-window.
• Your graphical implementation of the i2c analyzer is way cooler/better then the html-report. I'd rather didn't see that report until after I've specifically asked for it. However I can imagine cases where it is handy, I find myself using only the new annotation in the main screen. I hope you soon implement it for the other analyzers too.
• Maybe a short synopsis of the "chattering" on the bus somewhere in the main screen? Without all the small details, like this (like a msn-window):

• Channel labels can be changed already. Maybe this is one of the "hidden" features in the client. Simply go to Diagram -> Diagram Labels and you can edit them to your likings. I want all tools to provide the correct labels after they're done with their analysis, but this is currently only implemented in the I2C tool;
• Support for CMD+W on OSX is on my TODO list;
• Saw this strange behavior as well, but couldn't reproduce it always. I'll try to take a deeper look into this;
• Good idea! Making the "annotations" configurable already crossed my mind, and the color scheme + data representation is really something I'll put on my TODO list;
• Drag 'n drop of channels... That would be an interesting feature. I'll put it on my TODO list;
• The protocol analysis tools definitely deserve a more prominent place in the client. I was thinking about somehow integrating them in the capture process so you can run it directly after a capture... Would this come in handy?
• Currently the reports and annotations are two separate things, while in fact they are one and the same (only differently represented). I agree that it should be configurable on what you want to see;
• Hmm, a protocol-analysis synopsis. That might come in handy indeed. I've put this on my TODO list as well (which is growing exponentially )

• collect all data-samples between two frames;
• divide those data-samples in 256 equal buckets;
• check each bucket what its bit-value should be.

• upon a start-of-frame, reset a bit-counter to zero;
• upon each rise (or fall) of the clock signal, take a sample of the data, and increase the bit-counter;
• after 256 bits are read, you can split them out into the individual channel-bytes.

• Updated zoom behaviour to zoom "dead center"; keeping the current center as-is;
• Added additional toolbar button cancel a capture of the OLS; also provide you with a visual clue about whether or not the OLS is armed and awaiting a trigger;
• All decoder tools now annotate the capture data with their decoding results;
• All user settings are now retained upon stopping and starting of the client, including the last chosen directories for loading/saving data captures;
• The UART/I2C/SPI tools now can decode parts of the captured data. If cursors 1 & 2 are set, only this region will be decoded;
• Fixed close window behaviour on all platforms; now it is possible to close every dialog with CMD/CTRL + W and through the "X" on Windows;
• Many little UI-related bugfixes.