Add Data Output Capability

The ability to inject data makes the creation of tightly controlled test cases simpler and quicker. This also opens up the door for the Logic as a valid production test tool.

So often I've wanted just to hit a button and send a data stream down the RS232 line to save so much time and hassle when debugging!

  • Scribe
  • Jul 11 2018
  • Jul 11, 2018

    Admin Response

    What do people think about a basic $99 device that does output mode? Would it need a fancy GUI that does everything under the sun? How about a clean Python API (and editor) and lots of examples? What about voltage levels / speed requirements? Has anyone used the Bus Pirate ? What is awesome / what sucks about it? Just and idea I've been kicking around. We don't have the bandwidth for it right now but just putting it out there.
  • Mark Garrison commented
    11 Jul 21:32

    Thanks Bill! In the meantime, I should mention you can export captures you have taken with the current products in a variety of formats, which you might be able to feed into other output devices.

  • Bill Rau commented
    11 Jul 21:32

    I would find such a device to be a really neat addition to my toolbox but would need at least a relatively easy GUI as I don't know programming, or Python. Something which could playback captures from my Logic, the original version, so I could reproduce patterns recorded from a test would be great. Also the ability to do simple stuff like send 8 bit binary counts and stuff would be VERY helpful. If there were the ability to send data out in different ?protocols?, like text to Serial or Parallel ASCII, or to send MIDI data out from a MIDI file so that I could work on projects where I am trying to receive it would be nice since I could be sure what I was sending was what I was receiving. Yes this sounds like a VERY good idea for a product. Please let me know if you decide to pursue it as I will likely be one of the first to buy one.

  • roboknight commented
    11 Jul 21:33

    I've used the bus pirate. It is okay. It doesn't do I2C above 100Khz for monitor, but it does write to the bus at 400Khz. A "replay", or "selective replay" type functionality would be useful. What I've had to do in the past with i2c is basically use an antiquated monitor and then use Bus Pirate to send data out.

    Another issue, is maybe being able to capture a logic signal, for say, an unknown bus protocol, and being able to use a replay to play it back when needed.

    Of course, when playing it back, it would probably need some kind of "Expect--Response" mechanism so that you could identify the "expected data" and mark the "response" to that expected data (if you could script this by triggering on an input and then providing a "pre-recorded" waveform it would work fine if it was quick enough). This would be extraordinarily helpful, especially if you could change the response using either a GUI or a programatic interface (python would be great... I haven't had a chance to look at the SDK yet, so I don't know what all is in there). This is especially useful in today's 1-wire buses. Finally, output down to 1.8v is probably a must for many of the devices I look at, but this probably breaks your $99 price point. If you can deliver a tool like this, it would be worth a bit more.

  • Guest commented
    11 Jul 21:33

    A while back I suggested adding the capability for Logic to output a variable frequency/duty cycle signal similar to the PWMLogic s/w that was around for a while (seems to be gone now). I use that capability a lot to inject signals using my Logic.

  • Scribe commented
    11 Jul 21:33

    Really want this. I suggest to Saleae walk before you run, simply begin by exposing raw-output as an SDK/API. Gain feedback and then build upon this, consider adding functions to help users manage timings, adding some uniformity and clarity to code.

    Accessibility is my number 1 factor to a UI, I don't need single-click buttons, but I don't want to dig around for the edit window either. Macros for function or pattern reuse would save time and reduce the chance of bugs.

  • MarkH commented
    11 Jul 21:33

    What interfaces would the output mode support? For me, I am looking for I2C and SPI.

    1) I2C - support for 100 kHz and 400 kHz at a minimum, with nice to support of Hs , Fm+, and UFm.
    2) I2C - Support for clock stretching
    3) I2C - 8/16 bit addressing
    4) I2C - support for restart
    5) SPI - support for at least 10 MHz
    6) SPI - support for Single-SPI, Dual-SPI and Quad-SPI.

    One of the limitation I find with other devices (i.e., Aardvark I2C/SPI Host Adapter or QuickCAN/Q-Bridge) is the limited buffer size of 64 bytes. I would really like to see at least 256 bytes with up to 1 meg.

    For me, the GUI is the main interface I would be using as I need a nice GUI to verify embedded systems are working, but scripting would be great for running automated testing.

  • Naikrovek commented
    11 Jul 21:33

    Joe, I'm on board with that. Give it a clean API and someone out there will have a UI written for you in 10 days. THUMBS UP

  • Chris McKernan commented
    11 Jul 21:33

    I only just realized someone had already posted similar to my suggestion. If you added the ability to say, sample Channel 1 (or several), save it to disk, then replay the waveform back to the same Channel (or another, or several simultaneously). In theory there wouldn't be much UI, and scripting abilities like BUS Pirate aren't really necessary. Makes for a way to test devices with predefined data sets/wave forms. Bonus if you allowed channel data to be replayed when analog as well. This feature and Real Time view would make this device outstanding - well they're pretty good already ;-)

  • Pranav_Viking commented
    11 Jul 21:33

    A $99 Device with output would be a brilliant break through for hobbyists and students . It will add the capability of performing closed/open loop control systems.

    I believe if we ship enough examples along with few videos and white papers , the hobbyists and students would be able to work with it without any GUI.

    Cheers
    Pranav_Viking

  • alm commented
    11 Jul 21:33

    My $0.02:

    $99 price point sounds about right. Voltage levels at least 3.3 V and 5 V, ideally also lower. 8 channels, 24 MS/s with rise times in the order of the nanosecond would be sufficient for many applications and should be achievable with something very similar to the Logic hardware + output buffer.

    I love the Bus Pirate and I think it's an excellent companion to the Saleae logic analyzers. Once you get the hang of it it makes it very easy to interface using one of the slow serial buses. It's main downside in my opinion is the slow (FT232) PC interface used in v3. A recent application where this was a problem was when I wanted to send a continuous stream of data via SPI. The bus pirate is unable to repeat a pattern on its own (I didn't look into the BASIC scripting) and continuously sending commands from the PC would introduce delays.

    One thing that I think a 'Saleae Pirate' should exploit is integration with the Logic. If you buy an Agilent scope and function gen, then you can capture a waveform on the scope, export it to the function gen, and then output (a modified version of) this signal. It would be great if you could offer similar features. Ideally you would have a fancy GUI that allows you to edit the signal (cut/paste parts, change timing, move individual edges), but I'm not sure how much development resources you could commit to this.

    A Python API and a sample utility that could load a pattern from a text file and output it from the pattern gen would be a bare minimum (maybe consider sigrok integration), but Saleae's unique selling point is mainly the software in my opinion. So selling fairly basic hardware (FX2 + CPLD?) in a nice aluminum case with minimal software support might not be a good move.

  • DavidZ commented
    11 Jul 21:33

    It might be even more important that the cheapo version have the nice GUI. At $99, you might be targeting hobbyists that aren't the best or most versatile programmers (the common maker/Arduino world). They may not be interested in a more expensive device and they may have no idea how to write a script to output some SPI protocol.

    Just a thought. For me, I'm good with Python. Would I prefer a GUI? Of course. Would I happily accept (and use) an API instead? Yep. For whatever it is worth, I think either Python or Java would be excellent choices for the API.

  • Simon Diehl commented
    04 Sep 21:13

    I'm willing to pay 2 k€ and cmore for a Saleae adapter and software that is capable of data output. Just use your current architecture in reverse direction. Equip each channel with a high speed DAC and output buffers and you'll extend the capabilities by a mile. Finding a suitable FPGA shouldn't be the problem here, right? This opens up endless possibilities:

    • Generation of arbitrary analog and digital voltage signals (single ended or differential), current signals would be an addon, capacitive coupling and termination resistors for even more possibilities. I don't require it to be an SDR though.
    • Just use an external driver IC on a break out board and you'll be able to use virtually any physical layer
    • UART adapter for regular terminal use
    • Programmer, debugger and trace adapter for almost any interface with open OCD (or similar) driver support. You know the Lauterbach debugging adapter? This would be the same thing but with a much prettier case ;-)
    • Connection to PC with USB 3.1 gen 2 for sufficient data rate and power supply
    • Latency? Not a problem with an FPGA SoC that runs Linux and thus can easily synthesise a new FPGA configuration although the software development will be hell for you guys, my sympathies.
    • Matlab and LabVIEW support would fit perfect with the hardware's capabilities.

    I guess that I could append to this list for quite a while, but you get the point.

    The Saleae logic is easily the best logic analyser that I used in my life and I'd prefer it to any oscilloscope that I used before. The concept of I/O hardware and software on a usual PC ist just perfect and the optimal choice for my work. Adding analog channels to the software opened up many new capabilities that solely expensive MSOs where capable of.

    You may find some inspiration in this post, at least I hope so. Keep up the good work guys.