Dangerous Prototypes

[hr:][/hr:]

*** The latest version is available for download at the OLS homepage... (http://http://www.lxtreme.nl/ols/) ***
hope this saves you a trip to the end of this thread :)

• October 23rd, 2010: version 0.9.0 released;

[hr:][/hr:]

For a while now, I've been working on my own Java client for the OLS. While the original SUMP client certainly works, it has its drawbacks and limitations. For example, the fiddling around with the RXTX library on various OSs and the lack of (dynamic) runtime extensions without recompiling the clients to name a few. So, I took the original SUMP sources, and "hacked" away...

While it is certainly not ready or complete, it is already quite usable, so hereby I want to make a first public release.

A highlight of the changes:

• Make use of Felix OSGi framework as plugin mechanism/runtime environment;
• Integrated the RXTX library for Mac OSX (64-bit, SL), Linux (32/64 bit) and Windows (32/64 bit). The RXTX library no longer needs to be installed separately;
• Improved the UI "snappiness" by profiling the various drawing routines (signal drawing improved with approx. 200%) and making (better) use of the Java threading model (SwingWorker) to improve the analysis tools (done for I2C & state analyser);
• Support more than 2 cursors.

Ideas and future improvements:

• Make the sources publicly available through some public hosting site (Github, ...);
• Create some sort of home page/documentation;
• Add UI for performing some basic measurements between (sets of) cursors;
• Add tools for 1-wire, and other protocols (USB?);
• Improve the look&feel on other OSs (Linux and Windows);
• ...any other ideas?...

You can download my OLS client from: [s:]http://lxtreme.xs4all.nl/~jawi/ols/ols-0.5b3.tgz[/s:]. Basically, it is gunzipping/untarring the archive and running the "[tt:]run.sh[/tt:]" script in the felix folder, or invoking [tt:]java -jar bin/felix.jar[/tt:] from a commandline.

It looks really good, I had a problem with the waveform not drawing automatically. I had to move the cursor over the changed areas to get the waveform to show up. I'll try to record a video of it later.

But overall it has a nicer look and feel to it and improved functionality.

I was thinking of either migrating to git or using the svn-git program to allow the use of git for distributed development. I can actually change the svn repository at the project page to a git repository but I would need to talk to Ian and make sure he is cool with that first. Then the OLS project page git repository can become the "blessed" repository and the "Integration-Manager Workflow" can be used as outlined here. http://progit.org/book/ch5-1.html (http://progit.org/book/ch5-1.html)

So if you want to create an account at Github and check your project in I can start looking at either migrating to Git completely or trying to merge the changes using svn-git.

Jack.

Yeah, I spotted the "redraw" problem as well, forgot to do a repaint. Fixed some other small bugs as well, already.

I've got a GitHub account already, and have to find some time this week to push my all of my local repositories to it. I've got currently 15 separate git repositories, which I might need to repackage or something. I really need to do some more reading in Git, so your link is helpful (I even ordered the book already)...

I'll post my progress in this thread.

BTW: I've uploaded a new tarball to my local server with the redraw problems fixed as well as the "before/after" slider in the OLS configuration screen. You can find the latest archive from: http://lxtreme.xs4all.nl/~jawi/ols-0.5b4.tgz (http://http://lxtreme.xs4all.nl/~jawi/ols-0.5b4.tgz).

Redraw problem is gone, slider works nicely but I think it is the opposite of what the original client does?

I had an issue using a trigger, I set the trigger up and then it will take a while before I send the serial data that will set the trigger off. Before I can send the serial data it reports a, "Capture aborted! Data readout interrupted."

Once again, it looks really nice!

Jack.

[quote author="jack.gassett"]
I had an issue using a trigger, I set the trigger up and then it will take a while before I send the serial data that will set the trigger off. Before I can send the serial data it reports a, "Capture aborted! Data readout interrupted."
[/quote]

Thanks for the report; I've to test the triggering myself a bit. I'm mostly developing with the "test device", but intent to test with the OLS more extensively during this week. Will take a look at the trigger stuff in more depth, and the before/after inversion thingie as well...

After some fiddling around with git, I finally managed to get my 13 repositories up on GitHub. Anyone interested can take a look at http://github.com/jawi (http://http://github.com/jawi).

I've also cleaned up some of the stuff and projects, and have released version 0.7.0 of my OLS client. It is available for download on my site at http://www.lxtreme.nl/ols (http://http://www.lxtreme.nl/ols) (currently only some binaries, the webpage is on my todo list).

@jack.gassett: I think I've fixed the preliminary trigger abort; still have to test it more thoroughly with my own rig...

Finally got some time this weekend to make a decent "one repository, multiple projects" structure with Maven. This should simplify development significantly. You can find the new GIT repository on GitHub: http://github.com/jawi/ols (http://http://github.com/jawi/ols).

For the impatient ones: you can check out the above repository, and do an [tt:]mvn clean install[/tt:]. After a few seconds, you find a decent tarball or zip of the latest OLS distribution in [tt:]ols.distribution/target[/tt:]. This can be unpacked to a suitable location and be run with [tt:]run.sh[/tt:] or [tt:]run.bat[/tt:].

Latest changes:

• Merged with latest (2.11) release of OLS;
• verified trigger support for OpenBench LogicSniffer device;
• verified BusPirate "logic sniffer" mode is working with OLS.

To do:

• Clean up some graphics related stuff (move creation of Swing components to EDT);
• Do some small UI rework to make dialogs appear "good" on Windows & Linux;

not sure why but ..

[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/main/java/nl/lxtreme/ols/util/DisplayUtils.java:[110,18] unmappable character for encoding UTF8
...
[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/test/java/nl/lxtreme/ols/util/DisplayUtilsTest.java:[63,25] unmappable character for encoding UTF8

In both files the problematic character is greek mi char (micro seconds), replacing it with u solves the problem

[quote author="arhi"]
not sure why but ..

[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/main/java/nl/lxtreme/ols/util/DisplayUtils.java:[110,18] unmappable character for encoding UTF8
...
[INFO] Compilation failure
/home/arhimed/Dev/OBLS/Alternate/ols/util/src/test/java/nl/lxtreme/ols/util/DisplayUtilsTest.java:[63,25] unmappable character for encoding UTF8

In both files the problematic character is greek mi char (micro seconds), replacing it with u solves the problem
[/quote]

Oops; forgot about these embedded UTF-8 characters. Should be fixed in the latest HEAD repository.
Thanks for reporting!

Hi, there's one UTF-8 character left in client/src/main/java/nl/lxtreme/ols/client/signal/DiagramTimeLine.java

With that one change, it builds & runs fine here, thanks!

[quote author="jone"]
Hi, there's one UTF-8 character left in client/src/main/java/nl/lxtreme/ols/client/signal/DiagramTimeLine.java

With that one change, it builds & runs fine here, thanks!
[/quote]

Solved in HEAD repo. Thanks for reporting!

(Shameless topic bump ;))

I've busy getting to a 1.0-release. So, I've put version 0.8 online of my alternative OLS client. Grab it from http://www.lxtreme.nl/ols/ols-0.8.0.tar.gz (http://http://www.lxtreme.nl/ols/ols-0.8.0.tar.gz).

Changes:

• Fixed cursor setting/dragging in diagram;
• Added a new measurement tool allowing to perform some basic measurements between cursors;
• Some minor UI-related changes.

Questions to any testers out there: What platform (Windows, Linux, Mac OSX) are you running/testing my client on? What problems do you face? Should more effort be put in testing other platforms?

I'm now off for a two-week holiday, so replies in this topic can take a while...

I'm using it both on linux 64bit and windoze 64bit (win7) and the problem is that I have to use 32bit jre on windoze (rx library does not work for me for 64bit one).

second thing, from what I see one can easily talk much faster with obls then 115200, adding 921600, 460800 and 230400 bps speeds in drop down and using them to connect to obls should be simple and easy and should speed things up a bit :)

Yes, please, additional speed settings will improve transfer speed greatly on systems that throttle to CDC-ACM settings.

Nice initiative. I like how it looks and functions with the test device, but I don't know how to get the client to work with my OBLS hardware.

Platform: Linux (Ubuntu 10.04 32-bit)
Problems: I don't know how to get it to talk to my OBLS. (SUMP+OBLS works fine after following instructions in another forum thread.)

OLS starts out with this warning:

WARNING:  RXTX Version mismatch
   Jar version = RXTX-2.2
   native lib Version = RXTX-2.2pre2

[s:]I think I installed RXTX-2.2pre2 on my system because the SUMP client didn't work when I used RXTX from the Ubuntu repositories.[/s:]

Uh, actually I think I installed RXTX-2.1-7. This is what happens when I run SUMP:

Experimental:  JNI_OnLoad called.
Stable Library
=========================================
Native lib Version = RXTX-2.1-7
Java lib Version   = RXTX-2.1-7
/dev/OpenLogicSniffer

I have the same issue on both WinXP and Win7.
The RXTX version mismatch message and no comms with the OLS.

Randy

@ahri & ian: I've added the suggested speed options, but don't see any difference yet. Haven't tested it thoroughly yet, maybe I've overlooked some small detail or so.

@rasmus & Randy: I've just did some basic testing on my wife's Vista machine and don't have any problems (aside some UI-related ones, see below) with running OLS. What maybe important to say (and isn't documented) is that my OLS client does not like other versions of RxTx to be installed in the global Java installation. My client includes its own RxTx library, so this removes the need to install it globally. As for the warning message, this is something in the current CVS repository of RxTx but does not cause problems at runtime.

After some testing on a Vista machine, I discovered several annoying problems in the configuration dialog of my client causing all kinds of strange exceptions to appear in the logs. I've fixed those and uploaded version 0.8.1 (as intermediary release) on my site, direct download link: http://www.lxtreme.nl/ols/ols-0.8.1.tar.gz (http://http://www.lxtreme.nl/ols/ols-0.8.1.tar.gz).

Changes:

• Fixed several exceptions when running OLS without any user preferences (prevented dialogs from opening);
• Added speed settings for OLS communication up to 900kbps;
• Updated [tt:]run.bat[/tt:] to detect whether a JVM is installed or not.

Ah yes, much better.  The RXTX error message was throwing me off.  I thought that was causing it not to work.

The 921600 baud rate is nice.  Seems to really speed up captures.

I like the Before/after ratio slider.  That really comes in handy for me.  It allows you to use the I2C and UART analyzer with a minimum of 1% data before the trigger.  Gives you more data to analyze.

I do see some issues with zooming.  When I zoom in, at one point the traces all disappear.  I haven't characterized it enough to explain fully.

I do miss the time/frequency between cursors readout on the status bar.  The cursors should probably be sticky, they have to be reset after each capture.  At least the settings on the measure dialog could be persistant.

Very nice look and feel.  I like it.

Randy

[quote author="Randy"]
I do see some issues with zooming.  When I zoom in, at one point the traces all disappear.  I haven't characterized it enough to explain fully.
[/quote]

Hmm, never seen this before; but if you can provide some details on this, then I can take a look at it.

[quote author="Randy"]
I do miss the time/frequency between cursors readout on the status bar.  The cursors should probably be sticky, they have to be reset after each capture.  At least the settings on the measure dialog could be persistant.
[/quote]

Sticky cursors? I like that idea! I've implemented this in the latest Git repo already.

I moved the time/frequency readout for the first two cursors as tooltip, as "experiment". As I want to support multiple cursors, I've got some trouble "cramming" all that information in the status bar (or in a tooltip). Hence, I've introduced measure tool. I'm currently working in this area; if you've got ideas about how we can represent cursor time/frequency information in a more user-friendly manner, let me know.

Uh, yeah...
I think I probably just didn't know how to specify the port. :)

I figured that out now. Version 0.8.1 works fine under Ubuntu 32-bit. I'll play around with it some more later.

In case there is anyone else who is relatively clueless about how to get it to work on Ubuntu:

1. Untar
2. Open a terminal and cd into the directory
3. Now, if your OLS is for example /dev/OpenLogicSniffer, then run:

java -Dnl.lxtreme.ols.bundle.dir=plugins/ -cp "bin/*" -Dgnu.io.rxtx.SerialPorts="/dev/OpenLogicSniffer" nl.lxtreme.ols.runner.Runner

(4. Create a launcher and put it in a convenient place.)

Hi jawi,

It's working pretty well for me on 32bit Fedora (with the latest 2.12 test bitstream).
 
A couple of minor suggestions.

The rxtx library doesn't seem to recognise ttyACM ports. I'm creating a link to a ttyS port as a workaround, but I vaguely remember seeing a patch to add this support somewhere?

I can't get the UART analyser to run, it always gives an exception on real serial data.

Thanks,
Jon

Hi jone,

[quote author="jone"]
The rxtx library doesn't seem to recognise ttyACM ports. I'm creating a link to a ttyS port as a workaround, but I vaguely remember seeing a patch to add this support somewhere?
[/quote]

