This question has been asked before in various forms, however no satisfactory answer found.
This is a very basic mode of capturing a digital signal: I have a pulse signal on one of the channels - it starts low, then becomes high for a few ms, then goes back down. It is like a Gate signal used in frequency meters, or like a CS signal for a SPI communication - very common. I want to capture the signal(s) on other channel(s) WHILE this signal is ACTIVE (H). The sensible way to do it is to use it as a trigger, hence trigger mode. However, in Trigger Mode Capture they say: "The trigger mode will continuously record data until a digital trigger is found on a single channel. " ! Seriously?! I DON’T CARE about the ‘Data’ while the trigger is not active! I don’t wanna see it, much less record it! Just don’t bother! The trigger is a START signal, not a STOP! What part of it they don’t understand?! (Like on an oscilloscope, if you want). I don’t want to give how many GB of memory should be used, or how many hours AFTER the trigger stops (or starts) should record. Just record whatever comes WHILE the trigger is active and ignore the rest! Is this too much to ask? Is this a very unusual case, they didn’t consider? What am I missing here?
Thanks for any input, guys!
Luka
Actually I use the trigger on a scope to capture signals around a trigger event far more often than when I only care about signals after the event. That is even more often the case with a logic analyzer where the events leading up to an event are often much more important than the data following the event.
Different strokes for different folks I guess. However you have options:
In particular you can control how much data to collect after the trigger and you can limit the total buffer size. Playing with those parameters should let you configure a capture protocol that doesn’t chew masses of memory and lets you capture all of the event you are interested in. You even have an option to trim the cruft from before the trigger! Surely you have some idea what the maximum active time for your pulse is likely to be and can set an appropriate capture time?
A further mitigation is that for digital signals only edges are captured so the memory burden for modest activity signals is very small in any case.
What you are missing is the fact that Saleae have only ever had a very small dev team (3 at present), there are a limited number of hours in a day, and a huge amount of work to do for this amazing product. Priorities have to be assigned and some (many) desirable features have to be deferred.
Thank you Mr. Jaquiery,
I am an EE with many decades of experience in electronics and programming… and always an ‘old school’ professional. I am not the kind of guy who’ s ‘playing’ with things. I’m used to know what I’m doing and what to expect as a result. I know why things work and why they don’t! Very unusual these days with the X/Y/Z ‘generations’ (I call them the ‘copy & paste’, ‘gimme code’, or ‘fuckbook’ generations). Anyways, back to my issue:
-
while there are times when wave shapes around the trigger need to be inspected, most of the time I need to see what happens after that moment. On older scopes (analog) you don’t even have that luxury - the trace is triggered by the signal and starts then. Before that - just waiting!
-
with a LA, it might also be interesting to see signals around the trigger… In my case, however, there are no “events leading to”… it is simply a ‘gate’ signal (not quite a ‘trigger’ actually, because it defines both the Start and the Stop moments). Duration: unknown. Specifically, I’m analyzing a succession of SPI writes sent to a graphic display - there can be 2-3 bytes or 10000. I want to isolate a specific portion of these commands from a quasi-continuous stream, so I’m generating the ‘gate’ signal programmatically.
The Logic 2 software doesn’t offer such a simple feature. What you suggest are just workarounds - I’ve actually used such things and was able to export the captured data, but it was a painful process, and I thought it was my lack of deep knowledge of the tool that caused it. Apparently it wasn’t.
As they say, ‘you get what you pay for’. In this case, however, it’s a lot! Not perfect, but not bad at all, especially considering the small team behind this software!
As a side note: a ‘product’ is the hardware + the software that comes with it… And many companies kind of ignore the ‘software’ part. Not necessarily Saleae, but having such a small software team is kind of telling. Anyways, the ‘side note’: I bought a couple of years ago a ‘smart watch’ made by Fitbit. Not expensive, not the greatest, but I’m satisfied with the hardware! Good display, good UI, good battery life, touch mostly works, overall more than acceptable. I’m actually happy with it. The ‘software’ - app installed on your smart phone, without which you can’t use the watch -, on the other hand, is a catastrophe! It doesn’t start, it doesn’t stop(!), it crashes, etc. A total mess and totally unusable! In the latest version(s), they didn’t correct any bugs in the software, but introduced some very intrusive advertising! Speak of adding insult to injury! And, to make matters worse, you can’t choose not to use this shitty ‘software/app’, because without it, one can not even set the time on this very ‘smart’ watch! They built a great hardware and chose to use a small team (1?), or an external contractor for the software. How hard should that be - to write an android app for a product?!
Now, the question: would I ever buy anything from Fitbit again? NO WAY! Not even if it’s free! It is just not worth the aggravation!
Anyway, thanks again for taking the time to help with my issue. I really appreciate it!
Cheers,
Luka
While I agree that such a capture mode would be nice to have, I haven’t seen such a feature implemented. A trigger has always been an ‘event’ vs. a ‘filter’ or a ‘gate’ – so you pick your trigger ‘point’ and fill the buffer before and/or after the ‘event’ is seen.
With Saleae, you can stream to PC/host memory and have a huge ‘raw’ storage buffer, and then use low or high level analyzers to post-process (filter) the data to whatever you find interesting.
This works great for digital, but not as well for analog as the storage requirements for analog are much higher – less buffer space to run as long, and more overhead to keep up with a lot of data.
Depending on the nature of your signal, you might be able to use the automation API to capture & save each ‘event’ separately, but not likely to be fast enough if these ‘events’ are too close together.
What all do you want to capture? How many channels & what type of signal (analog/digital) for each?
Saleae is just one nice tool in the toolbox, but it can’t do everything for everyone. I am just curious about what you’d like it to do, and if Saleae can’t – what other tool(s) can actually do it?
Thank you, BitBob! - you are right, what I need is not a simple ‘trigger’. I mentioned that in my post: “a ‘gate’ signal - not quite a ‘trigger’ actually, because it defines both the Start and the Stop moments”. It is like taking a snapshot of a signal over a period defined by a signal on another ‘trigger’ channel…
I’ve mentioned briefly what I need to do:
“Specifically, I’m analyzing a succession of SPI writes sent to a graphic display - there can be 2-3 bytes or 10000. I want to isolate a specific portion of these commands from a quasi-continuous stream, so I’m generating the ‘gate’ signal programmatically.”
I have access to the hardware (hence the LA) and the software generating the signals. However, the software (in C++) is so convoluted - a mish-mash of functions, defines, macros and assembly - that it is easier to ‘see’ the train of commands and data that are actually sent to the display over SPI, than to make sense of its ‘logic’. To write a single pixel to this brain-dead TFT, 3 command and 6 data bytes need to be written to it! It wasn’t as ‘easy’ as I thought, but I managed to get the data that I needed, using the LA. It is a bit rudimentary for its purpose and, like you said, the automation API would likely be too slow. It’s a tool, not as sophisticated as I thought , but it serves a purpose if well understood and used. Because I use it so rarely, I have enough time in-between to forget most of its features and intricacies. To me, this ‘gating’ looks like a very basic function, so I expected it to be available, and not finding it was due to my lack of knowledge.
All clear now, I just learned something, new thanks to you guys!
Cheers!
I wonder if the Saleae, or even an LA is the right tool for this job?
I know the Total Phase Beagle protocol analyzer is old, and cannot deal with faster SPI rates, dual and quad SPI. However, if the Beagle is fast enough for your system, it would do the job for you want, logging transfers on the bus during the gate phase.
It sounds like your gate is for portions of the SPI traffic related to display, and is independent of the CS# for the display. Using your gate as the CS# input to the Beagle, and using Data Center - very mature software - you would get the isolated traffic you are looking for.
TotalPhase is not the only protocol analyzer for SPI, just one I’ve been using for a couple of decades.
Nice point! However, you might be able to exploit the same technique within Logic software as well: using the ‘gate’ signal as the SPI chip select rather than the chip select signal itself? I guess this depends on how much you care about both signals – do you need the assert/deassert edges of the real chip select, or not? Are there SPI transactions with any other devices during your ‘gate enabled’ intervals?
Otherwise, you can at least use your ‘gate’ channel as a navigation aide within the waveform view – manually skipping to the rising/falling edges to ‘jump’ to the next series of SPI transactions that you care about. May not be as nice as filtering out everything else automatically, but could be a practical work around for your use case.
I also like my Total Phase tools – but for most ‘monitoring’ use cases I’ve been too spoiled by my Saleae logic – as it combines a low-level ‘waveform’ view (with decoded overlay/bubbles) along with a ‘data table’ to have a more ‘protocol analyzer’ type view (and both are interactively linked for easy navigation back & forth between views). I typically want to see the decoded information in the context of other signals, and like seeing the signal waveforms vs. just decoded data stream output. I know you can capture a rudimentary amount of low-level data/signal timing (in the ‘Timing Pane’ view) with Total Phase Data Center – but it isn’t anything like having a full channel/waveform strip chart view like a traditional oscilloscope/logic analyzer.
Finally, If you really want something closer to your request – you could always:
- Enhance the low-level SPI analyzer and add your own ‘gate’ channel feature to the configuration OR
- Try using a hardware bi-directional level shifter (like this one from SparkFun) with an output enable (OE) pin connected to your ‘gate’ signal
I think the hardware-based technique could be used to filter any type of digital signals (not just SPI), but might have an impact/issues on some circuit designs. You’ll need to make sure the level shifter IC you pick is compatible with your hardware design and doesn’t interfere with the original signals, and make sure your ‘gate’ signal matches the polarity of the OE pin.
If I know my SPI is clean rail to rail, nice edges, even width, then I quit worrying about the analog domain for the most part.
The roar byte stream caught on Logic is, to me, harder to read than the total phase, trying to see what came in which burst. I really need to explore more of the plug-ins, or build my own.
I look forwards to seeing where this ends and what the solution ultimately is.
Thanks for your comments, guys!
First, let me reiterate: I have solved my ‚problem‘, using the LA with the Logic 2 software. I did it in a way that seemed suboptimal to me and I thought it was because I don’t know a better one, and should be a simpler, more direct way to extract the needed data – hence my original post/question. It seems such a simple way doesn’t exist – whatever the reasons. Good enough and good to know! And I thank you for that!
@aodonnell-ca – yes, this Saleae LA might not be the most appropriate tool for this job (although I think it should). Unfortunately, I don’t have a Total Phase Beagle device, and I don’t intend to purchase one. For the kind of money they’re asking, I’d build my own 
@BitBob – the idea of using the gate signal as a navigation aide – and not as a trigger – is another nice workaround. I don’t have the test (software+hw) setup installed anymore, so I cannot compare this solution with the ‚trigger‘ one. Regarding your two proposals: 1 - I’m not sure I have the necessary skills to ‚enhance‘ the Saleae software, I’m not in the business of improving ‚half-backed‘ tools, there is no really an incentive to do that, as I only use this tool a couple times a year, and, finally, I don’t have the time to do this at the moment.
2 – not sure why should I use a level shifter…I have no problem with levels, or drive capability. I could imagine many other solutions to sniff the SPI data, based on a gate (defined Start & Stop) signal. I even considered programming a Blue Pill board to do just that, but then I thought, „Hey, I have a LA that is already made for this task!“. And indeed, although suboptimal, and not as I expected, it did the job faster than writing the software for the Blue Pill for this probably one time task.
Thanks and cheers!
P.S. Why one cannot sample one (or several) channel(s), having defined Start and Stop signals (a ‚gate‘) is still beyond me! I just do not see the logic in that (pun intended)! They didn’t see the need? Really?!
On the other hand: I’m a hardware guy, and prefer assembly (‚a bit pusher‘ as some say) when it comes to programming. I lived in an era when 1KB of memory was a lot (and expensive too) and one could do a lot with it! I know I did. So, when I see a software ‚recording‘ and writing to a hard drive Gigabytes of useless data, that no one wants to know about – just noise, basically – and ignoring information that could select/define that data, the hair stands up on the back of my neck! It seems sloppy, idiotic and borderline criminal! Replacing a bit of quality with a lot of quantity, without a second thought. Like I said, beyond me!
The purpose for your scenario was to connect the ‘OE’ pin to your ‘gate’ signal so the SPI data being monitored would only be visible to logic when it’s enabled. Basically, use it as a wired hardware ‘gate’ filter on the SPI bus, just for monitoring. You could also just use simple ‘AND’ logic gates, but the level shifter might be a more handy tool for future use cases, too (i.e., when you want the level shifting feature, or want to ‘gate’ other digital signals).
Ok, I understand what you mean: basically a buffer, or an AND gate (not necessarily a level shifter), controlled by the gate signal to let only the portion of interest pass thru. I find this hw workaround an overkill, however. It worked fast enough with the current software as it is. Not ideal, but nothing dramatic either.
Thanks!
Hej hej,
while I do not agree with everything @lucian.marin.de said within this thread, I also feel slightly disappointed in the “Digital Trigger Mode” and maybe there is a rather easy fix…
When using similar features in oscilloscopes, the time you set for pretrigger data is the maximum amount of data being held in memory, until the trigger occurs. With the trigger the post-trigger recording time is added to that memory. Voila, just the right amount of data recorded…
With the Saleae software, you get something similar… an amount of time after trigger and an option to trim pre-trigger data AFTER the recording has ended…
As pointed out by @lucian.marin.de this highly non-standard for oscilloscopes (I see why this might be interesting for LA people )…
What seems to be working is an approach, that is not possible with the Automation API, so please @timreyes or @BitBob, tell me that it is actually possible…
Within the GUI, you can set the mode to looping, which trims data after stoppping, anddoes not record more than that amount of data specified as the mrmory limit …
So, when correctly configured, the amount of data in memory (as a FIFO) would be slightly more than your combined pre and post-trigger recording time (different units, but OK)…
So during capture:
and after stopping and (triming completed):
EDIT:
And once again, do NOT write posts from memory, without rechecking behaviour with a device (not even simulated ones…)
This is exactly how the triggered mode behaves, and also from the Automation API, so…
Just set memory limit low enough and trim pre-trigger data to zero …
Cheers
Niels Göran