EEVblog #879 - R&S 1202 Scope Bandwidth Hack Investigation

[Fungus]

Screams: The SPI bus problem is obvious! SPI can have several devices on the bus and the scope has two of those chips in it.

When you change bandwidth it updates both chips. The data/clock you're seeing one one scope is the data being sent to one chip, the data/clock you see on the other is the data being sent to the other chip. Only one of the two will generate a CS pulse on your piece of wire.

[RogerRowland]

But I guess I was involved in the same way working field service for mini-computer systems in the 1970s. Several of the options (but not all) just involved me as the field engineer to just remove or add a jumper or two, and for that the customer 'purchased' that specific option, function, or feature.

Yes, I think this "trick" has been around as long as software. In my first job as a computer operator on an ICL 2903 in 1977, when the engineer came to upgrade the operating system (using several boxes of punched cards), he told us that the faster performance from the higher fee we paid was simply a reduction in the counter values of some time-wasting loops built in to the OS.

[EEVblog]

Screams: The SPI bus problem is obvious! SPI can have several devices on the bus and the scope has two of those chips in it.

Some other busts has more than 24 cycles on them, so clearly more than just the other front end chip.

[richfiles]

But I guess I was involved in the same way working field service for mini-computer systems in the 1970s. Several of the options (but not all) just involved me as the field engineer to just remove or add a jumper or two, and for that the customer 'purchased' that specific option, function, or feature.

Yes, I think this "trick" has been around as long as software. In my first job as a computer operator on an ICL 2903 in 1977, when the engineer came to upgrade the operating system (using several boxes of punched cards), he told us that the faster performance from the higher fee we paid was simply a reduction in the counter values of some time-wasting loops built in to the OS.

I collect vintage calculators. There were hacks back in the late 1960s and early 70s that's similar to this practice on some models (I think Singer Friden did this in particular). They had a model that featured the Square Root function, and another model that did not. The chip set that made up the calculator (yes... chip set  ) had the square root function built in, and running a second chip set just to remove the function would not have been economical. Instead, they had an extra memory on the chip, and different models would either use one memory or two, have square root or not... and it was all in how they connected the keyboard matrix. I believe the square root function was a $100 option, on top of the calculator's base price!

Smart buyers who knew better could pop the top and either add a wire to jumper the extra memory key to the square root key (easily reversed, incase the calculator needed servicing), or if they were a bit bolder, they might buy a momentary pushbutton switch from their local electronics store (or grab it from the parts bin) and wire in the square root as it's own key, and save the extra memory function.

So basically, they were charging $100 to wire a switch differently, and add a function that was there all along!

[Fungus]

So basically, they were charging $100 to wire a switch differently, and add a function that was there all along!

Yep. It makes perfect sense to do that unless you can save a lot on the internal hardware. The extra cost of running two production lines and managing two supply chains adds up to a lot of $$$ in the real world.

[German_EE]

Getting past this is an exercise in timing. After CS goes low there is a half clock period then 24 rising SCLK clock pulses during which data is transferred to the chip. We need bits 6,7 and 8 held low so that means from the falling edge of CS a delay of 14.5 SCLK pulses, then the SDIO line clamped low for 3 pulses, then a delay of 6.5 SCLK pulses. Either side of the three filter bits are D5 and D9 which must be held low anyway so this makes the timing easier.

Get the values right and we could do this with a 555 timer.

Note: All data fields held low in the filter field means maximum bandwidth

[Helix70]

Isn't it possible that the scope is not adjusting the top rating of this VGA at all? Maybe all of the bandwidth models select 750Mhz as the top range, and the firmware is just restricting the horizontal timebase? That would give better -3dB performance and rise times and still limit the usable "bandwidth" of the scope.

I had a similar thought but it would seem a little odd to adjust the bandwidth at all if that were the case. Maybe, just maybe, there's an even higher bandwidth version in the pipeline?