Hmm, I remember that patch as well; have to look into that. I've noticed that RXTX has some weird semantics regarding its port-detection mechanism. Maybe the suggestion (adding the [tt:]-Dgnu.io.rxtx.SerialPorts="..."[/tt:] parameter) of rasmus above can work around your issue?

[quote author="jone"]
I can't get the UART analyser to run, it always gives an exception on real serial data.
[/quote]

I think this is solved in the beta-2 of 0.8.2 (http://http://www.lxtreme.nl/ols/ols-0.8.2-b2.tar.gz). It is not entirely ready yet, but you can find it, as always, on my site (http://http://www.lxtreme.nl/ols). Let me know if this resolves your issue.

I'm currently working on allowing tools to "annotate" the signal data with data, so the analysis results of the I2C decoding will show up along with the signals itself instead of a HTML report. If people are interested, grab the beta-2 of my client and perform an I2C analysis (e.g. using the test-device). After a -for now- manual redraw (zoom all, zoom out, etc.) the analysis results (should ;)) appear in the signals view...

Here you go, found a trivial patch to add ttyACM support - http://bugs.gentoo.org/show_bug.cgi?id=301126 (http://http://bugs.gentoo.org/show_bug.cgi?id=301126)

I'll grab the latest git & try another serial capture tomorrow..

Thanks, Jon

For what it's worth, there has been some activity on the RXTX mailing list lately about fixing some of the problems.   A user (not one of the core developers) tried to fix some of the problems with 2.2 and is now working on a proposal for RXTX 3.0.

http://mailman.qbang.org/mailman/listinfo/rxtx (http://mailman.qbang.org/mailman/listinfo/rxtx)

[quote author="jone"]
I'll grab the latest git & try another serial capture tomorrow..
[/quote]

Afraid it's still failing with the latest git, want me to upload a sample capture & the error messages somewhere?

Thanks,
Jon

[quote author="jone"]
Afraid it's still failing with the latest git, want me to upload a sample capture & the error messages somewhere?
[/quote]

You can mail me the error log(s) and sample capture to my personal email address found in the README of OLS (http://http://github.com/jawi/ols/blob/master/README).
I'll have a look and see what's going on...

H jawi,

thanks for this work. I figured out that I probably would have ot use that "maven" to build from source. I tried

mvn package

from the top-level directory after running "git clone".  So, before posting error message from the failed build: how do I recompile from source? I have some issues with the run-length encoding, as the current RLE-decoder in the client does not treat repeated RLE-counts properly.

Best regards,

Claus

[quote author="rotdrop"]
thanks for his work. I figured out that I probably would have ot use that "maven" to build from source. I tried

mvn package

from the top-level directory after running "git clone".  So, before posting error message from the failed build: how do I recompile from source? I have some issues with the run-length encoding, as the current RLE-decoder in the client does not treat repeated RLE-counts properly.
[/quote]

I'm not entirely a Maven expert myself, but I always do a [tt:]mvn clean install[/tt:] or a [tt:]mvn install[/tt:] which appears to work fine from a newly clones repository (just tested it out), as well as for my own development environment.

If you've got something you want to contribute, let me know; I'll can give you access to the GitHub repository...

Hi Jawi,
I have checked out you sources from the github repo, but I have not found a way to create an eclipse project from the files in the repo.
I have only marginal knowledge about eclipse, since I do most of my work with "emacs+ant+commandline".

When I looked at the code in the repo

it looked like it was run over by a car

because all the source-files from the packages somehow end up in in different directory trees, and not in  a subtree of a common src-dir.
For instance the java-code from the nl.lxtreme.tools.base and  nl.lxtreme.tools.i2c packages in my opinion should  not look like this:

Code: [Select]

│       ├── tool.base
│       │   ├── pom.xml
│       │   └── src
│       │       └── main
│       │           └── java
│       │               └── nl
│       │                   └── lxtreme
│       │                       └── ols
│       │                           └── tool
│       │                               └── base
│       │                                   ├── AsyncToolDialog.java
│       │                                   ├── BaseAsyncToolDialog.java
│       │                                   ├── BaseAsyncTool.java
│       │                                   ├── BaseAsyncToolWorker.java
│       │                                   ├── BaseData.java
│       │                                   ├── BaseDataSet.java
│       │                                   ├── BaseToolDialog.java
│       │                                   ├── BaseTool.java
│       │                                   └── ToolDialog.java
│       ├── tool.i2c
│       │   ├── pom.xml
│       │   └── src
│       │       └── main
│       │           └── java
│       │               └── nl
│       │                   └── lxtreme
│       │                       └── ols
│       │                           └── tool
│       │                               └── i2c
│       │                                   ├── Activator.java
│       │                                   ├── I2CAnalyser.java
│       │                                   ├── I2CAnalyserWorker.java
│       │                                   ├── I2CData.java
│       │                                   ├── I2CDataSet.java
│       │                                   └── I2CProtocolAnalysisDialog.java

But rather like this

Code: [Select]

 
│       ├── tool.base
│       │   ├── pom.xml
│       │   └── src
│       │       └── main
│       │           └── java
│       │               └── nl
│       │                   └── lxtreme
│       │                       └── ols
│       │                           └── tool
│       │                               └── base
│       │                                   ├── AsyncToolDialog.java
│       │                                   ├── BaseAsyncToolDialog.java
│       │                                   ├── BaseAsyncTool.java
│       │                                   ├── BaseAsyncToolWorker.java
│       │                                   ├── BaseData.java
│       │                                   ├── BaseDataSet.java
│       │                                   ├── BaseToolDialog.java
│       │                                   ├── BaseTool.java
│       │                                   └── ToolDialog.java
│       │                               └── i2c
│       │                                   ├── Activator.java
│       │                                   ├── I2CAnalyser.java
│       │                                   ├── I2CAnalyserWorker.java
│       │                                   ├── I2CData.java
│       │                                   ├── I2CDataSet.java
│       │                                   └── I2CProtocolAnalysisDialog.java

actually I organize my stuff like this

Code: [Select]

<MyProjectRootDir>
   └── src
         └── nl
               └── lxtreme
                     └── ols
                           └── tool
                                 ├── base
                                 │     ├── AsyncToolDialog.java
                                 │     ├── BaseAsyncToolDialog.java
                                 │     ├── BaseAsyncTool.java
                                 │     ├── BaseAsyncToolWorker.java
                                 │     ├── BaseData.java
                                 │     ├── BaseDataSet.java
                                 │     ├── BaseToolDialog.java
                                 │     ├── BaseTool.java
                                 │     └── ToolDialog.java
                                 └── i2c
                                       ├── Activator.java
                                       ├── I2CAnalyser.java
                                       ├── I2CAnalyserWorker.java
                                       ├── I2CData.java
                                       ├── I2CDataSet.java
                                       └── I2CProtocolAnalysisDialog.java

Eclipse seems to take care of this huge structure for you. But if you are not into IDE's that much, you don't really want to move through 18 directrories (9 up 9 down) to get from BaseData.java to I2CData.java.

The other problem I have with your code is the use of the OSGI framework. I was not able to find out how to install the framework into eclipse so I could compile the project. This is where I stopped. Do you really need the OSGI framework, or could you live without it? What exactly is it good for in this specific project?

I'd really like to help with the code, if you could consider  reorganizing the sources and (if possible) drop the OSGI dependency.

Besides not knowing much about Eclipse, I also know near to nothing about Git :-) I always seem to be one step behind (just managed to see mercurial as my friend not my enemy).

But I can promise to write a working ant build-file so you don't need maven to build the project (which also did not really work on my Ubuntu machine).
I'm really looking forward to a stable and convenient Client now that most of the hardware issues have been solved I think.

Eberhard

@wayoda: Thanks for the comments, let me explain the project setup a bit:

[quote author="wayoda"]
I have checked out you sources from the github repo, but I have not found a way to create an eclipse project from the files in the repo.
I have only marginal knowledge about eclipse, since I do most of my work with "emacs+ant+commandline".

When I looked at the code in the repo

it looked like it was run over by a car

because all the source-files from the packages somehow end up in in different directory trees, and not in  a subtree of a common src-dir.
[/quote]

*grin* the code is set up in such way that they are (very) loosly coupled, in the form of separate projects. The idea is to have small pieces of functionality each in their own project with well-defined interfaces. This way, it becomes very easy to compose new functionality and/or maintain existing functionality.
In my opinion, for example, I should be able to work the I2C tool while you work on the UART tool knowing that my changes cannot influence your code (unless I change the interface of course) and the other way around. Keeping everything in one source-tree makes this a bit harder to enforce.

[quote author="wayoda"]
The other problem I have with your code is the use of the OSGI framework. I was not able to find out how to install the framework into eclipse so I could compile the project. This is where I stopped. Do you really need the OSGI framework, or could you live without it? What exactly is it good for in this specific project?
[/quote]

The OSGi container solves the loading of the correct RXTX library for the correct host platform without having to mingle with JVM startup parameters, or fiddle with the JVM installation. I simply provide some additional metadata for the RXTX library and it is loaded for me. In addition, the OSGi container gives me all kind of nifty functionalities, like adding at runtime new tools, upgrade, or even remove unwanted tools without having to restart the application.

The problem you face in Eclipse is that (probably) you've not enabled the Maven support of the projects. This way, Eclipse doesn't recognize the Maven dependencies and does not add them to its compilation classpath. Maybe, I should add some lines in the README on which Eclipse plugins are minimally needed... ;)

(edit) I've update the project README and the main pom file in order to generate "better" eclipse projects out of the box; maybe this will aid you...

[quote author="wayoda"]
I'd really like to help with the code, if you could consider reorganizing the sources and (if possible) drop the OSGI dependency.

Besides not knowing much about Eclipse, I also know near to nothing about Git :-) I always seem to be one step behind (just managed to see mercurial as my friend not my enemy).
[/quote]

All help would be welcome, so if you're willing to invest some time in getting to know these tools you could let them work for you (not fight them ;)).

[quote author="wayoda"]
But I can promise to write a working ant build-file so you don't need maven to build the project (which also did not really work on my Ubuntu machine).
[/quote]

While I'm a big fan of Ant scripts myself, maven provides a plugin already to generate those for me ([tt:]mvn ant:ant[/tt:]). I've not checked it out myself, but it looks promising. How does Maven not run on your machine? I never had any problems with installing it myself (mostly unpacking it somewhere and simply start using it was sufficient, IIRC).

Let me know if you're problems with maven persist.

Hi,

*grin* the code is set up in such way that they are (very) loosly coupled, in the form of separate projects. The idea is to have small pieces of functionality each in their own project with well-defined interfaces. ...
I should be able to work the I2C tool while you work on the UART tool knowing that my changes cannot influence your code (unless I change the interface of course)

Ok, maybe trying to prove my point on the tools-tree was a bad choice. Current (and future) tools should definatly come in their own jar-file, with the client loading them into the application on request only. But splitting up the Gui , API and  the Device it self so that they live in different source trees is a bit too much for me.
For instance I'm currently playing around with capturing the data through ser2net (http://http://linux.die.net/man/8/ser2net) since I have a spare first generation netbook which handles the serialIO that is initiated from my desktop machine (with the big screen) over WLAN.
So my code would have to impelment stuff from the API project, but I would need to fiddle round with the Gui too, because I obviously need a Panel where the user sets the hostname and port where the OLS is sniffing.

The OSGi container solves the loading of the correct RXTX library for the correct host platform without having to mingle with JVM startup parameters, or fiddle with the JVM installation.

Yes, that is a good reason for Operating Systems that don't have a package manager. If I had to name one good reason why someone wants to switch to Linux its the package manager!

The problem you face in Eclipse is that (probably) you've not enabled the Maven support of the projects. This way, Eclipse doesn't recognize the Maven dependencies and does not add them to its compilation classpath. Maybe, I should add some lines in the README on which Eclipse plugins are minimally needed... ;)

I installed maven support but still no luck. I really not up to spending my time making Eclispe work or digging into maven and OSGI sorry.

Eberhard

Let me know if you're problems with maven persist.

FYI : Looks good up to bundle when running mvn package then

[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] ------------------------------------------------------------------------
[INFO] Building OLS Logging support
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/wayoda/lab/ols/code/ols/logging/src/main/resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 3 source files to /home/wayoda/lab/ols/code/ols/logging/target/classes
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/wayoda/lab/ols/code/ols/logging/src/test/resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] No sources to compile
[INFO] [surefire:test {execution: default-test}]
[INFO] No tests to run.
[INFO] [bundle:bundle {execution: default-bundle}]
[INFO] ------------------------------------------------------------------------
[INFO] Building OLS Swing client
[INFO]    task-segment: [package]
[INFO] ------------------------------------------------------------------------
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 19 resources
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.

