Oscilloscope recommendations

[rct]

If you have a Rigol DS1052E and plan on modding it to a 100 mhz scope via the simple hack that has been posted, you need to be extremely careful about how you enter the commands to change the model number and serial number. If you use a serial cable and a terminal emulator as described in the EEVblog entry, you CANNOT make ANY mistakes while entering the commands. The backspace key / delete key /return keys will not work, the rigol doesn't try to interpret those control characters when it receives a serial string so it will just store those as part of the strings. The extra characters will change the length of the stored model/serial string and could cause unintended side effects. Quite a few people have reported success, but a few have had problems after upgrading.

If you do go the serial route, do your typing in another window such as notepad, and then very carefully copy & paste the lines one at a time without a return, then enter a control-J (or alt-010 as mentioned in the video) to enter a newline (linefeed). Make sure when you select the line for copying that the selection ends and the last character and doesn't extend past it which would cause it to enter the return.

http://www.eevblog.com/2010/03/31/eevbl ... z-ds1102e/

[didier]

rct your post makes a lot of sens. In fact, I used a simple micro$oft terminal emulator on the first attempt... and finally I use my own (CommWithMe, funny nale isn't it?) application, and it worked like a charm. I retrospectively feel like I have been lucky. Just think about the billion pointers lost in blue sky...
So yes, caution must be taken, absolutely.

[sirket]

So I might as well comment on the Tektronix MSO4054 I ended up buying.

Mostly- the scope is _awesome_. It's a big scope- primarily because of the 10.4" screen. As big as it is- for mixed signal work- the 12.1" screen on the Agilent would have been nice- but it simply would not have fit on my desk at that point.

The MSO4054 has more options, menus and buttons than any scope should have. It can do just about _anything_, but it takes a long time go get use to all the options available to you. That's not to say they're hidden or hard to find- some are right in front of your face- but that fact that they exist at all is a surprise after coming from a much smaller TDS2024B. The Run/Stop and Trigger functionality covers 7 pages of the trigger menu. Like I said- options up the wazoo. Once you figure out how to actually use the scope- it's just a pleasure- oddball problems you would never have guessed at jump right out at you. Runts and other transient problems- right in front of your face. It's just plain wonderful.

The build quality of the scope is pure Tektronix. Solid as a rock, well built, well proportioned, and easy to use. I've yet to play with the Mixed Signal capabilities- but hopefully those will prove as useful as the Scope channels have.

If anyone has any questions about this scope please don't hesitate to ask and I will do my best to answer.

[sirket]

Having now used the mixed signal capabilities- all I can say is - man oh man where were you all my life???

I have an 8 bit bus with a number of other signal lines involved. I was getting behaviour I could not explain- threw the logic analyzer on it- and it looked good- but the signals remained high a bit too long. Left the logic analyzer on, added a couple of scope probes and then I could see the bus bits on the logic analyzer and the bus waveform itself on a scope probe. Lo and behold- there's a nice sharp rise but an RC circuit showing up on the falling edge. It shouldn't be there but it is. Added some termination resistors and while still not perfect, the waveform is now within the timing specs.

Awesome, just awesome. I could have gotten here just using the scope probes but it would have taken forever. With the mixed signal stuff I just put the data bus, part of the address bus, R/W line and system clock on the logic analyzer. Then I play my favorite Sesame Street game- "One of these things is not like the others." Throw a scope probe on that line and problem solved!

I really wish the Salae and other basic logic analyzers would come with more than 8 channels. That's enough for an 8 bit bus- but then you can't watch the clock line or anything else. The MSO4054 has 16 digital channels plus the 4 scope channels- enough for 8 bits of address bus, 8 bits of data bus, and the clock and other important signals on the scope probes.

[mojo]

Usually you don't need to monitor all the data lines on a wide bus, just maybe a couple of them and the control lines. That's why budget LAs are mostly fine for that sort of thing. You just check that the bus is working and within spec, and perhaps monitor say 4 bits of data to confirm that you have the right endianess and your hardware is reading it correctly. The actual protocol stuff you will need to do on your hardware since you can't monitor it directly, but that's the trade off between a budget LA and an expensive one.

I did think about getting one of the Chinese 16 channel LAs which are actually a bit cheaper than the Logic, but the software put me off a bit. You have to pay for the protocol analyzers and it wasn't clear if there was any kind of API to develop your own. Since I mostly do serial stuff with either I2C, SPI, 1wire or custom protocols like the Nintendo 64/GC/Wii/Dreamcast bus which need custom analyzers anyway I felt that the versatility and speed of the software gave the Logic an edge. If I was doing higher speed or parallel stuff I would have got the Chinese one.

Out of interest, I presume you can save your logic analyzer output to a USB flash drive or something for later analysis. Also, does it do any protocol analysis, and what is the highest sampling frequency? I wish I had the money for something like that, not that I have any immediate need for it

[sirket]

Usually you don't need to monitor all the data lines on a wide bus, just maybe a couple of them and the control lines.

I'll have to disagree with you there- I like being able to verify that the bits getting written are the ones I expect. And in this particular case- it was only three of the 8 data lines that was displaying this RC behaviour- something I might have missed if I only looked at the lower 4 lines.

Out of interest, I presume you can save your logic analyzer output to a USB flash drive or something for later analysis. Also, does it do any protocol analysis, and what is the highest sampling frequency? I wish I had the money for something like that, not that I have any immediate need for it

It does embedded serial (SPI, I2C), computer serial (rs232, rs485), video, I2S and a variety of other protocols, depending on which software modules you have installed. Mine is set up for both serial types. This scope can save to USB, compact flash, or can be accessed and controller by Ethernet, which makes subsequent analysis much easier.

It's a 500MHz scope with 2.5 GS/s on the analog channels and I forget what on the digital channels. It does 1024x768 resolution and can be connected to an external monitor as well. It was expensive but I am very very happy with it.

[mojo]

I'll have to disagree with you there- I like being able to verify that the bits getting written are the ones I expect. And in this particular case- it was only three of the 8 data lines that was displaying this RC behaviour- something I might have missed if I only looked at the lower 4 lines.

Sure, but my point was that for people such as myself who are not as rich as you a 8 channel LA can be used to do the same thing, it just takes longer because you have to do four lines at a time or whatever. It's a trade off between money spent on equipment and the time saved by having those extra features. I'd love to drive a Subaru but my Mitsubishi gets me there, just not as fast

It does embedded serial (SPI, I2C), computer serial (rs232, rs485), video, I2S and a variety of other protocols, depending on which software modules you have installed. Mine is set up for both serial types. This scope can save to USB, compact flash, or can be accessed and controller by Ethernet, which makes subsequent analysis much easier.

It's a 500MHz scope with 2.5 GS/s on the analog channels and I forget what on the digital channels. It does 1024x768 resolution and can be connected to an external monitor as well. It was expensive but I am very very happy with it.

Wow, that's a nice 'scope. I should probably have phrased by question a bit better though. What I meant was can you write your own protocol analyzers or save the raw data in some usable format like CSV to import into a spreadsheet or app? Being such a powerful 'scope I would imagine it's possible.

[sirket]

Sure, but my point was that for people such as myself who are not as rich as you a 8 channel LA can be used to do the same thing, it just takes longer because you have to do four lines at a time or whatever. It's a trade off between money spent on equipment and the time saved by having those extra features. I'd love to drive a Subaru but my Mitsubishi gets me there, just not as fast

I wasn't criticizing your choice of analyzer- I just don't know why manufacturers arbitrarily decided on multiples of 8- it would cost trivially more to add an extra line and then you could trigger on a clock while watching the data bus. It would be oh so much more useful (and everyone I know that does embedded design agrees).

Wow, that's a nice 'scope. I should probably have phrased by question a bit better though. What I meant was can you write your own protocol analyzers or save the raw data in some usable format like CSV to import into a spreadsheet or app? Being such a powerful 'scope I would imagine it's possible.

As I said- I can control is via USB or ethernet and have access to all the raw data- so yes- I can write my own protocol analysis tools. That said- I can't stress how useful the mixed signal capabilities are. Being able to see that there was a really bad decay on the lines was only possible with a scope- and being able to see how these lines compared to the rest of the bus was also important.

It's not for everyone- and you can certainly do it with other tools- but the speed and simplicity was simply astounding.

I bought this scope because I had more money in my budget than I expected at the end of the year so I bought a tool I really wanted.

[mojo]

I wasn't criticizing your choice of analyzer- I just don't know why manufacturers arbitrarily decided on multiples of 8- it would cost trivially more to add an extra line and then you could trigger on a click while watching the data bus. It would be oh so much more useful (and everyone I know that does embedded design agrees).

I see where you are coming from. The reason multiples of 8 are so popular is because most commonly available memory is 8 bits per word (or some multiple of , as are many buses, microcontrollers/cpus and other hardware. Buffer ICs come in packages of 8 for die. You end up in a situation where if you want a 9 bit interface you might as well go the whole way to 16 because much of the cost is for parts which support another 8 bits and it will also make processing the data much easier as you don't need to start packing bits or anything like that.

I imagine the reason the Logic is 8 bit is simply because that's the number of I/O lines the FPGA core can easily deal with at high speeds. It's basically a reference design with some I/O lines exposed.

As I said- I can control is via USB or ethernet and have access to all the raw data- so yes- I can write my own protocol analysis tools. That said- I can't stress how useful the mixed signal capabilities are. Being able to see that there was a really bad decay on the lines was only possible with a scope- and being able to see how these lines compared to the rest of the bus was also important.

I had a similar issue with an I2C bus. In the end it turned out that one of the pull-up resistors was simply not conducting at all. It's the first time I have ever encountered a completely dud resistor. This was before I got my 'scope and it took me a while to figure out with just the LA, so I can appreciate what you are saying.

[sirket]

I see where you are coming from. The reason multiples of 8 are so popular is because most commonly available memory is 8 bits per word (or some multiple of , as are many buses, microcontrollers/cpus and other hardware. Buffer ICs come in packages of 8 for die. You end up in a situation where if you want a 9 bit interface you might as well go the whole way to 16 because much of the cost is for parts which support another 8 bits and it will also make processing the data much easier as you don't need to start packing bits or anything like that.

I kept thinking that most of these small logic analyzers were nothing but an FPGA with no buffers. I have _no_ idea why I kept thinking this.

I imagine the reason the Logic is 8 bit is simply because that's the number of I/O lines the FPGA core can easily deal with at high speeds. It's basically a reference design with some I/O lines exposed.

None of the basic FPGA's I'm familiar with should have a hard time dealing with 9 lines rather than 8 but the USB bus could also be a problem- it's hard to say. I shouldn't be so quick to complain.

I had a similar issue with an I2C bus. In the end it turned out that one of the pull-up resistors was simply not conducting at all. It's the first time I have ever encountered a completely dud resistor. This was before I got my 'scope and it took me a while to figure out with just the LA, so I can appreciate what you are saying.

Yeah- I had another amazing experience with this scope- a friend of mine and I are building a 68B09 based system. The very first step we were taking was to initialize a 16c550 UART. For some reason we kept getting the wrong characters back.

We connected the data bus, address bus, read, write and clock lines to the logic analyzer and triggered on the CS strobe for this device using a scope probe (so it was nice and visible on the display).

Once we verified we were sending the correct characters on the data bus to the UART we figured maybe we were initializing it incorrectly. So, using the 10 megapoint memory, we set a single trigger on the CS strobe while holding the system in reset, and then let it go. We then scrolled through the various accesses. At each point we verified that we were writing not reading, that the correct register was selected on the address lines, and that the correct value was on the data lines (there are only 3 or four accesses so this only took about a minute).

Once we were certain we were writing the right values we decided to then read back the registers. This time when we scrolled through we saw that we were writing a 0131h but when we read the register back it was coming back 0000. We figured maybe we were initializing the chip too quickly after reset, added a delay, and poof- everything worked!

We went back over the datasheet and could not find a specific value for the delay after a reset. Considering that the processor was starting up and accessing the ROM before the UART ever got spoken to, and they both get the same RESET pulse, we still can't imagine why it wasn't ready.

I can't _imagine_ having had to solve this problem without this scope. In the end I imagine we would have simply added a delay out of desperation, or perhaps moved on to initializing the RAM first only to find out that the UART was now working. It would have worked- but we would have spent weeks wondering _why_ and worrying that the problem might return.

[Entropy]

I imagine the reason the Logic is 8 bit is simply because that's the number of I/O lines the FPGA core can easily deal with at high speeds. It's basically a reference design with some I/O lines exposed.

None of the basic FPGA's I'm familiar with should have a hard time dealing with 9 lines rather than 8 but the USB bus could also be a problem- it's hard to say. I shouldn't be so quick to complain.

Sample memory is probably the main limitation here (in addition to the aforementioned buffer circuit issue). External SRAMs are usually in multiples of 8. Not sure about internal BRAMs. I know the new Open Logic Sniffer uses multiples of 8.

[mojo]

I kept thinking that most of these small logic analyzers were nothing but an FPGA with no buffers. I have _no_ idea why I kept thinking this.

You are correct, they are.

None of the basic FPGA's I'm familiar with should have a hard time dealing with 9 lines rather than 8 but the USB bus could also be a problem- it's hard to say. I shouldn't be so quick to complain.

The USB bus is byte oriented which means 9 bits would have to be packed into 16 with either a lot of waste or some packing/unpacking at either end. Also keep in mind that a lot of FPGA stuff is actually implementations of CPU cores and the like, which are almost all based on some multiple of 8 bits. So yes, in theory it is not a problem for the FPGA in terms of signal processing limits but it is much much harder to implement since you can't use standard libraries or reference implementations without massive amounts of complex modification.

Yeah- I had another amazing experience with this scope- a friend of mine and I are building a 68B09 based system. The very first step we were taking was to initialize a 16c550 UART. For some reason we kept getting the wrong characters back.

We connected the data bus, address bus, read, write and clock lines to the logic analyzer and triggered on the CS strobe for this device using a scope probe (so it was nice and visible on the display).

Once we verified we were sending the correct characters on the data bus to the UART we figured maybe we were initializing it incorrectly. So, using the 10 megapoint memory, we set a single trigger on the CS strobe while holding the system in reset, and then let it go. We then scrolled through the various accesses. At each point we verified that we were writing not reading, that the correct register was selected on the address lines, and that the correct value was on the data lines (there are only 3 or four accesses so this only took about a minute).

Once we were certain we were writing the right values we decided to then read back the registers. This time when we scrolled through we saw that we were writing a 0131h but when we read the register back it was coming back 0000. We figured maybe we were initializing the chip too quickly after reset, added a delay, and poof- everything worked!

We went back over the datasheet and could not find a specific value for the delay after a reset. Considering that the processor was starting up and accessing the ROM before the UART ever got spoken to, and they both get the same RESET pulse, we still can't imagine why it wasn't ready.

I can't _imagine_ having had to solve this problem without this scope. In the end I imagine we would have simply added a delay out of desperation, or perhaps moved on to initializing the RAM first only to find out that the UART was now working. It would have worked- but we would have spent weeks wondering _why_ and worrying that the problem might return.

An interesting tale. You are making me envious of your mixed signal diagnostic power-tool

It's something I have come across a few times too, particularly with LCD display controllers. I had one which would never work when first powered on but would be fine after a reset. Using an ordinary 2 channel storage 'scope at my university's lab I eventually realised that it was due to the microcontroller (an H8) beginning to execute as soon as the 3.3V rail rose over about 3.2V, at which point the 5V rail was still on it's way up and not stabilised. Since the LCD controller used 5V an extra delay was required to account for the supply rise time.

I find that this sort of thing is more common with copies of popular ICs. Again LCDs are a good example as there are many compatible controllers available. For what I can only assume are marketing purposes they often omit things like reset times if they are worse than the original part. Then you wonder if it's your fault something doesn't work or the manufacturer's.

Another thing I found when I was studying at college (age 16) level was that my understanding of electronics rapidly increased once I had access to a 'scope. Somehow being able to visualise signals makes them a lot easier to comprehend. Maybe some people are fine with just the raw maths but for me even a graph in a book helps a lot. I have always been a lot better at digital electronics than analogue but now I am finding the latter to be a lot more intuitive.

[sirket]

The USB bus is byte oriented which means 9 bits would have to be packed into 16 with either a lot of waste or some packing/unpacking at either end. Also keep in mind that a lot of FPGA stuff is actually implementations of CPU cores and the like, which are almost all based on some multiple of 8 bits. So yes, in theory it is not a problem for the FPGA in terms of signal processing limits but it is much much harder to implement since you can't use standard libraries or reference implementations without massive amounts of complex modification.

16 bits for 9 is hardly a big deal on the USB bus.

As for the logic side- If they are, in fact, FPGA's with no buffers then I am definitely confused.
It's basically a parallel to USB connection- no need for processor cores or anything else. Still- I haven't bothered to design one so I probably shouldn't criticize.

It's something I have come across a few times too, particularly with LCD display controllers. I had one which would never work when first powered on but would be fine after a reset. Using an ordinary 2 channel storage 'scope at my university's lab I eventually realised that it was due to the microcontroller (an H8) beginning to execute as soon as the 3.3V rail rose over about 3.2V, at which point the 5V rail was still on it's way up and not stabilised. Since the LCD controller used 5V an extra delay was required to account for the supply rise time.

In our case- both chips were coming off the same 5volt rail, and the UART was in fact closer to the reset and should have been done resetting first.

I find that this sort of thing is more common with copies of popular ICs. Again LCDs are a good example as there are many compatible controllers available. For what I can only assume are marketing purposes they often omit things like reset times if they are worse than the original part. Then you wonder if it's your fault something doesn't work or the manufacturer's.

In this case we were using a genuine Motorola 68B09 and a TI 16C550 UART.

Another thing I found when I was studying at college (age 16) level was that my understanding of electronics rapidly increased once I had access to a 'scope. Somehow being able to visualise signals makes them a lot easier to comprehend. Maybe some people are fine with just the raw maths but for me even a graph in a book helps a lot. I have always been a lot better at digital electronics than analogue but now I am finding the latter to be a lot more intuitive.

I agree completely wrt to visualizing waveforms. As for the digital versus analog- digital is simple enough- almost every time I run into problems it's because of analog characteristics present in the digital waveform- ringing, bouncing, etc.

[mojo]

16 bits for 9 is hardly a big deal on the USB bus.

As for the logic side- If they are, in fact, FPGA's with no buffers then I am definitely confused.
It's basically a parallel to USB connection- no need for processor cores or anything else. Still- I haven't bothered to design one so I probably shouldn't criticize.

We are drifting way off topic now but basically USB is a complex protocol which needs some processing in order to service. At it's simplest a parallel to USB converter needs to be able to interpret packets on the USB bus and respond with the correct set-up data (device and configuration descriptors), then process bulk transfers via an endpoint. There is also some protocol management stuff like checking CRCs and doing re-transmits if required. The Logic doesn't have much of a buffer itself either so there needs to be additional code to manage the buffer and signal buffer overruns if the USB interface can't keep up.

Maybe you could do all that as pure logic on an FPGA but I am unaware of any designs which do. They all have some kind of code execution because it's just so much easier to do that way.

Going back to the point about 9 bits padded to a 16 bit word, sure it's not hard to do but you are missing the point. Since it's either a choice of wasting the other 7 bits or going to all the extra effort of packing/unpacking 9 bit words you might as well just use all 16 bits. That is why most logic analysers have multiples of 8 inputs. Sorry if I'm repeating myself but I really don't think it's that difficult to understand.

I agree completely wrt to visualizing waveforms. As for the digital versus analog- digital is simple enough- almost every time I run into problems it's because of analog characteristics present in the digital waveform- ringing, bouncing, etc.

No offence but your inability to grasp why logic analysers tend to have multiples of 8 inputs suggests otherwise.

To give an example I have found my Logic very handy when working on timing issues or emulating existing but poorly documented protocols. For example I recently improved compatibility with some models of the Playstation 2. Of course there is no official documentation for the controller protocol in the public domain but based on what people have discovered and my own readings taken from a real PS2 controller I had a working system. For some reason a few models of PS2 and one type of PS2 to USB converter didn't work though. It turns out that it's because those devices were starting the next byte too soon and not leaving enough time for the controller to ACK the last one. Sony PS2 controllers work because they can ACK and read/write bytes at the same time, but my hardware and several third party controllers could not. It seems that Sony realised this too as after two revisions that had the problem (and one of them on only one of the two ports for some reason) they fixed it. Fortunately I was able to modify my code.

[sirket]

No offence but your inability to grasp why logic analysers tend to have multiples of 8 inputs suggests otherwise.

Of course offense was meant- That's the only reason anyone says "no offense."

I also wasn't referring to logic analyzers in general- I was specifically referring to the super basic FPGA based ones:
"I really wish the Salae and other basic logic analyzers would come with more than 8 channels."

The Salae is a beautiful device. I own one and I like the ergonomics of the design as much as it's capabilities. It's small, simple, quick to set up and configure. Adding 1 more channel to trigger on would not have impacted the case design, or really added to the probe cost. Adding 8 more wires and ez-hooks would have increased just the material cost by about $30 (based on the pricing for those accessories on the Saleae web site) without taking into account the price of the newer, larger case design (or possibly having to move to a larger FPGA or any one of a hundred potential differences). That said- I know nothing of the economics involved so I could be even more wrong.

Not to mention- having to break out another 8 channel pod- when all I want to monitor is one additional channel- is frustrating. It's 7 additional wires in the way.

I spend a lot of my time tripping over poor design decisions. "Why not add another 8 channels" is the kind of mantra that engineers love and bad designers accept. (Like when Agilent/HP first went to digital scopes and replaced all the standard controls with menus and buttons and so on). A good tool doesn't have superfluous trappings. 12 channels is useful for an 8 bit system but 9 would be enough. 17 would be enough for a 16 bit system.

I understand why larger logic analyzers have data paths that are multiples of 8- the storage RAM is all in multiples of 8- the buffers, amplifiers and so on also all come that way (Although 12 channel buffers and such are often available). I was specifically referring to inexpensive USB based LA's that don't actually have any of these constraints. (Mixed signal devices all provide additional channels and are thus incredibly useful as a result).

If you're going to design a new product- you should do a lot of real world research into usage patterns, competitors shortcomings, etc. Just because everyone else does something one way- doesn't mean you have to too. In fact- it's probably a good way to differentiate your product.

If you want a much better idea- Rather than waste those additional 8 bits on 8 more data channels- why not provide a single extra channel with a rudimentary scope like functionality with 8 bits of resolution. Now you've given people a trigger channel that they can also use to help find oddball analog problems, along with 8 digital channels. It doesn't need to be super accurate or fast- just enough to keep up with the digital channels and hopefully provide a tiny bit more insight into a problem.

... For some reason a few models of PS2 and one type of PS2 to USB converter didn't work though. It turns out that it's because those devices were starting the next byte too soon and not leaving enough time for the controller to ACK the last one. Sony PS2 controllers work because they can ACK and read/write bytes at the same time, but my hardware and several third party controllers could not.

You should document your troubleshooting experience (if you haven't already) and post it here (on the forums obviously- not this thread ). People might find the process relevant to their own problems- the inferences you made- the missteps you took, etc. It would be doubly useful since you used the Saleae and that's going to be what a lot of people here end up using.