Products > Test Equipment
Open source lxi-tools and liblxi v1.0 released for GNU/Linux
Hydron:
The live view/control is VERY fast, e.g. see this video:
(skip to 50 min for a nice display of a swept function gen)
Unfortunately the UI could do with some speed improvements, especially when using lots of functions and channels simultaneously (and this is reflected in the LXI numbers as well). While it has a 1Gbit Ethernet interface, I don't think this has much effect as the bottleneck is not the connection (linked video is via WiFi access point I think). It's a shame as otherwise you could do some cool things with 1Gbit of network bandwidth (e.g. 10s of MSa/s streaming, or fast data capture/manipulation on PC). Hopefully manufacturers will start to improve in this area.
lundmar:
--- Quote from: Hydron on February 07, 2018, 05:58:22 pm ---The live view/control is VERY fast, e.g. see this video:
(skip to 50 min for a nice display of a swept function gen)
Unfortunately the UI could do with some speed improvements, especially when using lots of functions and channels simultaneously (and this is reflected in the LXI numbers as well). While it has a 1Gbit Ethernet interface, I don't think this has much effect as the bottleneck is not the connection (linked video is via WiFi access point I think). It's a shame as otherwise you could do some cool things with 1Gbit of network bandwidth (e.g. 10s of MSa/s streaming, or fast data capture/manipulation on PC). Hopefully manufacturers will start to improve in this area.
--- End quote ---
That looks like a very nice and responsive web live control interface. The update rate must be 24 fps or more and I bet that the video feed is hardware encoded and streamed via RTSP or similar protocol. Every scope should do this :)
Hydron:
I haven't looked properly into how they're doing it, but I don't think it's a hardware encoded video - everything is FPGA based internally so there's no hard IP blocks to do something like that (and no evidence of video encoding artifacts). I've attached the web page source and the "screencam.js" client side code incase it's of interest (the other javascript used is some standard library by the looks of it). I had to add .txt extension because of forum limitation.
lundmar:
--- Quote from: Hydron on February 07, 2018, 06:38:58 pm ---I haven't looked properly into how they're doing it, but I don't think it's a hardware encoded video - everything is FPGA based internally so there's no hard IP blocks to do something like that (and no evidence of video encoding artifacts). I've attached the web page source and the "screencam.js" client side code incase it's of interest (the other javascript used is some standard library by the looks of it). I had to add .txt extension because of forum limitation.
--- End quote ---
Ahh, I see. They are simply retrieving the image data directly from the webserver via HTTP requests:
"XMLHttpRequest;c.open("GET","/screenshot?img="+b+"&key="+vm,!0);c.setRequestHeader("Cache-Control","no-cache");..."
I can't tell from the code but the image format is likely just raw bitmap.
Inspired by this, I went ahead and reconfigured the R&S screenshot plugin to BMP. Feel free to test and see if it is faster than before :)
Hydron:
I tried to "refresh" the snap version to test, it reported that it was already up to date. Should I remove the snap version and clone/build the git repo?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version