Missing:
----------
1) nl.lxtreme.ols:api:jar:1.0.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=nl.lxtreme.ols -DartifactId=api -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=nl.lxtreme.ols -DartifactId=api -Dversion=1.0.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
        1) nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT
        2) nl.lxtreme.ols:api:jar:1.0.0-SNAPSHOT

2) nl.lxtreme.ols:util:jar:1.0.4-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
      mvn install:install-file -DgroupId=nl.lxtreme.ols -DartifactId=util -Dversion=1.0.4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
      mvn deploy:deploy-file -DgroupId=nl.lxtreme.ols -DartifactId=util -Dversion=1.0.4-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
        1) nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT
        2) nl.lxtreme.ols:util:jar:1.0.4-SNAPSHOT

----------
2 required artifacts are missing.

for artifact: 
  nl.lxtreme.ols:client:bundle:1.0.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

Ok,
updating the README helped.

I did fresh clone and was able to build the project from the commandline.

Eberhard

[quote author="wayoda"]
So my code would have to impelment stuff from the API project, but I would need to fiddle round with the Gui too, because I obviously need a Panel where the user sets the hostname and port where the OLS is sniffing.
[/quote]

Ah, I think I now understand your confusion...

As mentioned earlier, the current projects form small pieces of self-contained functionality. So, the "device.logicsniffer" project contains everything for the OLS-device (that is: UI, I/O, OLS-specific stuff, and so on). The "client"-project contains all code that make up the client, which is mostly UI. It is not my intention to split out all UI-code from the API, tools and device(s), that would be a complete nightmare for maintenance.

So, to make it more concrete, to support the ser2net as device, you would create a new project called (for example) "device.ser2net", and place everything in there (I/O, UI, other helper code). If this code uses the code from the "api" project then the other projects can make use of it out of the box.

In fact, if you derive the device controller from the DeviceController class (from the API project) and register it in the same way as the other devices (see the Activator class in, for example, "device.test"), the client would automatically be able to pick up your device and show it in the "Devices" menu, and also being able to use it.

I hope my explanation will clear things up for you to start contributing to the project...

I just released version the final 0.8.2 version of my alternative client. Download it from the usual location (http://http://www.lxtreme.nl/ols/ols-0.8.2.tar.gz).

A summary of changes:

• Added support for the dynamic sample depth as supported in the 2.12 firmware. A warning is issued when trying to capture with a sample depth that is not supported;
• Initial approach for "annotating" the captured data with the results of tool analysis. Currently only implemented for I2C;
• Updated the "measure" tool with a possibility to measure the clock frequency of a channel;
• Fixed the run scripts for both Windows and Linux to be location independent. Cudos to Wayoda for providing the solution;
• Fixed an exception in the UART tool + fixed the baudrate calculation. Cudos to jone for reporting;
• Adjusted the RLE decoding routines with the suggestions provided by rotdrop.

Thanks to anybody for trying the client and taking the time to report bugs.

A question: is the annotation support (as currently can be found in the I2C analysis tool) helpful or not? Should the reports currently created by some tools be replaced by this functionality or should that remain as-is?

[quote author="jawi"]
A question: is the annotation support (as currently can be found in the I2C analysis tool) helpful or not? Should the reports currently created by some tools be replaced by this functionality or should that remain as-is?
[/quote]

Just tried it with the I2C testdevice data, and the new annotation looks good! Think I'd like the reports as well though, as they're handy for the extra detail..

Just tried 0.8.2 because the SPI-tool of the original client is not working for me.

Unfortunately your SPI-tool is not working at all with my data.
Error message "Analysis aborted! the value should be from 0 to 100"

I can't send you my data because storing the data doesn't work either:
File -> Save -> enter the filename and hit save-button
but the file just is not created

Michael,

[quote author="Michael"]
Just tried 0.8.2 because the SPI-tool of the original client is not working for me.

Unfortunately your SPI-tool is not working at all with my data.
Error message "Analysis aborted! the value should be from 0 to 100"

I can't send you my data because storing the data doesn't work either:
File -> Save -> enter the filename and hit save-button
but the file just is not created
[/quote]

I've solved the issues you see already in the Git repository (there were several small bugs in the area of saving). You can either grab the latest sources from GitHub (http://http://www.github.com/jawi/ols) and compile it yourself, or wait for the next release (should be somewhere this week, I presume).

Thanks for reporting this.

The latest commit (2ade21a019b60ec9b1e5857ba3b1f9a807a864be) causes a test failure on my machine (Mac OS X 10.6):

Running nl.lxtreme.ols.util.ExportUtilsTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.083 sec
Running nl.lxtreme.ols.util.HostUtilsTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec <<< FAILURE!
Running nl.lxtreme.ols.util.NumberUtilsTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec
Running nl.lxtreme.ols.util.DisplayUtilsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec

Results :

Failed tests:
  testSetFileExtension(nl.lxtreme.ols.util.HostUtilsTest)

cat util/target/surefire-reports/nl.lxtreme.ols.util.HostUtilsTest.txt
-------------------------------------------------------------------------------
Test set: nl.lxtreme.ols.util.HostUtilsTest
-------------------------------------------------------------------------------
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec <<< FAILURE!
testSetFileExtension(nl.lxtreme.ols.util.HostUtilsTest)  Time elapsed: 0.009 sec  <<< FAILURE!
java.lang.AssertionError: expected: but was:
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:145)
   at nl.lxtreme.ols.util.HostUtilsTest.testSetFileExtension(HostUtilsTest.java:133)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
   at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
   at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
   at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
   at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
   at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
   at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)


It looks like perhaps a difference in file naming conventions is causing that test to fail and thus the build to fail.

[quote author="sdixon"]
The latest commit (2ade21a019b60ec9b1e5857ba3b1f9a807a864be) causes a test failure on my machine (Mac OS X 10.6):
...
It looks like perhaps a difference in file naming conventions is causing that test to fail and thus the build to fail.
[/quote]

Yeah, saw this when switching back to my Mac as well... As I couldn't exactly think of a correct cross-platform solution, I've simply removed that particular test-case for now. This will at least ensure the stuff compiles and passes the test suite again on Mac OSX.

I've pushed my changes to the central GitHub repository. I want to test some Swing-related stuff today and push out a new minor release... Thanks for reporting!

I just uploaded version 0.8.3 (http://http://www.lxtreme.nl/ols/ols-0.8.3.tar.gz), which is the "bugfix" release. For those who are curious about how the client looks, I've added some screenshots to my site (http://http://www.lxtreme.nl/ols/screenshots/). Currently only Mac OSX screenies, people are welcome to send me their own screenshots.

Changelog:

• Made the port-chooser editable, allowing people to enter their own device in case it is not listed. This should resolve the port issues on several operating systems;
• all dialog settings are now persisted across sessions (read: restart);
• fixed the progress indicator in the SPI tool as reported by Michael;
• fixed some issues with the file-save dialog also reported by Michael;
• fixed several minor UI-related issues causing potential resource leaks;
• various other cleanups.

Looking good, although I had only a small test-run.
I do, however, have some , mostly GUI related, comments.

• 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):
      
  • slave: blablabla
        
  • master: blablabla
        
  • slave: bladieblie
        
  • etc.
        
[/li]

These are just suggestions, no criticism, so let me know what you think;)
BTW: I think you're doing great! I hope you continue to develop your client this way, kudo's to you!

Is this where I should report bugs?

The OSX screen shots were enough to get me to try this.  I downloaded 0.8.3, modified run.sh to be executable, then ran ./run.sh

I got the following error message:

Exception in thread "main" java.lang.NoClassDefFoundError: nl/lxtreme/ols/runner/Runner

I see a file named ./bin/runner-1.0.0-SNAPSHOT.jar
There were no comments in the README about what else I might need.

@rsdio:

Assuming you're using OSX or linux, these are the commands that made it work for me:

Artemis:~ Ward$ chmod 0711 /Users/Ward/Downloads/ols-0.8.3/run 
Artemis:~ Ward$ cd /Users/Ward/Downloads/ols-0.8.3 
Artemis:ols-0.8.3 Ward$ ./run

As you probably know, you have to remove the extension from run.sh (make sure it's not hidden)

Thanks for the reply, but it has never been necessary to remove the .sh extension from a shell script under Unix.  In fact, many parts of the operating system run from shell scripts that have an extension.  Here is what I did:

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

... by the way, I copied run.sh to run and executed it again, but got the exact same error message.

By the way, I did not have the OLS attached to my Mac when I ran this, and haven't had the time to try that.

[quote author="rsdio"]
Thanks for the reply, but it has never been necessary to remove the .sh extension from a shell script under Unix.  In fact, many parts of the operating system run from shell scripts that have an extension.  Here is what I did:

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

... by the way, I copied run.sh to run and executed it again, but got the exact same error message.
[/quote]

That is strange. There are two possibilities I can think of:

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

Let me know what your results are, so we can hopefully get you(r client) up and running!

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)

I'll try echoing the variables...

[quote author="rsdio"]

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)

I'll try echoing the variables...
[/quote]

Ah, this is the culprit. The current codebase of the client has quite some dependencies with Java6 (even more than I initially thought), so even if the run scripts would be fixed the code would crash out with ClassNotFoundExceptions on various occasions.

Would it be possible for you to upgrade your JVM to Java6?

Hi wartos,

[quote author="wartos"]

• 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):

...
These are just suggestions, no criticism, so let me know what you think;)
[/quote]

Thanks for the (very good) suggestions, I'll cover them one by one:

• 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 ;))

[quote author="wartos"]
BTW: I think you're doing great! I hope you continue to develop your client this way, kudo's to you!
[/quote]

As long as I get such great responses with good suggestions I'll do my best...!

May I add some of your screenshots to the wiki page for the alternative client (CC-BY-SA)?

http://dangerousprototypes.com/docs/SUM ... lient_fork (http://dangerousprototypes.com/docs/SUMP_logic_analyzer_client_fork)

[quote author="ian"]
May I add some of your screenshots to the wiki page for the alternative client (CC-BY-SA)?

http://dangerousprototypes.com/docs/SUM ... lient_fork (http://dangerousprototypes.com/docs/SUMP_logic_analyzer_client_fork)
[/quote]

Sure, no problem.

Perhaps this is obvious to most, but being a neyophite...
I'm trying to debug a board that uses a TDM (time domain multiplexed) bus. There a 2MHz clock, a frame signal, and a data line. There are 32 8-bit slots.
I need to pull the byte out of one slot of every frame. Seems like a good, and relatively straight forward project to let me understand how the software actually works.

Now, any pointers on where to start, vis-a-vis adding a new mode/plug-in?


BTW - awesome job on the existing software. The easiest LA I've used in a long time!

[quote author="toddkrein"]
Perhaps this is obvious to most, but being a neyophite...
I'm trying to debug a board that uses a TDM (time domain multiplexed) bus. There a 2MHz clock, a frame signal, and a data line. There are 32 8-bit slots.
I need to pull the byte out of one slot of every frame. Seems like a good, and relatively straight forward project to let me understand how the software actually works.

Now, any pointers on where to start, vis-a-vis adding a new mode/plug-in?

BTW - awesome job on the existing software. The easiest LA I've used in a long time!
[/quote]

What you could do is (very naive approach; assuming the frame-signal indicates the start of each frame, and frames are sent consecutively, that is, no intermediary delays between frames):

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

Another approach (slightly less naive, using the clock signal as well):

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

For the latter approach, you could use a Java BitSet to keep all 256 bits together, or use an array of 32 bytes (involves more administration)...

You're welcome to develop your own analysis tool, take a look at the i2c and/or SPI tools for examples on how to write them...

