On 01/01/2013 04:03 PM, Martin Ling wrote: > Hi all, > > Nice to meet several of you at 29C3! > > As some of you will know, I pulled a couple of late nights at the > congress, writing a sigrok driver for the Rigol DS1000 series > oscilloscopes. > > This code is now available on GitHub: > > https://github.com/martinling/libsigrok/commits/rigol-ds1xx2 > > It's not finished yet - this is just the state the code was at when > Bert dragged me away from the scope so he could pack it away - but it > does sort of work, so I suppose I should let you see it. :)
Uwe is working on getting this merged. > Technical details follow: > > - The code was developed and tested against a DS1052E that had been > patched to 100MHz, i.e. a DS1102E. It should work for all the DS1xx2 > models including DS1xx2D variants, however the digital channels > on those latter models are not yet supported. I have a DS1102D at > home, so I will add that support when I get back from my travels. > > - The driver supports all the same parameters as the Hantek DSO driver: > timebase, vdiv, triggersource, triggerslope, triggerpos, coupling. I > gather these are the only analog scope settings that libsigrok currently > has hwcap mappings for. Other features will be very easy to add once > further mappings are decided on, since the protocol is well documented > and provides access to all the features of the scope. In fact this scope > could be a good initial reference model for designing those mappings. I'd agree with that. The existing ones are entirely based on what I needed for the hantek-dso driver at the time, and the DSO-2090 isn't that great compared to the Rigol. > - Some further work needs to be done on the actual waveform readout. > There are two readout modes available on the scope. When running, only > a 600 sample readout is available (corresponding to the signal > currently visible on the screen). When stopped, the full 1Msample > buffer can be read. Currently, the driver assumes the scope is running > and expects the 600 sample readout. The full buffer readout is not yet > supported. Also, currently only the first active channel is actually > read out by the driver, regardless of which probes are requested. As I mentioned at the congress, I have the feeling we need to do something similar for all such devices. The Rigol enforces this with the two buffer sizes being so directly related to continuous and single capture mode, respectively -- and the larger buffer size is not that usable for continuous display. But not everything is like that: the Hanteks DSO-2xxx/5xxx need manual trigger re-arming after every frame, and there's another one I'm working on that does the same. I'm thinking it would be best to mark some particular mode/buffersize as "default" for a frontend to use as a continuous display, and a deeper buffer selectable as one of the options. This will mesh with the Rigol obviously, but also be a reasonable default for other scopes. Joel, any opinions on this? This will come up in Pulseview soon enough. > - The hardware scan routine needs to be tamed. It should find a Rigol > DS1xx2 if you have one plugged in, but it will also grab any other > usbtmc device that responds to an "*IDN?" query. This is easy to fix > but will have to wait till I have a device handy again. So that makes the Rigol DS1052E, DS1102E, and Uwe's Siglent SDG1010. Here's the key question: does anyone on the list have (access to) any more USBTMC devices? We could really use some wider testing. > - Data readout in this protocol is on a per-channel basis, rather than > interleaved samples from all channels at once. However libsigrok > expects interleaved samples. I can interleave the data in the feed of > course, but that seems wasteful if subsequent code is just going to > de-interleave it again. Is it practical, or desirable, to support > uninterleaved data (with new metadata indicating the arrangement)? To summarize the discussion: some devices send all channels to the driver interleaved (Hantek), some send one channel at a time (Rigol). You're absolutely right in that there's no point in interleaving this data if the frontend just has to de-interleave again. We need to make this as easy for both the driver and the frontend to handle. Therefore I've come up with this: - We'll add a GSList of struct sr_probe to the sr_df_analog struct, which will contain a list of probes from which the data in the packet was obtained. The struct sr_probe are copies of the ones in the sdi, and the GSList itself can be freed, or indeed reused, by the driver after the packet is sent. The data is interleaved for those probes. - Drivers which receive the data from the hardware a probe at a time, like the Rigol, just send it in a packet that has only that one probe in this GSList. Thus they don't need to waste memory caching all kinds of data until all probes' samples have arrived, or waste cycles interleaving them. - Thus the frontend always deinterleaves in its processing loop, and doesn't need to worry about handling two different types of packets (IL/non-IL). It's simple enough to deinterleave, the analog output module does that now. Unless you have some existential problem with this, I'll implement it like that. > - Some of the hwcap settings (coupling and vdiv) apply to individual > probes rather than the device as a whole. I am applying the requested > settings to all probes for now, but obviously this isn't really the > right thing to be doing. How should these settings be supported > properly? That is indeed undecided, and incomplete in the hantek-dso driver. If you have ideas, let's hear them. -- Bert Vermeulen [email protected] email/xmpp ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
