Gap in continuous data

Forum for discussing PicoScope version 6 (non-automotive version)
Post Reply
Hugo
Newbie
Posts: 0
Joined: Tue Dec 01, 2009 4:53 pm

Gap in continuous data

Post by Hugo »

I use my pico scope 2203 to check the position of a sensor signal (ChA) in relation to a reading window (ChB).
The idea was to collect the data in continuous streaming mode while the machine is running (time base = 1sec/div).
At the end of a test sequence it should be possible to analyze the stored data.
This is not possible, because between the sampled pages is a time gap.
Is there a possibility to make the continuous stream continuous ?

PeterF
Advanced User
Advanced User
Posts: 435
Joined: Thu Jun 07, 2007 10:53 am
Location: Cambridgeshire

Re: Gap in continuous data

Post by PeterF »

Hi,
In Streaming mode the limitation is in Picoscope6 which limits the maximum number of samples per screen to 2MS. The input signal does not use the Scope buffer memory at all, the data is sent directly over the USB connection into the PC buffer memory (RAM). The downside of using a large (2MS) screen size is that it takes just over 1 second to transfer to PC RAM, thus there is that gap in the recorded data.
All data, in both block mode & streaming mode is saved to PC RAM only during recording and can only be saved to Hard Drive after recording has stopped. If you wrote your own application using our software development kit just to capture at 1MS/s you would be able to stream continuously.
Please contact again if you need more information.
Regards,
PeterF.

matt

Re: Gap in continuous data

Post by matt »

Hi,

I am interested in doing something similar to this.

Could you post info about your SDK?

Thanks

Robin
Advanced User
Advanced User
Posts: 558
Joined: Fri Sep 19, 2008 10:17 am

Re: Gap in continuous data

Post by Robin »

Hi

The SDK can be downloaded via http://www.picotech.com/software.html

The programmer's guide is available here: http://www.picotech.com/document/pdf/ps2000pg.en-3.pdf

HTH

Robin

Daniel S

Re: Gap in continuous data

Post by Daniel S »

Hi,
I have a similar issue. I need a measurement (Voltage over time) about ~ 10 seconds with 200ms/Div. That measn I have 5 pages or more. When I check the measurement in detail then the graph starts on page 2 not at the same value where it ends on page 1. Some data were lost between the pages. According to the hint above I have changed the sample rate to different lower values, but the datas will not be recorded continuously. The only possibilty for me is to adjust the time/div setting, but then the graph is too much compressed.
Is it feasible to solve this issue?

best regards

Daniel

atomlcp
Newbie
Posts: 0
Joined: Fri May 11, 2012 9:04 am

Re: Gap in continuous data

Post by atomlcp »

I notice the same issue when i try to track a continuous 5 second signal with my PICO2208.

I try to use low sampling rate but seem the problem does not solve.

If I cant have a continuos screen of the signal,what for I buy this the USB scope?

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Gap in continuous data

Post by Martyn »

If you set CollectionTime to 500ms/div, enable a repeat trigger, set the pre trigger to 100%, and move the trigger so that it never fires you will get a continuous 5s scrolling display.
Martyn
Technical Support Manager

kschwant
Newbie
Posts: 0
Joined: Fri Sep 28, 2012 2:13 pm

Re: Gap in continuous data

Post by kschwant »

Regarding the continuous data issue: I have noted the same issue when capturing start-up surge characteristics (E/I) of devices, where data is lost between 'screens".

Yes you can use a longer time base to capture the event in one screen, but that can loose some granularity even with the later expansion of the detail on the screen.

It is great to have a PC based oscilloscope with traditional look and feel but Pico might considered loosing some of this look and feel to something more like a chart recorder. Ideally the captured data when you hit start, should be contiguous in time and 'space' until you hit stop. This should work with any time base and triggering. I'd suggest offering the ability to 'chop' up the buffer into screens or leave it all as a complete record.

Marty mentioned in this thread a possible solution to one post on this topic, but I'm not clear how and why this solves the issue.
-The customer says he has the time base a 5 Sec/div yet the solution is to set it for 500 ms.
-The time base on the bottom of each screen resets to zero on the left for each screen when viewing the buffer, it should pick up the time from the last screen if contiguous.
-why should the trigger have anything to do with triggering?

This would make an already invaluable tool the ultimate.

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Gap in continuous data

Post by Martyn »

The previous poster was talking about a 5 second continuous signal which is why I suggested 500ms/div, with 10 divisions across the screen, as a possible solution.

We have many requests for additional features in the software and we have to balance these against our development resources. Your suggestions are already on the wish list although there are no immediate plans to add this functionality. We do provide an SDK that would allow someone to write software that matches there own unique needs.
Martyn
Technical Support Manager

Bob Mehew
User
User
Posts: 6
Joined: Tue Jun 16, 2009 10:07 am
Location: Southport

Re: Gap in continuous data

Post by Bob Mehew »

Having also found this phenomena and identified a work around, one additional minor point still irritates me. The Properties pane shows summary data in use including a value for the number of samples per waveform. Tests with a 4424 and a 4224 and several software versions (6.6 & 6.7) show that the actual number of samples recorded and downloaded into a csv file for the waveform is always 4 more than the reported value. Can one have confidence in the rest of the data in the Properties pane being precisely accurate?

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Gap in continuous data

Post by Martyn »

The Picoscope software always captures a few extra samples so that it can draw the screen capture accurately regardless of the size of the display window. All the parameters reported in the properties pane are accurate.
Martyn
Technical Support Manager

stevenvh
Newbie
Posts: 0
Joined: Mon Feb 09, 2015 3:02 pm

Re: Gap in continuous data

Post by stevenvh »

I'm not very happy with PeterF's (PicoTech) "solution":
If you wrote your own application using our software development kit just to capture at 1MS/s you would be able to stream continuously.
I spent a lot of good money on my 3200D MSO, I would expect it's your job to take care of features, not mine. Overmore, I'm not a software engineer, while your developers are.

Gaps in the data for different screens don't seem too bad if each screen will have its own trigger, but there's an application where the gaps do matter: untriggered mode, where you want the longest stream of uninterrupted data possible (think data logger).
This is a legitimate use for a scope, and it would be a great feature. Until this happens, I suggest you change the "buffer: 128 MS" in the features list to "buffer: 128 MS total, non-continuous".

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Gap in continuous data

Post by Martyn »

Currently the longest single data capture is just over 13hours, 5000s/div.

We are looking at increasing some of the performance limits in the software, possibly through a user option, to reflect the increased capabilities of modern PC's, and the increasing use of USB3 in our devices. These limits were in place to allow the software to work on low level PC's such as Netbooks, so some optional limit may still be required.
Martyn
Technical Support Manager

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Gap in continuous data

Post by Mark_O »

Martyn,
We are looking at increasing some of the performance limits in the software, possibly through a user option, to reflect the increased capabilities of modern PC's, and the increasing use of USB3 in our devices.
That would be very wise, and much appreciated.
These limits were in place to allow the software to work on low level PC's such as Netbooks, so some optional limit may still be required.
It is understandable to impose limits on lower speed devices, such as Netbooks. However, limiting ALL computers down to that lowest common denominator really makes no sense at all. When you do that, essentially you eliminate the benefit of having anything beyond a Netbook.

Post Reply