I just released & uploaded version 0.8.4 to my homepage (http://http://www.lxtreme.nl/ols). A summary of what's changed (see full changelog here (http://http://github.com/jawi/ols/blob/master/ChangeLog)):

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

Thanks to all of you who reported bugs and posted their findings.

While I'm at it: I'm already thinking quite some time about altering the color scheme; I think the current white/blue scheme is somewhat straining for the eyes, so I tried to make a scheme which is darker and provides different colors for each channel so its easier to distinguish which data is what channel. Would this be a good improvement or not? I've attached a screenie of how this would look like.

---

@jawi

This is looking really awesome! I just tested it out and I really like the look and feel etc. I will package this up with the next major release.

I like the proposed color scheme, can't wait to see a version with the new color scheme.

Keep up the great work, its much appreciated.

Jack.

/me likes

would be cool to be able to select "skin" or even "define skin" ... but anyhow I prefer the dark one over the original one

[quote author="jawi"]I think the current white/blue scheme is somewhat straining for the eyes, so I tried to make a scheme which is darker and provides different colors for each channel so its easier to distinguish which data is what channel. Would this be a good improvement or not? I've attached a screenie of how this would look like.[/quote]The rainbow is a nice effect, but I wonder if you could improve the contrast.  Blue is very dark against the black background, and purple is almost as bad.  If you could somehow improve the contrast ratio for those, that would probably help.  The yellow / yellow-green colors are a bit bright, and it would probably be easy to subdue that a bit - far easier than making blue "brighter."

[quote author="jawi"]
While I'm at it: I'm already thinking quite some time about altering the color scheme; I think the current white/blue scheme is somewhat straining for the eyes, so I tried to make a scheme which is darker and provides different colors for each channel so its easier to distinguish which data is what channel. Would this be a good improvement or not? I've attached a screenie of how this would look like.
[/quote]

The best solution to the problem I have seen so far is the Salea software.
http://www.saleae.com/logic/gallery/ (http://http://www.saleae.com/logic/gallery/)
The signal traces are white on some darkish background, which provides for a lot of contrast.
The probe colors are  shown along with the label which makes it easy to identify the probe that recorded the signal.
With this simple solution you are also free to use any other color for markup like Triggers or I2C analysis markers.

It is probably not nice to steal the idea from Saleae, but I bought one of their LA's so I feel less guilty.

Eberhard

Sorry for my ignorance but is this can run on windows?

If yes can you please point to a tutorial or something else?

Thank you.

Hi Toley - There's some tutorials and quick-start videos for the general SUMP client in the manual:
http://dangerousprototypes.com/docs/Ope ... troduction (http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer#Introduction)

I have been using many of the pre-releases of this version. I really like this client. I believe this client is a great step forward. The SPI analyser is working much better for me than the original client because the CS signal is honored better.

Love the color scheme. When can we have it! My experience with Jawi is that he is able to produce new releases of his client in an incredible pace. That has helped me a lot lately.

The varied signal colours are a definite improvement; I also think it'd be nicer if the signals were a few pixels shorter, whilst retaining the same spacing - that way it's less likely to confuse a permanent low/high signal with the signal adjacent to it.

[quote author="ian"]
Hi Toley - There's some tutorials and quick-start videos for the general SUMP client in the manual:
http://dangerousprototypes.com/docs/Ope ... troduction (http://dangerousprototypes.com/docs/Open_Bench_Logic_Sniffer#Introduction)
[/quote]

Thank you ian for the quick answer. I'm presently at work and it work very well here under windows xp. But at home it did not work under windows 7 64 bits. I will try again as soon as I'll be back. Thank you.

Thanks Toley, let us know how it turns out.

Hello ian, under windows 7 64bits when I start the run.bat file, a dos window quickly open and close but I had time to take a screen shot. The first screen shot show the content of the DOS window telling me that Java is not installed on my computer but second show the website telling me that java is installed. Maybe I have to install something else but I don't see it on your website. Thank you for your help.

---

I'm sorry, I'm not familiar with Win7 64bits and Java, but maybe someone else has it working and has some recommendations.

OK the problem is now solved. I always surf the web using Firefox so my version of Java is 32 bits by default. What I did is get on Java website using IE 64bits and then it let me install a 64 bits version of Java.

Thanks ian for your support and your great products, also thanks to jawi for this very nice interface.

Now that I am able to run the client, I will go with my little suggestions.

It would be nice if in the I2C graphical decoded view, we have the possibility to display the slave address in 7 or 8 bits (including or not the R/W bit). Also the choice to display this in hex or dec would be usefull. I also think there is too much text inside the blocks forcing us to zoom before seeing the information.

My next suggestion is concerning the great work made by jawi on this project. There is no doubt that the weakness of the Open Logic Sniffer was the original software provided with it. Now with jawi's client, the OLS looks and feel like a more costly commercial product. So my suggestion is to give a little something to jawi to help him keep his motivation. I know OLS is an open project but maybe the price of each device could be raised a little... But this is not of my business it's only a suggestion.

What I will be happy to do personnally is to make a little donation. So if you give me a Paypal address jawi, I will give you a little something for your great work.

Finally I just want to tell why I think jawi deserved to be paid. Be sure that I don't know him personnally and don't even know where he come from. I was very close to buy a commercial Logic analyser but I decided to go for the OLS cause I already own a Bus Pirate and really love it. But I must admit that I was disappointed by the software and think I should have pay more to get something that fits my needs. Now with jawi's client, it's very different and I think finally I've made a very good deal with the OLS.

FYI it'll work with 32 bit java, the problem is that it's not being added to the PATH variable.

howdy,

i just downloaded 0.8.4, and i only get abort messages for everything.

i run linux, have java version:
java version "1.6.0_21"
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)

i modified run.sh to add /dev/ttyACM1 as my serial port.
java -Dnl.lxtreme.ols.bundle.dir="$PLUGINDIR" -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM1" -cp "$CLASSPATH" nl.lxtreme.ols.runner.Runner

running strace when starting run.sh shows no attempt to open /dev/ttyACM1 at all.

aborts are similar to:
[9/12/10 2:56:43 AM - INFO  -    ols.client.ClientController]: Running tool: "State analyser ..." ...
java.lang.ArrayIndexOutOfBoundsException: 0
[9/12/10 2:56:48 AM - WARN  - ols.tool.base.BaseAsyncToolDialog]: Execution exception! Message: 0
        at nl.lxtreme.ols.tool.state.StateAnalysisWorker.doInBackground(StateAnalysisWorker.java:95)
        at nl.lxtreme.ols.tool.state.StateAnalysisWorker.doInBackground(StateAnalysisWorker.java:34)
        at javax.swing.SwingWorker$1.call(SwingWorker.java:277)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at javax.swing.SwingWorker.run(SwingWorker.java:316)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)

every tool generates something like this.

suggestions?

-david
p.s. not sure why this forum would suggest alt-s or alt-p to submit posts, they don't work - maybe it's a windows thing?

Bug report..

I2C decoder doesn't seem to work when SCL and SDA signals are physically swapped (SCL and SDA on bits 0 and 1 respectively on channel 0).
SUMP client from release 2.12 works properly with the same exact wiring.

I'm on Mac OS X 10.6.4 Snow Leopard.

Haven't tested SPI or UART yet.

Thanks.

Wow! After a weekend "deprived" of my broadband connection, it's good to see so many good responses on my latest release. Let me try to answer all questions/suggestions:

@jack.gasset: I'm honored to see my client included in the next release; that would be great!

@all responses regarding the proposed color scheme: I definitely want to provide ways to configure your own color scheme; but I also want a "good" default scheme which looks good. I'll create some screenshots with proposals and inform you all on the progress. The contrast definitely needs improvements, certainly on a dark background as this...

@Toley: good to hear it finally works on your platform. Regarding your questions on I2C decoding: there's some additional protocol information already being decoded in the annotations (such as read from address X, write to address Y), but that needs to be integrated in the CSV/HTML reports. As well as the other decoding tools. On my todo-list is already the idea to make the decoded information shown on screen/report configurable.

@FirefighterBlu3: just making a wild guess here, but did you do a data-capture first? The serial port is only used during the actual capturing process, so it isn't opened directly after starting the client. And the tools currently assume a data capture is available. Just make sure the correct device is selected, and hit the "capture" button (third button from left on the toolbar).

@9dof: thanks for the report; I'll give it a closer look as soon as possible and let you know the outcome.

edit: I've finally hacked up a small webpage for my OLS client; I'll update it in the upcoming days/weeks to provide more information and other content.

[quote author="Toley"]
My next suggestion is concerning the great work made by jawi on this project. There is no doubt that the weakness of the Open Logic Sniffer was the original software provided with it. Now with jawi's client, the OLS looks and feel like a more costly commercial product. So my suggestion is to give a little something to jawi to help him keep his motivation. I know OLS is an open project but maybe the price of each device could be raised a little... But this is not of my business it's only a suggestion.

What I will be happy to do personnally is to make a little donation. So if you give me a Paypal address jawi, I will give you a little something for your great work.

Finally I just want to tell why I think jawi deserved to be paid. Be sure that I don't know him personnally and don't even know where he come from. I was very close to buy a commercial Logic analyser but I decided to go for the OLS cause I already own a Bus Pirate and really love it. But I must admit that I was disappointed by the software and think I should have pay more to get something that fits my needs. Now with jawi's client, it's very different and I think finally I've made a very good deal with the OLS.
[/quote]

One of the main reasons for me to start on an alternative client for the Open Bench Logic Sniffer was because I really appreciate the work the guys of Dangerous Prototypes (and their contributors) are doing. Seeing the quality of hardware they make, together with the time they invest in its development and keeping it up-to-date is something really valuable for people working non-professionally with electronics (such as myself). However, good quality hardware without good quality software seriously impacts its usability and user acceptance.
In my daytime job I'm a software developer, so I see on a daily basis how much it matters for users to have good working software. This is another motivation to start working on my client software; the original software was so-so, and with some effort I got it to work better for most of you.
My motivation is greatly supported by hearing back from you people how great it now works, and how it made the difference with other logic analyzer software and so on. I'm not in favor of raising the price of the hardware for this, as the current low price is probably one of the main reasons people buy the OLS hardware (for me at least it was). Also, it should be up to the users to decide whether or not they want to donate (in any form) to my project.

To summarize: I really appreciate the feedback I get from users using my client software, and would like to see that feedback to keep coming in the future of my client software. If you really, really want to donate to my project you can find a flattr link on my client's homepage (http://http://www.lxtreme.nl/ols/).

Thanks for the hompage link, I added it to the OLS wiki and the alternative client wiki page.

[quote author="9dof"]
I2C decoder doesn't seem to work when SCL and SDA signals are physically swapped (SCL and SDA on bits 0 and 1 respectively on channel 0).
SUMP client from release 2.12 works properly with the same exact wiring.
[/quote]

While I haven't tested the decoding with a real I2C signal, it looks like I'm not able to reproduce this behaviour with my test-device. Could you provide me a saved capture with the I2C data so I can reproduce it locally?

@jawi, i couldn't find any way to select the device, /dev/ttyACM1.  i tried forcing the device selection by command line, but still no go.  nearly everything is grayed out and no devices available.

[quote author="FirefighterBlu3"]
@jawi, i couldn't find any way to select the device, /dev/ttyACM1.  i tried forcing the device selection by command line, but still no go.  nearly everything is grayed out and no devices available.
[/quote]

Is there neither device mentioned in the "Devices" menu, nor is the encircled button in the attached screenshot enabled? This button should present the configuration/capture dialog for the selected device.
The command line addition of /dev/ttyACM1 was needed in older versions because the RXTX library didn't recognize this as a serial device. As of 0.8.3 (I believe), you can simply type in the desired device in the OLS configuration dialog.

If the problem persists, could you post a screenshot + any of the logs? Maybe that will provide a clue...

---

well, i'll make a liar out of myself.  i deleted the felix-cache files and restarted.  previously, the referred to icon was enabled, but i only had "null" in the port option, now i have "null" and "/dev/ttyACM1".  the only difference being that i unplugged it sunday to show to my local hacker meetup, then brought it back and plugged it in.  no udev rule fiddling, my uid/desktop hasn't been changed in a couple months.  i don't recognize anything different in lsusb details but the previous enumeration has long since left my scrollback.

after selecting it, everything appears to be working fine.

thank you :)

-david

howdy again,

i am getting the idea that enabling RLE (with the OLBS) is broken.  i have control lines which are set to 5v+ and vgnd and show ~125mv max differential noise.  when RLE is enabled, i get artifacts all over the place on all channels, without RLE everything looks exact.

[quote author="FirefighterBlu3"]
i am getting the idea that enabling RLE (with the OLBS) is broken.  i have control lines which are set to 5v+ and vgnd and show ~125mv max differential noise.  when RLE is enabled, i get artifacts all over the place on all channels, without RLE everything looks exact.
[/quote]

Good to hear it finally works! Regarding the RLE support, while it is not heavy tested yet in my client (so it could well be that there are bugs in the RLE decoding) be aware that the RLE in firmware 2.12 requires at least 32-bit captures. See also this Wiki page (http://http://dangerousprototypes.com/docs/Logic_Sniffer:_Feature_status) for more information about this.

yes, i just discovered that RLE was broken on the board and i'm assuming my board is older than 2.12 or 2.11 where part of RLE was purportedly fixed.

i've checked out the ols-loader code from svn but there's no makefile in the project directory.  i'm waiting on an answer to that in the linux loader section before i write a short ditty for it.

i'm curious, with triggers, delay doesn't seem to do what i thought it would do.  i can only get delay to work at the incredibly slow 2MHz and at a very limited sample count of ~16770 to ~24998.  below 20850, a logic 1 gap starts appearing between samples.  there is no gap in the actual stream.  the shorter i make the delay, the more squashed the sample stream becomes, with a growing parallel gap of all active channels set to logic 1.  between 20850 and 24998, the samples appear normal* if you consider that 2MHz is losing significant amounts of data.  outside of these values all channels are flat logic 1. the sample width plus false gap width are exactly the same while samples are visible. when the sample shrinks, the gap grows.

below 16770, all logic 1
between 16670 and 20850, sample width and false logic 1 gap
between 20850 and 24998, delay appears to delay start of sampling.  * - at some period the samples appear to be start walking on top of themselves as they begin to lose their distinct pattern and appear to have grown on top of each other opposite shrinking and having a false gap.
above 24998, all logic 1

just an fyi. i'll have to retest this after i figure out which code version is burned to the chip and update to 2.12

p.s. please make the port configurable or make scanning for it more intelligent by scanning the usb bus for the correct vid:pid.  i have several devices plugged in that are ACM and 1) the ols client hangs while scanning, or 2) screws with the termios settings just at the wrong time when another program is accessing the other device, or 3) sends data that the device is not expecting causing a reboot condition or data corruption to occur.

