new Oscilloscope choice

[nctnico]

Now you make it sound that a Siglent scope is just as good as an A-brand scope 3 times the price. It just isn't in real life. Read the latest addition to the SDS200X+ thread ( https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/msg3564889/#msg3564889 ) for another example of 'rough edges'.

Rough edges aren't the same as functional bugs.

And the decoding issue that post talks about isn't a bug, but is a configuration error on the user's part.  It's something that bit me as well, until I understood what "include R/W bit" in the protocol decode config meant.

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

[Fungus]

I cut down a cheap screen protector for laptop to fit the RTB2k screen. Rather difficult to apply without dust particles behind.

That's just technique.

You need to cover the entire screen with masking tape. Peel it off just before you apply the protector.

Put little bit of masking tape on the corners of the screen to make it easy to pull the protector off again if you're not happy. Use masking tape to pick up bits of dust from the protector.

Remember that protectors can be be removed and put back as many time as you like but don't pick at the corners with your fingernails to get then off again, use a razor blade (or similar) to lift them then put a piece of masking tape underneath before using your finger to pull it off.

[kcbrown]

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

It doesn't make sense unless you want to see the entire address byte as the byte that went over the wire, rather than as 7 bits + 1 bit.

It's just a display option, nothing more.  How is it any different from other display options that you might not have a use for, but that others might?

Someone thought it would be useful.  They wouldn't have bothered to add it otherwise, because that takes engineering time, QA time (don't laugh  ), etc.

[2N3055]

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

It doesn't make sense unless you want to see the entire address byte as the byte that went over the wire, rather than as 7 bits + 1 bit.

It's just a display option, nothing more.  How is it any different from other display options that you might not have a use for, but that others might?

Someone thought it would be useful.  They wouldn't have bothered to add it otherwise, because that takes engineering time, QA time (don't laugh  ), etc.

While I agree that I don't find 8Bit address (combined 7bit address and R/W bit) useful myself, fact is that Keysight 3000T (and all Infiniivision series)  and Ikalogic logix software have a choice of 7/8 bit address.. So someone else thought it was necessary..

[Performa01]

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

It doesn't make sense unless you want to see the entire address byte as the byte that went over the wire, rather than as 7 bits + 1 bit.

It's just a display option, nothing more.  How is it any different from other display options that you might not have a use for, but that others might?

Someone thought it would be useful.  They wouldn't have bothered to add it otherwise, because that takes engineering time, QA time (don't laugh  ), etc.

While I agree that I don't find 8Bit address (combined 7bit address and R/W bit) useful myself, fact is that Keysight 3000T (and all Infiniivision series)  and Ikalogic logix software have a choice of 7/8 bit address.. So someone else thought it was necessary..

Well - purely hypothetically - what would you do if you got a contemporary A-brand DSO once in your life, wouldn't you think this has finally to be THE reference?

In a frantic attempt to bash a certain brand, especially if it's just for a feature you don't understand, it might turn out that this supposed reference has a few rough edges and is different from everything else - so much that it is the only one that has that deficit.

I'm puzzled how a Tek fan wouldn't know any better:
https://www.tek.com/support/faqs/how-do-i-set-i2c-bus-decode

The procedure to set up a I2C bus decode and trigger is simple once you understand the basics. First you have to have the correct module or scope option. Second make sure your signal is on screen and taking up as much of the DAC as possible with good resolution, this will require having proper probes and knowledge about your signal. Turn on the bus, and start by setting the channel and threashold levels. Once this is done you will begin to see your signal decode. Adjust some of the small things such as Read/Write in the Address and how you want to have the bus displayed such as Hex or binary. For a complete demonstration or further details watch the following video or look through the User Manual for more details.

[nctnico]

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

It doesn't make sense unless you want to see the entire address byte as the byte that went over the wire, rather than as 7 bits + 1 bit.

It's just a display option, nothing more.  How is it any different from other display options that you might not have a use for, but that others might?

Someone thought it would be useful.  They wouldn't have bothered to add it otherwise, because that takes engineering time, QA time (don't laugh  ), etc.

While I agree that I don't find 8Bit address (combined 7bit address and R/W bit) useful myself, fact is that Keysight 3000T (and all Infiniivision series)  and Ikalogic logix software have a choice of 7/8 bit address.. So someone else thought it was necessary..

