Buffer Count stops at 331 ...

Ask any questions about using PicoScope Automotive software here.

Buffer Count stops at 331 ...

Postby FioranoCars » Mon Oct 17, 2016 3:15 pm

Hi
When doing CAN-BUS captures using your template file (automotive menu), the buffers stop at 331 ?!
Our preferences are set to 9999

The file is huge, so can't upload easily (180mb)

If we change the time base to larger (ie more time on the screen), without changing the sample rates etc, then we get more buffers directly proportional to the time change?

Unless the sample rates are changing with the time settings, then surely this is reverse if ti was a file saize / memory limit?

Using current Release version.

Thoughts, and education lesson? :oops:

Thanks
Richard
User avatar
FioranoCars
TwoWaves
TwoWaves
 
Posts: 377
Joined: Thu Dec 13, 2012 1:26 pm
Location: London, UK

Re: Buffer Count stops at 331 ...

Postby Alan » Mon Oct 17, 2016 6:19 pm

Its all related to the memory settings. Your PicoScope 4425 has a 250 million sample memory as such you could capture 250 buffers each of 1 million samples or 125 each of 2 million etc. Lets for this example use the max memory set to 2.5 million samples to give a maximum of 100 buffers.

Where things get a little more complicated is capturing time periods that are too short for the scope to capture the full 2.5 million samples used in this example. Under these conditions you can end up with >100 buffers - take for example a timebase that only has enough time to collect 100,000 samples - its now possible to have 2500 buffers.

If you set the max no of buffers to 9999 then at the shortest timebases you will get lots of buffers, as you go to longer times it will drop. If you right click and show properties then you can see the number of samples captured - remember this is per channel.

\does that make it more of less clear - not sure I explained it very well!
Alan
Pico Staff Member
Pico Staff Member
 
Posts: 251
Joined: Thu May 25, 2006 10:02 am

Re: Buffer Count stops at 331 ...

Postby FioranoCars » Mon Oct 17, 2016 6:26 pm

No you explained perfectly, as I'd expect it to work ... what we had was the reverse, the longer the time base for any given capture rate, the more buffers we could collect!

Maybe I'll need to re-do the tests, but I was not going mad. It all started from using the CAN-BUS template, so should be easy to reproduce ... if you can't get the same effect as us, then I'll redo the tests we did and try to save the files and dropbox them over to you?

Thanks
Richard
User avatar
FioranoCars
TwoWaves
TwoWaves
 
Posts: 377
Joined: Thu Dec 13, 2012 1:26 pm
Location: London, UK

Re: Buffer Count stops at 331 ...

Postby Alan » Tue Oct 18, 2016 7:19 am

Hi Richard,

Please can you load your (180M) file into PicoScope then use file / save as to save a settings file (.pssettings) which will have the settings you used but not the data so should be very small to upload.

We can then have a look at what is happening.

Regards
Alan
Alan
Pico Staff Member
Pico Staff Member
 
Posts: 251
Joined: Thu May 25, 2006 10:02 am

Re: Buffer Count stops at 331 ...

Postby FioranoCars » Tue Oct 18, 2016 3:11 pm

H Alan
Please find settings file as requested.
I did have a brief try to look at/replicate this while using our 3 Series scope, but it failed to replicate, will probably be using the 4 series later myself and we try again, as I now feel like I was seeing things and going mad :oops:

But, I did double check it and while I was not looking at properties to see the capture rates, was and am certain the longer time frame per screen allowed more buffers, exactly the opposite of logic.

Anyway, maybe this, and flitting between scopes with different capabilities, has made me think about the fact the user requested "Sample Rate" is not what the scope might actually record!

Features request.png
Features request


So maybe it might be a wise idea to add to the menu bar (position 1) in picture the Real Sample rate PER CHANNEL, as a display box (not editable), so fools like me don't make stupid mistakes!? :roll: :roll:

But Seriously, I think when the requested figure is ignored (due to using a template from a high spec scope on an older model) or just asking too much, having a clear box that indicates (by being a RED border) that the requested rate is not possible. Something would be good ... the properties box is not something we have open while working.

On the subject of properties box, when reviewing files off-line with a scope attached, the channels cannot be accessed and things like "Probe" used, or Custom Probe are not shown in the properties panel. Could the properties panel list all the relevant data (filters, probe etc)? (And Math Channel data too - not checked so you might already!)