also, baudrate is probably irrelevant.  CDC-ACM doesn't use baudrate.

:)

[quote author="FirefighterBlu3"]
p.s. please make the port configurable or make scanning for it more intelligent by scanning the usb bus for the correct vid:pid.  i have several devices plugged in that are ACM and 1) the ols client hangs while scanning, or 2) screws with the termios settings just at the wrong time when another program is accessing the other device, or 3) sends data that the device is not expecting causing a reboot condition or data corruption to occur.
[/quote]

As of 0.8.3, the port is configurable; you can simply enter in the "analyzer port" dropdown your own device name, or com-port or whatever port you like. Regarding the automatic port scanning: it appears RXTX is indeed opening/closing each device which might clobber other devices. I'll take a look at this on how this can be improved. Thanks for reporting this.

[quote author="jawi"]
[quote author="9dof"]
I2C decoder doesn't seem to work when SCL and SDA signals are physically swapped (SCL and SDA on bits 0 and 1 respectively on channel 0).
SUMP client from release 2.12 works properly with the same exact wiring.
[/quote]

While I haven't tested the decoding with a real I2C signal, it looks like I'm not able to reproduce this behaviour with my test-device. Could you provide me a saved capture with the I2C data so I can reproduce it locally?
[/quote]

Looks like I filed a false bug. I just tried again and I couldn't duplicate the problem now. It could be due to my trigger was set wrong, capturing on the first data instead of on the I2C Start and not having enough pre-capture.

Sorry for the noise.

Hey FirefighterBlu3 - Thanks for the feedback.

The rxtx issue you might be having with resets on other COM ports has cropped up before. We believe it's an RXTX issue.

CDC-ACM doesn't use baudrate.

This actually depends on the system, some do limit it. Also, the ACM control channel passes the settings to the hardware so we can use it for stuff.

@jawi, @ian,

firstly, thank you very much for making something that works on linux and it's doing pretty good generally.  i'm having troubles with triggers but - one thing at a time :)

right, it's the automatic scanning that is clobbering non-ols ports.

SPI (9-bit) analyzer appears to be working properly in the main window but the popup dialog is failing to display any MOSI bits, all 0x000

-d

[quote author="FirefighterBlu3"]
SPI (9-bit) analyzer appears to be working properly in the main window but the popup dialog is failing to display any MOSI bits, all 0x000
[/quote]

Could you supply me a datafile so I can reproduce this? That's easier than finding a 9-bit SPI signal myself ;)

sure.  'tis attached once i remember how to use zip.

First of all, thanks jawi for great program...
Now to the problem :)
I have Compaq mini netbook that has 1024x600 resolution and in Capture window I can't see buttons. Actually if i turn on auto hide task-bar I can see buttons but I don't like when task-bar hides... so I always toggle task-bar auto hide when using Logic Analyzer Client. Could you reorganize Capture screen just a bit to reduce height... for example put Noise filter and RLE in same line and pull everything up few pixels... Thanks in advance and again thank you for great program...

@jawa This is a feature request:

1) Would it be possible to add Save and Restore to the Capture dialog so that we can more easily switch between different Trigger setups?  At a minimum, Trigger Settings and Analyzer Settings should be saved in the file, but Connection Settings might as well go along for the ride if that makes sense for consistency.

2) An even older request would be to show timing measurements between edges, or from rising to rising or falling to falling edges.  Obviously, this would show pulse duration and frequency, respectively, and would be far easier than manually counting and subtracting.  If that's too much calculation during hovering, then perhaps you can require a mouse click before the calculations are made.  Double-click is zoom, so single-click should be available unless I'm missing something.

3) How about those rainbow colors?  I just switched from a Saleae logic probe set (blk, brn, red, org, yel, grn, blu, vio, gry) to four [s:]Sprakfun[/s:]Sparkfun probe sets (red, org, yel, grn, blu, vio, gry, wht, blk).  You can probably guess where I'm going with this: Configurable colors would be nice, so that the user can set them to match the probes.

Note: I switched to using your program on XP, where it works fine, but I might try to upgrade my JVM under OSX to see how well it works there.  Thanks!

@siklosi: Thanks for the suggestion! I'll take a look at this dialog; maybe I can introduce two tabs, one for the connection settings (which don't change that often) and one for the sampling/trigger settings;

@rsdio: thanks for the suggestions, I'll put them on my todo list. Regarding the saving/restoring of settings: the open/save project functionality could be used for this (though I've disabled this functionality in the latest release as it wasn't working correctly yet). For the other suggestions: I'll keep you posted!

@jawi: while you're taking feature requests ;) I think it would be useful to have scrollwheel based zooming as well as the horizontal scrolling. Thanks again for the great client!

[quote author="jawi"]Regarding the saving/restoring of settings: the open/save project functionality could be used for this (though I've disabled this functionality in the latest release as it wasn't working correctly yet).[/quote]Open/Save Project would be perfectly acceptable, and would solve my question about whether the Connection Settings belong with the rest of the lot...

All right, I have some more feedback. Keep in mind I've only used it in Linux so far, which means that some of these could be platform specific for all I know, and some of these may have been discussed earlier in the thread:

1. Is there a way to display the timing of a cursor directly in the main window? I know it's available under Tools --> Measure, so no big problem really.

2. The time scale has 20 time steps between every time stamp. It looks nice and uncluttery, but my visual system can't automatically count to 20, if you know what I mean. What if there was a taller marker mid-way between time stamps? Picture of how that would look attached at the bottom.

3. I agree with some of the comments about the color scheme. White signals on a black background is neutral and easily viewable, which makes for a good default theme. It would be nice if you could let the user color-mark the signal label and the signal graph separately.

4. Keep up the great work! Your software really adds an incredible amount of value to the hardware.

---

A minor, but a bit confusing, bug in the measure tool.  The clock selection pulldown is one-based but the labels for the channels are zero-based.  I couldn't figure out why the clock calculation wasn't working for me until I noticed that you need to select channel 2 in the pulldown to analyze channel 1 in the main display.

@Jawi  This is a feature request:

1) Generate an image (JPG?), To attach to the documentation.
   Also interesting is the selection of a small area.

2) New Plugin for Protocol Analysis (IrDA, CAN, RS485, LIN ....)?



Drake

I'm currently "busy" with bugfixing the 0.9.5 release, which takes a bit longer than I anticipated...

@jone: done! ;) With the latest GitHub code you can use CTRL + mouse wheel to zoom in/out.

@rsdio: I'm currently testing this functionality to save/restore all settings to a project-file; this will be available in the next releaes.

@rasmus: if you hover over a cursor/channel, you will get a tooltip with some information about the sample you're hovering over. Regarding the timeline view: with the latest GitHub code, the timeline is divided in steps of ten, while the time is shown every twentieth step.

@sdixon: yeah, you're totally right. I'll review all parts in which channels are mentioned to make them all zero-based (which is the most "logical" for users). Will be fixed in the next release.

@drakelive: put the export-to-image functionality as todo on my list. As it currently stands, I don't think I'll implement it yet for the upcoming release, but soon after that. Adding new decoder tools would be great and certainly would gain more value to the OLS-client, I mostly don't have any valid test data/devices to verify them (easily). I intend to add decoder tools for at least 1-wire and maybe USB, but the time-schedule for those is unclear yet. However, the current tool-API should be "stable" enough for other users to create their own decoder tools easy. I'll put a todo on my list to write a short how to on writing your own (decoder) tools so people can fiddle with their own protocols...

Again, thanks to you all for your tips/suggestions and bug reports! Keep them coming...

I'll put a todo on my list to write a short how to on writing your own (decoder) tools so people can fiddle with their own protocols...

This would be great, I'd take a stab at writing a decoder.

Hi,

On the generate image, it may be better to do  PNG /TIFF (yes they are 'bigger' but they produce verbatim results that can be digitally edited).
This then allows the user to re-encode the  capture with the correct resolution and Quality for their own use (websites etc)

If you encode as JPG, the algorithms vary for each platform and in some cases  produce poor results when re-encoded  a second time as a jpg.
 I.E a JPG of a JPG  will not have the quality of the original, this may be a problem with  stamping external text over the jpg, the  anti-aliasing gets really messy and the JPG has problems compressing down correctly. This is not an issue with a PNG/TIFF which  after editing goes to a jpg in a single step making the anti-aliasing  cleaner.
(also the  java JPG library is not very good)

H.

[quote author="hardcore"]On the generate image, it may be better to do  PNG /TIFF (yes they are 'bigger' but they produce verbatim results that can be digitally edited).
This then allows the user to re-encode the  capture with the correct resolution and Quality for their own use (websites etc)[/quote]Agreed.  ... and note that TIFF has an indexed color option which, like GIF, allows for very small images when there are only two, four, or eight colors.  Even with every channel using a different color, there should be less than 16 colors, and thus 4 bits per pixel.  TIFF can easily handle this in a small file compared to the typical 24-bit TIFF.  I've done a lot of work with this in decades past, and it's well worth it.  PNG may have similar indexed-color formats, but I have not studied that file format.

@hardcore, rsdio: good remark. If I'm ready to implement the export-to-image functionality I'll take into consideration to provide as many image-formats as Java supports (which includes at least JPEG and PNG by default, not sure about TIFF).

There is libTIFF, but I don't know about access to that from Java

I don't see the point of JPEG for screenshots and graphs, it was designed for photos, and produces ugly artifacts with smooth surfaces and sharp lines. PNG should be fine, and also includes indexed formats. TIFF is rarely used outside the graphics industry, I don't think most browsers can render TIFF by default.

Agreed.  Support for JPEG would just encourage improper use of the format.

PNG, TIFF, and GIF should probably be the only formats considered.  If TIFF is too difficult to support, then don't bother, but OSX can render it natively.  GIF is encumbered, but if free libraries exist then it would make more sense to support GIF than JPEG.

[quote author="jawi"]
@hardcore, rsdio: good remark. If I'm ready to implement the export-to-image functionality I'll take into consideration to provide as many image-formats as Java supports (which includes at least JPEG and PNG by default, not sure about TIFF).
[/quote]

Personally I would not beat myself up over multiple formats, its better to spend time on bug fixes and signal functionality, (there is a standard format to export  waveforms in, that allows other viewers to manipulate the signals)

I think one lossless export format for graphics is fine, anything else can be provided by packages that specialize in graphic format manipulation.
if you want to get really clever then SVG, since it would allow individual editing of signal/timebase/scale and  gridlines as separate sections of the image, plus it is scalable, but for this I  think PNG or some other lossless system is fine.

@hardcore, rsdio & alm:
Writing images to PNG is by default supported in Java (as are other formats like GIF, BMP and JPEG), so it won't be that much of a problem to support it.

I understand there is much need for an export to PNG, so let's start with implementing that one first, and put focus on the remainder of the provided functionality...

