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 ?
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.
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?
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.
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.
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.
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?
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.
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".
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.
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.