Tutorial about logical analyzer

Logic 2 Software
1

Hello!
I recently bought a Logic Pro 8 analyzer and had a try. It works fine, but there is something
a bit weird about the way it works. Maybe it’s a matter of configuration and lack of knowledge
(I got it this week), so that’s why I won’t complain too loud (for the time being^^)…

When I use an oscilloscope, be it a scope from the 60s or a recent one, lets sau post 2020,
I just have to push a button, and the curve appears. Then with the latest ones, I select the
channels I want to enable (or disable as it remembers the previous shutdown setting).
And it runs at the speed of the last timebase. So I would appreciate if I could setup the same
kind of interface. Is this possible?

The only thing I can do is to press the play button so that it records the current signal, there
is apparently no way to display the signal without recording. Or is there?

Thanks for any hint!

Elodie

2

@elodie Thanks for writing in! You may want to try Looping Mode as summarized in the support article below.

In addition, you can configure a memory buffer size to limit the maximum memory usage that a continuously running recording will consume. Hopefully that helps!

3

Hello Tim!
Thanks for your reply.
Yes, I’m aware of this mode, but the question is: why do I have to record in the first place?
By the way, why using the “play” symbol to record? I would understand it as a way to replay
what I just recorded (with a record button). And while we are at it, a fulle VCR interface
would be great.
Recording can be useful in some cases, but most of the time, what I want to do is to check
the signal I have triggered.
→ One shot in case it’s a short signal I want to capture, either from a comparator-like trigger
or from a digital (e.g. detect a specific OpCode between a microcontroller and a device)
→ Continuous, for example to check what happens after a repetitive trigger.

The current version works fine, but I’m sure it could be improved by being more oscilloscope
like. Oscilloscope have evolved this way for the last 100+ years, there must be a reason.
I’m sure you have engineers who know what is a scope. Why not asking them?
The constantly moving time grid might be interested as an added feature, not as the main dish.

In my case (using BiSS), what I would like is to set a fixed width window (for instance
1µs per square), and check a continuous data flow, with the frames always starting at the same
place within the display window. For example the start signal of the frame.

Is there a tutorial for doing my own decoder? I mean, from the C++ source code to the
.so lib of the decoder?
Where should I put this file in Linux? There is only an appimage.

Best regards,

Elodie

4

I think it’s semantics of the new logic 2 vs. traditional scopes. ‘Play’ is the same as ‘Run/Stop’ button, so until you push play, the capturing is off/stopped. The data is streamed between the logic device and your PC over USB only when you push ‘play’, otherwise the USB is idle. That way, you can avoid USB overhead of logic and use more bandwidth for other USB devices. Meanwhile, all the data is being captured (or ‘recorded’ in your terms) to the PC memory (RAM buffer), until you decide to save a capture to a file.

It seems like you want a re-triggering ‘live’ view (non-stop update on screen), and not a snapshot (auto-stop after trigger or other criteria). This is done by the ‘trigger view’ mode:

Maybe the biggest difference between logic 2 vs. traditional scopes is that the PC’s memory / RAM buffer is much bigger than most scope’s device memory (you can use as much RAM as you have on your PC – 10’s of GiBs vs. <= ~1 GiB / channel). Thus, the buffer size will scroll past your monitor vs. keep the entire capture on screen. That’s a good thing & why I love using a logic rather than a scope – much more capture range to see longer time sequences all in one snapshot. Instead of complex triggering to get one ‘hi-res photo’ (taken just at the right time), you can just record one big ‘HD video’ and then FF/rewind/zoom in/out to the scene(s) you’re interested in reviewing.

Bottom line: think of it as a USB streaming logic analyzer w/ analog channel data and ‘deep memory’ buffers, not a traditional ‘one screen’ oscilloscope (a new tool, with a different way of working).

5

Hello again!

Thanks for your reply.

The data is streamed between the logic device and your PC over USB only when you push ‘play’, otherwise the USB is idle. That way, you can avoid USB overhead of logic and use more bandwidth for other USB devices.

There would not be very much overhead. If you want continuous display, it sounds counter-intuitive, but you display discontinuous data only. For instance, when you sample an analog signal with some trigger, you will (probably) want to display the trigger to observe some phenomenon following (within a certain delay) this trigger. Super simple example: you want to observe the switching pulse of a laser. This happens ONLY when the laser starts, and the width of this signal will be in the range of 100ps to a ns, depending on the laser, the switched current, etc. This means that you will discard most of the signal, and you will end up with, say, 1000 pixel wide data display at 30 fps, and have an impression of continuity with a signal refreshed faster than you can even see.

What data rate do you need in this case? Supposing you have one measurement per pixel in horizontal direction, it means you need 1 k byte buffer (2k if you have a 16 bit oscillo, which will probably not be the case with ultra fast signals). 1 k byte x 30 frames is 30 k of data per channel. I don’t remember USB3 throughput, but even USB2 is 480 Mbit which is usually thought as 54 MBytes actual data if I remember correctly). So your 30kbytes data per second or 480k bytes.

if you have 16 channels, it will cost 0.1% of USB2 max throughput and even less for USB3.
Multiply the window width by 4 and the data width by 2 (16 bits), you’re still under 1% of USB2 max throughput per channel.
And for the logic probe, you have 16 channels for the price of 1 analog (1 bit per sample).

NB: the data rate is so low that I have the impression I made a mistake somewhere. Please don’t hesitate to tell me if it’s the case, if possible with some level of courtesy.

Let’s put this into perspective: a video camera (for instance the USB3 microscope I’m using for soldering), spits images 3 MPix images, the frame rate being limited to 24. Therefore (roughly) 10 MBytes per frame x 24 frames only because USB3 is quite saturated. And it sometimes happens that I leave the camera on for hours, it doesn’t harm or impede the other USB devices.

To summarize, I’m afraid the throughput issue wouldn’t be a problem.

Best regards,

Elodie

Addendum:
With this way of continuously displaying, it would still be possible to start recording like it does now. Or record from some trigger.

6

The Saleae hardware doesn’t have an internal buffer; all of the data while ‘running’ (or ‘playing’) must go to PC software to be processed. As far as I know, you don’t do any triggering in hardware on the device, it is all done in software. So, you must stream it all just to decide when to trigger.

It is not a hardware oscilloscope with any significant device memory buffering, it is a USB logic analyzer that uses PC/host resources to work (buffer, trigger, display).

All that being said, I think you can use the ‘trigger view’ capture mode to get the UI behavior you want.

Note: You may need to use a work-around, depending on exactly how you want it to behave, see:

… and:

Until Saleae implements the feature requested (feel free to ‘up-vote’ it, if you’d like native support for this):