I just uploaded the 0.8.5 release of my client on usual location (http://http://www.lxtreme.nl/ols/).

An overview of the most important changes (the full changelog can be found on GitHub (http://http://github.com/jawi/ols/blob/master/ChangeLog)):

• Added user preferences for height of channels & signals, and initial color schemes; by default the "light" scheme is used, but you can also choose for a dark "rainbow" scheme. You can also change the way the colors are applied, for example to the channel background or to the label;
• Restored the load/save project functionality; this allows you to save/restore settings used in dialogs;
• Reworked most of the dialogs to have a "cleaner" look and reduced the height of some dialogs for lower resolution displays;
• Several look and feel improvements:
  • Added support to use shortcut keys for accessing menu functions (under Windows and Linux);
     
  • Added support for mouse wheel zooming (CTRL + mouse wheel; under Windows and Linux);
     
  • Some visual improvements on the time line view (display notch every ten ticks);
[/li]

• The OLS device does no longer scan all serial ports upon opening the configuration dialog; this is now only done when the port combobox is opened for the first time. Should avoid havoc on other serial devices on the USB bus.

This will be the last release in the 0.8 release, as I'm planning several big changes for the 0.9 release. Some highlights: export functionality for captured data (at least PNG and VCD), a 1-Wire decoder tool, custom color schemes (make your own rainbow!), and (ad hoc) timing measurements between two edges. Oh yeah, I'm also planning to write a short how-to-write-your-own-decoder-tool.

Have fun!

Thanks!  I/we have been waiting for this!

Hi,

Whilst it does eventually start under OS x , I think it needs a better startup method there are some errors during startup:
(i never understand why people need a command line  Bash script to start a java app under OS X), thats what manifest files are for.



 sudo ./run.sh
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._api-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._base-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._client-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._i2c-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._logging-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._logicsniffer-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._measure-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._org.apache.felix.log-1.0.0.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._org.apache.felix.prefs-1.0.4.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._org.apache.felix.shell-1.4.2.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._org.apache.felix.shell.remote-1.0.4.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._org.rxtx-2.2.0-8.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._spi-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._state-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._test-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._uart-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._util-1.0.4-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
[10/2/10 8:03:59 AM - INFO  -     nl.lxtreme.ols.client.Host]: LogicSniffer v0.8.5 started ...

[quote author="hardcore"]
Hi,

Whilst it does eventually start under OS x , I think it needs a better startup method there are some errors during startup:
(i never understand why people need a command line  Bash script to start a java app under OS X), thats what manifest files are for.

 sudo ./run.sh
Auto-deploy install: org.osgi.framework.BundleException: Unable to cache bundle: file:/Volumes/EXCHANGE/logic_sniffer/ols-0.8.5/./plugins/._api-1.0.0-SNAPSHOT.jar - java.util.zip.ZipException: error in opening zip file
(snip)
[10/2/10 8:03:59 AM - INFO  -     nl.lxtreme.ols.client.Host]: LogicSniffer v0.8.5 started ...
[/quote]

Agreed; for OSX there should be a separate installer (I'm working on OSX myself as well), so let's make this a feature of the upcoming 0.9 release. :)

PS: just out of curiosity, why are you running the client as superuser?

PS: just out of curiosity, why are you running the client as superuser?

I just like to live dangerously and tend to get bored easily......
Actually because the  run.sh, does not have the correct privileges to execute and i'm too bloody lazy to change them.

As regards an 'installer' for OS X  you do not need it, just correctly  reference the libraries from within java's class loader, then dynamically load  based on the application  base folder. it is completely cross platform, I use a  "props" file that contains the file names of libraries i want loading.
On  main class startup there is zero reference to external libraries, so no library errors, then just "reflect" the libraries in, it allows for graceful/ controllable failure if a library is missing

[quote author="hardcore"]Actually because the  run.sh, does not have the correct privileges to execute and i'm too bloody lazy to change them.[/quote]It's incredibly easy

chmod +x run.sh

It's incredibly easy
Code: [Select]
chmod +x run.sh

still way longer than
su root

@jawi

It keeps getting better and better! I've officially started using your client exclusively, I just spent the last couple days troubleshooting some SPI output from the AVR8 Soft Processor core (http://http://gadgetforge.gadgetfactory.net/gf/project/avr_core/) project and your client didn't miss a beat.

I've been checking out InstallJammer for Windows and intend to make a installer for the latest version including your client soon.

One thing I noticed that is a minor issue is that when the OpenBench Logic Sniffer device is selected the banner that shows the Channel and time overwrites the signal display. It doesn't do so when the Test Device is selected though...

Keep up the great work!

Jack.

So I downloaded the tarball from http://www.lxtreme.nl/ols/ols-0.8.5.tar.gz.. (http://www.lxtreme.nl/ols/ols-0.8.5.tar.gz..). extracted it all to my desired location, and what do I do with these class files???
And I don't see the run script that is frequently mentioned....
I am using windows XP 32bit.  Have Java 1.6.0_21.  The older, less function client that came with the 2.12 Test Release of the obls soft/firm ware is pretty easy to get going, but based on the comments I was really hoping to use this client.
Help would be appreciated.

[quote author="shawn"]
So I downloaded the tarball from http://www.lxtreme.nl/ols/ols-0.8.5.tar.gz.. (http://www.lxtreme.nl/ols/ols-0.8.5.tar.gz..). extracted it all to my desired location, and what do I do with these class files???
And I don't see the run script that is frequently mentioned....
[/quote]

Hi Shawn,

After unpacking with 7-Zip (or whatever archiver you're using), you should get a structure like:

├── AUTHOR
├── LICENSE
├── README
├── bin
│   ├── looks-2.2.2.jar
│   ├── org.apache.felix.main-3.0.1.jar
│   ├── org.osgi.compendium-4.2.0.jar
│   └── runner-1.0.0-SNAPSHOT.jar
├── plugins
│   ├── api-1.0.0-SNAPSHOT.jar
│   ├── base-1.0.0-SNAPSHOT.jar
│   ├── client-1.0.0-SNAPSHOT.jar
│   ├── i2c-1.0.0-SNAPSHOT.jar
│   ├── logging-1.0.0-SNAPSHOT.jar
│   ├── logicsniffer-1.0.0-SNAPSHOT.jar
│   ├── measure-1.0.0-SNAPSHOT.jar
│   ├── org.apache.felix.log-1.0.0.jar
│   ├── org.apache.felix.prefs-1.0.4.jar
│   ├── org.apache.felix.shell-1.4.2.jar
│   ├── org.apache.felix.shell.remote-1.0.4.jar
│   ├── org.rxtx-2.2.0-8.jar
│   ├── spi-1.0.0-SNAPSHOT.jar
│   ├── state-1.0.0-SNAPSHOT.jar
│   ├── test-1.0.0-SNAPSHOT.jar
│   ├── uart-1.0.0-SNAPSHOT.jar
│   └── util-1.0.4-SNAPSHOT.jar
├── run.bat
└── run.sh

You should now be able to run the client by simply running the "run.bat" script (double clicking from an Explorer should work as well).

Let me know if you run into other issues...

HtH

@jawi:
so I actually have a directory structure like..

|- META-INF
|   |- MANIFEST.MF
|	|- maven
|	    |- nl.lxtreme.ols
|		    |- util
|				|- pom.properties
|				|- pom.xml
|
|- nl
    |- lxtreme
	    |- ols
		    |- util
			    |-"bunch of .class files"
                            |- swing
                                |- "bunch of .class files"
                                |- component

There is a little more under nllxtremeolsutil, but you get the idea.  I don't have anything like the structure you described. 

So I started downloading older versions... and ols-0.8.4, ols-0.8.2, and ols-0.8.0 also extracted to that same directory structure.  ols-0.7.0 extracted to something more like the structure you showed, and that version executed but did not recognize the obls.

So I thought, well I have eclipse installed I'll just load up the project and build it myself.  That didn't go too well.

So I thought, well I will just setup maven by hand and build it from the command line.  This went smoothly.  So I am now running ols-0.8.5.  And it is much nicer than the default SUMP client.  So good job on the coding.

I don't know what is going on with those archives on the website, but they are really messed up.  It was very easy to see what files were required in ols.distribution and ols.distributiontarget after I built the project.  So I just made an ols-0.8.5 directory and copied the LICENSE, AUTHOR, README, run.bat, run.sh files and the targetbin and targetplugins folders from ols.distribution.  double click run.bat and everything runs fine.

You have "extracted" too far...........

a *.jar file is actually a .zip file.   the structure you have currently is from the fact that somehow the  *.jar files have been extracted, into their composite classes

I would suspect that *.jar has been associated with the Zip program in the windows registry.

You need to extract so that the directory is filled with  *.jar files and don't go any further into the extraction process.

@hardcore
I don't know man, I was using 7-Zip.  And in testing with other archives containing jars, it doesn't automatically descend.  Are you telling me that if you download the file I linked to in my first post, and extract it, you get the proper directory structure and not the structure I showed?

-Shawn

[quote author="shawn"]Are you telling me that if you download the file I linked to in my first post, and extract it, you get the proper directory structure and not the structure I showed?[/quote]Yep.  I have downloaded at least three different versions of the Alternative Java client and simply used the Extract all feature that is built in to Window XP.  If you're having trouble with 7-Zip, then why just not use the Microsoft version?  You really don't need anything more than that.

Jawi,

First, thank you for all your efforts producing this client for the Open Logic Sniffer, it is greatly appreciated.

I was playing with my OLS this evening and have found what seems to be a consistent discontinuity in the data.  I have no idea if this is an artifact of the client or the actual OLS hardware.  I set up a pattern generator to count up on three bits continuously to create something for the OLS to look at.  I have found that there almost always seems to be discontinuities in repeatable spots in the acquired waveform.  I have attached a few screen captures showing the problem.  Between approximately 40us and 41us there is a discontinuity.  As can be seen in the pictures it is not always the same but always occurs at about the time.  I have verified with my "real" HP logic analyzer that there are no discontinuities like this in the generated pattern.  I am not using any trigger qualification so the OLS runs as soon as I press capture.  This is why the pattern is not consistent relative to a given time -- however the artifact is.  The artifact appears to repeats five times at a constant interval throughout the captured data.  I have also attached a picture of the settings I was using other than the trigger which was not set up at all.  Again, I do not know if this is a client or OLS issue -- or possibly even my computer.

I also have two usability suggestions as well. 

1) When a capture is executed, especially using the repeat capture  button, could the display zoom and location please remain the same?  For example, while I was investigating the discontinuity issue I was rerunning the capture multiple times but always wanted to look at the same spot at the same zoom.  There is a one click way to zoom out to fit everything but no easy way to get back to your prior view.  If the zoom and position stayed the same it would make this type of analysis much easier but for the people that wanted to see everything it is a one click process.  Possibly a preference setting to control the behavior would provide either functionality, a "Zoom to Best Fit after Acquisition" check box. 

2) There is no way to view the capture settings with out executing a capture.  The only way to view the acquisition and trigger settings is to press the start capture button.  Once in this dialog though pressing either the capture button or the close button will initiate a new capture.  Even pressing the close X in the upper right corner will start a capture.  There is no way to view the settings and then exit without causing a new capture.

Thanks again for all you hard work.

-Eric

---

I noticed a weird archive thing - I had to click the '.' directory on the default first level in the archive to see the author/run/readme/etc. The location in 7-zip looks like this: Desktopols-0.8.5.tarols-0.8.5., but I do seem to have all the correct files.

[quote author="Eric"]I was playing with my OLS this evening and have found what seems to be a consistent discontinuity in the data.  I have no idea if this is an artifact of the client or the actual OLS hardware.[/quote]Did you do anything to upgrade or otherwise install the latest Flash bitstream and PIC firmware on your OLS?  The reason I ask is that it at least seems possible that having an older bitstream could cause a problem like this.  However, please take note that I'm just guessing here.  I have the OLS and have been using it with this client, but I have not extensively tested it like you have.  I do know that I have the latest firmware and bitstream, though.

@shawn, ian: I've been playing with the archive in 7-Zip as well, and have found the following: shawn is probably running 7-Zip 9.xx, which makes a total mess out of my archives, ian is running 7-Zip 4.65, which does a "neat" trick with the root folder, but should extract just fine. I get the same results with other gzipped tarballs as well.

Further investigation reveiled also that there is some inconsistencies in the archives themselves; they extract fine with Cygwin's tar utility, but reports something about ignoring trailing blocks. I've to investigate whether this is due to: a) Maven, b) OSX, or c) 32- vs. 64-bits.

Thanks for pointing this out; in the meantime I suggest using either the 4.65 version of 7-Zip, or another extraction tool, like WinZip.

edit: I've pinpointed parts of the problems to Maven (click here (http://http://jira.codehaus.org/browse/PLXCOMP-38) for bug report); have a patch ready for fixing the issues reported by Ian. It will not fix the problems seen by Shawn, as 7-Zip v9 totally keeps messing up the archive.

[quote author="rsdio"]
[quote author="Eric"]I was playing with my OLS this evening and have found what seems to be a consistent discontinuity in the data.  I have no idea if this is an artifact of the client or the actual OLS hardware.[/quote]Did you do anything to upgrade or otherwise install the latest Flash bitstream and PIC firmware on your OLS?  The reason I ask is that it at least seems possible that having an older bitstream could cause a problem like this.  However, please take note that I'm just guessing here.  I have the OLS and have been using it with this client, but I have not extensively tested it like you have.  I do know that I have the latest firmware and bitstream, though.
[/quote]

No, I have not upgraded any of the firmware in my OLS.  It is a recently purchased unit from SparkFun and I understand they got a batch from Seeed not that long ago.  When I get a chance this evening I will check the version information. 

This seemed like a problem someone would have found during the early testing of the OLS and since the Alternative Java client is much newer, and still in development, I was guessing the problem was likely related to the client.  I will try running this with the original client to see if I get the same results.  The first time I tried using the original client though I had some problems and do not remember if I was ever able to get it to work.


-Eric

