Alpha Release 7

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.


Pending dependency fix, pls check back ~Tuesday July 30th.


Windows: (Windows 8, 10 - for Win 7, pls check back ~Tuesday)

Note: It is our goal to have the alpha software stable enough to use for real work by J̶u̶l̶y̶ ̶1̶ August 1 .

Join the Alpha Users Mailing List to be notified about the next release!

Coming up next

  • Protocol analyzer search / list view
  • Protocol analyzer export
  • Improved capture configuration UI/UX
  • Proper settings persistence
  • High priority issue fixes

Planned for this Quarter (Q3)

  • Analyzer Sequence Search
  • Context-sensitive help
  • Proper shortcuts
  • Delete channels
  • Trim capture
  • Wall-clock time display
  • analog/digital proper alignment
  • Analog channel v2
  • App performance metrics
  • Sidebar resize and collapse
  • Auto-update
  • Digital Scope-View
  • Trigger-on-Analog
  • Scope-View v2
  • Performance improvements
  • Comprehensive USB reliability testing (internal)
  • Themes
  • Art updates / polish

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

Thanks for the feedback 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.

I gave alpha 7 a try. I guess some UI aspects reported for previous alpha 6 release haven’t been included yet.

Three suggestions:

  • Please sort the protocol analysers. For example, I²C is a the very bottom, after USB.

  • 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.

Two questions:

Hi Rei,

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.

This should NOT happen. Does this always happen on your computer, or sometimes?

We don’t have demo mode for protocol analyzers wired up just yet. Thanks for reminding me to check on that.

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.

  • I haven’t found a similar feature on the alpha 7, and I’m really missing it.

  • Release 1.2.29 and previous pre-populated the signals for protocol analysers, here for SPI.

  • Release alpha 7 lists all the ports as blank, allows selecting the same port multiple times, and complains only when the Save button is hit.

On ar7 ( windows 8.1 ):

  • No hint whe you hover the mouse un analyzer settings
  • the quadrature analyzer ( I’m working on ) works as expected
  • I can’t load .logicdata files ( saved on version 1.2.18 )

Regards, Davide

Thanks for the feedback Davide! And welcome!

Thanks, we’ll fix that.

That’s great to hear! Our goal is for all previous analyzer to continue working well in the new version.

This won’t be possible for some time I’m afraid. We’ll need to create some sort of conversion utility to make it possible.

Thanks Rei -

  • Good to know it’s repeatable. I can’t get it to reproduce yet on my Mac, although I have run into similar issues in the past. We keep after it.

Thanks for pointing that out. I’ve verified its on the near-term roadmap.

Yes, it should initialize the channels like the old software did, thanks - will get that fixed asap.

I think we can get it to complain right away as well.

Hi, I’m testing the Alpha 7 release right now.
You’ve done a great job so far.:+1:

When trying to open the menu, time markers are often set instead of opening the menu (Windows).

But in this area above the sidebar:

it doesn’t make sense to set markers blind anyway, does it?

Maybe you can limit the area where you can set time markers to the visible signal, or enlarge the mouse area of the menu button a bit. :wink:

Keep up the good work!

1 Like

Hi Pascal - and welcome!


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.

Thanks - we’re cranking away!

Hi Joe,

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:

Sorry for not being more helpful

Hi Rani,

Thank you for the response. I do understand the criticality of new features.

I have requested the logging to disk for years now. The last response from Joe was:

Support for paging DRAM A/D samples to disk in real-time?

“Yes, this will happen as part of comprehensive support for data logging. It’s currently on the board for Q1 of next year.”

That was in July 2019, Is this still planned?



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?

Hi Rani,

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 :slight_smile: