The measurements are performed by the PicoScope 6 software, post collection, using the Laptops processing power.
The most efficient way would be to use the VBA application to do the data collection from the driver, and then process the data as required.
I had a feeling that this was the case after playing with it.
I have written the software to do the same processing, but I have noticed a major difference. The speed at which my software makes the calculation is much slower. While I am streaming the data I am calculating. It takes about 23 seconds to calculate from the point where the scope triggers for a 10 second window. The PicoScope software finishes the calculation a second after the capture is complete, mine takes an extra 13 seconds. Do you think that this is due to the nature of VBA? Is the PicoScope software using less points to do a similar calculation? Is there anyway to export this value from the PicoScope software? (why re-invent the wheel)
I should also mention that I was playing with the buffer size on the scope and noticed a considerable speed difference when using the maximum vs a small chunk. My sample rate isn't any faster than 9.8MS/s. It should come out to 98MS for a 9.8 second window. I am setting this with about a 102ns between points. I figured that you wouldn't see any speed difference since it is just under the buffer size.
When reading the specifications that the scope has a 100MS buffer, it also says it can use the PC as a buffer. How do you do this? The code written for ps6000SetDataBuffer in the manual seems to only refer to the buffers on the channels. I tried declaring a variant in replacement of a channel buffer, but this seems to just crash VBA.
I would look at downsampling the data from the device as part of the data collection, that is what the PicoScope 6 software is doing. This helps to reduce the loading on the USB bus.
As you are sampling at low rates it would be possible to use streaming mode which will transfer data directly to the PC's memory rather than collecting to the device. Once you have all the data in the PC, you would then be able to perform the calculations without the need to download data from the device.
When you apply measurements, the software will call down a subset of the data from the device to perform the calculation. The amount of data will be appropriate for the measurement(s) you have requested and whether you are looking at the full window or a portion of it.
I have turned on averaging mode. My program keeps returning that the ratio is invalid. I have tried putting in several values into the downsample ratio. It keeps giving me the same error.
I was expecting that if you put in 4, every 4 points will be averaged.
I am able to stream with my program, but I fall behind 3.4 seconds for every 10 seconds of recording. There is no dataloss up until I reach 30 seconds. I don't know if this is because I am using VBA. I have an i7 chip in the laptop. I have set VBA to realtime processesing. There is only two codes in the loop. One to indicate where the sample index is and one doing math to convert the values to mV and then taking averaging the RMS value. Once it exits the loop it divides it by the total number of samples.
Would you be able to assist with this downsample ratio?
Then divide by the total number of samples and root once you exit the loop. When you set Applications.Calculation = xlCalculationManual it seems to go slightly faster as well. I seem to be able to get up to 20MS/s while calculating the true rms before the computer can no longer keep up. I am using a 32bit version of excel currentely, and will eventually get a 64bit verison.
I am now having a problem with the Picoscope sending back an error of: PICO_MEMORY_FAIL: - Not enough memory could be allocated on the host machine. This happens when I try to demand a lot of samples 600MSamples+. Is there a way to have it continually run forever until I tell it to stop?
There is plenty of memory available on the laptop. Is there a setting in excel that I have to set to demand more resources from the hardware? It seems to do this calculation before attempting to stream. Is there a way around this problem so that the Picoscope will at least make an attempt?
One more problem to solve from the previous post...
I have tried downsampling anyways to see how much vertical accuracy is lost. I have turned up the sample rate equal to the downsample rate. I have been playing with it to see the trade off between real time and vertical accuracy. I seem to hit a wall when I tried to turn the sample rate beyond 156MS/s. It seems to be programmed because of the USB3 limit. If I am downsampling, should I not be able to surpass the 156MS/s limit?
Is there a command to determine what sample rate has been chosen by the scope once you pass the channel parameters?
If I set the channel to 102ns I have noticed that I am closer to 102.4ns. I need to know that exact number so that I can determine the limit of real time measurements.
Transfer rates over USB can vary widely due to the real time utilization of the bus, and we have found that the fastest reliable transfer rate of PicoScope data over USB 3.00 is 156MS/s. For this reason the maximum streaming rate has been capped at that rate.
The exact sample interval used should be available in the location pointed to by *sampleInterval, when you exit the runStreaming() command, and will be in the units that you specified when executing the function (further details are in the Programmers Guide for your PicoScope).
Thank you. I didn't not realise that there was also a return from variable.
I am still stuck at 20MS/s while calculating the RMS with no dataloss. When I try to repaint any values in a window for the user to see (once in 2-3seconds), it takes away too much from the computer to keep up. I will just have to play with it to see what is optimum.
If you're calculating the values from the raw sample data, but only displaying RMS values every 2 or 3 seconds, then you would be better off letting the driver reduce the amount of calculations that need to be done, by downsampling in 'Average' mode, and then calculating the RMS values from the downsampled values. You can still collect and store the raw sample values if they're required for later calculations. You can get both downsampled, and raw data from the driver, because the call back function will place the full sample value data in one buffer, and the downsampled data in another. You just need to setup the buffers and provide their location to the callback function.