Well - purely hypothetically - what would you do if you got a contemporary A-brand DSO once in your life, wouldn't you think this has finally to be THE reference?

In a frantic attempt to bash a certain brand, especially if it's just for a feature you don't understand, it might turn out that this supposed reference has a few rough edges and is different from everything else - so much that it is the only one that has that deficit.

You seem to fail to see that two people on this forum already got confused by this. I wouldn't be surprised Keysight will also adjust the trigger condition (7 bit / 8 bit) accordingly instead of allowing to trigger on a 7 bit I2C address and display an 8 bit number. Probably the UI is also a lot more clear. Thats why I wrote 'rough edges' and not 'bug'. Stuff that can send a less experienced engineer on a wild goose chase.

And don't for a minute think the R&S is the only A-brand scope that went through my hands. If you'd paid attention you'd know it is just one scope in a very long list of scopes I own or have owned. So your frantic attempt to downplay my remark fails miserably.

[Performa01]

... I am rather underwhelmed with the search capabilities of the Siglent.  It's a weakness that I think needs to be addressed.  The Instek is better in that regard.

Remember how I was talking about how segments are an afterthought in the Instek?  Well, it turns out that the search capability is a great example of how that's the case.  It's not available at all with segments turned on.

While it's certainly true that there could be a lot more search conditions, the segment search is definitely there, at least on the touch screen instruments starting with the SDS2000X Plus.

The following link, reply #275, shows a demonstration of how it works on an SDS5000X - it is exactly the same for the SDS2000X Plus:

https://www.eevblog.com/forum/testgear/at-last-siglent_s-sds5054x-touchscreen/msg2471931/#msg2471931

[kcbrown]

You seem to fail to see that two people on this forum got confused by this. I wouldn't be surprised Keysight will also adjust the trigger condition (7 bit / 8 bit) accordingly instead of allowing to trigger on a 7 bit address and display an 8 bit number. Thats why I wrote 'rough edges' and not 'bug'. Stuff that can send a less experienced engineer on a wild goose chase.

And yet you criticize Siglent, and not Keysight, for this display characteristic.  Whether or not Keysight's trigger condition changes in response to this display option depends on how they've set up the configuration mechanism for it in the first place.  For instance, if (as is likely) they allow you to independently specify the read/write bit value in the UI trigger specification, then they'd have to actively change the address match as well.  And note that if you have "don't care" for the address but are specifying a read/write bit value, then the display of the address would have to somehow reflect that.  How do you display "don't care" for 7 bits and the specified read/write bit for the LSB when you're displaying hex?

Point being that it gets to be a mess.  It's simpler to just leave the address and the read/write bit as separate things in the trigger configuration, and to not do anything with respect to them in response to a change in how the read/write bit is displayed.   Far better to simply have something on the trigger configuration that, when "include read/write bit" is set, alerts that displayed address values will include the read/write bit in the LSB, so that the user is keenly aware of what he'll see.

I'm curious what the R&S RTB series does with this, since an excellent UI is one of its strong suits.  If it has the option to incorporate the read/write bit in the address display, then it's likely they thought through how best to do i2c triggering with that setting in mind.

[kcbrown]

While it's certainly true that there could be a lot more search conditions, the segment search is definitely there, at least on the touch screen instruments starting with the SDS2000X Plus.

I think you may have misunderstood my meaning.  I was complaining about how the Instek doesn't have search when segments are enabled.   I've modified my message to improve its clarity in this regard.

The Siglent does, of course, have search with segments enabled because segments are a first-class citizen in the firmware, and are always on and always available, so any feature that Siglent implements must account for it.  And that was really my point: Instek's segments are an afterthought, whilst Siglent's are not.

My complaint about search on the Siglent is not with respect to the segment support, but rather that it is lacking in search conditions, particularly relative to triggering.  You can trigger on a much wider variety of things than you can search for, when the search capabilities should at a minimum be the same as the trigger capabilities, if not a superset of them.

[2N3055]

That kind of makes my point. For example R&S doesn't have this option. An I2C address is 7 bit or 10 bit (through a protocol extension I have not seen being used in the wild). Not 8 bit so why the option to display the I2C address as 8 bit? It doesn't make sense.

It doesn't make sense unless you want to see the entire address byte as the byte that went over the wire, rather than as 7 bits + 1 bit.

