Author
Topic: Rigol DS10xxZ firmware re-write (Read 18932 times)

As outlined in http://www.eevblog.com/forum/buysellwanted/wtb-broken-rigol-ds10xxz-scopemainboard/, I started to look into re-writing the RigolDS10xxZ firmware. The goal is to provide new software for the iMX as well as for the FPGA so we have an open-source (software) scope that's easily hackable. To be very plain: this hasn't happened yet. But I still want to open this thread in case other people want to work with me.

Motivation

The motivation for this effort is that the Rigol DS10xxZ is a dirt-cheap scope with okay-ish hardware that's hackable. Other scopes either have inferior hardware, are more expensive, have weird application processor architectures for which no open toolchains (compiler, debugger, infrastructure in general) exist, or use ASICs. The DS10xxZ is in sweet spot where it's affordable, uses off-the-shelf chips, ARM architecture, Xilinx Spartan-6 FPGA (for which a free toolchain exists), and is decently-spec'ed. I understand there are other scopes which are similar, but it seems the Rigol one is most popular.

(It is a valid question whether a Zynq-based scope would be a better target, and I would immediately say "yes" if availability for these wouldn't be so poor at a sub-400EUR price point.)

What I have today

I can boot Linux, which means we have:

USB

LCD/Framebuffer

Ethernet

Frontpanel LEDs

Frontpanel buttons

u-boot is here: https://github.com/tmbinc/rigol-ubootI load u-boot via JTAG/OpenOCD and then boot from USB-storage, I haven't yet looked into writing u-boot to flash. I'm not saying that Linux is the ideal choice, but it's a good test vehicle to validate that the hardware works.

There's a lot of things to figure out - including the whole "scope" part, the FPGA pinout, the FPGA<>iMX communication.

Out of curiosity, what in particular would you be looking to improve in an eventual open-source firmware versus the standard firmware? Obviously there's a lot of work to do just to get to parity with the factory firmware, but just curious about your ultimate motivation.

Off the shelf products always do 99% of the things you want, but there's no way to get that last 1% unless the manufacturer happens to add it. If there's a decent open base you can code it yourself.

There's also changing the way the manufacturer did things to better suit your requirements, workflow, etc. Granted, an open source project don't always result in something that's on par or better than the original, but it opens the possibility to do more, do it differently, or keep it going longer than the manufacturer wants to support it.

If it could come anywhere close to the success of the open source firmware available for popular broadband routers then that would really be something. A scope seems a lot more complex, at least on the surface, but perhaps it's actually not. I don't know how much of the "magic" is done in hardware and how much relies on the software.

What i.MX is that? I'm currently repurposing a kindle 4 as a datalogger (I love that eink display), it's an i.MX508. Amazon has published most of the gpled code and there's a lot of info @ mobileread.com. Have you managed to get any sources? from Rigol perhaps? That would help a lot.

Oh, what a pity, that -to me- sounds like bad news. I can read the sources of the eink driver and not have to figure it all out. Or see exactly how/what does it do to read the battery's mAh from the gas gauge chip, etc.

But my project is essentially different because as I'm not trying to use the kindle as a kindle anymore I don't need to use nor understand any of its apps (whose sources aren't available), but you will have to. I have even deleted them already! With the sources headers and configs I can compile my own drivers and apps and be happy.

But no sources at all? No, I for one would be totally lost if I were you!

Hi,saw this featured on Hackaday, so i decided to join the party. I call a Rigol MSO1104Z (one with logic analyzer) my own. I like the scope, but i think it could perform better. Its mostly aliasing(REALLY ANNOYING), slow interface responding and an XY-Mode (that is actually a joke) which could be well improved. Try to put oscillofun on it and you see what i mean. Maybe we can add more features like XYZ-Mode, SDR stuff, eye diagrams and others.

Since I'm into SDR and Spartan 6 Ill try to help where i can.

To the RE:I think theres a chance of getting the firmware and bitstreams of the FPGA, but because of the nature of FPGA's it will be next to impossible to RE the bitstreams. Thats bad because the HDL is directly coupled with the software. I would start with getting the full schematic together and then find out how it is driven and how it performs tasks like calibrating, selftest and so on.

Since this is my only scope im not going to tear it apart, maybe ill find another one on ebay.

I just bought my ds1054z yesterday and now such a thing happens!One might take a look at the DSO quad community firmware (wildcat) which is an OSS app to drive the tiny oscilloscope. It is quite feature-packed compared to theoriginal software and might be easy to port over and be a starting point. The hardware is different (Lattice ICE65) but the verilog code is out there, quite simple and might be also possible to re-target.I am unsure if its a good idea to port it rather than start from scratch, but at least it´s something worth to take a look at.