I have an idea to design new main board for Keysight 1000 x-series scope, to make it 800MHz bandwidth. It have ADC, FPGA and processor on separated board, so I will be much easier then design all oscilloscope hardware and software for processor and FGPA. Do you have some schematics, application notes, literature and other resources, which can be helpful? I want to base on http://www.ti.com/lit/ug/tiduba4/tiduba4.pdf and on photos from Dave teardown - https://www.flickr.com/photos/eevblog/albums/72157657671196148 . I have complete schematic of Keysight main board from reverse engineering.
The best way to proceed is to politely request the source code for any instrument you own using an embedded Linux distro.
The best way to proceed is to politely request the source code for any instrument you own using an embedded Linux distro.
"Running Linux" does not universally mean "I can get source code for it". You cannot request source code of application that does not contain (or link to) GPL'ed software or parts of it. Even drivers can be proprietary, thus "closed source", if developed correctly from licensing point of view - as you correctly mention nVidia example. Those companies can afford to invest into development that does not rely on open source components, thus have no obligation to give away their intellectual property. All you can get - some irrelevant kernel code modifications that maybe show how to I/O hardware of instrument, but basically that's it. In case of scope it is even worse - because most of "business" happens not in the Linux "user land" application, but FPGA. You definitely can cool down on your idea
Duh. Yeah, entirely true. Aside from a lack of attention to grammar, what is your point?
The serious problems are in the UI, not the FPGA code.
If you think the GPL code is irrelevant, you have no clue about the subject.
I've had to maintain over 2 million lines of other people's code.
If we can read the data from the input channels and write data to the display, the rest is easy to do. It does *not* require doing something difficult like designing a broadband front end or manufacturing it. Writing a new UI is not a big deal.
I was deliberately rude because your sole interest is trumpeting that you are right and everyone else is wrong.
I suggest you read your own post. I did *not* put words in your mouth.
You have no way of knowing what I do or do not know.
Fact is I have repaired several analog scopes including a Tek 465. I also have over 30 years of DSP experience.
If you actually knew what a DSO is doing, you would not consider it very complex. It's not.
There are some significant timing challenges, but that and broadband circuit design are the only hard parts. The timing constraints pretty much dictate everything about the VHDL code for the FPGA. There's just not much wiggle room in how the logic is laid out on the device.
As regards the Agilent thread, I'd seen it, but never bothered to read it. As I suspected, it's almost entirely about enabling license options.
The primary purpose of having people ask for the source is to make clear to the the low end Chinese T & M OEMs that there is a marketing advantage to making their products "open source" and allowing the user community to write apps for the instruments.
Substantial parts of the UIs are written in a scripting language. Once one has the ability to run a script that reads button presses and sends commands to the FPGA and the ARM host, pretty much all the functionality of the unit becomes accessible. That's not a very high bar.
The T & M OEMs are using the dev tools provided by the chip makers.
If you're not interested in having an open source instrument, that's fine with me. I and other people are.
Unfortunately, you seem to have driven them away.
Your assertions amount to saying that the Chinese are able to clone competitor's instruments but no one else can even grasp how they work.
I don't recall that the Chinese invented the stuff they're making. They just copied American products using American parts.
i have used the seeed DSO nan0https://www.seeedstudio.com/DSO-Nano-v3-p-1358.html for 4 years, and studied it's hardware and firmware(seems not designed by the seeed official but some pressional firmware engineers), almost meet my daily requests , with only about 60$(purchased in their special sales.)
Funny a lot cheaper on Amazon
https://www.amazon.com/seeed-studio-TOL01241P-Nano-Oscilloscope/dp/B00BB4ETJW/ref=sr_1_1?ie=UTF8&qid=1513393398&sr=8-1&keywords=dso+nano+v3
1. Include a simple function generator so the relatively low performance DSO may be used as a low frequency network analyser. Keysight has taken a minor step in this direction but the performance of their solution is terrible; is this to prevent competition with their low frequency network analyzers? There are a couple of USB DSOs which support this but not very well.
2. Include the noise marker function in the FFT capability. I am tired of DSOs which cannot do this simple thing making them useless without a PC to do it for them and in that case, why is the DSO needed at all?
Sampling scope is already done....
http://www.fastsampling.com/PHP/products.php
4 GHz for 300+ USD, 11 GHZ for a 1000 USD... Members of the forum here tested it and said it worked quite well..
I will probably spring for a 4GHz one in months to come.. I have some work for it...
1. Include a simple function generator so the relatively low performance DSO may be used as a low frequency network analyser. Keysight has taken a minor step in this direction but the performance of their solution is terrible; is this to prevent competition with their low frequency network analyzers? There are a couple of USB DSOs which support this but not very well.
Rigol 1000Z series and Instek MSO-2000EA scopes are doing what you ask for, they both have 2-channel 25MHz AWG. Just add PC software and directional coupler(s).
That is the maddening thing about it. These DSOs have all of the necessary hardware but the firmware lacks these features. In some cases like FFTs, the firmware deliberately prevents it from being used this way but for instance discarding the phase results.
If the firmware could be rewritten this could be solved but that is never going to happen.
At present the updates are not encrypted. They *could*, but there is not a lot of CPU available. So doing that would make updates *really* slow. Moreover, the relative speed of a desktop machine with a GPU makes brute forcing the encryption key very simple, albeit perhaps slow. But so what? Let's say it takes a week to brute force the FW update key.
The OEM simply cannot use a key that is unique to each scope unless it's a hash of something like the serial number. So once the key is cracked it does not need to be done again.
If there are a large number of people who buy a scope *because* it is fully open source, the OEM is not going to should themselves in the head to prevent it. My theory is that at least one of the OEMs will decide to exploit the marketing advantage.
It's not really necessary for it to be "fully open". It just needs to be sufficiently open that it can be modified to add features and fix bugs. Doing that *is* a good bit of work, but not as difficult as it might seem. If the FPGA bitstream is working properly it doesn't matter if the source is not available at the moment.
Take a look at FW update files for a few instruments. They're pretty simple and do the obvious thing. Better yet, get a Zedboard and implement a FW updater. The minZed is about $100.
I agree with your comments about encryption, but I stand by my original comment. I am not an expert, but I learned the rudiments of cryptanalysis 50 years ago. The principles have not changed. But the nVidia and Radeon GPUs have radically changed how large a problem you can solve by brute force. Bitcoin miners are doing this at large scale.
Rigol has sold a lot of DS1054Zs by allowing the license keys to be hacked. Another OEM would get a lot of that market share if their scope were open. I don't think they would be so stupid as to fight it. Linksys restarted production of the WRT54G in response to the popularity of that device.
As I have commented previously, an important first step is to get the GPL'd source code so we can build the infrastructure from source. The OEMs are using one of several embedded Linux distros. I *very* much doubt that any of the Zynq based scopes use anything other than the Xilinx tool chain. Try selling "We're going to use a Zynq, but we don't want to use the Xilinx supported Linux distro for the Zynq." to your boss.