It's just a display option, nothing more.  How is it any different from other display options that you might not have a use for, but that others might?

Someone thought it would be useful.  They wouldn't have bothered to add it otherwise, because that takes engineering time, QA time (don't laugh  ), etc.

While I agree that I don't find 8Bit address (combined 7bit address and R/W bit) useful myself, fact is that Keysight 3000T (and all Infiniivision series)  and Ikalogic logix software have a choice of 7/8 bit address.. So someone else thought it was necessary..

Well - purely hypothetically - what would you do if you got a contemporary A-brand DSO once in your life, wouldn't you think this has finally to be THE reference?

In a frantic attempt to bash a certain brand, especially if it's just for a feature you don't understand, it might turn out that this supposed reference has a few rough edges and is different from everything else - so much that it is the only one that has that deficit.

You seem to fail to see that two people on this forum already got confused by this. I wouldn't be surprised Keysight will also adjust the trigger condition (7 bit / 8 bit) accordingly instead of allowing to trigger on a 7 bit I2C address and display an 8 bit number. Probably the UI is also a lot more clear. Thats why I wrote 'rough edges' and not 'bug'. Stuff that can send a less experienced engineer on a wild goose chase.

And don't for a minute think the R&S is the only A-brand scope that went through my hands. If you'd paid attention you'd know it is just one scope in a very long list of scopes I own or have owned. So your frantic attempt to downplay my remark fails miserably.

It is clearly explained in the manual........  Very clearly..

Configuration
There is only one item Include R/W Bit in the configuration of the I2C
decode. When it is disabled, the address is represented separately from
the R/W bit, and when it is enabled, the R/W bit is represented together
with the address.
For example, the address 0x4E: Write: Ack, is displayed as "0x4E (W)"
when the R/W bit is not included and is displayed as "0x9C"when the R/W
bit is included.

[kcbrown]

I'm curious what the R&S RTB series does with this, since an excellent UI is one of its strong suits.  If it has the option to incorporate the read/write bit in the address display, then it's likely they thought through how best to do i2c triggering with that setting in mind.

In answer to this, I went and examined the RTB2000 series user manual.  And the answer is: they don't have the option of including the R/W bit in the displayed address.

[technogeeky]

In your world there are only Boing, Lockheed Martin and looser hobby users, and nothing in between.

Education buyers who buy overpriced scopes for education are asses, because they buy 2 scopes instead of 20 with budged they have. 
Same with companies. Not every company is  military contractor, with unlimited budget (coming from taxpayers pocket and nobody can ask why, because you know ...). 
And that is super rich USA. Now enter rest of the 6,5e9 people on the world.

OK, and do you or my arguments support wider access to better technology

Siglent and Rigol scopes are good value even at retail prices, with no hacks, especially when they run specials that give you thousands of USD worth of options for free.

I didn't say they aren't (tey are). The options that give you thousands of USD don't have that kind of expected value in a world with hackable scopes; or DIY devices. And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

And open source works backward of what you said. I know open something agenda tells you different but it isn't so.
It took Linux 20 years and 10s of thousands of patches and additions to basic OS kernel and API by likes of IBM, Novell, Microsoft (yes Microsoft) etc, to make it a good, usable, operating system it is today. Open sourcing it didn't do a thing. It was free (no money) that did it.

I won't comment on the unsubstantiated claims; but yes that's exactly what I'm saying. It should be free *and* open source.

You cannot open source scope of any significance that easy. Hardware manufacturing margins are so low that all the profit comes from analysis software sitting on top of it. Why would a company do that for practically free so somebody else can make money on it. Or not, for free..

Then charge a tiny bit more and let people actually fix and improve the scopes rather than locking them in to a set of issues for the next decade? The argument is that the expected value of the software isn't thousands of dollars because many many people are getting them for $0 through hacking and discounts. So charge the extra, on average, $55 on the hardware and let a community work on the software.

It's funny how you leap from "capitalism good" A companies "deserve" to charge huge amounts of money for their scopes, to "other" companies should give it for practically free..

I dispute this has anything to do with capitalism. They should not make a loss selling the hardware, and they should not spent time staying way behind on the software  and let their end users make the experience they want themselves.

Write a letter to Keysight and ask them why they don't release opens source scope... If feel a bit of double standards there..

