Skip to main content
Topic: Windows OLS Client (Read 12325 times) previous topic - next topic

Windows OLS Client

Here's a client for the sump protocol. Requires .net 3.5.
It still a bit rough, still working on it. I'll publish code when it's publishable.

Re: Windows OLS Client

Reply #1
The setup file attached in previous post is not working.Here is the correct one:

Edit : I removed the install package from here. See the new version later in the thread.

 

Re: Windows OLS Client

Reply #3
Is there a newer verison?  I tried the one on your post, and all I get is time outs.

Re: Windows OLS Client

Reply #4
make sure you are specifying the correct com port in the config tab.
Is it working in the Java Client?

Re: Windows OLS Client

Reply #5
The java client works most of the time for me.   I was just giving you feedback, I took it into work so I had it on a windoze box, normally I avoid those, unless someone is paying lots of money to do it.

Re: Windows OLS Client

Reply #6
I am surprised how fast you came up with the SUMP LA.net client (and a first documentation :) ... nice work! :)

Considering the problems some users have reported with their OLSs, it is encouraging to see a new application for the SUMP LA/OLS emerging only one month after the OLS started shipping!

The second installer worked well for me as did running some quick first trials with the OLS ... no problems with the communicaton between the SUMP LA.net client and the OLS (it should be noted that the Java client communicates with my OLSs without problems as well).

I will watch this project closely .... one first thing I noticed is that the SUMP LA.net client seems to display glitches at the very beginning of a capture that are actually not part of the captured data received from the OLS (see attached picture - the picture you posted seems to show some similar glitches at the beginning so they are not as obvious because zoom was off when you took the pic).

Re: Windows OLS Client

Reply #7
Great!

Still need some fixes and improvements.

1/ There is an invalid "return" trace (using demo)


2/ When we modify the window size, the displayed trace is not refreshed.
BTW we enlarge the window, not the trace.


3/ I think that the buffer size should be implemented with another step. May be a Listbox with only a few predefined values

4/ The push button (Noise Filter, RLE) should be implemented with a better color contrast between ON/OFF. Here it's more or less a Yellow in both cases

Congratulations.

Marc

Re: Windows OLS Client

Reply #8
Thanks all for the kind words, but no, I'm not superhuman: this was not done in one month. I had started  this project thinking I would use a PIC 32 to capture data about a year ago. When that did not work well enough, I shelved it until the OLS came out. Hmmm... Dusted it off and cleaned it up, implemented the sump protocol, and voila.

As for the bugs:
- I'll investigate the invalid trace return, it seems to happen sporadically.
-  Resizing the window does not resize the trace. The zoom control does. If you zoom so that not the whole trace is showing, you will see more of the trace when the window is resized, at the same zoom level.
- buffer size and button colors, i'll get that in the next release.

Thanks for the gracious feedback and enjoy!

Re: Windows OLS Client

Reply #9
you get a timeout if you select the wrong sample size
also, how do you select which channels to capture ? (needed for bitstreams other than the 32bit one)
the triggers dont seem to work either
i am using the 8 bit 16k bitstream inside
everything works fine using the java client

Re: Windows OLS Client

Reply #10
rajkosto,
I'm using the default set-up as it came from seeed. I'll try the 8 bit stream to see what the problem is. I think there is no way in the protocol to tell what bitstream is loaded...
As for the triggers, it might be that because you are using 8 bits , the bit numbering is off. I'll check into that too.
Thanks.

Re: Windows OLS Client

Reply #11
Unfortunately the 8bit and 16bit bitstreams are out and being used bei some OLS users. Unfortunately, because there is no (direct) support for them in the SUMP protocol nor in the Java client yet ... and most of all because the VHDL code needs some fixing to make the UART interface work stable on all OLS boards - yes, some work just fine but others don't due to normal tolerances in the FPGA manufacturing process (the FPGA chips on the OLS boards shipped by Seeed are all ok and within the manufacturers specification but some encounter timing issues when running the bitstreams from the current VHDL code). First the (UART/PIC-FPGA interface part of the) VHDL code for the standard 32bit bitstream will be addressed and fixed then we will have to decide if we want to extend the SUMP protocol to provide direct support for bitstreams with different channel width/buffer depth or fix the UART part for the alternative bitstreams. At this point it is the responsibility of the user to select proper capture parameters in the client in particular if they are using alternative bitstreams.

@raphihouri: you are right, the current protocol has no option/command to find out what bitstream is loaded/used. Eventually, there will be extensions to the protocol but that's a bit down the road.

Re: Windows OLS Client

Reply #12
yes i use the 8bit one just fine with java
yes i know everything has to be set manually in order for the capture to be correct
i just complained that there was no way to choose what bitstream you are running in this .net client
i cannot wait for unified bitstreams/SPI comms as those would be much faster
also fixing rle mode to work with all capture lengths would be nice as well, and also the option to choose internal/wing port before capturing

Re: Windows OLS Client

Reply #13
Here's a new version incorporating some of the suggestions on this thread.

Fixed:
    - glitches at the begining of trace.
    - invalid trace returns in demo mode.
    - window resizing stretches the trace.
    - channel and trigger numbering and mapping.(rajkosto, you may want to try the 8bit bitstream again)
Added/changed:
    - Buffer size is now a combo box with choices configurable.
    - Improved contrast on some buttons.
    - Serial port time outs are now configurable.
    - trace color and background are now configurable.

Waiting for feedback.
Thanks.

Re: Windows OLS Client

Reply #14
It's not working on my computer.


The Buffer-Size-Field is empty.

The Clock-Field too, but you can choose an entry.


By pressing RUN, there comes a messagebox :


"Der Objektverweis wurde nicht auf einer Objektinstanz festgelegt"



Maschine translation:

"Object reference not set to an object instance"