@jack.gassett: sorry, I accidentally missed your post. Thanks for the compliment! I'll look into the issue you reported; mostly this has something to do with an incorrect paint. Do you have perhaps any clue how I could reproduce this problem?

@erik: thanks for the suggestions; I like the idea of keeping the current zoom & viewpoint as-is upon recapturing. Regarding the second issue: nice catch; this only occurs after you've performed a successful capture at least once. Fixed this already in the main GitHub repo.

[quote author="jawi"]
@[s:]erik[/s:]Eric: Regarding the second issue: nice catch; this only occurs after you've performed a successful capture at least once. Fixed this already in the main GitHub repo.
[/quote]

Glad I could help.

[quote author="jawi"]
@[s:]erik[/s:]Eric: thanks for the suggestions; I like the idea of keeping the current zoom & viewpoint as-is upon recapturing.
[/quote]

I was thinking about this some more and I believe the most intuitive way to do it might be to preserve the zoom and viewpoint if you use the repeat capture but reset it to best fit if you use the interactive capture button. 

My thinking is if you are using the repeat button you probably have everything configured (channels, trigger, zoom, etc.) the way you want it and are just getting updated data.  So in this case it would probably be best to leave the zoom and viewpoint as is.  If you are using the capture button then you are probably adjusting something in the trigger or capture settings so zooming to best fit is probably most appropriate because you have likely changed something anyway.  If fact the previous zoom and viewpoint settings may not even be valid if you have changed the sample rate or depth. 


-Eric

That glitch that you have Eric could be a hardware problem.

I've noticed that my OLS sometimes triggers on the signal from my wireless mouse (or possibly the receiver of the mouse). I also get occasional crosstalk between the input channels. For example if I'm measuring a signal on channel 2 i may sometimes get it on channels 1 and 3 as well. Splitting up the proble cable and holding the individual channel cables apart seems to help.

[quote author="rsdio"]
[quote author="shawn"]Are you telling me that if you download the file I linked to in my first post, and extract it, you get the proper directory structure and not the structure I showed?[/quote]Yep.  I have downloaded at least three different versions of the Alternative Java client and simply used the Extract all feature that is built in to Window XP.  If you're having trouble with 7-Zip, then why just not use the Microsoft version?  You really don't need anything more than that.
[/quote]
That seems hard to believe since Windows XP doesn't have built in capability to extract .tar.gz files, it can only extract .zip files natively.  Perhaps you have WinZip or other archive tool with shell integration?
However I did just do it from my MSYS command line, and it came out right.  REALLY strange.  I have never had an issue with 7zip before.  I wonder if it is a gnu tar vs. BSD tar issue?  or something similar.  Or a symbolic link issue?  That can cause problems on Windows.

@jawi - Actually I have found some mention of problems with certain tar files in 7Zip versions newer than 9.15.  And Igor says:

We must ask developers about version of TAR software that was used to create these "bad" archives.
And then we can ask these TAR software developers to fix bugs.

  So the 7-Zip developers have seen "bad" tar archives, and think that the tar programs used to create them should be fixed.  Unfortunately I suspect that there are enough slightly different versions of tar floating around the world that maybe we should all just try to deal with the issues.... But this was a somewhat frustrating one for me. 
So I wouldn't mind knowing what program, and version of it, you are using to create the tars, and I would maybe encourage you to look at using something else.  But in the end it probably doesn't matter too much, as this will only affect persons using newer versions of 7Zip to extract.  Although it is interesting that whatever you used to make ols-0.7.0.tar.gz compressed that in such a way that new versions of 7Zip could deal with it.

-Shawn

- edit @jawi - so maybe just ignore most of my post, I just saw yours... Appreciate your looking into this.  And hopefully the world will one day agree on how to handle tar... your would think that 30+ years would be enough time to get it "right", lol.

[quote author="Eric"]I was thinking about this some more and I believe the most intuitive way to do it might be to preserve the zoom and viewpoint if you use the repeat capture but reset it to best fit if you use the interactive capture button. 

My thinking is if you are using the repeat button you probably have everything configured (channels, trigger, zoom, etc.) the way you want it and are just getting updated data.  So in this case it would probably be best to leave the zoom and viewpoint as is.  If you are using the capture button then you are probably adjusting something in the trigger or capture settings so zooming to best fit is probably most appropriate because you have likely changed something anyway.  If fact the previous zoom and viewpoint settings may not even be valid if you have changed the sample rate or depth.[/quote]Agreed, in general, but I sometimes use the interactive capture to confirm that my settings are exactly as I thought they were.  So, perhaps the best programming would be to destroy the cached zoom and viewpoint whenever the capture settings are actually changed, but not merely by which button is clicked.

[quote author="shawn"]
[quote author="rsdio"]I have downloaded at least three different versions of the Alternative Java client and simply used the Extract all feature that is built in to Window XP.  If you're having trouble with 7-Zip, then why just not use the Microsoft version?  You really don't need anything more than that.
[/quote]
That seems hard to believe since Windows XP doesn't have built in capability to extract .tar.gz files, it can only extract .zip files natively.  Perhaps you have WinZip or other archive tool with shell integration?[/quote]My apologies!  I shouldn't shoot from the hip, because sometimes I work too fast to keep up with everything I'm doing.  Now that you mention it, I recall that I actually download the .tar.gz to my OSX machine, double-click in the Finder to let Apple expand the files, then I select the resulting directory and use the Finder again to create a .zip file which I ftp from my OSX to XP machine.  At that point, the XP machine has an Apple-created .zip that is easy to extract.  I've actually done this three times now, so I can't believe that I forgot about it!

Apparently I was comparing Apples to oranges.  The OSX Finder .tar.gz expansion is producing the correct files with built-in functions, not XP.

P.S.  I do hope to try this under OSX again soon, but lately I've left my OLS1 attached to the XP machine.

By the way, I'm back to having to edit the line in the ./run.sh script to:

java -Dnl.lxtreme.ols.bundle.dir="$PLUGINDIR" -cp "$CLASSPATH" -Dgnu.io.rxtx.SerialPorts="/dev/OpenLogicSniffer" nl.lxtreme.ols.runner.Runner

Or without the udev rule:

java -Dnl.lxtreme.ols.bundle.dir="$PLUGINDIR" -cp "$CLASSPATH" -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM0" nl.lxtreme.ols.runner.Runner

I think that this is probably because of something I did to my box, but I'm posting it just in case anyone runs into the same problem under Linux.

Retested and downloaded the file  from the link given by shawn......

There appears to be nothing wrong with the  archive.
Extracting it  gives a folder "ols-0.8.5" , inside are the correctly formed *.jar libraries.

nested extraction of a *.jar file is a problem with the extraction program, not the *.jar

[quote author="rsdio"]
[quote author="Eric"]I was thinking about this some more and I believe the most intuitive way to do it might be to preserve the zoom and viewpoint if you use the repeat capture but reset it to best fit if you use the interactive capture button. 

My thinking is if you are using the repeat button you probably have everything configured (channels, trigger, zoom, etc.) the way you want it and are just getting updated data.  So in this case it would probably be best to leave the zoom and viewpoint as is.  If you are using the capture button then you are probably adjusting something in the trigger or capture settings so zooming to best fit is probably most appropriate because you have likely changed something anyway.  If fact the previous zoom and viewpoint settings may not even be valid if you have changed the sample rate or depth.[/quote]Agreed, in general, but I sometimes use the interactive capture to confirm that my settings are exactly as I thought they were.  So, perhaps the best programming would be to destroy the cached zoom and viewpoint whenever the capture settings are actually changed, but not merely by which button is clicked.
[/quote]

Yes, that would be the most elegant solution for sure if it can be implemented easily.  However, now that the close button is if fixed you could open the dialog to confirm the settings and then close it without initiating a capture.  Then use the repeat button when you want to execute another capture without affecting the zoom settings. 

I was actually thinking that the button now used for the interactive capture could be changed to say Capture and Trigger settings and the repeat button could be changed to say Capture.  Leave the capture button at the bottom of the settings dialog box as a shortcut.  Maybe it is just the paradigm of the hardware logic analyzers I have used but there is normally a big lighted "Run" button, either in software or hardware, that starts a capture and then somewhere else is a "Trigger" button or menu as well as an "Acquisition Settings" button or menu that controls these parameters.  The difference is the top/primary/biggest/brightest/most-prominent control is the run button that does what the repeat button does.  The acquisition and trigger settings are of less prominence.


-Eric

[quote author="Eric"]
[quote author="rsdio"]
[quote author="Eric"]I was playing with my OLS this evening and have found what seems to be a consistent discontinuity in the data.  I have no idea if this is an artifact of the client or the actual OLS hardware.[/quote]Did you do anything to upgrade or otherwise install the latest Flash bitstream and PIC firmware on your OLS?  The reason I ask is that it at least seems possible that having an older bitstream could cause a problem like this.  However, please take note that I'm just guessing here.  I have the OLS and have been using it with this client, but I have not extensively tested it like you have.  I do know that I have the latest firmware and bitstream, though.[/quote]
No, I have not upgraded any of the firmware in my OLS.  It is a recently purchased unit from SparkFun and I understand they got a batch from Seeed not that long ago.  When I get a chance this evening I will check the version information.  [/quote]

I updated my OLS to the latest (stable?) 2.1 version and it seems to have fixed the problem.  Before I did this I tested it with the original client and was getting the same discontinuities so it had nothing to do with the client.  

I guess I should have updated everything before I started -- my apologies --  I thought since I purchased this so recently it would have reasonably up to date firmware.  My mistake, sorry for clogging up the forum.

I will give the 2.12 Test Release a try next.


-Eric

[quote author="rasmus"]
By the way, I'm back to having to edit the line in the ./run.sh script to:

java -Dnl.lxtreme.ols.bundle.dir="$PLUGINDIR" -cp "$CLASSPATH" -Dgnu.io.rxtx.SerialPorts="/dev/OpenLogicSniffer" nl.lxtreme.ols.runner.Runner

Or without the udev rule:

java -Dnl.lxtreme.ols.bundle.dir="$PLUGINDIR" -cp "$CLASSPATH" -Dgnu.io.rxtx.SerialPorts="/dev/ttyACM0" nl.lxtreme.ols.runner.Runner

I think that this is probably because of something I did to my box, but I'm posting it just in case anyone runs into the same problem under Linux.
[/quote]

Thanks for mentioning this, rasmus; an alternative would be to leave the run scripts as-is, and type the device path into the capture settings dialog. It is remembered between session, so this should often be a once-only action.

Right, but that's exactly what's not working on my box any more. It says "Capture aborted! Failed to attach to /dev/ttyACM0: no such port". I don't know why, but all 0.8.x versions stopped working (they all stopped working simultaneously) unless I run them with the -Dgnu.io.rxtx.SerialPorts argument.

This is probably a problem on my end, but I'm throwing it out here just in case someone else gets stuck with the same problem.

[quote author="rasmus"]
Right, but that's exactly what's not working on my box any more. It says "Capture aborted! Failed to attach to /dev/ttyACM0: no such port". I don't know why, but all 0.8.x versions stopped working (they all stopped working simultaneously) unless I run them with the -Dgnu.io.rxtx.SerialPorts argument.

This is probably a problem on my end, but I'm throwing it out here just in case someone else gets stuck with the same problem.
[/quote]

No, it is not; it RXTX (again) that appears to cause this behaviour. In short, in the way it is currently used, it only accepts serial ports it "knows". Will fix this problem in the first upcoming release. Are you interested in testing a possible fix?

Sure, let me know when you have something you want tested.

Just to be clear: 0.8.5 works fine under Linux once it knows where the OLS is. No problems at all capturing and viewing data from the OLS and the test device. Here's a shot of the test device in action. Looking pretty good:

---

Jawi,

I have two more suggestions for future versions of your client.

First, could you change the protocol analyzer window to not steal the focus when it is open.  I am testing the I2C protocol analyzer and would like to go back and forth between the waveform view and the protocol analyzer view.  But when the protocol analyzer window is open I can not adjust the main window.  The Measure tool works much better, I can leave it open and switch back and forth between it and the main window.

The second is more of a confusion issue.  When cursors are off the Diagram menu has an item "Enable cursors."   Once the cursors are tuned on this item changes to "Disable cursors" but now also has a check beside it.  It makes it seem like the disable cursor function is turned on which would mean the cursors are off -- kind of a double negative.  I think it would be clearer to either have the "Enable Cursors" change to "Disable cursors" with no check mark or to leave the menu item the same "Enable cursors" or even just "Cursors" and use a check mark when they are on.

Thanks again for all the time you have put into this improved client.


-Eric

[quote author="Eric"]
I have two more suggestions for future versions of your client.

First, could you change the protocol analyzer window to not steal the focus when it is open.  I am testing the I2C protocol analyzer and would like to go back and forth between the waveform view and the protocol analyzer view.  But when the protocol analyzer window is open I can not adjust the main window.  The Measure tool works much better, I can leave it open and switch back and forth between it and the main window.