Yes!! I literally started my post by splitting these companies in two categories!! I don't think I could be clearer about that.

They will tell me because they have absolutely enormous software development staff that works on these devices for years adding whole clusters of analysis options of different kinds.

They wouldn't tell me, but it's clear that it's because so much of the expected value of their services are in the software options, and that open sourcing them would dilute this. Their cheap aren't so cheap that there is only a small jump, fully optioned, up to a more expensive ine.

Hive mind did answer it. We have one user that insists on specific thing, one that trolls every discussion on everything, many who think all is fine as it is, and many that don't care, because the simply use any device the way it says in a book, do the job and move on to another project. After Dave made video on it, where he mudded situation even more by talking about similar but slightly different issue, even then, nobody cared enough to make a poll. Nobody cares, it's just few loud ones that make this visible... LeCroy users like it well enough, and even on those scopes that have optional manual control, people use it in AUTO all the time...
So yeah, potential users need to know different scopes have some idiosyncrasies in a way they work, and that is it.

I don't care about that particular zoom issue. It's not the point. We had people here that moved heaven and earth to hack the 1054z to get rid of the phrase "Riglol' and they shouldn't have had to do so. There have been slight bugs and annoyances the whole time, and they don't have the staff to respond to the huge number of requests for fixes, customization, and feature addition that is required when your customer base is hobbyists (who aren't going to have the most focused bug reports) and freakin' huge.

The ecosystem and innovation in the oscilloscope market would benefit if they would stop trying to act like they have the right tools to do all the software themselves and not let the people using the damn things work on it!

[technogeeky]

The latter category, however, is driven by the hobbyists and self-selectors; the people who might not be participating at all if it weren't for the huge value presented by the hacks (and the hacks, we have to admit, at this point are a marketing strategy and not a technical oversight...). The hacks were first on the cheapest entry item (the Rigol 1054z), then some Siglent scopes, then more expensive Siglent scopes; then back to the newer, cheaper Rigol scopes...

The "hacks" are not a marketing strategy on theirselves. Most of the time, what people here call "hacks", are no more no less than taking advantage of the licensing mechanism that the manufacturer developed for adding features after sale.

Once the mechanism becomes known, the manufacturer could try to change the mechanism and we've seen it done many times. That decision to change or not the licensing mechanism is the decision that could be called in the "marketing strategy". Although, changing a licensing mechanism can present HUGE costs and technical difficulties that are hard to deal (as backward/forward compatibilities, etc.)

Bear in mind that practically ALL scopes that have licenseable options can be (or is it "have been"...  ) upgraded by others besides the vendor. The fact that only the more common and lower-priced (B and C) scopes have their methods in the public's eye doesn't mean that all A-brands haven't had their methods known under the counter in more private forums.

So, is that a "marketing strategy"? I call it a "feature" of the licenseable options world.

I meant more or less exactly this - maybe for the 1054z it wasn't intentional. But surely, at this point it must be.

And yes, tons of other devices get hacked but usually very late in life - because they don't make the sheer volume of devices, and because they spend the effort to try and secure the licensing system.

This leads in to my overall point: the volume of devices fact combined the now-it's-a-marketing-strategy fact imply that they should just go the last step. Figure out what the EV of their options package is, go ahead and charge that little bit extra in the price of the hardware (this will surely NOT close the gap between the sub-1500 market and the rest upward), then let your darn users do the software.

[tautech]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

[kcbrown]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

Like defining a stop condition that will stop the scope when it's been hit.  You'd then use the trigger to define when a capture is to be taken and use the stop condition to tell the scope when to stop performing captures.  You could then examine the segments (however many of them there might be -- depending on your timebase and the time delta between trigger event and stop event, there might be only one) to see everything in between.

I didn't come up with this, actually.  Someone named Tom Biskupic did in a comment in response to @mikeselectricstuff's video on the RTB2004's segmented memory system:

[tautech]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

Like defining a stop condition that will stop the scope when it's been hit.

Single ?

[kcbrown]

Like defining a stop condition that will stop the scope when it's been hit.

Single ?

Nope.  That just gets you one capture.  The actual stop condition might occur after multiple trigger events, and the idea here is that you'd want to capture all such events (or, at least, the last N events, where N is the number of segments you can capture based on your settings) up until the stop condition occurs.