However it works I'm now interested in seeing those LMH chips on a board in front of me, they look like great fun and could potentially be very useful for me if I can make them behave.

Then why the 700 mhz instead of 350mhz limit for the top 300mhz model?

[rch]

Getting past this is an exercise in timing. After CS goes low there is a half clock period then 24 rising SCLK clock pulses during which data is transferred to the chip. We need bits 6,7 and 8 held low so that means from the falling edge of CS a delay of 14.5 SCLK pulses, then the SDIO line clamped low for 3 pulses, then a delay of 6.5 SCLK pulses. Either side of the three filter bits are D5 and D9 which must be held low anyway so this makes the timing easier.

Get the values right and we could do this with a 555 timer.

Note: All data fields held low in the filter field means maximum bandwidth

And yet R&S didn't use the maximum bandwidth setting on their maximum bandwidth scope, although  the setting they did use is well above the nominal 300MHz.  Perhaps the maximum bandwidth setting isn't stable in their setup?

Edit: optimistic bandwidth units

[EPTech]

Hi there,

Yeah, I like German_EE's solution.

How about this: use a counter that is reset on the CS, and a decoder that will keep the filter bits all low (AND with the data line). You don't even have to worry about clock timing that way.

Great idea's!

[Fungus]

Then why the 700 mhz instead of 350mhz limit for the top 300mhz model?

Simple: Because they can!

 

[rs20]

Then why the 700 mhz instead of 350mhz limit for the top 300mhz model?

Simple: Because they can!

 

Correct. But more specifically, Helix70, you must remember that a stated bandwidth is a -3dB point, not a brickwall before which attenuation is 0.0dB, and after which attenuation is infinite.

As such, if the rest of the circuitry has a bandwidth of 300 MHz, and the preamp is configured to have a bandwidth of 350 MHz, then the bandwidth of the system as a whole will be considerably less than 300 MHz. I don't have the most attuned intuition, but I think even two typical 350 MHz blocks connected together will have an overall bandwidth of less than 300 MHz.

For more details about this, see: https://www.eevblog.com/2014/01/25/eevblog-572-cascading-opamps-for-increased-bandwidth/

Long story short, you want to set your bandwidth exactly once, and keep all other bandwidths well above that point.

[Fungus]

Screams: The SPI bus problem is obvious! SPI can have several devices on the bus and the scope has two of those chips in it.

Some other busts has more than 24 cycles on them, so clearly more than just the other front end chip.

Looks like you started to twig towards the end of the video. 

[MadTux]

Any idea what part that 8pin C6648Z chip is? Left and above the Atmel ARM in this pic:
Perhaps that is the SPI EEPROM with options in it?
https://www.flickr.com/photos/eevblog/24126444969/in/album-72157661401340554/

Since it is all build from non proprietary parts, there probably isn't any asymmetric crypto in it. Thereby the firmware should be interchangeable between different units. Only question is where the options are saved, either in that M29W128 flash chip or in some external SPI ROM. That ARM has 160kB ROM in it, so that also might be used to save options (every unit starts in piss poor config and is that updated by writing the ROM, since obviously no downgrade is possible using ROM)

[EPTech]

Hi there,

Options are usually stored in an external (serial) EEPROM instead of a program flash, the main reason being: embedded software engineers consider it dangerous to erase a page in the program flash and it can be, depending on the storage scheme that they use. It is safer to store that stuff in a separate memory and if for any reason it gets corrupted, one can still revert to default settings so the device is at least usable. If the program memory gets corrupted by whatever bug or glitch, it may render the device unusable. BUt then again, these modern scopes also have some internal storage area for traces and setups. If the serial eeprom is on the small side  it may be that they use a larger (separate) parallel flash for internal storage and possibly the options. If there is only one parallel flash, it is safe to say it is dedicated to the application program. Besides. Processors that run their application from external flash usually fetch instructions directly from external flash. So unless they run part of their code from an internal program flash, it is impossible for them to execute instructions and erase/write some option bits in a shared flash at the same time. Some processors can self program internal program memory though.

