No triggering at slow display speeds

I have a bunch of I2C data that I'm capturing with the digital inputs on my CleverScope. I'm using app version 4.624. When I have the display set to 10ms per div, the triggering works great and I see all of the individual bits on the screen. But my I2C data goes on for about 20 seconds, then off for about 10, the on again. I need to time that large block of data. As I slowly decrease the 'horizontal sweep' rate to about 100ms/div, I still get triggers but they come very slowly. When I zoom out one more time to 1s/div, I never, ever get a trigger. All I did was zoom out one more step! I let the thing sit all night thinking that maybe it just takes a long time to acquire. But it never triggers - no new information is ever displayed on the screen.

Help! How can one see things on the CleverScope that take seconds to happen? I've tried this on all three trigger modes (Triggered, Auto, and Single) and get exactly the same result. When on 'triggered' mode, I've tried using the digital pattern as the trigger source, and also Channel A (clipped onto the I2C clock line). Same results.

Thanks-

*Brian

I have a bunch of I2C data that I'm capturing with the digital inputs on my CleverScope. I'm using app version 4.624. When I have the display set to 10ms per div, the triggering works great and I see all of the individual bits on the screen. But my I2C data goes on for about 20 seconds, then off for about 10, the on again. I need to time that large block of data. As I slowly decrease the 'horizontal sweep' rate to about 100ms/div, I still get triggers but they come very slowly. When I zoom out one more time to 1s/div, I never, ever get a trigger. All I did was zoom out one more step! I let the thing sit all night thinking that maybe it just takes a long time to acquire. But it never triggers - no new information is ever displayed on the screen. Help! How can one see things on the CleverScope that take seconds to happen? I've tried this on all three trigger modes (Triggered, Auto, and Single) and get exactly the same result. When on 'triggered' mode, I've tried using the digital pattern as the trigger source, and also Channel A (clipped onto the I2C clock line). Same results. Thanks- *Brian

This is a new one - we will check it out. Sorry about the delay in looking.

This is a new one - we will check it out. Sorry about the delay in looking.

Bart,

Any progress on reproducing this problem or figuring out why it happens?

Thanks-

*Brian

Bart, Any progress on reproducing this problem or figuring out why it happens? Thanks- *Brian

Hello Brian,
Ok, we have figured out the fault here. If the screen is wider than 10ns * 2**31 = 21.4 seconds, you get the fault. It's because we used a signed integer in one part of the decimation process, when we should have used an unsigned 32. However, even with fixing the u32, we have the limitation of 42 seconds. So we have done that for the next build, but are thinking of ways of doing it so there is no limitation, and you can just choose what you want.

Hello Brian, Ok, we have figured out the fault here. If the screen is wider than 10ns * 2**31 = 21.4 seconds, you get the fault. It's because we used a signed integer in one part of the decimation process, when we should have used an unsigned 32. However, even with fixing the u32, we have the limitation of 42 seconds. So we have done that for the next build, but are thinking of ways of doing it so there is no limitation, and you can just choose what you want.

Thanks! Is just going to an unsigned long long (i.e. 64 bits) not an option?

Also, what software version would this fix be in? I always have a hard time finding out what's changed in which software versions. Is there any documentation published about that? (i.e. release notes - fixed bugs, new features, etc. for each new version?)

Thanks-

*Brian

Thanks! Is just going to an unsigned long long (i.e. 64 bits) not an option? Also, what software version would this fix be in? I always have a hard time finding out what's changed in which software versions. Is there any documentation published about that? (i.e. release notes - fixed bugs, new features, etc. for each new version?) Thanks- *Brian

Hello Brian, we fixed the intermediate step (I32-> U32) in 6427. There is a list of features that have been added - if you go to the home page, and find the Software Releases section, and click on 'Click for more', you will see the history.

