Protocol analyzer in v4.633

Protocol analyzer in v4.633, a forum discussion on Cleverscope. Join us for more discussions on Protocol analyzer in v4.633 on our Questions forum.

Back to Forum Index : Back to Questions   RSS

28 Dec 2008
Posts: 22

I used the protocol analyzer with v4.631 a lot, the last three weeks.

Your Christmas release v4.633 unfortunately left my old CS328 (without A)
Scope (downgraded to v5330 because of missing trigger 2 functionality)
without the possibilty of further I2C debugging:

The extra protocol line disappears right at the moment a valid protocol
is recognized.
If the scope is running in auto mode (or you are triggering on another
event, which does not contain a valid protocol) the line comes back and
disappears as soon as some (valid) protocol shows up.

Another point:
What was the reason for you to exclude v5331 from the v4.633 release?
The missing trigger 2 functionality? Is there anything else ""I should"" know?
(means: Anything else, that is not working?)

As a non-A scope user, what are my prospects regarding future development?
Will the old, non-A units drop off somewhen?
What are my options, then? Is it possible to exchange a non-A unit for a newer one?

And a last one:
Is it possible to link a ""A"" and a non-A unit?
What happens if your ""A"" scope has more resolution or memory?
What happens to the function generators, if available?


""The Log"" still works ;-)

29 Dec 2008
Posts: 73

Hi Axel,
Glad you have been enjoying the protocol analyser. We were pushed to get the new release out before Christmas and now the development team is on holiday until mid-January. I can only suggest you roll back until we can revew the issues.

As you can understand, our focus was to get the software working with the latest hardware and we have done little testing yet with the ""classic"" 328. We will get back onto bringing it up to date but some time in 2009 it will run out of internal logic elements to do what the newer units can do. When the versions diverge we will consider options for owners of the older hardware.

Of course the option for ethernet is only available in the later version!

Until we are confident of the firmware we will only offer the last known stable version in our updates.

You are able to link two diferent units together - either using two seperate instances of the software or the four channel software - which is now some distance behind the current release in functionality. An ""A"" version will use as much memory and sampling as it has available. Any channel can be used for triggering and if signal generators are fitted they function as usual.

Have a great New Year.
Roger Carter

12 Feb 2009
Posts: 395

An update - the problem with the protocol dissapearing just as it was decoded is not a CS328 specific problem, and has now been fixed. It was a problem with a faulty over sampling rate finding algorithm. It should work fine with the Cs328.
We didn't include 5331 because of the missing trigger 2 problem. We will be bring out new software for the Cs328 to bring it back into line. But as Roger says, the FPGA is full, and so the scope for further logicware improvements is limited.

13 Feb 2009
Posts: 22

Thank you very much for your explanations, Bart.

Unfortunately, the behaviour is exactly like before:

- As usual, I copied over the new files
- I started cleverscope app. and - with I2C analyzer turned on, performed
some acquisitions.
=> Yes! The I2C line showed up and everything seemed to work fine.
- I stopped the acquisition for about 3-4 minutes while working on some source code.
- Turned back on, the line disappeared as soon as a valid I2C protocol was showing up.

I tried almost everything:
- deleted ini and prf files
- copied the new files over again
- turned off and on cleverscope hardware as well as software
- plugged out and in the USB cable
I tested almost any of the above in any possible combination.
No go. I was not able to make it run again.

Do you have any further suggestions?


13 Feb 2009
Posts: 395

We will investigate further, and see what the problem is. Could you possible do a save as, and send us the resulting .apc file by email, to support@.. Thanks

2 Apr 2009
Posts: 395

Hello Axel,
Well we found and fixed the problem, but we then mucked around with the application for quite some time improving triggering, text files, logging and such, and so it has been a long time before we have released a new update, which we have now done. The update includes a new firmware file (now with the suffix .csf) for the CS328. The classic CS328 peak detect function was not working properly and putting an extra pulse on every trailing edge of a square wave. You could not see this with the application (unless you used Lock result). This wrecks the protocol decoder. We believe it is no fixed. Sorry about the very long delay, it became quite hard to fit the most recent version of logicware into the Classic CS328 FPGA (it's full!) Happily the CS328A still has lot's of room.

4 Apr 2009
Posts: 22

Hello Bart,

thank you very much for your investigations on this!

Good news first:
- protocol analyser is working again
- trigger 2 functionality is back

Actually, I am perfectly satisfied with good old non-A-CS328 functionalities.
At least I have got more now, compared to the time I once bought it =)

