reagarding this topic. Since the stream-function is not really inifinite against as streaming does suggest:
What would be the best possibilty to stream infinite 8 channels data with PICO (or 16 channels with 2 Pico) at very high sample frequencies > 16kHz ?
The blockmode suggest that between reading the blocks the may data loss ?
What is the exact requirement for your application?
You should be able to stream continuously at 16 kS/s with the driver. One alternative approach is to set the autoStop flag to false in the call to RunStreaming() and use a counter to keep track of the number of samples collected.
When the number of samples has been collected, you can stop the data collection. You would need to be managing the data collection in this instance to ensure that it is processed appropriately as it is returned from the driver.
the requiments are quite clear and I think described very well in this thread.
We want to have an "never ending" stream (that means days, weeks) of 8 channels each 16KS/s or may be more like 64KS/s and also for some reason stops after a specified time ... and as I wrote in a seperate thread with more than one PICO.
Both solutions you suggest are implemented. RunStream with autostop will stop because the 4GS Limit. Without autostop and using pre and max trigger parameters failes as described either with 4GS Limit and also some Values less the 4GS Limit.
The work around for using max streaming time is allready as suggested in usage by using the max Values and stop the streaming because the count of collected values is about the predefined timer setting (FS*t) per channel. But this will not run "never ending" as you allready wrote e.g. with 16KS/s only 4,6 hours as descibed in this thread below.
The best thing in this situation would be to set the autoStop flag to false and then use some code to control when you want to stop the data collection.
The arguments for the max pre- and post-trigger samples are used for when you want to retrieve data values from the driver post-capture.
thx for your advise.
This is the currently used solution, but I think it is limited by 4GS as you wrote in a former entry. Am I right?
So still not noverending?
If you set the autoStop flag to false and set the number of pre-trigger and post-trigger samples below the limit, it should be possible to collect data until you wish to stop.
[DllImport(_DRIVER_FILENAME, EntryPoint = "ps4000aRunStreaming")]
public static extern UInt32 RunStreaming(
short handle,
ref uint sampleInterval,
ReportedTimeUnits sampleIntervalTimeUnits,
uint maxPreTriggerSamples,
uint maxPostPreTriggerSamples,
short autoStop,
uint downSampleRatio,
DownSamplingMode downSamplingRatioMode,
uint overviewBufferSize);
If you do not need to retrieve the data from the driver post capture, then set maxPreTriggerSamples and maxPostTriggerSamples to values well below the limit and autoStop to 0.
When you then start streaming, make sure you are copying the data inside the callback/delegate function into application buffers and then process the data as required. At the same time, in your data collection loop use a variable e.g. totalSamples to keep track of the amount of data collected and stop when your totalSamples has reached or exceeded the number to collect. You can also use a boolean flag so that when you want to stop data collection, the flag is set.
thx for your advise. This what described in your last two post is quite clear. This is what I am not talking about.
Again:
1) using maxPreTriggerSamples and minPreTriggerSamples (with or without autostop = 0) has for some amounts the result that the PICO returns only "PICO_BUSY". Since I don't use this setting anymore and just keep track how much data PICO received, it is not necessary anymore (but have more comfort). This we can handle as solved
2) question about the total Limit regarding RunStreaming. Here I got different answers, some time confusing .
That why I ask again just yes/no question.
The total limit is to collect total data with 4GS @32-bit? Please confirm.
An 8GS Solution for 32-Bit is currently overhanded to your dev team? Please confirm.
I cannot get data as long I want (see my 24 hours example with 16Khz and 8 channels)? I did test this issue but PICO stopped sending data after the corresponding.
Please confirm that collecting data like the upper example without interruption is not possible since there are more than 11GS.
The total limit for the max pre-trigger samples and post-trigger samples is 2 GS (4 GB).
Development will not be looking into how to obtain 8 GB as this is not possible due to 32-bit address spacing so 64-bit drivers need to be used instead.
With regards to the last question, are you able to use 64-bit drivers or is your application only for a 32-bit system?
Both systems are 64-bit Systems. So it is possible to use 64-bit version as well. Currently I let control the OS which library it "will use" and there is normally the 32-bit version used.
But both Sytems are Windows 7 Environments (I remember some trouble around 64-bit with that systems).
But while using 64-Bit it does not solve the problem completely.
If we would be able to get 8GB (4GS), we might collect data than (16k, 8ch) for 9 hours only, instead 4,66 hours without interruption.
Again we have a limit. How to solve?
Is a solution possible having e.g. 2 seperate Streaming methods?
Lets say streaming s1 and streaming s2.
At 2pm I start s1.
Short time before I expect the "end of data" I start s2 with another delegate function than for s1.
and next short time before "end of data" I switch back to s1.
Does the PICO Driver allow either 2 seperate RunStreaming calls or calling GetStreamingLatestValues with different CallBack delegates with the idea to get on a 32-bit System more than 4,66 hours data with (16k, 8ch)?
Can I ask as to what tests you have carried out with the 64-bit drivers?
Unfortunately, it is not possible to call the function to start streaming data collection while another data collection session is running. You would need to stop data collection and then start the data collection again.
The normal method of collection would be to register a single callback function with the driver.
How many samples can you collect before you encounter an issue with the 64-bit drivers? What status codes do you get if any once you reach this number?
at 16k and 8 ch it should be possible to stream for a couple of day's
this is 128k word / sec = 256k byte / sec
this will be about 920 MB / hour, if you write the data to disk then you can keep this up for a couple of days.
You will only need to do the triggering in software on the incoming data (not using picosocpe trigger)
Even a Raspberry-PI can do this with an external HD connected to it.
Edit:
reading back the tread you already mentioned the streaming will always stop after 4GS, i always expected streaming to be infinitive.
In fact I have done this with the picoscope software many times at 5MS / sec then you have 4GS in about 800 sec.
Running now at single trigger which will never hit 2 s/div 5MS/s (100Ms whole screen)
Ok after 30 min I stopped it manually this was after 9GS of streaming data. pssettings of the test is attached.
thx for your feedback.
You are right I did also expect having infinite sampling using Streaming Mode.
Also I expected that I am able to use a "internal timer" - by using max and pre trigger in combination with autostop.
The answer I got in this forum and the experience I had is: data streaming is limited by 2GS (4GS) with respect to OS architecture. So after 4.66 h PICO doesn't send any data through the Driver to the PC, but it is still running and online.
Your example is right - by calculating, but writing to disk (what I do of course as well), has nothing to do with the internal memory usage inside the Pico hardware or the SDK Driver, I think. This belongs more to the limits of the used PC hardware surrounding. So this thread is not about HD space.
I do not understand your trigger solution and how this idea might solve my issue. Can you please explain it again?