The Intel 8 series chipset/USB host controller had a rocky launch, but I’m pretty sure it’s been stable on Linux for the last several years worth of kernels.
Right now we’re running Ubuntu 16 on a 7 series intel host controller and Ubuntu 19 on a 100 series intel host controller. I’ve just tested both with Logic Pro 16 and the alpha software. It’s clear we have a lot of work to do on the Alpha software when recording at the performance limit of the device, 500 MSPS on 6 digital channels. After about 10 seconds, the software is trying to free up memory by discarding processed data but it isn’t able to process the data in real time. Trying to close a tab with a lot of data has a chance of breaking the app. We’ll get working on that soon. We do most of our development and testing on higher performance machines; we do mostly UI/interface testing on these lower performance machines. We’re planning on setting up automated benchmark testing for the back-end on a slower machine, so we can improve the situation, and make sure we don’t accidentally step backwards.
What capture settings are you using? Does it capture reliably even at very low sample rates?
In other news, we found the problem with Windows 7 (and presumably 2008). Turns out a few months ago we introduced an API for debugging purposes that was only available in a specific update to windows 10. Removing it fixed the problem.
The next alpha release candidate was already created on Friday, but it has bugs. there is a 50/50 the windows 7 fix will land in alpha 15, and if not, it should be in alpha 16.
One final note on USB stability in the alpha software. The USB layer is the only piece of the 1.X software that still remains in the 2.X alpha codebase. It’s going to be a big project to overhaul, and we haven’t started working on it - but it is planned. What we are trying to do now is capture more detailed analytics from customers who’ve opted in so we can figure out what percentage of customers are affected and how bad the stability problems are for those users. From what we know so far, a very small percentage of users are having a pretty terrible experience with the product. Unfortunately, it’s a pain to reproduce. We’ve already bought several computers identical to the machines our customers have reported the problems with, and still haven’t been able to reliably reproduce them here. I also have a box full of “USB exercisers” next to me which I’m looking forward to integrating into some end-to-end reliability testing for our hardware and software.
Thanks @markp, turns out we’ve been tracking analytics for calibration download errors, and have tracked almost 300 instances where a problem occurred downloading calibration in the Alpha software. We weren’t capturing specific details of the error, but I’ve just added that to the application. Hopefully we’ll be able to improve calibration download reliability with that information.
(this requires opting into both analytics and crash reporting)
In the meantime, it seems like the problem is intermittent. The retry button on the calibration error popup is a good bet.
What capture settings are you using? Does it capture reliably even at very low sample rates?
I want to say It did not matter. I will retest on the next release.
I also have some news. I had a recollection of installing USB cap or USB windows message analyse and I recall it saying it was changing a BIOS or EFI entry in the process. But it was too long ago to recall.
So after ruling out filters, I forced updated the BIOS on the p9x79-e ws BIOS (to the last published 2015) and after a tad bit of panic, in getting the machine to boot again (to many options, dependency), now 1.2.18 works at top speed all channels (D+A)
I wish I could tell you the setting or it it was an EFI driver that fixed it. All I can say is the pain was worth the gain.
If it is not there, it might be a good to add the question “Have you installed USB cap or any USB analyzer tools?” to the fault isolation process.
I have just started playing some with the new Alpha builds. I have been using the earlier Beta builds for awhile on several different analyzers (Original - which I gave away, earlier 16, Logic 8, and Logic Pro 8)
I am still doing most of my hardware/code debug time with the Beta build, as this Alpha build appears to hang on me and/or I can not start/stop it again. Will debug more when the new alpha comes out.
The last hang was testing out I2C stuff, where I only had two digital channel open running probably running as fast as I can, typically for maybe 10-20 seconds. The first sample worked fine, I then tried to start up a new one, and it either hung before it, or hung where I could not stop it. I am mostly using the Pro 8 on Windows 10 64 bit plugged in USB3.
Sorry that I don’t have more specific information, but will again try when new build comes out.
UI minor suggestion. When I decide to add a protocol analyzer, the resulting dialog does not appear to be moveable. Which often times I might need to move it, in order to remember which IO pin is what.
I think you can reproduce this fairly quickly. If you invoke the GUI with the hardware disconnected, then connect the USB connector to the Logic. It seems to always fails with a capture running (waiting for trigger), then I can’t stop it and have to kill it. Once I invoke again, it seems to be OK most of the time. Today it failed a second time about an hour later so I agree that it is random.
Feature - Auto assignment for Signals of Analyzer
There also might be an improvement for the analyzer in general.
As in post above, I like to name my “wires” like the signals. Afterwards I apply the analyzer Signals according to the names I’ve given the wires. So e.g. I assign the wire “MOSI” to the signal MOSI.
In my opinion it’s a nice Feature, if the analyzer would assign a Signal Called MOSI, assign to the wire called MOSI. To extend this, probably MOSI1 CS1 etc. could be grouped to GROUP1, to make this even quicker. This could help, if you had several interfaces the same time.
Interesting idea
I don’t know if naming the channels upfront is a common use case tbh, I’d love to hear other people’s feedback on that.
There are two things that we’re planning on doing:
Auto-detect analyzers - you capture data and the app does the rest for you by suggesting you the right analyzer with the right configuration. I believe that it’s a more robust solution.
Allow users to write plugins such as that. In this case, you’d be able to intercept the “create analyzer” process and assign the channels as you like with code.
How would someone use this option of labeling channels. Default is “Channel #n”. Labeling it e.g. MOSI is the obvious choice to me.
Would be amazing. For example, it might be obvious that what ever your capture is SPI, but to find the correct mode(0,1,2,3) would be actually nice. But please leave the user a chance to change the suggested.
nice =). Which language, python :)?
While creating a interface for plugins, would it be possible to actually make use of a existing analyzer, and overwrite methods? I’ve something in my mind like replacing single Bytes or sequences of sniffed bytes with the actual command. e.g. a own plugin special written for say a LSM6DS3 sensor.
# example for LSM6DS3
MOSI: 0x8F followd by MISO: 0x69
should be translated to:
"Get WHO_AM_I register" and "WHO_AM_I: 0x69"
Thinking of it, would such a lookup be helpful for others too? The user would only provide a json-file with sequences and the associated replacements accordingly. The Analyzer would do the lookup. The next step would be a repository maintained by the community with the json-files for lot’s of overlay protocols.
But please leave the user a chance to change the suggested.
Of course
Which language, python :)?
We haven’t decided yet but sounds reasonable. It’s pretty far on the roadmap though.
I’ve something in my mind like replacing single Bytes or sequences of sniffed
We have just started working on something like that. We call it High-Level Analyzers (HLA). You’d be able to feed an HLA with the results of a low-level analyzer and process its results in Python. A basic use case is, as you mentioned, a lookup function.
If I’ve a recording of a interview. There is a time frame before and after the interview in the audio file. I like to mark them and afterwards hit [ del ] to delete the unnecessary start frame and end frame.
As a user of saleae I would love to delete a unimportant part of the trace and keep the important ones. If this is a hiding function or a deletion does not matter. It should avoid the scrolling to the start. It think the timestamp should remain the same.
Imagine a 2 GB trace. Probably it would also be nice to cut several parts out of a huge trace into some small file. This small file could be easily attached to a issue in a ticket system or send via mail. So a copy and past while preserving time stamps and origin file to not louse track of the source.
Do you usually want to keep multiple parts of the trace?
The reason I’m asking that is that we were thinking of allowing users to trim the capture only from the left and right (but not to several pieces). It’s of course much simpler from engineering perspective
I have a 3 sec capture and the measurements are only showing up intermittently. For instance, in the screen shot below, I can only occasionally get the measurement to pop up on the bottom trace, and that is only if I very carefully point at the bottom of the trace. The measurements on the top two traces work intermittently, but more often than the bottom trace. The measurements on the analog waveform seem to always work.
I am zoomed all the way out. If I zoom in 2 levels I can get the measurements to start working on all the traces. If I then zoom all the way out, it will continue to work until I point to the high frequency traces then move off. That seems to break it again.
Thanks @markp, a *.sal capture file would help a lot. we can test out the measurements over here and see if we can figure out what’s broken.
There is a long criteria in the app to decide if a measurement should be slown or not, based on a number of factors - is the measurement at least a few pixels wide, is it on screen, etc…
There is code that runs when the cursor moves in and out of a channel. The fact that moving it over one area and then to another breaks it is quite odd.
It might also be a performance problem - what digital sample rate was used for that capture?
The current measurement system is pretty bare bones, and needs improvement.
I’ve just taken a look and the problem is that the clock channel is picking up glitches around the transitions. If you zoom in on those falling edges you will see this:
This is a common problem with the Pro devices because they have very narrow hysteresis range.
I’m not sure why this is not detected in the old software.
Please check that the IO voltage range in the Alpha is set correctly. Here is a quick screenshot showing where the option is in the old software and the new software:
If you use the same sample rate and the same I/O voltage mode in the old and new applications, you should get the same results. We re-used the USB level and below from the old application in the new alpha.
In the next alpha release, 2.1.2, we have also added a basic glitch filter which will allow you to suppress pulses that are shorter than a specified number of samples. In your capture with the Alpha software, the glitch you are seeing is 2 samples low followed by a single sample high.
We’re trying to wrap up the 2.1.2 release right now, and if all goes well, it will be published in a few hours.