Here for the bad news, which somehow makes v5332 almost unusable:

The whole application runs on <1fps (compared to ~20 with v5330).
It feels like having a full-speed (or even low-speed ;-) connection to the FTDI
(But could of course be anything else. May be the protocol analyser is busy
all the time, even if turned off?).

All operations/functionality is completely blocked (e.g.: display, trigger, logging, ...).
Downgrading to v5330 fixes the problem immediately.

Best way to check:
Time for downloading full buffer (2 frames, largest timescale to maintain 10ns sampling time):

v5330: ~5s
v5332: ~50s(!)

The last challenge, Bart!


4 Apr 2009
Posts: 395

Hello Axel,
Ok, we can see what you are saying about the CS328. We found the fault with the CS328 firmware. It was our own stupidity (often the case!) - the build was done without optimization, and the debug environment on, which slows things down a great deal. We have put a new version on the website. So now you have your triggers back, it runs at normal speeds, and it supports trigger time stamping.

Another point:

If the protocol setup window has any protocols set to 'ON' the decoder will run. So even if the window is closed, the decoder still goes. Maybe we should have a global decoder on/off button. What do you think?
Now if the decoder is on, it dynamically varies the number of samples returned to get a good sample interval to reliably decode the protocol. For example, with SPI, we want 5 samples per clock pulse. If it can find nothing to decode, it assumes it is sampling too slowly, and so it reduces the sample time interval, which increases the number of samples transferred. There is a limit to this - it goes to 65K samples maximum. For the USB 2.0 solution (CS328A) which transfers at 18 Mbyte/sec effective, this takes 65k x 4 / 18M = 14 ms. So you don't really notice it. With the CS328 which transfers at about 400 kbyte/sec effective it takes 0.65 secs. You really notice it. You can see the number of samples transferred in the N Display value on the control panel. If this is anything more than 10k, the decoder is on, and things will be slower also. We will probably set two limits on the maximum number of samples - one for the CS328 and one for the CS328A.

We will keep you posted.

regards, Bart

6 Apr 2009
Posts: 22

Oh yes, that looks and feels a lot better, thanks!

But what is the reason for this:
(Unfortunately, I have no older ""new-flash-filetype"" binaries than v5330
Is it still save to use the old flasher (with old files, of course) to program it?).

(Protocol decoder turned off)

N Display ~3200:
v5330: 13fps
v5333: 6fps

N Display ~8300 (my normal setting):
v5330: 6fps
v5333: 3fps

I could swear it was much faster in the past, or am I wrong?


How does an A-unit compete, here?
Maybe I would upgrade...

6 Apr 2009
Posts: 395

Hello Axel,
I think we are being hasty. We will check out the reduction you are seeing (though it looked ok here). Anyway, the trigger light is a very accurate indicator of frame rate, and we shall measure it! With an average size screen we would expect 12 fps.

Yes, you can still use the older binary Rom Loader to load CS328's. NOTE other people: you cannot do this with the CS328A, as the firmware in the USB module has also changed.

The CS328A runs at 20 fps pretty much independant of width and how many windows you have open. It does slow down if you have lot's of Maths + Spectrum running.

20 May 2009
Posts: 395

Hello Axel,
Just an update. We found the cause of the slow response on the CS328 Classic, and have fixed it. The latest update on the web includes cscope_fw5334.csf which loads with Rom Loader 5.1 into a CS328. Some numbers for you:
v5326 - USB throughput 3.6 Mbit/sec
v5330 - USB throughput 1.1 Mbit/sec
v5334 - USB throughput 5.4 Mbit/sec

(Just for comparison:
v6437 USB2.0 Throughput 144 Mbit/sec
v6432 Ethernet throughput 40 Mbit/sec)

Another note - we have the CS328 setup for 12 Frame/sec, and the CS328A setup for 20 frame/sec.

I hope this helps.

21 May 2009
Posts: 22

Hello Bart,

beyond doubt, another grand release!
Indeed, it is much faster now.

Great, great, great...

Back to Forum Index : Back to Questions   RSS
You must be logged in to post a reply

You need to Register or Log In before posting on these forums.


Your shopping cart is empty.