I have seen a youtube video where the poster claims his Rigol scope has suddenly turned into a fully optioned, max bandwidth version after some weird event. Possibly his external eeprom got corrupted and it defaults to the best usage case, being max bandwidth and fully optioned. Maybe worth trying to lift the MISO pin on the external eeprom. Who knows what will happen. If you lift the MOSI pin as well and monitor it, the application processor may even try to write back default values in the external eeprom. 

[CJay]

So another company who restricts in software to get people to overpay.

 I kind of agree, it just seems wrong somehow.

 It's not adding to the manufacture's cost to offer full bandwidth over the lowest bandwidth version, so it's a marketing device, no? I guess they can say that all their competition do the same so they have to do the same. But that just sounds like an 'industry collusion' kind of thing against the buyers/consumers of the device.

 But I guess I was involved in the same way working field service for mini-computer systems in the 1970s. Several of the options (but not all) just involved me as the field engineer to just remove or add a jumper or two, and for that the customer 'purchased' that specific option, function, or feature.

 I would be curious to hear of others opinion on this pricing via firmware configuration settings with the hardware being identical all the same?

It seems wrong to me, sure if the 'option' was an extra module of firmware like a protocol decoder or FFT function then I could understand the extra cost, that's a license/IP issue and rightfully chargeable but just to enable the full functionality of the hardware that you've already bought, no...

The problem comes with the silly IP and anti piracy laws that abound, I think it'd entirely possible that publicising 'hacking' the hardware could land someone with a DMCA takedown (and I know, that's a US law but youTube as well as an awful lot of the other content platforms pay attention to those things as they're US companies)

[Fungus]

So another company who restricts in software to get people to overpay.

I kind of agree, it just seems wrong somehow.

You'd prefer that they built physically different hardware for each model and sold them that way? 

Result: It would cost them more money to manufacture and that cost would be passed along to you, the customer. ie. You lose.

It's not adding to the manufacture's cost to offer full bandwidth over the lowest bandwidth version

Yes it is.

Their costs (ie. R&D, manufacturing, salaries, office rent, marketing, etc) have to be spread across the entire range] of products. The profit margins on the high end models partially offset the lower margins on the low end models.

If they only sell one model with everything unlocked it would have to be sold at a higher price than the low end model. ie. You lose again.

It's basic economics...

[rch]

The problem comes with the silly IP and anti piracy laws that abound, I think it'd entirely possible that publicising 'hacking' the hardware could land someone with a DMCA takedown (and I know, that's a US law but youTube as well as an awful lot of the other content platforms pay attention to those things as they're US companies)

(And you can be extradited too!)   But Rigol *hasn't* complained.   And a Keysight rep hinted on this forum that his firm would not be over-concerned if hobbyists hacked their scopes.  The system of differentiated prices for businesses (which could after all  in theory be contractually enforced if not by firmware merely by agreement and audit) and enterprising hobbyists being able to get a higher rate scope at a reasonable price seems to be good for everyone.  Except for people like me who are too frightened of breaking the scope!

[CJay]

So another company who restricts in software to get people to overpay.

I kind of agree, it just seems wrong somehow.

You'd prefer that they built physically different hardware for each model and sold them that way? 

Result: It would cost them more money to manufacture and that cost would be passed along to you, the customer. ie. You lose.

It's not adding to the manufacture's cost to offer full bandwidth over the lowest bandwidth version

Yes it is.

Their costs (ie. R&D, manufacturing, salaries, office rent, marketing, etc) have to be spread across the entire range] of products. The profit margins on the high end models partially offset the lower margins on the low end models.

If they only sell one model with everything unlocked it would have to be sold at a higher price than the low end model. ie. You lose again.

It's basic economics...

I'd think rather the other way round, after all it's one platform that's been developed, the 300MHz version and then they limited it.

It's somewhat unlikely they aimed for a 100MHz product and then found it accidentally worked at 300MHz so extra effort and cost has to have gone into *adding* the restrictions.

