From: Mathias G. <mg...@za...> - 2013-10-27 17:55:02
|
Hi everybody, Next thing I want to implement for the Rigol DS2xx2 driver is reading the sample memory. For that the scope has to be stopped. I think I will detect whether it's running or stopped and depending on that read the display memory or the sample memory. I think there is no way to specify that the device should be stopped or what memory to read? If multiple frames have been requested there are two possibilities: 1. Return an error because only one frame is available. 2. Read the data, then set the trigger to "single", let the scope acquire new data, read that and so on. Due to the large sample memory this could result in quite large datasets though. What do you think makes sense? Thank you, MGri |
From: Martin L. <mar...@ea...> - 2013-11-01 11:45:16
|
Hi Mathias, I think that the correct way to drive these scopes from sigrok is going to be to stop the scope and use single triggering. Otherwise we will run into all sorts of issues as you've already seen with e.g. partial data, channels not from the same acquisition, etc. The protocol implemented by the Rigols simply doesn't make it possible to read data while they're running and know anything much about when it is from. The implementation I did in the DS1xx2 driver, which just lets the scope run freely and reads whatever it gets, was a quick and dirty hack just to get something working. Now that you've implemented waiting for a trigger, it's straightforward for us to get the driver to stop the scope, set the trigger condition, read out a frame once triggered and then repeat as many times as frames are requested. This is consistent with how every other supported device is used, as I understand things. I don't know what Rigol's own Windows UI software does; it would be interesting to capture this somehow just in case it knows some undocumented tricks. But I guess it just continuously reads data and splats it to the screen, and if channels are out of sync momentarily it doesn't really matter because they're being refreshed continually anyway. After the user stops the scope it can read the final waveforms out. It would be nice if sigrok could also support this sort of "live" operation, where the only thing we know about the timing of the data is that it's recent and should be displayed immediately. But I think this would need to be explicitly requested somehow, because it's not what any of the current tools expect. Martin On Sun, Oct 27, 2013 at 05:49:40PM +0100, Mathias Grimmberger wrote: > > > Hi everybody, > > Next thing I want to implement for the Rigol DS2xx2 driver is reading > the sample memory. > > For that the scope has to be stopped. > > I think I will detect whether it's running or stopped and depending on > that read the display memory or the sample memory. I think there is no > way to specify that the device should be stopped or what memory to read? > > If multiple frames have been requested there are two possibilities: > > 1. Return an error because only one frame is available. > > 2. Read the data, then set the trigger to "single", let the scope > acquire new data, read that and so on. Due to the large sample memory > this could result in quite large datasets though. > > What do you think makes sense? > > > Thank you, > > MGri > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > sigrok-devel mailing list > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel > |
From: Mathias G. <mg...@za...> - 2013-11-01 20:08:44
|
Hi Martin, Martin Ling writes: > Hi Mathias, > > I think that the correct way to drive these scopes from sigrok is going > to be to stop the scope and use single triggering. What I implemented now is to recognize whether the scope is already stopped and decide from that. We don't have the capability to completely configure the thing anyway, so may as well take some hints from how the user has set up the device. Complete configurability should wait for the LibreVISA version, there are just so many options I don't think it's worth implementing everything twice. [...] > I don't know what Rigol's own Windows UI software does; it would be > interesting to capture this somehow just in case it knows some > undocumented tricks. But I guess it just continuously reads data and > splats it to the screen, and if channels are out of sync momentarily > it doesn't really matter because they're being refreshed continually > anyway. After the user stops the scope it can read the final waveforms > out. AFAIK the software uses the NIVISA runtime. NIVISA should come with a nifty tool called "nispy.exe" or similar - it does what the name suggests. No such luck for the DS2000 series, Rigol doesn't have a Windows software for these. > It would be nice if sigrok could also support this sort of "live" > operation, where the only thing we know about the timing of the data is > that it's recent and should be displayed immediately. But I think this > would need to be explicitly requested somehow, because it's not what any > of the current tools expect. Would what I explained above, i.e. using the state of the scope when recognizing the device (or maybe when starting the capture, makes a difference for pulseview?) be OK? MGri |
From: Martin L. <mar...@ea...> - 2013-11-01 22:46:06
|
On Fri, Nov 01, 2013 at 08:36:53PM +0100, Mathias Grimmberger wrote: > > What I implemented now is to recognize whether the scope is already > stopped and decide from that. We don't have the capability to completely > configure the thing anyway, so may as well take some hints from how the > user has set up the device. Complete configurability should wait for the > LibreVISA version, there are just so many options I don't think it's > worth implementing everything twice. The change to using librevisa isn't going to affect the driver code much, it's just the transport. Basically rigol_ds_send will switch to using librevisa to send its messages and the serial_read calls will be replaced with some other librevisa call. But the content of the protocol will be the same, so things implemented now will not be wasted. > AFAIK the software uses the NIVISA runtime. NIVISA should come with a > nifty tool called "nispy.exe" or similar - it does what the name > suggests. It I think that will show the higher level queries made to the driver, I'd be more interested in what it's actually sending on the wire to the device. But I may give it a try at some point. > > It would be nice if sigrok could also support this sort of "live" > > operation, where the only thing we know about the timing of the data is > > that it's recent and should be displayed immediately. But I think this > > would need to be explicitly requested somehow, because it's not what any > > of the current tools expect. > > Would what I explained above, i.e. using the state of the scope when > recognizing the device (or maybe when starting the capture, makes a > difference for pulseview?) be OK? I think the use cases are as follows: 1. Batch / offline tools e.g. sigrok-cli, custom python scripts, etc. These are currently really expecting to be the sole user of a device that is initially in some idle state. They set up the device as desired for a capture, do the capture, and expect meaningful data. For these we want to first stop the scope, and then run single-trigger captures for as many frames as desired, to be sure we're always getting a complete coherent frame. This should be the default behaviour and should not depend on whether the scope is initially running or stopped. These tools should be usable unattended with consistent results. 2. GUI tools that don't provide a continuously updating display, e.g. current versions of PulseView. Basically these should be handled as for 1. 3. GUI tools that provide a continuously updating display (none yet existing but I would like to write one!) These should explicitly request that they are willing to accept "live" data which is for immediate display but does not have a well-defined relationship to any individual frame or trigger event. This will require some new API in libsigrok, I think. For this case, the current state of the device could be used to decide whether the tool starts up running or stopped by default. But I think that's the only time when we should care about that. Martin |
From: Mathias G. <mg...@za...> - 2013-11-02 20:15:14
|
Hi Martin, Martin Ling writes: > On Fri, Nov 01, 2013 at 08:36:53PM +0100, Mathias Grimmberger wrote: > > > > What I implemented now is to recognize whether the scope is already > > stopped and decide from that. We don't have the capability to completely > > configure the thing anyway, so may as well take some hints from how the > > user has set up the device. Complete configurability should wait for the > > LibreVISA version, there are just so many options I don't think it's > > worth implementing everything twice. > > The change to using librevisa isn't going to affect the driver code > much, it's just the transport. Basically rigol_ds_send will switch to > using librevisa to send its messages and the serial_read calls will be > replaced with some other librevisa call. But the content of the protocol > will be the same, so things implemented now will not be wasted. Ah, OK, didn't understand that. > > AFAIK the software uses the NIVISA runtime. NIVISA should come with a > > nifty tool called "nispy.exe" or similar - it does what the name > > suggests. > > It I think that will show the higher level queries made to the driver, > I'd be more interested in what it's actually sending on the wire to the > device. But I may give it a try at some point. Yes, it will show the VISA calls. To see the wire stuff you could sniff USB, Wireshark on Linux can do this AFAIK, should work with the Windows SW inside something like VMware Player. For RS232 I don't know, but certainly some way must exist. MGri |
From: Joel H. <jo...@ai...> - 2013-11-02 10:59:25
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > 3. GUI tools that provide a continuously updating display (none > yet existing but I would like to write one!) I plan this for PulseView. Though I didn't expect there would be a problem with getting the full data of each sweep. I've been wanting to do digital phosphor, but with a time machine type thing that allows you to step back to viewing earlier sweeps. Still, I do think there's a place to have something different, maybe something like QtDSO in the sigrok ecosystem. Joel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSdMvKAAoJEP98VB76lN3ZLkwIAKDAcgBMo3ObJxQU7grzRjo0 W3Z9najDAU/6GsTbZdgebJFK0tFVda8rJNy1xdLRgjHTMMHtDhlf/r6vGzVrWDb/ Hh/i6vS7TttQKUBxpOWUU2ud9jFynZrSIWiudx06isAFkHhorA2iMh5EcAyk/taN GwRwOxCuEGsv7MOXKN6gvirxhAlOGKEipEqnO6vZUFMYDkwW4DyZCYcqRin36HWu YezP0v4NIJsqX61wnSFF/XeM5Ab24qMauALi9zCOJWSZXqyZIb+MT56A40qxuitX tZ+ou3P4iyoi3DdgJHbCToM8WsFQiAzI74BWiIXbyXJ8pjJqGE4MBjibZbfolgI= =cn47 -----END PGP SIGNATURE----- |
From: Peter S. <pe...@st...> - 2013-11-02 12:34:32
|
Joel Holdsworth wrote: > I've been wanting to do digital phosphor https://sdr.osmocom.org/trac/wiki/fosphor http://youtu.be/mjD-l3GAghU //Peter |
From: Martin L. <mar...@ea...> - 2013-11-02 17:53:58
|
On Sat, Nov 02, 2013 at 09:54:18AM +0000, Joel Holdsworth wrote: > > > 3. GUI tools that provide a continuously updating display (none > > yet existing but I would like to write one!) > > I plan this for PulseView. Though I didn't expect there would be a > problem with getting the full data of each sweep. Yeah, that's the fundamental issue here at least with the Rigols. When the scope is running, it's triggering and updating of its own accord, and all you can do on the wire is ask for what's on the screen right now for each channel, one channel at a time. So there's no way to guarantee that you're getting a coherent set of data for a single sweep, unless you stop the scope first and then read out. > I've been wanting to do digital phosphor, but with a time machine type > thing that allows you to step back to viewing earlier sweeps. Digital phosphor would be fine in the "live" mode, but you wouldn't reliably be able to go back through individual sweeps. To do that you'd need to have run the capture in the start-wait-stop-read way. > Still, I do think there's a place to have something different, maybe > something like QtDSO in the sigrok ecosystem. That's the sort of tool I've been meaning to bash out at some point, probably in python using the bindings. Not so much as a finished product but more just as an experiment - I'd be quite happy to see all the functionality just rolled into pulseview eventually. Martin |