[Caliaxy]

Hello,

I am still unsure as to what scope to purchase, after following all the replies, both the R&S RTB2004 and the Siglent SDS2104X+ both seem to be fantastic pieces of test equipment for the money.

You are the only one who can make this choice. If money is not an issue, hope you chose R&S - there is nothing like a 10 bit ADC.  Siglent seems to be a great tool, too. In a few years they’ll very likely have a 10 bit scope as well. Either one of them would be a big leap forward.

[tautech]

Like defining a stop condition that will stop the scope when it's been hit.

Single ?

Nope.  That just gets you one capture.  The actual stop condition might occur after multiple trigger events, and the idea here is that you'd want to capture all such events (or, at least, the last N events, where N is the number of segments you can capture based on your settings) up until the stop condition occurs.

There's a lot of this functionality already in X Plus and SDS5000X DSO's if you were to follow the link in Reply #158.
Once Search parameters have been properly set you can define them to Trigger conditions and tune them further.

[technogeeky]

And then there's the issue of the entire ecosystem of things you could program a scope to do that aren't even thought of by existing vendors.

Like what ? 

From my Rigol:
* letting a user define an extra virtual channels they can use for math functions, offsets, etc (constants)
* adding highlight frequency in ffts
* adding the ability to anchor the trigger point left, center, or right - R&S has this
* porting over the math functions like e.g. micsig has - arbitrary functions so you can normalize waveforms, etc
* adding overrides, like adding 2.5x or 7.5x probe values so you can do tricky offsets (some other scopes have this in hardware)

I mean, whichever scope has large sales and open source will very, very quickly have the best bus decoding features out there.

[kcbrown]

There's a lot of this functionality already in X Plus and SDS5000X DSO's if you were to follow the link in Reply #158.
Once Search parameters have been properly set you can define them to Trigger conditions and tune them further.

Sure, but that's not the point.  The point is that with an open source firmware implementation, it's possible to implement essentially anything you can think of, irrespective of what the manufacturer has implemented or has even thought of.

You asked for an example of such a thing.  Well, I think the example I came up with certainly qualifies, no?

And as for the search parameters, on the SDS2k+ they're a small subset of the available trigger parameters.  For instance, I can't search for a separate set of i2c data values within a given i2c capture.  In fact, there's no protocol search capability at all that I can find.

Most certainly the SDS2k+ series scopes are immensely capable, but that's not the point.  The point is that an open firmware scope would make it possible to do things that the scope otherwise wouldn't be able to do.  And on top of that, it would make it possible to make improvements that the manufacturer otherwise might not make.  For instance, as good as the SDS2k+ series is, its UI responsiveness (particularly to panel controls) does leave something to be desired, particularly when the scope is stopped.  There are other scopes that do quite a bit better, e.g. the Instek series, but they have their own firmware-based problems (such as the fact that segments are an afterthought and not a first-class fundamental mechanism like they are in the Siglent).

[tautech]

 
Oh no....OT another OS DSO thread ! 

Please take it elsewhere.

[kcbrown]

Oh no....OT another OS DSO thread ! 

Please take it elsewhere.

Uh, it's a bit odd to be calling the answers to your own question "OT", don't you think?

(true as the characterization may be ... )

[kcbrown]

John, to make things (un)clearer for you: the RTB is as "doctorable" as the SDS.

Really?
I thought some had started and dumped the firmware, but no real progress had been made, as most RTB users got a full-spec bundle at one of the sales.

I've got the COM4 bundle too so it's "too late" for me, but could you link to the thread where they've cracked that nut?

I, too, am very curious about this.  A link to the thread in which hacking the RTB is described would be appreciated, as it's likely to make for some interesting reading.

[tautech]

Oh no....OT another OS DSO thread ! 

Please take it elsewhere.

Uh, it's a bit odd to be calling the answers to your own question "OT", don't you think?

(true as the characterization may be ... )

More to come about the "Like what ?" later as it was a leading question and not directed at you KC. 

technogeeky has given a partial reply but not mentioned the model of scope and should really take it up with the manufacturer or in one of the threads here like this one:
https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus-bugs-missing-features-feature-requests/

Input about opensource DSO's is best sent here:
https://www.eevblog.com/forum/testgear/a-high-performance-open-source-oscilloscope-development-log-future-ideas/