Margins may be different across the range but somehow I don't think R&S are a stupid company, certainly if I were running a company I'd be ensuring that my costs were covered and profit was made from the base model only, any extra profit from the high end is just gravy (albeit profit that could be ploughed back into extra R&D over and above forecast)

Would be interesting to work out a component cost for this or a similar 'scope (I am not anti profit, it's essential to ensure the survival of a company)

[jnz]

Margins may be different across the range but somehow I don't think R&S are a stupid company, certainly if I were running a company I'd be ensuring that my costs were covered and profit was made from the base model only, any extra profit from the high end is just gravy (albeit profit that could be ploughed back into extra R&D over and above forecast)

That's.... Not a good idea. That's how you wind up with a garbage line. You shoot for the moon in development. You don't plan on making and making your money on a base line product. That's some design-by-committee think. This is why we had gererations of Motorola Razor and flip phones before the iphone changed the game.

You're glossing over the fact that they make a 300Mhz model and artificially knock it down, allowing them to leverage the volume and design time of one hardware design - OR - they design two unique hardware models, which means the 300Mhz and 100Mhz customers both pay more for them.

They are using the model that makes the most sense. It's not "unfair" to anyone, if you want to hack it, go right ahead, if you hack it and still think they need to support it - that's a whole different issue.

[Fungus]

if I were running a company I'd be ensuring that my costs were covered and profit was made from the base model only

Then your base model will be more expensive than your competitors'. They'll sell more, you'll sell less than you planned for.

This will increase the amount money you need to earn with your next generation of oscilloscopes and that makes them more expensive than the current generation. Rinse, repeat. Go bankrupt.

They are using the model that makes the most sense. It's not "unfair" to anyone

It's actually fairer to the people with less money to spend.

[CJay]

Margins may be different across the range but somehow I don't think R&S are a stupid company, certainly if I were running a company I'd be ensuring that my costs were covered and profit was made from the base model only, any extra profit from the high end is just gravy (albeit profit that could be ploughed back into extra R&D over and above forecast)

That's.... Not a good idea. That's how you wind up with a garbage line. You shoot for the moon in development. You don't plan on making and making your money on a base line product. That's some design-by-committee think. This is why we had gererations of Motorola Razor and flip phones before the iphone changed the game.

You're glossing over the fact that they make a 300Mhz model and artificially knock it down, allowing them to leverage the volume and design time of one hardware design - OR - they design two unique hardware models, which means the 300Mhz and 100Mhz customers both pay more for them.

They are using the model that makes the most sense. It's not "unfair" to anyone, if you want to hack it, go right ahead, if you hack it and still think they need to support it - that's a whole different issue.

Umm, yeah, that's what I said, they developed a 300MHz 'scope and then limited it to create a series. They didn't accidentally design a 100MHz 'scope and find it worked at 300MHz.

I didn't suggest they should support a hacked model, I'd be amazed if they would and I'd certainly never expect it.

[CJay]

if I were running a company I'd be ensuring that my costs were covered and profit was made from the base model only

Then your base model will be more expensive than your competitors'. They'll sell more, you'll sell less than you planned for.

This will increase the amount money you need to earn with your next generation of oscilloscopes and that makes them more expensive than the current generation. Rinse, repeat. Go bankrupt.

How does that work out? They sell every base model in the series at less than cost?

I doubt that very much.

[Fungus]

How does that work out? They sell every base model in the series at less than cost?

They can do that if they're selling enough high end models, yes.

Why would they do that? To put their competitors out of business.

In reality they probably wouldn't sell at less than cost but the margins will be too slim to sustain the company of they didn't sell any high-end models.

[H.O]

Guys, there's a already 640 posts long thread discussing why manufacturers do it the way they are, why people takes advantage of it and why some people think those who do are unethical crooks. Do we have to get into all that in this thread as well?

[pa3hfu]

Further investigation stopped...??