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?
See the extended 50 minute version here that has much more detail and mucking around trying to get the R&S1202 to probe itself.
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.
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.
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
.
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?
See the extended 50 minute version here that has much more detail and mucking around trying to get the R&S1202 to probe itself.
Thanks Dave:- Yet another interesting hands on video that imparts knowledge and experience to us Young and Old Ones.