Skip to main content ↑ ↓
Topic: Alternative Java client (Read 52410 times) previous topic - next topic

Re: Alternative Java client

Reply #135 –
[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

Re: Alternative Java client

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

Code: [Select]
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:

Code: [Select]
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.
when good software is not an alternative...

Re: Alternative Java client

Reply #137 –
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.

Re: Alternative Java client

Reply #138 –
[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?
when good software is not an alternative...

Re: Alternative Java client

Reply #139 –
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:

Re: Alternative Java client

Reply #140 –
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

Re: Alternative Java client

Reply #141 –
[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?
when good software is not an alternative...

Re: Alternative Java client

Reply #142 –
[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

Re: Alternative Java client

Reply #143 –
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.

Re: Alternative Java client

Reply #144 –
@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.
when good software is not an alternative...

Re: Alternative Java client

Reply #145 –
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.

Re: Alternative Java client

Reply #146 –
[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...
when good software is not an alternative...

Re: Alternative Java client

Reply #147 –
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!
Got a question? Please ask in the forum for the fastest answers.

Re: Alternative Java client

Reply #148 –
[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?
when good software is not an alternative...

Re: Alternative Java client

Reply #149 –
[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.