EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog on May 13, 2016, 03:47:33 am
-
Dave investigates how the front end bandwidth limiting works on the Rohde & Schwarz 1202 series oscilloscope.
Is the bandwidth limit set just by the LMH6518 front end Variable Gain Amplifier chip through the SPI bus?
https://www.youtube.com/watch?v=3THvWEKGOwE (https://www.youtube.com/watch?v=3THvWEKGOwE)
See the extended 50 minute version here that has much more detail and mucking around trying to get the R&S1202 to probe itself.
https://www.youtube.com/watch?v=HiqtXdK1Dtk (https://www.youtube.com/watch?v=HiqtXdK1Dtk)
-
Super interesting video Dave. I'm hoping someone on here comes forward to take it to completion with a lower BW version of the scope and confirms your suspicions. I could watch these kinds of exploratory analysis videos all day. I'm working on something sort of similar for a particular big red tool company that has lithium-ion battery chargers for their cordless line. For now I'm deciphering the SMPS before I get into the more interesting microcontrollery bits.
-
Super interesting video Dave. I'm hoping someone on here comes forward to take it to completion with a lower BW version of the scope and confirms your suspicions.
Yes, I need to either be able to remove the 300MHz license, or have a low bandwidth version before I can make hardware to verify it.
Of course it's likely the time base might not be as fast as the licensed version.
-
Regarding the trigger problem: From the video it is rather obvious: The scope resets the trigger system when changing settings probably to avoid false trigger pulses when changing bandwidth or voltage range. Therefore trigger pulses are being blocked while changing the mode, so it can't trigger when writing the bandwidth setting.
That does not affect normal operation, because you don't care about a missed trigger pulse when changing settings, because it would be most likely a false trigger pulse.
-
Regarding the trigger problem: From the video it is rather obvious: The scope resets the trigger system when changing settings probably to avoid false trigger pulses when changing bandwidth or voltage range. Therefore trigger pulses are being blocked while changing the mode, so it can't trigger when writing the bandwidth setting.
That does not affect normal operation, because you don't care about a missed trigger pulse when changing settings, because it would be most likely a false trigger pulse.
Correct. I realised this later on in the video. Still did not explain why the R&S did not trigger on the CS line.
-
Regarding the trigger problem: From the video it is rather obvious: The scope resets the trigger system when changing settings probably to avoid false trigger pulses when changing bandwidth or voltage range. Therefore trigger pulses are being blocked while changing the mode, so it can't trigger when writing the bandwidth setting.
That does not affect normal operation, because you don't care about a missed trigger pulse when changing settings, because it would be most likely a false trigger pulse.
Correct. I realised this later on in the video. Still did not explain why the R&S did not trigger on the CS line.
Same problem. The trigger gets blocked for some time after changing settings to allow the new settings to settle.
The data with the missing CS signal was some other data on the SPI bus that has probably nothing to do with the frontend settings, therefore the trigger is not blocked and the scope can capture it.
Nevertheless it is an interesting video. It shows once again that it is a bad idea to use measurement equipment to measure itself unless you know exactly what you are doing because you most likely get false results. It is like using a frequency counter to measure its own reference frequency...
-
That was an very interesting video.
I'm too clumsy for this sort of mod.
I'm using steel-needles with soldered on wires and put them to the via / ic-pin I want to temporaly tap in and hold them in place with an insulated rare earth magnet placed on the other side of the board.
-
The scope can't trigger while setting up the channel so it couldn't catch the chip select. The data you was catching was other devices on the bus.
-
Hi there,
I see an opportunity here.
Cut the SPI traces to the IC and bodge a smal MCU in between and write a small program that receives the SPI from the scope on one end and send through to the IC with the filter bits modded of course. ;D
Or put a small MCU over the bus and do the same but take control of the bus during a time where you are absolutely sure the bus is idle.
I do not know which one is easier, either the above or jtagging the application processor and figuring out what it is doing at exactly the time the register is written to. I leave that up to the hackers.
-
Cut the SPI traces to the IC and bodge a smal MCU in between and write a small program that receives the SPI from the scope on one end and send through to the IC with the filter bits modded of course. ;D
Or put a small MCU over the bus and do the same but take control of the bus during a time where you are absolutely sure the bus is idle.
I see 2 ways here -
1 - cut all 3 wires (MOSI, CLOCK, CS), put something like arduino nano between, read configuration bits by its hardware SPI interface, output modified configuration by software emulated SPI. Plus you can easily add LCD screen and buttons to manually change bandwidth. That would look funny.
2 - cut only data wire, put in AND logic, and do the mod with discrete logic witch counts clock pulses (only when CS is low, and reset count when CS is high) and force puts low only required bits. For example it can be based on 74HC161 counters + 74HC154 decoder and a dip switch array to set low any bit in a packet.
-
2 - cut only data wire, put in AND logic, and do the mod with discrete logic witch counts clock pulses (only when CS is low, and reset count when CS is high) and force puts low only required bits. For example it can be based on 74HC161 counters + 74HC154 decoder and a dip switch array to set low any bit in a packet.
Yeah, I like a classic solution like that.
-
The scope can't trigger while setting up the channel so it couldn't catch the chip select. The data you was catching was other devices on the bus.
Yep, that must be it, the scope can't do both at once.
-
As others have pointed out, the scope obviously disables all triggering while it configures of the frontend. That seems like a sensible decision to avoid false triggering. So the scope disables triggering, configures the frontend, then re-enables triggering.
Dave was trying to trigger on the configuration of the frontend, which is then futile, because triggering is disabled exactly during that time period.
The data signals that he saw were just signals for other chips on the bus, at time periods when triggering was enabled again. Probably confusing, but the non-matching length and lack of chip select signal could have been a hint.
-
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.
-
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.
-
I have seen video's ;) where a scope is hacked and both the bandwidth and the time base setting were affected. Not sure is this is the case with this model.
But is it really necessary to have the shorter time base? Sure if you are taking the leap from 100MHz to for instance 500MHz. It is already worth the effort to have more HF components displayed (at a realistic amplitude) and the higher rise time on those slopes of course.
-
It would be nice to retest with a second scope and see how the VGA is configured.
-
Just a quick thought, but if even you did change the SPI packet to the device - are we sure that's the ONLY thing that is registering to make that bandwidth happen?
For example... If on the front end they when in 300Mhz mode they change the scaling or line thickness, or storage, or averaging, or whatever - the scope front end would still think it's in 100Mhz mode, when the variable gain amp is in 300Mhz mode.
So isn't there a chance something would be wonky by causing a disconnect between the front end and the setting the gain chip gets?
-
So another company who restricts in software to get people to overpay.
-
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?
-
So another company who restricts in software to get people to overpay.
I think that's back to front logic.
While the reaction is not surprising you can't really say they built a 100MHz scope that can do 300MHz. Seriously, what designer could get away with that?
It seems to me that the practical approach is to design and build a 300MHz scope for the purpose of selling to those who need that bandwidth. Once you have that design, it can be hobbled to produce a lesser capable product for practically no real cost and offered for sale at a lesser price, thus increasing overall sales. There is a marketing term for this.
The proper response is to thank the manufacturer for making a version of their 300MHz scope available at a price more people can afford - with the simple trade-off of bandwidth. JMHO
-
Just a quick thought, but if even you did change the SPI packet to the device - are we sure that's the ONLY thing that is registering to make that bandwidth happen?
99% sure.
To be 100% sure all you need is someone to test a lesser bandwidth mode and see that it sets the 200MHz or 100MHz bits in the chip.
-
So another company who restricts in software to get people to overpay.
I think that's back to front logic.
While the reaction is not surprising you can't really say they built a 100MHz scope that can do 300MHz. Seriously, what designer could get away with that?
It seems to me that the practical approach is to design and build a 300MHz scope for the purpose of selling to those who need that bandwidth. Once you have that design, it can be hobbled to produce a lesser capable product for practically no real cost and offered for sale at a lesser price, thus increasing overall sales. There is a marketing term for this.
The proper response is to thank the manufacturer for making a version of their 300MHz scope available at a price more people can afford - with the simple trade-off of bandwidth. JMHO
100% agree, if they had to make a new design for each bandwith model, the prices of all models will go up. I think thats overpaying
-
Isn't it possible that to avoid this kind of hacks, they also implement a digital lowpass filter in FPGA, ASIC what so ever. Even if analog part passes full BW signal it can be filtered in digital domain, yet it may not be practical to do this, I don't know internals of scopes very much :-BROKE.
-
Dave investigates how the front end bandwidth limiting works on the Rohde & Schwarz 1202 series oscilloscope.
Is the bandwidth limit set just by the LMH6518 front end Variable Gain Amplifier chip through the SPI bus?
https://www.youtube.com/watch?v=3THvWEKGOwE (https://www.youtube.com/watch?v=3THvWEKGOwE)
See the extended 50 minute version here that has much more detail and mucking around trying to get the R&S1202 to probe itself.
https://www.youtube.com/watch?v=HiqtXdK1Dtk (https://www.youtube.com/watch?v=HiqtXdK1Dtk)
Thanks Dave:- Yet another interesting hands on video that imparts knowledge and experience to us Young and Old Ones.
-
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.
-
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.
-
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.
-
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 ;D ) 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!
-
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.
-
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
-
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?
-
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
-
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!
-
Then why the 700 mhz instead of 350mhz limit for the top 300mhz model?
Simple: Because they can!
:-//
-
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/ (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.
-
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. ;)
-
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/ (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)
-
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. 8)
-
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)
-
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...
-
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!
-
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)
-
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.
-
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.
-
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.
-
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.
-
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.
-
Guys, there's a already 640 posts long thread (https://www.eevblog.com/forum/testgear/reasons-for-hacking-dsos/) 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?
-
Further investigation stopped...??
-
How do you actually enter the upgrade keys on one of these scopes?
Is it through the front panel, like a Rigol? A special file on a USB stick? How?
What information doe R&S need to be able to make you a key? Serial number?
Anybody been through the process?
-
Generate the license key directly from http://voucher.hameg.com/. (http://voucher.hameg.com/.) Download the key code and transfer it to your device via USB stick
-
Generate the license key directly from http://voucher.hameg.com/. (http://voucher.hameg.com/.) Download the key code and transfer it to your device via USB stick
Hmmm....
Unfortunately the keygen isn't in javascript on the web page.
It's a start though.
Next step would be a ROM disassembly :popcorn:
-
Unfortunately the keygen isn't in javascript on the web page.
Gosh darnit, those sneaky buggers -- always one step ahead! :P
-
Has this 'nice project' been stopped...??
-
I just watched the extended video and yes, I was jumping up an down and yelling at Dave just like he predicted but I see you guys figured it out; the oscilloscope disables acquisitions while updating the configuration making the chip select and other things invisible to the oscilloscope itself.
On the subject of programmable options which you have to pay for, think instead of a 300 MHz oscilloscope which R&S also sells at a discount to users who will accept a lower bandwidth. I do not particularly like it either however in theory the market gets a product which otherwise would not exist at a lower price while R&S makes more sales even if some of them are for less profit allowing them to produce the product in the first place.
https://en.wikipedia.org/wiki/Price_discrimination
-
On the subject of programmable options which you have to pay for, think instead of a 300 MHz oscilloscope which R&S also sells at a discount to users who will accept a lower bandwidth. I do not particularly like it either however in theory the market gets a product which otherwise would not exist at a lower price while R&S makes more sales even if some of them are for less profit allowing them to produce the product in the first place.
This very topic - in particular, the circumvention of certain constraints - endured a long and tortuous discussion on this forum not too long ago. It was done to death then - and I hope it stays that way.
However, I do agree with the final point.