I’m confused a bit
What’s the difference? Have you been running it for an hour with or without analog channels?
btw, the digital data is compressed, therefore, if you run it at a low sample rate then 0 MB makes sense (if we can keep up with the processing).
Am I trying to do something that’s not supported?
Not at all, we should support capturing for as long as you want! Both analog and digital!
Sorry - I turned off the analog channels, and started it up with just four digital channels sampling (it’s not hooked up to my DUT right now, so they’re all just low). And now I see that it’s finally shown some memory usage - 20MB I’ll let it run as long as I can and see if after a very long time it starts to have trouble. I think you’re quite right - having the analog on there makes the trouble happen a lot sooner.
If I have my two analog channels turned on, then its only a matter of maybe 10 or 15 minutes before it completely stops updating and the stop button has no effect.
Hello,
I experience a bug on I2C analyzer, upgraded from alpha 2.2.8 behave same.
I2C has a bus fault at end of transaction, SDA held low.
My bug catch another one
Capture attached here: I2cFault.sal (636.8 KB)
Start from reset: decode command to Oled addr 0x78 data 0x00 0xae Addr0x78 0x00 0xd5 …
Starting/repeat analysis from left decode transaction.
From right side where bus error is, void all I2C data also on good transaction.
Machine Lenovo Laptop V155-15API-81_5 Ryzen 5 20GB ram
Linux Mint 19.3
Logic 8
STM32:
STM32F401 ONEWire on Half duplex single pin, I2C LL drivers, LCD On SPI, OLED on I2C.
No device on OneWire Bus.
Software is released to Github not this version too.
Regards
Roberto
About Alpha version:
2.2.8 was running smoothly on USB 3.x no more USB fault.
No more joint error on STM32 debugger (STLINK V2.x. Ordered STlink 3 to test.) No more disconnect on long debug session when LA start and fail.
No request to disconnect and reconnect Device.
Device now run smoothly from USB3.x HUB too.
GUI changed too much from release so I need time to adapt. (Just time to acquaint on)
2.2.9 same as 2.2.8 seem stable till now.
Regards
Roberto
When using the Async serial (UART) analyzer and CTRL+click’ing to go the the value, sometimes the value I see in the decode doesn’t match the data that I CTRL+click’ed
One more thing about the Async serial protocol analyser: I really like the idea of the “terminal”, but in order for me to be really useful when looking at the NMEA sentences sent by a GNSS receiver, I would need the terminal to actually print all the characters as their ASCII representations, so “,” and not “COMMA” and so forth. Maybe I just missed an obvious setting somethere?
In your example, when you ctrl-click on a box (a “bubble” as we call it) that contains multiple results, the table moves to the first result of that box and not to the one that you clicked on. Sorry about the confusion.
The table is currently using Elasticsearch and the time precision is not high enough, therefore, we might move to the wrong value sometimes. We’re almost done replacing Elasticsearch with a faster and better database.
@luisfhm007@Kai you’re absolutely right!
We’ve been working on that feature over the past couple of weeks - first, we upgraded the streaming service to a faster solution that will also allow us (in the future) to stream to other destinations (files, terminals, etc). Second, we need to upgrade the analyzers themselves to support proper streaming (e.g. remove COMMAs).
@rani thanks for the feedback. I just wanted to be sure that you were aware of this issue.
As for bubble vs the table: I expected the table to move to the first result (the software does this consistently enough that as a user, I immediately get trained to expect this), but in the case that I screenshotted, it didn’t. The bubble starts with “$GNRMC” but the table starts with “24142” so clearly somewhere else. Could be an artifact of the Elastisearch.
Looking forward to the terminal improvements. For my purposes, simple parsing & printing of the ASCII text (e.g. \n and \r) would be enough - I do not need colors or advanced cursor movement (that would be a time sink to do full tty).
Great, thank you
I was also playing a bit with the analog measurement extensions and I think there is no way to get the sampling rate or is it? I think it may be important to have that available for more advance analyzers…
I like it. It will open a lot of possibilities for sure.
Some wild ideas for the future:
I still can’t have 1/∆T (be it in time markers or extensions)
An enable/disable switch for the extensions, not just uninstall/add, so one can easily select which extensions one needs
Allow the extension to return also a time marker(s) that will be added in the trace, so the extension for example can place a time marker at the highest voltage. it would be coupled to the measurement, so if the measurement is deleted, the marker would also be deleted, if the measurement extent is moved the marker(s) are also moved.
Is it possible to do something about this screen capture blockage on macOS (reported on previous versions, but I do not remember any feedback about it). Thanks a lot.
BTW, did you receive the Instruments’ capture file about the issue related to CPU 100% load?. Thanks.
Is it possible to do something about this screen capture blockage on macOS
I wasn’t able to find it, any chance that you can post a link here? Sorry about that…
BTW, did you receive the Instruments’ capture file about the issue related to CPU 100% load?
Yes, thanks!
We might have (finally) found the issue yesterday - we suspect that the feedback addon that we’re using is causing it. We’re still investigating though.
I wasn’t able to find it, any chance that you can post a link here? Sorry about that…
Sorry, I may have logged this to the “Ideas” website befor understanding it was a bad idea to do so.
I’m trying to find it on https://ideas.saleae.com, but it seems the site is in trouble:
To sum up, the issue is that on macOS, when you want to create a screenshot, you use ⌘+⇧+N, where N usually = 4.
However, whenever ⇧ (shift) is hit, Logic2 changes the display, discarding for example the time between two edges. This ends up to capturing something else, and no way - at least I found none - to capture a very important information of the graph…