Oscilloscope Power Probe Logic Analyzer

[cr0sh]

Has anybody else here seen this:

Oscilloscope Power Probe

I just ran across it while doing an ebay search for logic analyzers.

I have an inkling of how it works, but I was wondering if anyone has played with this particular tool, how well it works, whether it would be worth buying, etc. Also - ideas on how to replicate it...? I have a 100 MHz Fluke Combiscope that might go well with it...

I also ran across the ChronoVu USB logic analyzer during the same search (which has software that runs under Linux - which is a plus in my book):

**broken link removed**

 

[Reloadron]

I didn't see a price on the Power Probe? Did I miss it?

Ron

 

[MikeMl]

Think of it as 14 parallel n-bit serial-in serial-out shift registers, where n is likely 1024 or 4096. Unless I missed it, it seems to quantize the inputs to just a 1 or 0; not to 8bits, like a digital O'scope.

A "time base" has to sample all of the inputs concurrently, and shift the bits into the shift registers.

To read out the 14 traces, there has to be a state machine that cycles through the 14 SRs, and is also hooked to a DAC, which progressively DC-offsets each scope trace below the one above it. The state machine also has to trigger main scope, or possibly generate a X deflection signal to the scope (so that the time-base in the scope is not used).

 

[BrownOut]

These work simply by digitizing and capturing the input signals, then multiplexing the digital signals with a shifting DC bias so they display like a logic analyzer. You can totally duplicate it, and I've seen articles in the past for such projects. I didn't catch the price, so I can't say it wouldn't be better just to buy it.

Keep in mind that each signal stream is a new trace on the o'scope, so you will probably get flicker. That is one inportant way it would differ from a 'real' logic analyser. It should also in include a couple analog channels to be a complete tool. If you're looking for a simple logic analyzer, give the USB units a good look too.

Awhile back, someone linked a project for a logic analyzer using a uController development board. My idea is to use an FPGA dev board and USB to make a logic analyzer, just so I can say I made it myself. That is, if I ever get enough time away from work so I can work on my projects.

 

[cr0sh]

I didn't see a price on the Power Probe? Did I miss it?

Ron

Here's the Ebay auction I saw - note that I don't know for certain if seller on this auction is the same guy behind the website:

**broken link removed**

If it is, he values it at $100.00 (buy-it-now price).

 

[cr0sh]

These work simply by digitizing and capturing the input signals, then multiplexing the digital signals with a shifting DC bias so they display like a logic analyzer. You can totally duplicate it, and I've seen articles in the past for such projects. I didn't catch the price, so I can't say it wouldn't be better just to buy it.

Keep in mind that each signal stream is a new trace on the o'scope, so you will probably get flicker. That is one inportant way it would differ from a 'real' logic analyser. It should also in include a couple analog channels to be a complete tool. If you're looking for a simple logic analyzer, give the USB units a good look too.

Awhile back, someone linked a project for a logic analyzer using a uController development board. My idea is to use an FPGA dev board and USB to make a logic analyzer, just so I can say I made it myself. That is, if I ever get enough time away from work so I can work on my projects.

Your's and Mike's explanation is kinda how I was figuring it was being done; what I don't understand is why the cables seem short? Is the external trigger being used (I was thinking the Z-input would be used to blank the trace as it was moved vertically - but it being so short - and on both of my scopes the Z-input is on the rear - so maybe blanking of the trace isn't needed)?

I'm not currently "in the market" for a logic analyzer, but I figure that someday I would be; that USB scope I posted seems the like the best bet for me (it doesn't seem as advanced as a Saleae Logic device, but I've been waiting forever for Saleae to make a Linux port of their software, which they say they are working on - if I have to go with their competition, so be it).

Even so, this seemed like a neat device, and would allow me to use the scopes I already own (and yeah, I realize there would be flicker) - but I am kinda wary of spending $100.00, considering how cheap the USB logic analyzer scopes are (and how simple this kind of device would be to construct - in theory).

 

[BrownOut]

The probes aren't actually that short. There is a resonably long ribbon cable, and short breakouts from it ( the probes ) That's pretty typical of a logic analyzer. You want to make the breakouts short as possible to reduce the length of uncontrolled impedance. Also, there are 3 BNC connectors, one of which I would guess would be for the external trigger, so that the display triggers at the beginning of each signal stream, regardless of it's 'level'. The other two are probably for two channels. That's my guess anyway.

 

[cr0sh]

