I have highspeed 2.5 Mbit/s async serial. When analyser is configured when sampling the buffer fills up with a factor ~20 in speed. In my setup I can sample ~10s with analyzer configured but ~250s with out the analyzer configured. Buffer size set to 0.5GB. If I add the analyzer on the already sampled data everything is decoded as it should. The capture file size of the of the same 0.5GB full buffer are 5MB analyzer enabled vs 112MB analyser disabled. Also if I sample a fixed time the captured files saved have same length although buffer used while sampling is >20 higher when analyser is used. Another strange thing is that the higher the bite rate the faster the buffer fills up for the same signal ???
@h_larsen Memory usage (as indicated by the Memory status bar at the bottom right of the software during a capture) does increase when analyzers are enabled during a capture, so the behavior you described does in fact look like expected behavior.
The memory usage during a capture also increases with the number/density of digital transitions that are recorded. I suspect that, when increasing the sampling rate, you are also potentially catching/recording more digital transitions, and therefore, increasing memory usage during said capture.
Hopefully that explains it!
You write that memory usage does increase when analyzers are enabled. This is OK but in this case it makes the analyser/tool unusable. The buffer length decreases by a factor of ~25 in length when enabling the async serial analyzer set to 2.5Mbit/s. Workaround I use is to set the bitrate low <0.5MBit/s while sampling and then change it back to 2.5Mbit/s when looking at the data but it is quite tedious. Also note that the higher I set the bitrate, only in the analyzer the signal is the same, the higher the derate factor is?
@h_larsen I’ll discuss this with the software team to see if the severity of memory usage discrepancy is expected. Each protocol bubble generated takes up a set amount of memory. Increasing the bit rate setting of the Asyn Serial Analyzer is likely generating more bubbles, hence the higher memory usage.
In the meantime, deleting the Async Serial Analyzer before a capture, then re-adding it after the capture may save a bit of time compared to modifying the bitrate setting, since the bit rate setting will persist (meaning, you don’t need to re-type the bitrate, or reconfigure any of the settings).
@h_larsen Can you also let me know more about your end goal with regards to what you are trying to accomplish? This might give us a better idea of what kind of workaround we may want to suggest.
We are producing realtime embedded motor controls and I would like sample “everything” together with correct timing. We have 8xPWM’s, 2x highspeed async+1lowspeed, 1 CAN, 1xSPI and 4 analog channels. Analog are swapped for 4 PWMs or SPI when needed. We typical don’t use triggers but rely on a big enough buffer to catch any issues.
@h_larsen Thanks for describing that. Besides increasing your buffer size setting, it looks like the best workaround to ensure you capture more data within the same buffer size will be to remove analyzers during the capture, then re-add them after the capture is complete.
I’ve scheduled some time next week with our software team to review the memory usage of our analyzers in more detail and I’ll share more on that once I have more info.
Thanks for writing in about this, and sorry for the trouble! I wanted to add a few more things to Tim’s reply, for context.
- The buffer limit in the software only applies while running the capture. When adding analyzers to the capture after recording is complete, the buffer limit is ignored. (we’re not sure if this is a feature or a bug, but it needs to be addressed either way. We need to make big improvements for high-memory users)
- For digital signals, we run-length encode the data, meaning we only store information when the signal changes. How long you can record for is directly determined by the number of digital transitions per second. You can record 9600 baud serial for extremely long periods of time, but 2.5 Mbit/sec (especially at high utilization) will consume memory very quickly.
- We store protocol results very inefficiently at the moment, and this is in our backlog list of things that need improvement. In the meantime, what Tim mentioned - recording without the analyzers, then adding them after the capture, will help a lot. First, it reduces CPU usage during the capture, and it will ignore the memory limit. Second, once the capture is complete, the recorded data can be allowed to page to disk normally, so even if the memory usage is very high - perhaps higher than the installed RAM, the software will continue to work. We recommend using saved presets to easily switch between no analyzers and all of your analyzers properly configured. You can save all of your active settings, remove all analyzers, and then save another preset, and then alternate between the two.
- The saved files only contain the raw digital and/or analog data, they don’t contain analyzer results. That’s why the save file sizes are so different. When you load a saved capture, the analyzers are simply re-run.
- For huge captures, I recommend only having one open at a time, and I recommend saving them right after your capture is complete.
I am aware of most of the points your are stating. The thing I found strange was that enabling an analyser would reduced the buffer length so dramatically.
I did a test sampling a 0.5GB buffer with only one digital channel a 2.5Mbit Async serial that is 46% loaded(112kB/s). Sampling without analyser gets me 491 seconds and with analyser only 11 seconds.
I don’t have a fast computer and can see that the analyser really struggles when enabled while samling. But also enabling the analyser afterwards on the 0.5GB (491seconds) buffer takes 57minutes to analyse 
I have a laptop with 32GB RAM and a AMD Ryzen 5 PRO 4650U with Radeon Graphics, 2100 Mhz, 6 Core(s), 12 Logical Processor(s)
I was not aware that you could load a preset on already sampled data, that helps a lot not having to configure 5 analysers every time after I have sampled, thank you 
Maybe each analyser could have an enable/disable button, that would make it even easier 
@h_larsen You’re absolutely right about including the ability to quickly disable/enable an analyzer. We’re tracking this feature request below, and I’ve added a comment to track your need for it. We’re working on other priority projects at the moment, and I’m hoping we can get to this once we’ve moved on.
By the way, 57 minutes sounds quite long! Do you happen to have a copy of your capture file (in .sal file format) that we can test over here?
Feel free to send me (Tim) a message using the link below, and we can move the conversation over to email if you’re interested in sending that over to me for review (I’d provide a private file upload link for you).
https://contact.saleae.com/hc/en-us/requests/new