So,... buffer... It should be 250M samples.
I've been wondering the moment, before next screen will be updated to a PC's screen. And... how do I see the data, captured during this "moment"?
In the attached pic is a CAN signal.
5th screen is visible on a main screen, 6th screen in a small thumbnail.
As can be seen, 6th is empty????
Where is the data between screens 5 & 6?
How do internal buffer capture samples?
Am I missing some setting, but it looks like it captures a screen, then there's a break, after a couple of seconds, next screen will appear.
But data between screens is lost??
Well... I tried to attach a screenshot, but maybe I don't have a permission to attach files...
So...no pic.
Hit 1st preview. I guess data files also needed.
I am super curious about this one as it is claimed there isn’t a pico gap and its just a fanatsy:
Quote:
We don't usually post PicoScope tips and techniques on the public boards like this but, in this case, it seemed appropriate to post it here in this discussion. Seems the 'Pico Gap' fantasy has a life of it's own even though it has no basis in reality.
We just thought that this would serve as another 'Myth Buster' for those that seek the truth. Wink
It's good that Matt and others are sharing this tip as well. Since Matt Started his PicoScope journey with Autonerdz, he has sure come a long way. Smiley
There are plenty more great tips and techniques available to Autonerdz Picogroup members. Since we introduced PicoScope to the automotive industry in North America, we have grown the largest and greatest PicoScope automotive user's group in the world.
Not sure what the AN post was about (perhaps there is a bit of the post missing?) but there is a "Pico Gap" ie data missing on screen refresh - I am not sure if that is only when in 200m/s + but that is where it is most noticeable. Though I see you are sampling at 1ms so I guess it still happens at the shorter time frames too.
The way around it is to set the trigger at the far end so it never triggers.
This demonstration might help:
The video above is a real nice work around for ensuring all data is captured along with this forum post that also highlights how to capture a stall when the vehicle is unattended (i.e., hands-free operation with no missing data) viewtopic.php?p=90671#p90671
Coming back to the initial post in this thread, I can see you are measuring and decoding a CAN network and data could be missing between buffers unless we configure the scope to suit our application.
If decoding CAN data is the sole purpose of the scope application (i.e., there are no errors or interference from other sources we need to capture) then a CAN data logger would be better suited for seamless logging
If, however you suspect the physical layer is the reason for multiple CAN errors then tigering on CAN might be a better option as Ben has described here: viewtopic.php?p=90601#p90601
It maybe you suspect CAN interference from an outside source is the reason for CAN errors, in which case we have 2 other channels we can utilize to simultaneously monitor (or trigger upon) to ensure we capture all offending events
We have used this technique over a slower time frame here to monitor the operation of the “Park switch” topic21680.html
Combining both PicoScope and Logger data is an incredibly powerful “means to an end” giving you the best of both worlds as we have here topic22669.html
All in all, we have numerous options to limit or prevent any data loss between buffers depending on what suits your current application
That was a good explanation for CAN decoding, but... my intention was not to focus on CAN. It happened to be a good example of a capture, where wave does not continue from the same spot, it ends on previous screen.
Let's make this simple (for a simple user...).
Here's a capture of sine wave.
As seen, wave has no continuity.
My understanding, and the way I thought, this fast sample memory works, is that it will capture first 250M samples and when there's more samples than that, the oldest will be overwritten?
Now there's 3 screens of sine wave.
1st screen ends "up", second continues from "down"?
2nd ends and 3rd starts, both "up"??
This should be quite common, simple measurement.
I've selected sample rate, 8Ms/s. (Why there's 7.14 ?)
(Now, when amount of samples is fixed, I'd like to see somewhere possible amount of sceens with this sample rate. Or converted to a time, based on the s/div setting.)
According to amount of sceens (3), there should be a total of 150ms captures?
Obviously, something is missing from between sceens?
Is it just the part which is not visible or even more?
Now the simple part (for a simple user).
How do I set this program in a way I will see a complete sine wave, which continues from screen to another?
The video that picowight linked to, "Big thanks to Brian Mann for posting this " explains perfectly how to avoid the pico gap that seems to be troubling you.
My personal experience is that the gap is only there, if you make it there by your settings.
Make good choices around what you are measuring, what you expect to see and how best to achieve the optimal result. All variable depending on the testing you are undertaking and with regard to sample rate and file size.
Picokev
"My personal experience is that the gap is only there, if you make it there by your settings."
Internal fast sample memory should be an issue, which should be "hardcoded/built".
No matter, what user selects, 250M memory should be continuous, which should capture data between screen change. When capturing data without trigger.
Pico library doesn't tell much bout this...
Picowight video??
"The way around it is to set the trigger at the far end so it never triggers."
When trigger is not preset, gaps shoudn't be present??
The video that picowight linked to, "Big thanks to Brian Mann for posting this " explains perfectly how to avoid the pico gap that seems to be troubling you.
I was refering to the YT video from Brian Mann contained in picowight's post.
Picoscope has worked in this was ever since I have been using it (and believe me that is a long time! ACD212 anyone ) perhaps there is an automotive scope that works how you want it (Snap On does not by the way, it does exactly what Brian demonstrated except with a less capable scope and less samples). If it is out there please share! I for one would be intrigued.
Have a look on the autonerdz site, Tom Roberts did a number of studies around the pico gap, some good reading there.