EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: MerseyViking on March 24, 2015, 12:16:18 pm
-
Hi,
I took delivery of my shiny new Rigol DS1054Z the other day, and being a programmer first, ee second, I decided to see if I could get some data out of the 'scope and on to my Android phone. My main motivation was curiosity, but I justified it to myself by thinking that if the DUT is in an awkward place relative to the 'scope, and moving your body to better see the 'scope could move the probes, a remote display would be useful.
So, I tinkered around at the weekend and came up with Scoperoid! The code is open source and can be found here: https://github.com/MerseyViking/scoperoid
And this is it in action:
(https://pbs.twimg.com/media/CAtU-0ZXIAALKQi.jpg:large)
And a screenshot:
(https://pbs.twimg.com/media/CAtU8SfWQAEXDP8.png:large)
It pulls the data off via USB, but I am considering playing around with the Ethernet port so I can use WiFi. Check out the readme on the github page for some more information.
So would people find this sort of thing useful? I don't plan on it competing with marmad's excellent UltraVision Utilities (unless someone pays me of course ;) ), it's just a bit of fun at the moment, and not ready for prime-time.
On a related note, has anyone played around with the USBTMC commands on a Rigol? There's a command for setting the RUN/STOP mode, but I can't for the life of me find a command to query the state. PEBKAC or Rigolian oversight?
-
Seriously cool! Even just for the "fun factor". I'll let you develop it a bit further before I try it out on the MSO.
McBryce.
-
Very nice!
(And the DS1054Z continues to impress with it's abilities...)
-
What if this would work via Ethernet... ;)
I see this is already on your to-do list. :-+
-
Very (very) nice!
(And the DS1054Z continues to impress with it's abilities...)
-
Peter, you're a genius! Thank you.
What if this would work via Ethernet... ;)
I see this is already on your to-do list. :-+
Indeed, Ethernet would solve all my USB woes and hacks. It may well introduce TCP/IP woes of course, but I'm more familiar with those :)
-JD
-
Now that's 8). I'd definitely use something like that.
-
I vote Ethernet/Wifi as well. Then we can work on an iOS version.
-
Google will figure out a way to put ads on the display :p
-
After a bit of poking around, pulling data off the scope over Ethernet is pretty easy. I wrote a little Python script to see how quick it is, and the answer is "not very but probably sufficient". Getting channel 1's data over WiFi gave me about 26kb/s which amounts to a frame rate of ~22fps. Getting all four channels drops that down to ~7fps. This may change when I use the Android network code though.
So with an unexpectedly and mostly free weekend coming up, expect Scoperoid to be enhanced.
I shall write up my findings on the github page so if anyone fancies doing an iOS version there will be a starting point.
-
This is really cool! Nice work :)
-
Very cool! :-+ Definitely going to hack with this too. Never knew the USB/WIFI bits could work without VISA.
Another idea I have is to make additional controls/shortcuts for the scope. Think pinch to zoom, etc.
-
Very Nice!
I suggest you to put something like a PayPal Donate button somewhere, your work deserve it.
-
Very Nice!
I suggest you to put something like a PayPal Donate button somewhere, your work deserve it.
Not always a good idea. I had to stop it on a small Android app I did, as Paypal was charging way too much and I had to join a another bank to get the money out and then with even more fee.
Oddly, years later people still send me donations (beers) without the link even being in the app :D
-
For now I am happy to have it out there for free (as in beer) as well as libre to encourage community involvement (or let it die if there's not enough interest). If it does get popular, I would put it on the PlayStore for a modest price and never have adverts (although is having the Rigol logo on it considered advertising? :)) Either way, the code will always stay open source.
-
Well what a weekend of frustration!
Getting the 'scope's IP address and port for sending SCPI commands was quite straightforward thanks to it's Zeroconf interface. What was frustrating was that I could send commands, but much of the time they failed, or at least the query commands did. It seems to be fairly arbitrary, and might be to do with timing, but putting in various delays between commands only made it fail slightly less often. I have put in a support ticket to Rigol, but as I know this board is frequented by people far cleverer than me, any one out there have idea what I'm doing wrong?
For instance, if I send the following command sequence:
*RST
<sleep for a few seconds>
*CLS;*SRE 0;*ESE 0;*OPC?
<wait for data to be received>
:WAV:MODE NORM
:WAV:PRE?
<wait for data to be received>
The scope returns "command error", and querying the error with:
:SYST:ERR?
Sometimes gives me "command error" or sometimes a -410,"Query INTERRUPTED"
Putting a *OPC? command after :WAV:MODE NORM (either in-line or as a separate command) makes no difference.
A -410 error implies there is a previous response waiting for me to consume before querying again, or that I am issuing a second query before the first has been completed. But I wait with a nice big buffer after every query, and I still get the "command error" response.
I have tried it with TCP_NODELAY enabled and disabled, big receive buffers, and all manner of futzing about to get at least a consistent response. Sending the same command sequence over USB caused no problems, so I'm assuming it's something to do with the 'scope's interface between its internal command queue and its TCP/IP stack, or a PEBKAC. :-BROKE
-
Hello MerseyViking
Really cool work! :-+ :-+ I'll try this out soon!
Are you able to read more than 489 samples from the scope over USB? I was unable to read more than 489 with sigrok. I am not sure if this is an issue with the scope or with sigrok (or both, perhaps).
-
Thanks aveekbh
I had no trouble with USB getting all 1200 samples at a frame rate of >100 fps. I've not looked at sigrok to see how it's doing it though. My method was just to bang requests to the scope as fast as possible and it responded with little difficulty.
-
Hi MerseyViking,
Did you ever get a reply from Rigol about the TCP "command error" problem?
I get the same behaviour from a C# client over TcpClient or direct socket. Very frustrating.
-
Well what a weekend of frustration!
Getting the 'scope's IP address and port for sending SCPI commands was quite straightforward thanks to it's Zeroconf interface. What was frustrating was that I could send commands, but much of the time they failed, or at least the query commands did. It seems to be fairly arbitrary, and might be to do with timing, but putting in various delays between commands only made it fail slightly less often. I have put in a support ticket to Rigol, but as I know this board is frequented by people far cleverer than me, any one out there have idea what I'm doing wrong?
For instance, if I send the following command sequence:
*RST
<sleep for a few seconds>
*CLS;*SRE 0;*ESE 0;*OPC?
<wait for data to be received>
:WAV:MODE NORM
:WAV:PRE?
<wait for data to be received>
The scope returns "command error", and querying the error with:
:SYST:ERR?
Sometimes gives me "command error" or sometimes a -410,"Query INTERRUPTED"
Putting a *OPC? command after :WAV:MODE NORM (either in-line or as a separate command) makes no difference.
A -410 error implies there is a previous response waiting for me to consume before querying again, or that I am issuing a second query before the first has been completed. But I wait with a nice big buffer after every query, and I still get the "command error" response.
I have tried it with TCP_NODELAY enabled and disabled, big receive buffers, and all manner of futzing about to get at least a consistent response. Sending the same command sequence over USB caused no problems, so I'm assuming it's something to do with the 'scope's interface between its internal command queue and its TCP/IP stack, or a PEBKAC. :-BROKE
I don't know if it helps or not, but I had noticed that my Scope Cam script was doing the same thing. Just hanging. I tried an experiment and just emptied any data left over after I was done. Since I'm a script I just did:
nc -w 5 rigollan.local 5555 # attempt to stop lock up?
Basically a 5 second drain of the port (remember, I'm not streaming so...)
After nearly 2 hours it is still kicking over. BTW, that's my Android solution: put it on a web server and look at it on a web page ;-)