The probes aren't actually that short. There is a resonably long ribbon cable, and short breakouts from it ( the probes ) That's pretty typical of a logic analyzer. You want to make the breakouts short as possible to reduce the length of uncontrolled impedance. Also, there are 3 BNC connectors, one of which I would guess would be for the external trigger, so that the display triggers at the beginning of each signal stream, regardless of it's 'level'. The other two are probably for two channels. That's my guess anyway.

I was actually wondering about the BNC cable length; the ribbon cable you would likely want as short as practical or possible, for the reason you stated, of course. If it is using external trigger, and not the Z intensity, that would make sense on their length (though I wonder why you don't see the trace all over the place on each channel? I'm missing something...).

 

[BrownOut]

I'm not sure what you mean??? By "all over the place" do you mean why do all the traces line up at the on the time axis???

 

[cr0sh]

I'm not sure what you mean??? By "all over the place" do you mean why do all the traces line up at the on the time axis???

I guess I mean that I haven't played with an oscilloscope beyond measurement/check of waveforms; certainly not anything to do with external triggering. What I need to do is look up some information on external triggering and what it means/how it works, while playing with one of my scopes (I've only owned a real scope since earlier this year; never had a need for one before, and found the Tek at a price that was right - prior to that, the last time I played with one was in tech school in 1991).

I assume (and I am probably wrong) that by "external trigger", it means to start the horizontal motion of the trace on "trigger" of a signal (and looking at my scopes, that could be any number of things depending on the settings of various front-panel switches, etc); but doesn't the horizontal sweep of the trace continue, and you output the various voltage levels (y-axis) on each trace (in a dual trace scope); but if that is true, and you are simulating multiple traces by moving the the vertical position of a trace as it sweeps - there seems to be a couple of issues:

1) you better be quick, or the periods of the waveform won't line up; even if you are very quick, they still will likely be off by some amount - the more simulated traces, the worse it is
2) this vertical movement should (unless its super-quick? I don't know!) leave a trace as it moves from simulated trace to simulated trace - because you aren't blanking the beam(s) - right?

So - like I said - I am missing something - obviously, it has to do with how the scope uses external triggering, what it means, etc. I'm sure it was covered very briefly at my tech school, but that's going on 20 years ago, and since I haven't played with a scope or anything since then, my memory is a little rusty (and to be honest, if they did mention it - it was super brief, and we never did anything with it - so it likely made even less of an impression on me).

Maybe you or someone else here can explain it, or point me to a resource regarding it (beyond my manuals, of course)? I'm here to learn...

 

[Reloadron]

As to dual trace it actually comes in a few flavors. You want to display for example two vertical channels on the scope. Most scopes especially the earlier ones offered to ways to do it. There is an alternate mode where the trace completes a full sweep then alternates to the other to the other trace and do the same. This method is used at the faster sweep speeds. Then we have the chop mode where an internal chopper switches vertical channels at a chop rate. Early scopes that used chop switched channels at about a 1 KHz rate. Therefore at sweep rates below 1 mS / Div they were practical. So what the scope is doing is actually displaying two vertical channels using a chop or alternate process. That holds true for most CRT type scopes anyway.

Currently visiting my mom for Christmas and somewhere in the basement with all my old stuff is an external chopper for a scope. This thread got me to thinking about it. Maybe I'll drag some of the other old things out and home.

More later on triggering and things. Got grand kids bugging me.

Ron

 

[BrownOut]

There are two basic modes for triggering a scope; internal trigger and external trigger. For the internal mode, the trigger is developed within the scope's circuitry from the signal being viewed/displayed. For external mode, a connection is available on the scope for a signal other than the one being displayed to be used as the trigger. Thus, you can view a waveform of a signal while triggering the sweep from a totally different signal. That would handy for an application such as this, because each sweep of the scope is at a different DC level, and the level of the internal trigger is set once and thus does not change. Therefore, only one of the displayed signals would have the proper level to trigger the scope, at most. If on the other hand, a trigger signal was developed for each of the many different signals being displayed, and it was at the same levle for each, then the external mode can be used to synchronize every signal to the sweep, and since every signal is synchronized to the same point, they are synchronized to each other. Now, I don't know if that's exactly how this particular product works, but this description represents one way to accomplish signal/sweep synchronization.

) you better be quick, or the periods of the waveform won't line up; even if you are very quick, they still will likely be off by some amount - the more simulated traces, the worse it is