Going to U64 is not so easy, because it impacts onto large chunks of our FPGA design (all the high speed design is done with logic ware - and all of it is controlled via a 32 bit bus, with lot's of 32 bit counters all over the place). We have been instead thinking that the timing system should work at the decimated sample rate instead. This will happen, but it won't be overnight.

Hello Brian, we fixed the intermediate step (I32-> U32) in 6427. There is a list of features that have been added - if you go to the home page, and find the Software Releases section, and click on 'Click for more', you will see the history. Going to U64 is not so easy, because it impacts onto large chunks of our FPGA design (all the high speed design is done with logic ware - and all of it is controlled via a 32 bit bus, with lot's of 32 bit counters all over the place). We have been instead thinking that the timing system should work at the decimated sample rate instead. This will happen, but it won't be overnight.

Bart,

Thanks for the information - I believe you meant 4.627, right? However, I don't see this change listed in the things that changed in that version (as you said, clicking on the Click for more... under Software Releases).

Another easy suggestion - it would be really nice to have dates along with the version numbers on that Software Releases page.

One thing I noticed is a display bug - if you set your window to show -40 to +40 seconds, then make the window really narrow (as narrow as it can be) the timescale jumps to something like -100ms to +100ms, but when I drag the window back to its normal size, it doesn't go back to -40 to +40. Maybe this isn't a bug per se, but it is difficult to set your window width to 2 main divisions and then make it represent -40 to +40 seconds because there is not enough room to show things clearly. So my intuition says to set it to -40 to +40 as a large window, then narrow the window down and it will stay -40 to +40, but that's not how it works.

Anyway, I understand about the FPGA thing - I would be really cool if you could work out a way to have the decimated values go up to the PC for these long-timescale type measurements. It would be really nice to be able to have relatively slow sampling, but just continuously stream to the PC (strip chart recorder mode basically) with no gaps between frames. Or at the very least, have the ability to do very slow sampling of a single frame (let's say 600 seconds worth) and then upload that to the PC.

*Brian

Bart, Thanks for the information - I believe you meant 4.627, right? However, I don't see this change listed in the things that changed in that version (as you said, clicking on the Click for more... under Software Releases). Another easy suggestion - it would be really nice to have dates along with the version numbers on that Software Releases page. One thing I noticed is a display bug - if you set your window to show -40 to +40 seconds, then make the window really narrow (as narrow as it can be) the timescale jumps to something like -100ms to +100ms, but when I drag the window back to its normal size, it doesn't go back to -40 to +40. Maybe this isn't a bug per se, but it is difficult to set your window width to 2 main divisions and then make it represent -40 to +40 seconds because there is not enough room to show things clearly. So my intuition says to set it to -40 to +40 as a large window, then narrow the window down and it will stay -40 to +40, but that's not how it works. Anyway, I understand about the FPGA thing - I would be really cool if you could work out a way to have the decimated values go up to the PC for these long-timescale type measurements. It would be really nice to be able to have relatively slow sampling, but just continuously stream to the PC (strip chart recorder mode basically) with no gaps between frames. Or at the very least, have the ability to do very slow sampling of a single frame (let's say 600 seconds worth) and then upload that to the PC. *Brian

Hi Brian,
Thanks for the suggestions. Yes we will put date in the update. And yes, if there is a bug fix, we will add it. Yes it was 6427.
The easiest way to set the windows at -40 to +40 is just to overtype the left and right axis labels with -40 and +40.

The current plan is to finish protocol (SPI and UART are done, just doing I2C), and then get onto scrolling graph, and streaming save. But we also have to fit multi-language support in there somewhere!

The plan for the scrolling graph is that the graph display rotates fairly slowly (100ms duration up to a day or more duration), and that anytime you want, you can zoom into the samples at whatever point you want with the tracking graph, up to the limit of the buffer. Naturally if you stop the capture you can zoom in after the fact.

The plan with the streaming graph is to have samples come at the PC at whatever rate it can handle (up to 5MSPS), save to disk, and decimate on the fly for the display, in the PC. That's probably step 1, and helps a bunch of people. Step 2 is to make a viewer that allows the user to see the streaming samples saved in this way, in a timely manner. This is a harder ask, but we have a plan. The file size will be up to 2 GS.

In doing these steps, we hope to do what you want!

regards, Bart

Hi Brian, Thanks for the suggestions. Yes we will put date in the update. And yes, if there is a bug fix, we will add it. Yes it was 6427. The easiest way to set the windows at -40 to +40 is just to overtype the left and right axis labels with -40 and +40. The current plan is to finish protocol (SPI and UART are done, just doing I2C), and then get onto scrolling graph, and streaming save. But we also have to fit multi-language support in there somewhere! The plan for the scrolling graph is that the graph display rotates fairly slowly (100ms duration up to a day or more duration), and that anytime you want, you can zoom into the samples at whatever point you want with the tracking graph, up to the limit of the buffer. Naturally if you stop the capture you can zoom in after the fact. The plan with the streaming graph is to have samples come at the PC at whatever rate it can handle (up to 5MSPS), save to disk, and decimate on the fly for the display, in the PC. That's probably step 1, and helps a bunch of people. Step 2 is to make a viewer that allows the user to see the streaming samples saved in this way, in a timely manner. This is a harder ask, but we have a plan. The file size will be up to 2 GS. In doing these steps, we hope to do what you want! regards, Bart

Bart,

That's absolutely awesome. The functionality (both 1) and 2), but even just 1)) would be very useful. I understand about schedules - I'm a developer too.

Keep up the great work-

*Brian

Bart, That's absolutely awesome. The functionality (both 1) and 2), but even just 1)) would be very useful. I understand about schedules - I'm a developer too. Keep up the great work- *Brian