Thanks
Richard
Attachments
331 pages.pssettings
settings file
(4.78 KiB) Downloaded 53 times
User avatar
FioranoCars
TwoWaves
TwoWaves
 
Posts: 377
Joined: Thu Dec 13, 2012 1:26 pm
Location: London, UK

Re: Buffer Count stops at 331 ...

Postby PicoGerry » Mon Oct 24, 2016 12:30 pm

Hi Richard,

To answer your question regarding the increasing/decreasing number of buffers available for changes in Timebase settings, you didn't imagine it! The number of buffers you get is influenced by different factors depending upon which TimeBase range you are in. This is easier to explain with a visual guide, so I have put together a spreadsheet that shows the different factors for the different Timebase ranges and how it all fits together.



So, to explain further, if we assume the following:
    We always request more than the maximum number of samples for the PicoScope 4425/4225
    We select 10,000 for the maximum number of buffers
    We only use channel A
If we then start with the shortest Total Collection Time for the PicScope 4425/4225, i.e. 50nS, the number of samples per buffer is 20. As the size of the buffer memory in the Hardware PicoScope is just over 250M samples (the PicoScope uses some extra samples for housekeeping) it can easily accommodate 10,000 buffers of 20 samples each. (The total number of buffers that get used is actually 10,001 because one extra buffer is used for the USB transfer, so the Total number of samples used is 200,020). The same is true when we increase the collection time all the way up to 50uS, where each buffer stores 20,000 samples and the total samples collected is 200,020,000 when using all 10,000 data buffers (and the transfer buffer).
If we now increase the TimeBase to 100uS the size of the buffer memory in the hardware PicoScope becomes a limiting factor, so the number of data buffers used is decreased to 6,584 in order to capture 263,360,000 samples. As the Timebase is increased further the number of buffers are decreased (as you expected) until the point is reached where the sampling mode changes from Fast Sampling to Slow Sampling (where the data is streamed to the PC as it is being collected). The Timebase value where this occurs can be set in the Preferences section of your PicoScope 6 automotive software.
In the example used for the data in the spreadsheet the transition to Slow Sampling was set to 1S (so that you can see the number of buffers decrease all the way down to 1 in fast sampling mode before the switch is made) and you can see that, after the switch, the number of data buffers used now increases to 9. This may be what you saw, that seemed confusing, and the reason for it is that in Slow Sampling mode the number of samples that can be collected are limited by the number of samples that can be transferred (rather than the size of the hardware buffer memory). PicoScope 6 automotive artificially limits the number of samples that can be transferred to 100,000,000 for the PicoScope 4225/4425 (to avoid inadvertently overwhelming PC resources). What is happening at this point is that the hardware PicoScope is continually sending the data over USB while collecting the data in the available buffers (because the data is still arriving to fast to send without using storage). So, at a Total Collection Time of 1S the number of samples that can be collected per buffer is 10,000, and 10 full buffers (including the transfer buffer) equate to the maximum that is permitted to be transferred in this mode. Now, once again, as you increase the collection time the number of data buffers available decreases until the data stored in 1 buffer is 50,000 at a Total collection time of 5S.
As the Timebase is increased further to 10S the data is now arriving slowly enough to be able to transfer without having to fill buffers so there is no change in the available samples and number of data buffers used beyond this point. (Note that, because the data is being transferred without filling a buffer, the USB transfer buffer is not needed.)

Regarding the number of samples requested versus the number of samples used, I do take your point in that there is no indication when they don't agree. I think that how it is intended to be used is an important factor here. For example, we have an indication (the red exclamation box) when an input is out of range, but this is represents an adjustment that needs to be made during operation (something that you can't know when setting the input range). However, at the point that you request a number of samples you can get instant feedback as to whether you have them or not, by starting a capture and checking in Properties. I know that you say you don't have the properties window open when while working but it would be a good idea to have it open while setting up (for checking other parameters as well). Once you're ready to start acquiring the data you can then remove the window.

