Markers not exporting data, UI slow on saved data

Hi all, first days with the Joulescope and loving it!

I’m using software version 0.8.3 on Windows 10, here are two questions I couldn’t figure out or find previous posts about…

  1. The right-click context menu for dual markers has an “Export data” item. It brings up a file dialog but when I choose a file (new or existing) and click “save”, a tiny message box appears for a split second (too fast to read what it says) and nothing is actually saved, no file created or anything. ?

  2. Data captured live, after pausing the capture, responds blazing fast (zoom in/out, pan etc.) but data loaded from a recording (=file) responds slowly. Isn’t it loaded to RAM the same way as live data? Should it?


1 Like

Hi @igendel

For (1), this was an error (Issue #47) we introduced in the 0.8.3 release. We will have a release this week to fix it.

For (2), it does not load to RAM the same way. The software is designed to support VERY large files. It is pretty fast even with captures of many hours. The downside is that it does have to retrieve information from the file which takes much longer than RAM. The JLS file format does accelerate the search and zoomed out view, which is sometimes why zoomed out is faster than zoomed in. At full rate, Joulescope records 8.2 MB/s, which adds up quick.

Are you dealing with short files? We could add an optimization that would load files up to certain size into RAM.

1 Like

Right! I need to remember to check GitHub too. I’ll wait for the update, no problem.

Depends on the definition of “short files” :slight_smile: I can certainly see many scenarios where I would record up to say ten minutes, just to test little features and tweaks. But I don’t know if I’m a typical enough user to warrant a significant effort on the software…

1 Like

10 minutes is approximately:
8.2 MB/s * 60 s /min * 10 min = 5 GB

However, the existing RAM format does take more space than the SDD/HDD, at least today. I think that this is a common enough use case that it would help many people. I created Issue #48 over on GitHub.

1 Like

That would be great. I actually put 10 minutes as a max value - the average case will be shorter, even much shorter with GPIO triggering. Thanks again!

1 Like