I would love to hear from you! Any feedback is helpful – please reply to this thread or start a new one!
Getting there! This release adds:
Basic Protocol Analyzers
Save/Load files
USB performance and other issues fixed
There are still issues in Window 7 and Ubuntu/Linux related to missing dependencies. I apologize those aren’t fixed yet, it should be wrapped up in a few days.
Low expectations please: This alpha is rough, unstable, and lacks crucial functionality.
Linux:
Pending dependency fix, pls check back ~Tuesday July 30th.
I tried AR 7, it looks, great! Just a question about supporting analog sample rates lower than 781 kS/s? Many physical systems don’t need to be sampled this fast, audio, strain gauges, geophones, … It makes the files WAY too big. One last question, what’s the plan for paging DRAM A/D samples to disk in real-time (even with limited sample rates or channels? Thanks, Richard
Yes, this will be supported, certainly before data-logging (see below)
By the way, when you ‘export’, you can now “resample” the collected analog data at a much lower speed. And saving captures to disk should also be result in much smaller file sizes in this version - the data is more efficiently stored and is also zip-compressed.
Yes, this will happen as part of comprehensive support for data logging. It’s currently on the board for Q1 of next year.
As a better alternative, list the most common protocols first, provide a Show more analysers option, and contrast the whole selected line, as in main release.
Grey shades for the menus may be aesthetically pleasant but are hard to read. Turning only the I²C text in green may not be contrasted enough. Contrast the whole selected line, as shown in the mock-up below. Similarly, use white instead of light grey for text for better readability.
Great feedback, thank you! I am sorry that the UI remains largely un-updated, we have tasks for this, they remain slightly behind some remaining feature development that’s necessary for feature parity.
Will do. This is a first rough effort. Still, this should have been done since it’s so easy.
The plan is to do something like this, were the analyzers most common to the particular user show up first (in a dedicated section) - initially they would be Serial, SPI, I2C but over time they would evolve to match the user.
We’re very much in the mode of get the basics working and leave the off the polish until ‘the core set of functionality’ works well. I’m not sure if it is the best strategy, but it does have some advantages.
Thanks, I’ll talk with our designer and the developer (Tanveer and Rani) about this. Looks like it doesn’t match the original art either.
Unfortunately, it does always, after a while once the I²C protocol analyser has been selected.
Two more things about the UI:
Release 1.2.29 and previous had very handy screen short-cuts to move to the previous and next change of signal. Those short-cuts were shown when the mouse pointer was hovering on the left and right limits of the signal.
Yes, this is super annoying isn’t it! Sorry about that. In the next design refresh it will no longer be possible to do that because the ‘timing area’ will no longer extend over the top of the ‘sidebar’. I figured we should wait until then (2 weeks I hope) instead of doing a temporary solution.
It’s been 9 months, any possibility of supporting analog sample rates lower than 781 kS/s? I would love to help test his Alpha, but can’t use it in my application without the slower speeds… Also any ETA on the logging to disk?
Hey Richard,
We know that this feature is critical for some of our users and we apologize for the delay. As we’re a small company, we have to to stay focused and prioritize our features. Unfortunately, it means that sometimes we disappoint some of our users. It’s not an excuse of course, and we’re working hard on shipping features faster (and better).
In regards to low sample rate, it’s on our plans for this quarter. We’ll keep you posted.
We don’t have an ETA on the logging to disk unfortunately. I can add that to our feature requests board if you’d like: https://ideas.saleae.com/b/feature-requests/
It’s still planned, yes. However, to be completely honest, it’s not our highest priority.
On main goals are currently performance, high-level analyzers and continuous triggering (analog, digital and protocols).
Low sample rate shouldn’t take long and I believe that we’d be able to ship that this quarter.
In regards to logging to disk, can you elaborate? What would you like to log? analyzer results or digital data?
What I mean by logging to disk is saving analog values to disk either as continuous streams, or through a simple ping-pong buffer approach. Obviously this wound not work with the aggregate data rate over a certain limit (A/D sample rate
number of channels). Our application is monitoring power consumption in battery operated devices over extended periods of time (larger than the available DRAM). This captured data is post processed and analyzed for power anomalies. We have cases where
we acquired over 1TB of samples! The really old school method for capturing slowly changing analog data was with a chart recorder and paper! The next revolution was to RAM to disk, the birth of the “data logger”. There are many low speed (<128kSPS) applications
where extended storage would be useful for monitoring temperature, pressure, stress, strain, flexure, displacement, audio, seismic, … Disk drives would be the cheapest way of expanding the storage capacity (2TB is <<$100). This data logging application
could be a new market beyond R&D and Test.
Thanks for the detailed explanation.
Data logging is a very interesting market indeed, and we’re hoping to build more tools for it in the future. Unfortunately, looking at our current plan, we won’t be able to add that feature in the near future. I’m really sorry about that, but I don’t want to create false hopes.
Semi-related idea:
We’re planning on making the app more extensible, similarly to our Python high-level analyzers and measurement. Currently you have to add the measurement manually, but we’re thinking of automating this process. As part of that, you might be able to use it and build an extension that logs to disk. It’s just an idea though