Regarding viewing files off-line, if you view them in the same PicoScope series/model that created them you should be able to see all of the channel information (it's when you use a different model that the channel info isn't accessible, because it may not apply). Adding a number of additional bits of information for each channel could make the properties window become too cluttered (it's only intended to show basic, and essential information at glance). Maths channels and their associated formulae are visible regardless of what scope you use to view the data file.

I hope this clarifies things for you.

Regards,

Gerry
Last edited by PicoGerry on Wed Oct 26, 2016 11:59 am, edited 1 time in total.
PicoGerry
Pico Staff Member
Pico Staff Member
 
Posts: 2
Joined: Mon Jul 25, 2016 11:08 am

Re: Buffer Count stops at 331 ...

Postby FioranoCars » Mon Oct 24, 2016 1:37 pm

Hi Gerry
Lots to take in there!
Thanks for adding the file, will take a look early this week and let you know of any questions.
Very thorough!

Thanks
Richard
User avatar
FioranoCars
TwoWaves
TwoWaves
 
Posts: 377
Joined: Thu Dec 13, 2012 1:26 pm
Location: London, UK

Re: Buffer Count stops at 331 ...

Postby PicoGerry » Wed Oct 26, 2016 12:07 pm

Hi Richard,

There were a few mistakes in my post which I've now corrected. So, I apologise if the message got lost in the details.

Regards,

Gerry
PicoGerry
Pico Staff Member
Pico Staff Member
 
Posts: 2
Joined: Mon Jul 25, 2016 11:08 am

Re: Buffer Count stops at 331 ...

Postby FioranoCars » Wed Oct 26, 2016 1:45 pm

Hi Gerry
First can I thank you for such a detailed post, and corrections (no I've not spotted any errors :wink: ) and of course welcome you to the Pico Team, and look forward to your posts continuing with such detailed and in depth explanations, sometimes its easier to give it the full monty, and then we all learn something, which I have. So Many thanks :D

I'll split the comments into two separate posts and the offline stuff is actaully in a separate thread over here:
https://www.picoauto.com/support/topic15061.html

so I have put together a spreadsheet that shows the different factors for the different Timebase ranges and how it all fits together.

Amazing, thanks for sharing the Excel file, along with the description. While some of this I had a vauge idea about, the actual logic/workings will help to forsee and avoid potential pitfalls, some of which I have encountered before ... the devil is in the detail!

Regarding the number of samples requested versus the number of samples used, I do take your point in that there is no indication when they don't agree. I think that how it is intended to be used is an important factor here. For example, we have an indication (the red exclamation box) when an input is out of range, but this is represents an adjustment that needs to be made during operation (something that you can't know when setting the input range).

I do understand the difference, but some sort of warning would be good (samples box outline green when within scopes range, blinking red when it's outside the range possible) would not add clutter, and maybe use a preference for novice users to default the feature to "off" and let advanced nerds turn it on? :idea: :D

However, at the point that you request a number of samples you can get instant feedback as to whether you have them or not, by starting a capture and checking in Properties. I know that you say you don't have the properties window open when while working but it would be a good idea to have it open while setting up (for checking other parameters as well). Once you're ready to start acquiring the data you can then remove the window.

Arrh, this comes back to the clutter arguement! Well it's a pain, as the properties window remembers the last status (open or closed) so you have to undertake 3 clicks to open it, not user friendly and while as a work around is Ok, it's not ideal. There is space on the tool bar, again using advanced preferences to show or hide these things would be nice, pretty please!

Adding a number of additional bits of information for each channel could make the properties window become too cluttered (it's only intended to show basic, and essential information at glance).

I think the tool bar has lots of space, making the display user customisable (using preferences) and the size of the preference window open verse 1 or 2 boxes in the tool bar is a mute arguement for clutter, really it is! The preferences box is huge, adding a couple of optionaal boxes for advanced users is no big distraction!

OK, so where is my original problem, well in a nutshell I've not had lots of time to try to replicate it, but I have no doubt it happened, so, armed with the new information, I'll monitor it and try and see if I can get it reproduce, but so far I have not managed. I will check the properties window (until you put them on the tool bar :wink: ) to see samples and capture rate etc, and if I find the issue will post back fully armed with settings files and screen shots :D

As always, the feedback is given in the hope a great product can continue to evolve in better and more user freindly ways, although in this instance the request may be completely confusing to a novice, but could be critical to understand why the scope behaviour was what it was for an advanced user ...

Off to fathom masks and alarms, as clearly don't know enough about them ... any tutorials you can point me towards will be most welcome!

Thanks, and as ever still learning ...
Richard
User avatar
FioranoCars
TwoWaves
TwoWaves
 
Posts: 377
Joined: Thu Dec 13, 2012 1:26 pm
Location: London, UK


Return to PicoScope 6 Automotive software

Who is online

Users browsing this forum: No registered users and 0 guests