In "normal" triggering mode, the sweep begins at the left edge of the display, sweeps across to the right edge, returns back and waits for the next trigger. The sweep won't start again until it receives the next trigger from the device. In "auto" mode, the sweep will start, return and start again if there is a trigger or not. In that case, the trigger needs to arrive before the next sweep starts, which depends on the time base and retrace time.

2) this vertical movement should (unless its super-quick? I don't know!) leave a trace as it moves from simulated trace to simulated trace - because you aren't blanking the beam(s) - right?

As above, in the case of a "normal" mode, the trace is waiting at the left edge of the display, and not moving across the visible portion. In the "auto" case, the change should happen during the retrace period, where the beam is "blanked" and not visible. You might see a little vertical movement at the left edge of the display, depending on how your scope handles retrace, etc. But that shouldn't affect how the signals display much.

Hope this helps.

 

[cr0sh]

Hope this helps.

Ok - your explanation does help, and it seems to confirm how I thought it worked; thank you.

I am thinking now that maybe my thinking is "wrong" in regards to how I thought the device worked: My thinking was that as the trace(s) were swept, all "n" number of virtual traces were created, by moving the y-axis up/down to the proper positions based on the reading of the shift-registers (or whatever is used). This would obviously leave a "smear" of the trace "all over" the screen.

However, if instead of that, you triggered once for each virtual trace, and output the waveform for that trace, then moved "down" to the next voltage level, and triggered the trace and output for the next virtual trace, and so on (for all the virtual traces) - basically like a raster scan (except you vary the voltage of the trace to produce the square waves at its vertical offset, instead of intensity). Does this make sense?

I could see how by that method, that would work fairly well (but with a bit of flicker, likely).

Something else I was wondering - I was looking into serial shift registers last night on Mouser, and all I could find (at best) were 64 bit quad devices (in various packages) - for a maximum "daisy-chained" register of 256 bits; to get up to a 4096-bit length for that many samples (as suggested before), would require 16 of these devices, and you would need such a chain per channel. It was working out to be several hundred dollars just in shift registers!

I have a feeling that if you really wanted to replicate this, you would either use a fast microcontroller with enough memory (internal or external) - or some kind of FPGA or such (that you would have to custom program) to implement the shift registers yourself (or maybe you would do a combination of both methods). FPGAs are well beyond me, but I think I could do something with a microcontroller.

This is all very fascinating and interesting; definitely something I will be thinking about for a future project!

 

[BrownOut]

However, if instead of that, you triggered once for each virtual trace, and output the waveform for that trace, then moved "down" to the next voltage level, and triggered the trace and output for the next virtual trace, and so on (for all the virtual traces) - basically like a raster scan (except you vary the voltage of the trace to produce the square waves at its vertical offset, instead of intensity). Does this make sense?

Sounds like you have it

Something else I was wondering - I was looking into serial shift registers last night on Mouser, and all I could find (at best) were 64 bit quad devices (in various packages) - for a maximum "daisy-chained" register of 256 bits; to get up to a 4096-bit length for that many samples (as suggested before), would require 16 of these devices, and you would need such a chain per channel. It was working out to be several hundred dollars just in shift registers!

Hmmm...? Using an FPGA would be very helpful. I can help you get started, but it won't be cheap. I think I paid about $250 for my simple Spartan dev board. If instead of storing all the samples in registers, you stored them in a memory array, then you would only need to store enough info per channel to capture the signal during the memory cycles, as each channel is stored. Also, you might think about this: sampling each channel faster than the system clock rate may not be necessary. For example, of you only intend to display, say 10 clock samples, then you generally need only 10 samples per channel. You won't catch any glitching that way, but it would be a start.

 

[Reloadron]

If you want to experiment a little with a relatively inexpensive device maybe something like this in about the $50 range. Gives you 8 channels and runs USB on any PC. They are obviously not high speed data acquisition but considering fifty bucks they work fine for most basic apps and signals. Additionally beyond the included software they are easy to write your own programs around.

Ron

 

[BrownOut]

One more thing, if you intend to display repetative signals, your storage requirements shrink to nothing. Otherwise, I was just thinking, if you used a 16-bit SRAM running at 50Mhz, and had 16 channels, then you get 50 M-samples per channel. And you only need a single 16 bit shift register per channel. If you want to double that rate, the you can parallel another 16 bit SRAM, but then of course, you'd need another DMA for the each additional SRAM.