The second is more of a confusion issue.  When cursors are off the Diagram menu has an item "Enable cursors."   Once the cursors are tuned on this item changes to "Disable cursors" but now also has a check beside it.  It makes it seem like the disable cursor function is turned on which would mean the cursors are off -- kind of a double negative.  I think it would be clearer to either have the "Enable Cursors" change to "Disable cursors" with no check mark or to leave the menu item the same "Enable cursors" or even just "Cursors" and use a check mark when they are on.
[/quote]

Thanks for the suggestions, Eric. I'll take a look at the first one, I don't see any major reasons why this shouldn't work. The "enable/disable cursors" menu item shall be renamed to "Cursor mode". In combination with the check this should be clear enough, not?

[quote author="jawi"]
Thanks for the suggestions, Eric.[/quote]

No problem, thanks for writing the software.

[quote author="jawi"]
The "enable/disable cursors" menu item shall be renamed to "Cursor mode". In combination with the check this should be clear enough, not?[/quote]

If you are going to use the check mark I would just call it "Cursors."  Adding "mode" would seem to imply that either (1) there is some type of mode configuration for the cursors or (2) that "cursor mode" is a special "mode" inherently different from normal mode.  Neither of which is the case.  Either way would be clearer, at this point we're splitting hairs.


-Eric

Another feature request (perhaps for 1.0) would be the ability to display all clock edges as straight, perpendicular line segments, in order to make it easier on the eyes. Or in other words to make the starting point and ending point of the clock edges have the same x-coordinates. This would be a toggle on/off since it destroys some data in the process.

@Eric: some times hairs need to be split in order to have clear semantics; it is now "Cursors" with a checkmark;

@rasmus: straight/perpendicular edges are on the wishlist, thanks for mentioning it.

This tool is just getting better and better!

However, I'm currently having an issue with the SPI module; it insists on ignoring my /CS signal (despite "Honour /CS" being checked) and just starts decoding several clock cycles late. I've also seen it insist there are /CS transitions when none exist in the data. It's correctly configured in the decoder dialog, but perhaps it's reading data from the wrong place?

Additionally, it's not setting the channel labels for /CS and SCK, just MOSI and MISO (although I don't know if that's by design or part of the bug.) EDIT: okay, looks like it's by design.

---

[quote author="pelrun"]
However, I'm currently having an issue with the SPI module; it insists on ignoring my /CS signal (despite "Honour /CS" being checked) and just starts decoding several clock cycles late. I've also seen it insist there are /CS transitions when none exist in the data. It's correctly configured in the decoder dialog, but perhaps it's reading data from the wrong place?
[/quote]

could you provide me a dumpfile with sample data so I can look into this problem myself?

[quote author="pelrun"]
Additionally, it's not setting the channel labels for /CS and SCK, just MOSI and MISO (although I don't know if that's by design or part of the bug.) EDIT: okay, looks like it's by design.
[/quote]

Actually, this is a todo on my side; the behaviour of labels should be equivalent to the I2C decoder. Thanks for reminding me (to put it on my todo list) ;)

EDIT: pelrun, could you try to place the area you're trying to decode between cursors 1 & 2 and try the SPI decoder again? If this works, then I already know what is going on and will fix it...

I had to rock some intense LAing today, and I just wanted to say that the latest version is fantastic! I've completely abandoned the old version for yours, and moved it to the top of the wiki software list :) It's a joy to use and it doesn't 'feel like Java'. In my opinion this is nicer and richer than the Saleae client (I use the Saleae a lot too).

Great work! Thank you so much!

[quote author="ian"]
I had to rock some intense LAing today, and I just wanted to say that the latest version is fantastic! I've completely abandoned the old version for yours, and moved it to the top of the wiki software list :) It's a joy to use and it doesn't 'feel like Java'. In my opinion this is nicer and richer than the Saleae client (I use the Saleae a lot too).

Great work! Thank you so much!
[/quote]

Thanks for the great compliment! Do you mind if I place (parts of) your quote on the OLS website as sort of testimonial?

[quote author="ian"]
 it doesn't 'feel like Java'.
[/quote]

You will be surprised at just how fast java is, when it is correctly written.
Too many people blow it off because they remember the cases of poorly written java apps, its also about the fastest language to knock up GUI's plus if you find yourself in a bind and do need more speed, you just code a bit of C and call it from the java.

Jdeveloper from oracle is a free download/usage, allows you to build GUI's without those stupid 'do not edit below this line' code inserts of "form" files many other java Dev tools use, as such it allows "manual' tweaking of the GUI.

[quote author="hardcore"]Jdeveloper from oracle is a free download/usage, allows you to build GUI's without those stupid 'do not edit below this line' code inserts of "form" files many other java Dev tools use, as such it allows "manual' tweaking of the GUI.[/quote]Cocoa is like this, too, except that you never have to code a bit of C and call it from Cocoa because Cocoa is already C.  Too bad Cocoa is basically only available on OSX and iOS, unless you count Solaris and Win32.

[quote author="jawi"]
[quote author="pelrun"]
However, I'm currently having an issue with the SPI module; it insists on ignoring my /CS signal (despite "Honour /CS" being checked) and just starts decoding several clock cycles late. I've also seen it insist there are /CS transitions when none exist in the data. It's correctly configured in the decoder dialog, but perhaps it's reading data from the wrong place?
[/quote]

could you provide me a dumpfile with sample data so I can look into this problem myself?

EDIT: pelrun, could you try to place the area you're trying to decode between cursors 1 & 2 and try the SPI decoder again? If this works, then I already know what is going on and will fix it...
[/quote]

I've attached a capture to this post. Using the cursors just causes analysis to fail with a "CS not detected" error - incidentally, that closes the analysis dialog which is a bit annoying...

@jawi - of course, use away!

@jawi

any chance you could update the link in your very first post?

@Neganur - Thanks for the suggestion, I added a link the new download page on the first post.

Fresh from the presses: version 0.9.0 (http://http://www.lxtreme.nl/ols/ols-0.9.0.tar.gz) of my (nowadays not so) alternative OLS client. As always available from its homepage (http://http://www.lxtreme.nl/ols). I've updated the first post of this topic to make note of the new release as well...

This is the first release of the 0.9 series, and changes for this release are:

• Added export to image (PNG) and VCD files;
• Added option to show signal edges as straight edges or slanted edges;
• Better support for [tt:]/dev/ttyACM[/tt:] device names on Linux systems;
• The client is now distributed in ZIP (Windows), TAR-GZ (Linux) and DMG archives (OSX);
• Many more bugfixes, see the ChangeLog on GitHub for more information.

As always I like to thank all people that have sent in their requests, proposals and bug reports; keep them coming in the future!

Regards,

  JaWi

Awesome!

Is it feasible to add a live preview or scrolling live capture mode (without major overhaul of the display stuff)? I was looking at the scanalogic client today, it has a feature like this:
http://www.ikalogic.com/scanalogic2/index.php (http://www.ikalogic.com/scanalogic2/index.php)

Continuous sampling is a frequently requested feature that would be a related change in the core. 

How about the meta data string described here:
http://dangerousprototypes.com/docs/The ... P_protocol (http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol)
I'll try to make a test bitstream that supports that first. I almost have it locked down.

[quote author="ian"]
Is it feasible to add a live preview or scrolling live capture mode (without major overhaul of the display stuff)? I was looking at the scanalogic client today, it has a feature like this:
http://www.ikalogic.com/scanalogic2/index.php (http://www.ikalogic.com/scanalogic2/index.php)

Continuous sampling is a frequently requested feature that would be a related change in the core. 

How about the meta data string described here:
http://dangerousprototypes.com/docs/The ... P_protocol (http://dangerousprototypes.com/docs/The_Logic_Sniffer%27s_extended_SUMP_protocol)
I'll try to make a test bitstream that supports that first. I almost have it locked down.
[/quote]

Thanks for the suggestions, ian. The continuous sampling could be added quite easily, I guess. If you've got a bitstream that allows this from the hardware side, drop me a line, I'll take a look at implementing it in the UI. I presume the live capture stream will stop once the buffer memory is full (or will it continue at the beginning of the memory, i.e., round robin)?

Regarding the metadata, I didn't know it was already in; now I can add some additional checks to the client regarding what kind of Logic Sniffer I'm talking to... Are these commands available during run-mode, or only during program/boot mode?

Sorry to get ahead of myself.

The metadata isn't in, that is just a suggested format. I think I have it working in a test though. That meta data could be adopted by all the DP stuff that supports SUMP.

I think the same basic changes to the FPGA can enable to continuous sample features:
1. Live preview - while waiting for a trigger we can see what's happening
2. Continuous - for low sample speeds, the sample sizes can be huge and we just dump samples at that speed. This is like a saleae logic, and really helps with I2C traffic logging. It'll be limited by the CDC protocol and the max 12Mbps USB bandwidth, but could be useful.

Some buffering in the FPGA might be good, but to start it may be simpler to just read out the pin states like a shift register.

Just something to think about. I'll post some test bitstreams when I have something that's working.

[quote author="ian"]
Is it feasible to add a live preview or scrolling live capture mode...[/quote]

While not as sophisticated as a scrolling live capture, most of the logic analyzers I have used have had a sort of live preview called Activity Indicators.  These are more akin to a logic probe on each channel (Hi,Low,Pulse) but provide a good idea of what is happening and may be easier to implement.

-Eric

---

Hallo,
I have downloaded http://www.lxtreme.nl/ols/ols-0.9.0.tar.gz (http://http://www.lxtreme.nl/ols/ols-0.9.0.tar.gz). I unpacked it to folder E:programsLogicSniffer2 and ran console and run.bat. When I want change the COM port, the client is frozen. Logic Analyzer Client->Caputure settings->Analyzer port. Is there some workaround?

Microsoft Windows 2000 [Verze 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

E:programsLogicSniffer2>path
PATH=C:Program FilesCommon FilesSiemensSqlany;
etc.;
etc.;
etc.;
C:programsJavajdk1.6.0_22bin;C:programsJavajre6bi
n;E:programsLogicSniffer2

E:programsLogicSniffer2>java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing)

E:programsLogicSniffer2>run.bat
Oct 31, 2010 10:51:15 AM nl.lxtreme.ols.client.Host start
INFO: LogicSniffer v0.9.0 started ...
WARNING:  RXTX Version mismatch
        Jar version = RXTX-2.2
        native lib Version = RXTX-2.2pre2

If I try the original client it works well. Gadget Factory->OpenBench Logic Sniffer->Files->OpenBench_LogicSniffer_JAVA_CLIENT_2.1.zip

@frpr666: does the client freeze when opening the drop-down/combobox, or when entering the name of the com-port directly? There's an issue with the used RXTX library that will try to scan all 255(!) possible COM-ports on a system; this might take a while (hence resulting in a freeze of the client)...

@Jawi: the client get freeze when I try change the com-port combobox. After that I can't do anything with the window Caputure settings. I tried to wait but it's still the same. . I will try it under win XP on Monday. Maybe it is issue of my win. 2000. Sometimes I have troubles with runnig java apps. as Processing or Arduino.

@jawi:
really too bad this software can't run on mac os x 10.5 which is not a so old operating system (even 10.4 ?)...
10.6 is "only" one year old and i dont think a logic analyzer REQUIRES a 64bit OS ...
also don't see what prevents you from making a 10.5 version ?
I already saw java softwares that runs perfectly from 10.3 to 10.6 ... ?
by the way nice work, cannot use it, but nice work.
regards,

kripton, u only need 32bit version of rxtx and the app should work on older osx

[quote author="kripton2035"]
really too bad this software can't run on mac os x 10.5 which is not a so old operating system (even 10.4 ?)...
10.6 is "only" one year old and i dont think a logic analyzer REQUIRES a 64bit OS ...
also don't see what prevents you from making a 10.5 version ?
I already saw java softwares that runs perfectly from 10.3 to 10.6 ... ?
by the way nice work, cannot use it, but nice work.
regards,
[/quote]

Well, as mentioned already by arhi, the only thing is that I do not (yet) supply a 32-bit version of the RXTX native library. I'll try to find one to include in the 0.9.1 release.
Another thing to keep in mind: my client requires Java6 (10.5 defaults with Java5, not sure whether there's a native 32-bit Java6 available yet). Though support for Java5 is requested some time ago, I currently do not intend to support it.

@jawi - I hope it wasn't presumptuous, but I started two new (sticky) threads for your client (no longer alternative :) ). This post is getting really long:

Jawi's Logic Sniffer client software - support and bug reports (http://http://dangerousprototypes.com/forum/index.php?topic=1196.0)
Jawi's Logic Sniffer client software - releases and requests (http://http://dangerousprototypes.com/forum/index.php?topic=1195.0)